Re: [RFC PATCH 04/11] smb/server: watch directories for changes

Namjae Jeon <[email protected]> Sat, 25 Jul 2026 22:44:13 +0900
Newsgroups org.kernel.vger.linux-cifs
Message-ID <CAKYAXd9Oc3YbYaHDjs5_r9Uz=dcWy=JR49wYVhOhnA2MP3UC=A@mail.gmail.com>
> +static struct fsnotify_mark *
> +ksmbd_notify_add_mark(struct ksmbd_notify *notify, u32 mask,
> +                     struct fsnotify_group **group)
> +{
> +       struct ksmbd_notify_mark *notify_mark;
> +       int err;
> +
> +       *group = fsnotify_alloc_group(&ksmbd_notify_fsnotify_ops, 0);
> +       if (IS_ERR(*group)) {
> +               pr_err("Failed to allocate fsnotify group: %ld\n",
> +                      PTR_ERR(*group));
> +               return ERR_CAST(*group);
> +       }
> +
> +       notify_mark = kzalloc_obj(*notify_mark, KSMBD_DEFAULT_GFP);
> +       if (!notify_mark) {
> +               pr_err("Failed to allocate fsnotify mark\n");
> +               err = -ENOMEM;
> +               goto err_put_group;
> +       }
> +
> +       notify_mark->notify = notify;
> +       fsnotify_init_mark(&notify_mark->mark, *group);
> +       notify_mark->mark.mask = mask | FS_EVENT_ON_CHILD;
Where is SMB2_WATCH_TREE handled?
FS_EVENT_ON_CHILD only reports events for immediate children of this
inode. it does not recursively monitor descendants.

>  static struct ksmbd_file *
>  ksmbd_notify_validate_req(struct ksmbd_work *work,
>                           struct smb2_change_notify_req *req,
> @@ -88,10 +270,40 @@ ksmbd_notify_validate_req(struct ksmbd_work *work,
>         return ERR_PTR(err);
>  }
>
> +static struct ksmbd_notify *
> +ksmbd_notify_setup_watch(struct ksmbd_file *fp,
> +                        struct smb2_change_notify_req *req,
> +                        struct smb2_change_notify_rsp *rsp)
> +{
> +       struct ksmbd_notify *notify;
> +       u32 filter, mask;
> +       int err;
> +
> +       filter = le32_to_cpu(req->CompletionFilter);
> +       mask = ksmbd_notify_map(filter);
> +       if (!mask) {
Please do not reject a CompletionFilter merely because no currently
mapped bit remains.
If no valid bits remain, the request must stay pending until it is
cancelled or the directory handle is closed.
Also, the mapping currently omits valid filter bits such as
FILE_NOTIFY_CHANGE_SIZE, FILE_NOTIFY_CHANGE_CREATION, and the
stream-related filters. Those need either implementation or explicitly
correct handling according to the protocol requirements.