On Wed, Mar 22, 2023 at 9:43 PM Amol Dixit <amoldd@xxxxxxxxx> wrote: > > On Wed, Mar 22, 2023 at 12:16 AM Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > > > On Wed, Mar 22, 2023 at 4:13 AM Amol Dixit <amoldd@xxxxxxxxx> wrote: > > > > > > Hello, > > > Apologies if this has been discussed or clarified in the past. > > > > > > The lack of file modification notification events (inotify, fanotify) > > > for mmap() regions is a big hole to anybody watching file changes from > > > userspace. I can imagine atleast 2 reasons why that support may be > > > lacking, perhaps there are more: > > > > > > 1. mmap() writeback is async (unless msync/fsync triggered) driven by > > > file IO and page cache writeback mechanims, unlike write system calls > > > that get funneled via the vfs layer, whih is a convenient common place > > > to issue notifications. Now mm code would have to find a common ground > > > with filesystem/vfs, which is messy. > > > > > > 2. writepages, being an address-space op is treated by each file > > > system independently. If mm did not want to get involved, onus would > > > be on each filesystem to make their .writepages handlers notification > > > aware. This is probably also considered not worth the trouble. > > > > > > So my question is, notwithstanding minor hurdles (like lost events, > > > hardlinks etc.), would the community like to extend inotify support > > > for mmap'ed writes to files? Under configs options, would a fix on a > > > per filesystem basis be an acceptable solution (I can start with say > > > ext4 writepages linking back to inode/dentry and firing a > > > notification)? > > > > > > Eventually we will have larger support across the board and > > > inotify/fanotify can be a reliable tracking mechanism for > > > modifications to files. > > > > > > > What is the use case? > > Would it be sufficient if you had an OPEN_WRITE event? > > or if OPEN event had the O_ flags as an extra info to the event? > > I have a patch for the above and I personally find this information > > missing from OPEN events. > > > > Are you trying to monitor mmap() calls? write to an mmaped area? > > because writepages() will get you neither of these. > > OPEN events are not useful to track file modifications in real time, > although I can do see the usefulness of OPEN_WRITE events to track > files that can change. > > I am trying to track writes to mmaped area (as these are not notified > using inotify events). I wanted to ask the community of the > feasibility and usefulness of this. I had some design ideas of > tracking writes (using jbd commit callbacks for instance) in the > kernel, but to make it generic sprucing up the inotify interface is a > much better approach. > > Hope that provides some context. Not enough. For a given file mmaped writable by a process that is writing to that mapped memory all the time for a long time. What do you expect to happen? How many events? On first time write to a page? To the memory region? When dirty memory is written back to disk? You have mixed a lot of different things in your question. You need to be more specific about what the purpose of this monitoring is. >From all of the above, only MODIFY on mmap() call seems reasonable to me and MODIFY on first write to an mmaped area is something that we can consider if there is very good justification. FYI, the existing MODIFY events are from after the write system call modified the page cache and there is no guarantee about when writeback to disk is done. Thanks, Amir.
