On Tue, Mar 22, 2022 at 6:44 PM Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > > FYI, I've implemented the above and pushed to branch fan_evictable. > > Yes, I also changed the name of the flag to be more coherent with the > > documented behavior: > > > > fanotify: add support for "evictable" inode marks > > > > When an inode mark is created with flag FAN_MARK_EVICTABLE, it will not > > pin the marked inode to inode cache, so when inode is evicted from cache > > due to memory pressure, the mark will be lost. > > > > When an inode mark with flag FAN_MARK_EVICATBLE is updated without using > > this flag, the marked inode is pinned to inode cache. > > > > When an inode mark is updated with flag FAN_MARK_EVICTABLE but an > > existing mark already has the inode pinned, the mark update fails with > > error EEXIST. > > > > I also took care of avoiding direct reclaim deadlocks from fanotify_add_mark(). > > If you agree to the proposed UAPI I will post v2 patches. > > Jan, > > Before implementing your suggested solution, I wrote a test patch > that reproduces the deadlock. > It took me a while to get to a reproducible scenario and I ended up using > a debug feature called FAN_MARK_LARGE to get there. > > You can see the test patches at the tip of these kernel and ltp branches: > https://github.com/amir73il/linux/commits/fan_evictable > https://github.com/amir73il/ltp/commits/fan_evictable > > The question is how can we test this in release kernels? > Should we include FAN_MARK_LARGE as a hidden (admin only) > feature? Use sysctl knob to enable it? use an ioctl? something else? > I went for ioctl and I kind of like it like. Pushed. Thanks, Amir.
