#
d0e71e23 |
| 20-May-2024 |
Linus Torvalds <torvalds@linux-foundation.org> |
Revert "fanotify: remove unneeded sub-zero check for unsigned value"
This reverts commit e6595224464b692ddae193d783402130d1625147.
These kinds of patches are only making the code worse.
Compilers
Revert "fanotify: remove unneeded sub-zero check for unsigned value"
This reverts commit e6595224464b692ddae193d783402130d1625147.
These kinds of patches are only making the code worse.
Compilers don't care about the unnecessary check, but removing it makes the code less obvious to a human. The declaration of 'len' is more than 80 lines earlier, so a human won't easily see that 'len' is of an unsigned type, so to a human the range check that checks against zero is much more explicit and obvious.
Any tool that complains about a range check like this just because the variable is unsigned is actively detrimental, and should be ignored.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
show more ...
|
#
477cf917 |
| 17-Mar-2024 |
Amir Goldstein <amir73il@gmail.com> |
fsnotify: use an enum for group priority constants
And use meaningfull names for the constants.
Signed-off-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Jan Kara <jack@suse.cz> Message-Id:
fsnotify: use an enum for group priority constants
And use meaningfull names for the constants.
Signed-off-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Jan Kara <jack@suse.cz> Message-Id: <20240317184154.1200192-10-amir73il@gmail.com>
show more ...
|
#
687c217c |
| 17-Mar-2024 |
Amir Goldstein <amir73il@gmail.com> |
fsnotify: pass object pointer and type to fsnotify mark helpers
Instead of passing fsnotify_connp_t, pass the pointer to the marked object.
Store the object pointer in the connector and move the de
fsnotify: pass object pointer and type to fsnotify mark helpers
Instead of passing fsnotify_connp_t, pass the pointer to the marked object.
Store the object pointer in the connector and move the definition of fsnotify_connp_t to internal fsnotify subsystem API, so it is no longer used by fsnotify backends.
Suggested-by: Jan Kara <jack@suse.cz> Signed-off-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Jan Kara <jack@suse.cz> Message-Id: <20240317184154.1200192-6-amir73il@gmail.com>
show more ...
|
#
b5cae086 |
| 17-Mar-2024 |
Amir Goldstein <amir73il@gmail.com> |
fanotify: merge two checks regarding add of ignore mark
There are two similar checks for adding an ignore mark without FAN_MARK_IGNORED_SURV_MODIFY, one for the old FAN_MARK_IGNORED flag and one for
fanotify: merge two checks regarding add of ignore mark
There are two similar checks for adding an ignore mark without FAN_MARK_IGNORED_SURV_MODIFY, one for the old FAN_MARK_IGNORED flag and one for the new FAN_MARK_IGNORE flag.
Merge the two checks into a single location.
Signed-off-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Jan Kara <jack@suse.cz> Message-Id: <20240317184154.1200192-5-amir73il@gmail.com>
show more ...
|
#
e6595224 |
| 14-Mar-2024 |
Nikita Kiryushin <kiryushin@ancud.ru> |
fanotify: remove unneeded sub-zero check for unsigned value
Unsigned size_t len in copy_fid_info_to_user is checked for negative value. This check is redundant as it is always false.
Found by Linux
fanotify: remove unneeded sub-zero check for unsigned value
Unsigned size_t len in copy_fid_info_to_user is checked for negative value. This check is redundant as it is always false.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: 5e469c830fdb ("fanotify: copy event fid info to user") Signed-off-by: Nikita Kiryushin <kiryushin@ancud.ru> Signed-off-by: Jan Kara <jack@suse.cz> Message-Id: <d296ff1c-dcf7-4813-994b-3c4369debb7d@ancud.ru>
show more ...
|
#
9d5b9475 |
| 21-Nov-2023 |
Joel Granados <j.granados@samsung.com> |
fs: Remove the now superfluous sentinel elements from ctl_table array
This commit comes at the tail end of a greater effort to remove the empty elements at the end of the ctl_table arrays (sentinels
fs: Remove the now superfluous sentinel elements from ctl_table array
This commit comes at the tail end of a greater effort to remove the empty elements at the end of the ctl_table arrays (sentinels) which will reduce the overall build time size of the kernel and run time memory bloat by ~64 bytes per sentinel (further information Link : https://lore.kernel.org/all/ZO5Yx5JFogGi%2FcBo@bombadil.infradead.org/)
Remove sentinel elements ctl_table struct. Special attention was placed in making sure that an empty directory for fs/verity was created when CONFIG_FS_VERITY_BUILTIN_SIGNATURES is not defined. In this case we use the register sysctl call that expects a size.
Signed-off-by: Joel Granados <j.granados@samsung.com> Reviewed-by: Jan Kara <jack@suse.cz> Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> Acked-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
show more ...
|
#
30ad1938 |
| 30-Nov-2023 |
Amir Goldstein <amir73il@gmail.com> |
fanotify: allow "weak" fsid when watching a single filesystem
So far, fanotify returns -ENODEV or -EXDEV when trying to set a mark on a filesystem with a "weak" fsid, namely, zero fsid (e.g. fuse),
fanotify: allow "weak" fsid when watching a single filesystem
So far, fanotify returns -ENODEV or -EXDEV when trying to set a mark on a filesystem with a "weak" fsid, namely, zero fsid (e.g. fuse), or non-uniform fsid (e.g. btrfs non-root subvol).
When group is watching inodes all from the same filesystem (or subvol), allow adding inode marks with "weak" fsid, because there is no ambiguity regarding which filesystem reports the event.
The first mark added to a group determines if this group is single or multi filesystem, depending on the fsid at the path of the added mark.
If the first mark added has a "strong" fsid, marks with "weak" fsid cannot be added and vice versa.
If the first mark added has a "weak" fsid, following marks must have the same "weak" fsid and the same sb as the first mark.
Signed-off-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Jan Kara <jack@suse.cz> Message-Id: <20231130165619.3386452-3-amir73il@gmail.com>
show more ...
|
#
7232522e |
| 30-Nov-2023 |
Amir Goldstein <amir73il@gmail.com> |
fanotify: store fsid in mark instead of in connector
Some filesystems like fuse and nfs have zero or non-unique fsid. We would like to avoid reporting ambiguous fsid in events, so we need to avoid m
fanotify: store fsid in mark instead of in connector
Some filesystems like fuse and nfs have zero or non-unique fsid. We would like to avoid reporting ambiguous fsid in events, so we need to avoid marking objects with same fsid and different sb.
To make this easier to enforce, store the fsid in the marks of the group instead of in the shared conenctor.
Signed-off-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Jan Kara <jack@suse.cz> Message-Id: <20231130165619.3386452-2-amir73il@gmail.com>
show more ...
|
#
66c62769 |
| 23-Oct-2023 |
Amir Goldstein <amir73il@gmail.com> |
exportfs: add helpers to check if filesystem can encode/decode file handles
The logic of whether filesystem can encode/decode file handles is open coded in many places.
In preparation to changing t
exportfs: add helpers to check if filesystem can encode/decode file handles
The logic of whether filesystem can encode/decode file handles is open coded in many places.
In preparation to changing the logic, move the open coded logic into inline helpers.
Reviewed-by: Jan Kara <jack@suse.cz> Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Amir Goldstein <amir73il@gmail.com> Link: https://lore.kernel.org/r/20231023180801.2953446-2-amir73il@gmail.com Signed-off-by: Christian Brauner <brauner@kernel.org>
show more ...
|
#
97ac4897 |
| 18-Oct-2023 |
Amir Goldstein <amir73il@gmail.com> |
fanotify: limit reporting of event with non-decodeable file handles
Commit a95aef69a740 ("fanotify: support reporting non-decodeable file handles") merged in v6.5-rc1, added the ability to use an fa
fanotify: limit reporting of event with non-decodeable file handles
Commit a95aef69a740 ("fanotify: support reporting non-decodeable file handles") merged in v6.5-rc1, added the ability to use an fanotify group with FAN_REPORT_FID mode to watch filesystems that do not support nfs export, but do know how to encode non-decodeable file handles, with the newly introduced AT_HANDLE_FID flag.
At the time that this commit was merged, there were no filesystems in-tree with those traits.
Commit 16aac5ad1fa9 ("ovl: support encoding non-decodable file handles"), merged in v6.6-rc1, added this trait to overlayfs, thus allowing fanotify watching of overlayfs with FAN_REPORT_FID mode.
In retrospect, allowing an fanotify filesystem/mount mark on such filesystem in FAN_REPORT_FID mode will result in getting events with file handles, without the ability to resolve the filesystem objects from those file handles (i.e. no open_by_handle_at() support).
For v6.6, the safer option would be to allow this mode for inode marks only, where the caller has the opportunity to use name_to_handle_at() at the time of setting the mark. In the future we can revise this decision.
Fixes: a95aef69a740 ("fanotify: support reporting non-decodeable file handles") Signed-off-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Jan Kara <jack@suse.cz> Message-Id: <20231018100000.2453965-2-amir73il@gmail.com>
show more ...
|
#
68279f9c |
| 11-Oct-2023 |
Alexey Dobriyan <adobriyan@gmail.com> |
treewide: mark stuff as __ro_after_init
__read_mostly predates __ro_after_init. Many variables which are marked __read_mostly should have been __ro_after_init from day 1.
Also, mark some stuff as "
treewide: mark stuff as __ro_after_init
__read_mostly predates __ro_after_init. Many variables which are marked __read_mostly should have been __ro_after_init from day 1.
Also, mark some stuff as "const" and "__init" while I'm at it.
[akpm@linux-foundation.org: revert sysctl_nr_open_min, sysctl_nr_open_max changes due to arm warning] [akpm@linux-foundation.org: coding-style cleanups] Link: https://lkml.kernel.org/r/4f6bb9c0-abba-4ee4-a7aa-89265e886817@p183 Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
show more ...
|
#
69562eb0 |
| 29-Jun-2023 |
Amir Goldstein <amir73il@gmail.com> |
fanotify: disallow mount/sb marks on kernel internal pseudo fs
Hopefully, nobody is trying to abuse mount/sb marks for watching all anonymous pipes/inodes.
I cannot think of a good reason to allow
fanotify: disallow mount/sb marks on kernel internal pseudo fs
Hopefully, nobody is trying to abuse mount/sb marks for watching all anonymous pipes/inodes.
I cannot think of a good reason to allow this - it looks like an oversight that dated back to the original fanotify API.
Link: https://lore.kernel.org/linux-fsdevel/20230628101132.kvchg544mczxv2pm@quack3/ Fixes: 0ff21db9fcc3 ("fanotify: hooks the fanotify_mark syscall to the vfsmount code") Signed-off-by: Amir Goldstein <amir73il@gmail.com> Reviewed-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Jan Kara <jack@suse.cz> Message-Id: <20230629042044.25723-1-amir73il@gmail.com>
show more ...
|
#
a95aef69 |
| 02-May-2023 |
Amir Goldstein <amir73il@gmail.com> |
fanotify: support reporting non-decodeable file handles
fanotify users do not always need to decode the file handles reported with FAN_REPORT_FID.
Relax the restriction that filesystem needs to sup
fanotify: support reporting non-decodeable file handles
fanotify users do not always need to decode the file handles reported with FAN_REPORT_FID.
Relax the restriction that filesystem needs to support NFS export and allow reporting file handles from filesystems that only support ecoding unique file handles.
Even filesystems that do not have export_operations at all can fallback to use the default FILEID_INO32_GEN encoding, but we use the existence of export_operations as an indication that the encoded file handles will be sufficiently unique and that user will be able to compare them to filesystem objects using AT_HANDLE_FID flag to name_to_handle_at(2).
For filesystems that do not support NFS export, users will have to use the AT_HANDLE_FID of name_to_handle_at(2) if they want to compare the object in path to the object fid reported in an event.
Signed-off-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Jan Kara <jack@suse.cz> Message-Id: <20230502124817.3070545-5-amir73il@gmail.com>
show more ...
|
#
eee3a0e9 |
| 27-Mar-2023 |
Christian Brauner <brauner@kernel.org> |
fanotify: use pidfd_prepare()
We generally try to avoid installing a file descriptor into the caller's file descriptor table just to close it again via close_fd() in case an error occurs. Instead we
fanotify: use pidfd_prepare()
We generally try to avoid installing a file descriptor into the caller's file descriptor table just to close it again via close_fd() in case an error occurs. Instead we reserve a file descriptor but don't install it into the caller's file descriptor table yet. If we fail for other, unrelated reasons we can just close the reserved file descriptor and if we make it past all meaningful error paths we just install it. Fanotify gets this right already for one fd type but not for pidfds.
Use the new pidfd_prepare() helper to reserve a pidfd and a pidfd file and switch to the more common fd allocation and installation pattern.
Acked-by: Jan Kara <jack@suse.cz> Message-Id: <20230327-pidfd-file-api-v1-3-5c0e9a3158e4@kernel.org> Signed-off-by: Christian Brauner <brauner@kernel.org>
show more ...
|
#
70529a19 |
| 03-Feb-2023 |
Richard Guy Briggs <rgb@redhat.com> |
fanotify: define struct members to hold response decision context
This patch adds a flag, FAN_INFO and an extensible buffer to provide additional information about response decisions. The buffer co
fanotify: define struct members to hold response decision context
This patch adds a flag, FAN_INFO and an extensible buffer to provide additional information about response decisions. The buffer contains one or more headers defining the information type and the length of the following information. The patch defines one additional information type, FAN_RESPONSE_INFO_AUDIT_RULE, to audit a rule number. This will allow for the creation of other information types in the future if other users of the API identify different needs.
The kernel can be tested if it supports a given info type by supplying the complete info extension but setting fd to FAN_NOFD. It will return the expected size but not issue an audit record.
Suggested-by: Steve Grubb <sgrubb@redhat.com> Link: https://lore.kernel.org/r/2745105.e9J7NaK4W3@x2 Suggested-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20201001101219.GE17860@quack2.suse.cz Tested-by: Steve Grubb <sgrubb@redhat.com> Acked-by: Steve Grubb <sgrubb@redhat.com> Signed-off-by: Richard Guy Briggs <rgb@redhat.com> Signed-off-by: Jan Kara <jack@suse.cz> Message-Id: <10177cfcae5480926b7176321a28d9da6835b667.1675373475.git.rgb@redhat.com>
show more ...
|
#
2e0a5471 |
| 03-Feb-2023 |
Richard Guy Briggs <rgb@redhat.com> |
fanotify: Ensure consistent variable type for response
The user space API for the response variable is __u32. This patch makes sure that the whole path through the kernel uses u32 so that there is n
fanotify: Ensure consistent variable type for response
The user space API for the response variable is __u32. This patch makes sure that the whole path through the kernel uses u32 so that there is no sign extension or truncation of the user space response.
Suggested-by: Steve Grubb <sgrubb@redhat.com> Link: https://lore.kernel.org/r/12617626.uLZWGnKmhe@x2 Signed-off-by: Richard Guy Briggs <rgb@redhat.com> Acked-by: Paul Moore <paul@paul-moore.com> Tested-by: Steve Grubb <sgrubb@redhat.com> Acked-by: Steve Grubb <sgrubb@redhat.com> Signed-off-by: Jan Kara <jack@suse.cz> Message-Id: <3778cb0b3501bc4e686ba7770b20eb9ab0506cf4.1675373475.git.rgb@redhat.com>
show more ...
|
#
d5bf8889 |
| 04-Aug-2022 |
Al Viro <viro@zeniv.linux.org.uk> |
fs/notify: constify path
Reviewed-by: Matthew Bobrowski <repnop@google.com> Reviewed-by: Christian Brauner (Microsoft) <brauner@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
#
e252f2ed |
| 29-Jun-2022 |
Amir Goldstein <amir73il@gmail.com> |
fanotify: introduce FAN_MARK_IGNORE
This flag is a new way to configure ignore mask which allows adding and removing the event flags FAN_ONDIR and FAN_EVENT_ON_CHILD in ignore mask.
The legacy FAN_
fanotify: introduce FAN_MARK_IGNORE
This flag is a new way to configure ignore mask which allows adding and removing the event flags FAN_ONDIR and FAN_EVENT_ON_CHILD in ignore mask.
The legacy FAN_MARK_IGNORED_MASK flag would always ignore events on directories and would ignore events on children depending on whether the FAN_EVENT_ON_CHILD flag was set in the (non ignored) mask.
FAN_MARK_IGNORE can be used to ignore events on children without setting FAN_EVENT_ON_CHILD in the mark's mask and will not ignore events on directories unconditionally, only when FAN_ONDIR is set in ignore mask.
The new behavior is non-downgradable. After calling fanotify_mark() with FAN_MARK_IGNORE once, calling fanotify_mark() with FAN_MARK_IGNORED_MASK on the same object will return EEXIST error.
Setting the event flags with FAN_MARK_IGNORE on a non-dir inode mark has no meaning and will return ENOTDIR error.
The meaning of FAN_MARK_IGNORED_SURV_MODIFY is preserved with the new FAN_MARK_IGNORE flag, but with a few semantic differences:
1. FAN_MARK_IGNORED_SURV_MODIFY is required for filesystem and mount marks and on an inode mark on a directory. Omitting this flag will return EINVAL or EISDIR error.
2. An ignore mask on a non-directory inode that survives modify could never be downgraded to an ignore mask that does not survive modify. With new FAN_MARK_IGNORE semantics we make that rule explicit - trying to update a surviving ignore mask without the flag FAN_MARK_IGNORED_SURV_MODIFY will return EEXIST error.
The conveniene macro FAN_MARK_IGNORE_SURV is added for (FAN_MARK_IGNORE | FAN_MARK_IGNORED_SURV_MODIFY), because the common case should use short constant names.
Link: https://lore.kernel.org/r/20220629144210.2983229-4-amir73il@gmail.com Signed-off-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Jan Kara <jack@suse.cz>
show more ...
|
#
8afd7215 |
| 29-Jun-2022 |
Amir Goldstein <amir73il@gmail.com> |
fanotify: cleanups for fanotify_mark() input validations
Create helper fanotify_may_update_existing_mark() for checking for conflicts between existing mark flags and fanotify_mark() flags.
Use vari
fanotify: cleanups for fanotify_mark() input validations
Create helper fanotify_may_update_existing_mark() for checking for conflicts between existing mark flags and fanotify_mark() flags.
Use variable mark_cmd to make the checks for mark command bits cleaner.
Link: https://lore.kernel.org/r/20220629144210.2983229-3-amir73il@gmail.com Signed-off-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Jan Kara <jack@suse.cz>
show more ...
|
#
31a371e4 |
| 29-Jun-2022 |
Amir Goldstein <amir73il@gmail.com> |
fanotify: prepare for setting event flags in ignore mask
Setting flags FAN_ONDIR FAN_EVENT_ON_CHILD in ignore mask has no effect. The FAN_EVENT_ON_CHILD flag in mask implicitly applies to ignore mas
fanotify: prepare for setting event flags in ignore mask
Setting flags FAN_ONDIR FAN_EVENT_ON_CHILD in ignore mask has no effect. The FAN_EVENT_ON_CHILD flag in mask implicitly applies to ignore mask and ignore mask is always implicitly applied to events on directories.
Define a mark flag that replaces this legacy behavior with logic of applying the ignore mask according to event flags in ignore mask.
Implement the new logic to prepare for supporting an ignore mask that ignores events on children and ignore mask that does not ignore events on directories.
To emphasize the change in terminology, also rename ignored_mask mark member to ignore_mask and use accessors to get only the effective ignored events or the ignored events and flags.
This change in terminology finally aligns with the "ignore mask" language in man pages and in most of the comments.
Link: https://lore.kernel.org/r/20220629144210.2983229-2-amir73il@gmail.com Signed-off-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Jan Kara <jack@suse.cz>
show more ...
|
#
8698e3ba |
| 27-Jun-2022 |
Amir Goldstein <amir73il@gmail.com> |
fanotify: refine the validation checks on non-dir inode mask
Commit ceaf69f8eadc ("fanotify: do not allow setting dirent events in mask of non-dir") added restrictions about setting dirent events in
fanotify: refine the validation checks on non-dir inode mask
Commit ceaf69f8eadc ("fanotify: do not allow setting dirent events in mask of non-dir") added restrictions about setting dirent events in the mask of a non-dir inode mark, which does not make any sense.
For backward compatibility, these restictions were added only to new (v5.17+) APIs.
It also does not make any sense to set the flags FAN_EVENT_ON_CHILD or FAN_ONDIR in the mask of a non-dir inode. Add these flags to the dir-only restriction of the new APIs as well.
Move the check of the dir-only flags for new APIs into the helper fanotify_events_supported(), which is only called for FAN_MARK_ADD, because there is no need to error on an attempt to remove the dir-only flags from non-dir inode.
Fixes: ceaf69f8eadc ("fanotify: do not allow setting dirent events in mask of non-dir") Link: https://lore.kernel.org/linux-fsdevel/20220627113224.kr2725conevh53u4@quack3.lan/ Link: https://lore.kernel.org/r/20220627174719.2838175-1-amir73il@gmail.com Signed-off-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Jan Kara <jack@suse.cz>
show more ...
|
#
dccd8557 |
| 22-May-2022 |
Vasily Averin <vvs@openvz.org> |
fanotify: fix incorrect fmode_t casts
Fixes sparce warnings: fs/notify/fanotify/fanotify_user.c:267:63: sparse: warning: restricted fmode_t degrades to integer fs/notify/fanotify/fanotify_user.c:13
fanotify: fix incorrect fmode_t casts
Fixes sparce warnings: fs/notify/fanotify/fanotify_user.c:267:63: sparse: warning: restricted fmode_t degrades to integer fs/notify/fanotify/fanotify_user.c:1351:28: sparse: warning: restricted fmode_t degrades to integer
FMODE_NONTIFY have bitwise fmode_t type and requires __force attribute for any casts.
Signed-off-by: Vasily Averin <vvs@openvz.org> Reviewed-by: Christian Brauner (Microsoft) <brauner@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/9adfd6ac-1b89-791e-796b-49ada3293985@openvz.org
show more ...
|
#
ceaf69f8 |
| 07-May-2022 |
Amir Goldstein <amir73il@gmail.com> |
fanotify: do not allow setting dirent events in mask of non-dir
Dirent events (create/delete/move) are only reported on watched directory inodes, but in fanotify as well as in legacy inotify, it was
fanotify: do not allow setting dirent events in mask of non-dir
Dirent events (create/delete/move) are only reported on watched directory inodes, but in fanotify as well as in legacy inotify, it was always allowed to set them on non-dir inode, which does not result in any meaningful outcome.
Until kernel v5.17, dirent events in fanotify also differed from events "on child" (e.g. FAN_OPEN) in the information provided in the event. For example, FAN_OPEN could be set in the mask of a non-dir or the mask of its parent and event would report the fid of the child regardless of the marked object. By contrast, FAN_DELETE is not reported if the child is marked and the child fid was not reported in the events.
Since kernel v5.17, with fanotify group flag FAN_REPORT_TARGET_FID, the fid of the child is reported with dirent events, like events "on child", which may create confusion for users expecting the same behavior as events "on child" when setting events in the mask on a child.
The desired semantics of setting dirent events in the mask of a child are not clear, so for now, deny this action for a group initialized with flag FAN_REPORT_TARGET_FID and for the new event FAN_RENAME. We may relax this restriction in the future if we decide on the semantics and implement them.
Fixes: d61fd650e9d2 ("fanotify: introduce group flag FAN_REPORT_TARGET_FID") Fixes: 8cc3b1ccd930 ("fanotify: wire up FAN_RENAME event") Link: https://lore.kernel.org/linux-fsdevel/20220505133057.zm5t6vumc4xdcnsg@quack3.lan/ Signed-off-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20220507080028.219826-1-amir73il@gmail.com
show more ...
|
#
5f9d3bd5 |
| 22-Apr-2022 |
Amir Goldstein <amir73il@gmail.com> |
fanotify: enable "evictable" inode marks
Now that the direct reclaim path is handled we can enable evictable inode marks.
Link: https://lore.kernel.org/r/20220422120327.3459282-17-amir73il@gmail.co
fanotify: enable "evictable" inode marks
Now that the direct reclaim path is handled we can enable evictable inode marks.
Link: https://lore.kernel.org/r/20220422120327.3459282-17-amir73il@gmail.com Signed-off-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Jan Kara <jack@suse.cz>
show more ...
|
#
e79719a2 |
| 22-Apr-2022 |
Amir Goldstein <amir73il@gmail.com> |
fanotify: use fsnotify group lock helpers
Direct reclaim from fanotify mark allocation context may try to evict inodes with evictable marks of the same group and hit this deadlock:
[<0>] fsnotify_d
fanotify: use fsnotify group lock helpers
Direct reclaim from fanotify mark allocation context may try to evict inodes with evictable marks of the same group and hit this deadlock:
[<0>] fsnotify_destroy_mark+0x1f/0x3a [<0>] fsnotify_destroy_marks+0x71/0xd9 [<0>] __destroy_inode+0x24/0x7e [<0>] destroy_inode+0x2c/0x67 [<0>] dispose_list+0x49/0x68 [<0>] prune_icache_sb+0x5b/0x79 [<0>] super_cache_scan+0x11c/0x16f [<0>] shrink_slab.constprop.0+0x23e/0x40f [<0>] shrink_node+0x218/0x3e7 [<0>] do_try_to_free_pages+0x12a/0x2d2 [<0>] try_to_free_pages+0x166/0x242 [<0>] __alloc_pages_slowpath.constprop.0+0x30c/0x903 [<0>] __alloc_pages+0xeb/0x1c7 [<0>] cache_grow_begin+0x6f/0x31e [<0>] fallback_alloc+0xe0/0x12d [<0>] ____cache_alloc_node+0x15a/0x17e [<0>] kmem_cache_alloc_trace+0xa1/0x143 [<0>] fanotify_add_mark+0xd5/0x2b2 [<0>] do_fanotify_mark+0x566/0x5eb [<0>] __x64_sys_fanotify_mark+0x21/0x24 [<0>] do_syscall_64+0x6d/0x80 [<0>] entry_SYSCALL_64_after_hwframe+0x44/0xae
Set the FSNOTIFY_GROUP_NOFS flag to prevent going into direct reclaim from allocations under fanotify group lock and use the safe group lock helpers.
Link: https://lore.kernel.org/r/20220422120327.3459282-16-amir73il@gmail.com Suggested-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20220321112310.vpr7oxro2xkz5llh@quack3.lan/ Signed-off-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Jan Kara <jack@suse.cz>
show more ...
|