With btrfs, a marked inode and marked sb may have a different fsid.
If both inode and sb are marked with a specific event type in mask,
report the more specific fsid (i.e. of the inode) in the event.
This is needed to support fanotify marks in btrfs sub-volumes.
Signed-off-by: Amir Goldstein <amir73il@xxxxxxxxx>
---
fs/notify/fanotify/fanotify.c | 2 ++
include/linux/fsnotify_backend.h | 5 +++--
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
index aff1ab3c32aa..3053606d7ff5 100644
--- a/fs/notify/fanotify/fanotify.c
+++ b/fs/notify/fanotify/fanotify.c
@@ -840,6 +840,8 @@ static struct fanotify_event *fanotify_alloc_event(
/*
* Get cached fsid of the filesystem containing the object from any mark.
* All marks are supposed to have the same fsid, but we do not verify that here.
+ * With btrfs, a marked inode and marked sb may have a different fsid.
+ * In this case, we will return the more specific fsid (i.e. of the inode).
*/
static __kernel_fsid_t fanotify_get_fsid(struct fsnotify_iter_info *iter_info)
{
diff --git a/include/linux/fsnotify_backend.h b/include/linux/fsnotify_backend.h
index a80b525ca653..f329375bef22 100644
--- a/include/linux/fsnotify_backend.h
+++ b/include/linux/fsnotify_backend.h
@@ -372,13 +372,14 @@ static inline struct fs_error_report *fsnotify_data_error_report(
* the other way around, because an event can match different watched objects
* of the same object type.
* For example, both parent and child are watching an object of type inode.
+ * The order of iteration is from most specific (inode) to most general (sb).
*/
enum fsnotify_iter_type {
FSNOTIFY_ITER_TYPE_INODE,
+ FSNOTIFY_ITER_TYPE_INODE2,
+ FSNOTIFY_ITER_TYPE_PARENT,
FSNOTIFY_ITER_TYPE_VFSMOUNT,
FSNOTIFY_ITER_TYPE_SB,
- FSNOTIFY_ITER_TYPE_PARENT,
- FSNOTIFY_ITER_TYPE_INODE2,
FSNOTIFY_ITER_TYPE_COUNT
};
--
2.34.1
