The patch titled
Subject: fallocate: create FAN_MODIFY and IN_MODIFY events
has been added to the -mm tree. Its filename is
fallocate-create-fan_modify-and-in_modify-events.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/fallocate-create-fan_modify-and-in_modify-events.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/fallocate-create-fan_modify-and-in_modify-events.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Heinrich Schuchardt <xypron.glpk@xxxxxx>
Subject: fallocate: create FAN_MODIFY and IN_MODIFY events
The fanotify and the inotify API can be used to monitor changes of the
file system. System call fallocate() modifies files. Hence it should
trigger the corresponding fanotify (FAN_MODIFY) and inotify (IN_MODIFY)
events. The most interesting case is FALLOC_FL_COLLAPSE_RANGE because
this value allows to create arbitrary file content from random data.
This patch adds the missing call to fsnotify_modify().
The FAN_MODIFY and IN_MODIFY event will be created when fallocate()
succeeds. It will even be created if the file length remains unchanged,
e.g. when calling fanotify with flag FALLOC_FL_KEEP_SIZE.
This logic was primarily chosen to keep the coding simple.
It resembles the logic of the write() system call.
When we call write() we always create a FAN_MODIFY event, even in the case
of overwriting with identical data.
Events FAN_MODIFY and IN_MODIFY do not provide any guarantee that data was
actually changed.
Furthermore even if if the filesize remains unchanged, fallocate() may
influence whether a subsequent write() will succeed and hence the
fallocate() call may be considered a modification.
The fallocate(2) man page teaches: After a successful call, subsequent
writes into the range specified by offset and len are guaranteed not to
fail because of lack of disk space.
So calling fallocate(fd, FALLOC_FL_KEEP_SIZE, offset, len) may result in
offset and len.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@xxxxxx>
Reviewed-by: Jan Kara <jack@xxxxxxx>
Cc: Jan Kara <jack@xxxxxxx>
Cc: Alexander Viro <viro@xxxxxxxxxxxxxxxxxx>
Cc: Eric Paris <eparis@xxxxxxxxxxxxxx>
Cc: John McCutchan <john@xxxxxxxxxxxxxxxxx>
Cc: Robert Love <rlove@xxxxxxxxx>
Cc: Michael Kerrisk <mtk.manpages@xxxxxxxxx>
Cc: Theodore Ts'o <tytso@xxxxxxx>
Cc: Dave Chinner <david@xxxxxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
fs/open.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff -puN fs/open.c~fallocate-create-fan_modify-and-in_modify-events fs/open.c
--- a/fs/open.c~fallocate-create-fan_modify-and-in_modify-events
+++ a/fs/open.c
@@ -295,6 +295,17 @@ int do_fallocate(struct file *file, int
sb_start_write(inode->i_sb);
ret = file->f_op->fallocate(file, mode, offset, len);
+
+ /*
+ * Create inotify and fanotify events.
+ *
+ * To keep the logic simple always create events if fallocate succeeds.
+ * This implies that events are even created if the file size remains
+ * unchanged, e.g. when using flag FALLOC_FL_KEEP_SIZE.
+ */
+ if (ret == 0)
+ fsnotify_modify(file);
+
sb_end_write(inode->i_sb);
return ret;
}
_
Patches currently in -mm which might be from xypron.glpk@xxxxxx are
fallocate-create-fan_modify-and-in_modify-events.patch
--
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
