> 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? Thanks, Amir.
