All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Jan Kara <jack@suse.cz>, Alexander Viro <viro@zeniv.linux.org.uk>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	Eric Paris <eparis@parisplace.org>,
	John McCutchan <john@johnmccutchan.com>,
	Robert Love <rlove@rlove.org>,
	Michael Kerrisk <mtk.manpages@gmail.com>
Subject: Re: [PATCH 1/1] fallocate: create FAN_MODIFY and IN_MODIFY events
Date: Tue, 7 Oct 2014 20:05:59 +0200	[thread overview]
Message-ID: <20141007180559.GC30038@quack.suse.cz> (raw)
In-Reply-To: <5432E921.7040306@gmx.de>

On Mon 06-10-14 21:10:25, Heinrich Schuchardt wrote:
> On 06.10.2014 16:12, Jan Kara wrote:
> >On Fri 03-10-14 10:19:30, Heinrich Schuchardt wrote:
> >>The fanotify and the inotify API can 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.
> >>
> >>This patch adds the missing call to fsnotify_modify.
> >   Well, there are different fallocate() commands and e.g. pure
> >FALLOC_FL_KEEP_SIZE call will not change any data in the file. I'm not sure
> >how much we care but I wanted to point that out...
> 
> The most interesting case is FALLOC_FL_COLLAPSE_RANGE because this
> value allows to create arbitrary file content from random data.
> Hence I think we really need to create FAN_MODIFY in this case.
> 
> As 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 different outcomes of a subsequent write depending on the
> values of offset and len.
> 
> Calling fallocate for a region already zeroed will not result in any
> data change.
> 
> I would like to compare fallocate() with write().
> 
> When we call write() we always create a FAN_MODIFY event even in the
> case of overwriting with identical data.
> 
> So event FAN_MODIFY does not provide any guarantee that data was
> actually changed.
> 
> In analogy to write() I suggest to keep the logic for fallocate() as
> trivial as possible:
> If fallocate() succeeds, create IN_MODIFY and FAN_MODIFY events.
  OK, makes sense. You can add:
Reviewed-by: Jan Kara <jack@suse.cz>

								Honza
> >>Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> >>---
> >>  fs/open.c | 5 +++++
> >>  1 file changed, 5 insertions(+)
> >>
> >>diff --git a/fs/open.c b/fs/open.c
> >>index d6fd3ac..03aa8e5 100644
> >>--- a/fs/open.c
> >>+++ b/fs/open.c
> >>@@ -295,6 +295,11 @@ int do_fallocate(struct file *file, int mode, loff_t offset, loff_t len)
> >>
> >>  	sb_start_write(inode->i_sb);
> >>  	ret = file->f_op->fallocate(file, mode, offset, len);
> >>+
> >>+	/* Create inotify and fanotify events. */
> >>+	if (ret == 0)
> >>+		fsnotify_modify(file);
> >>+
> >>  	sb_end_write(inode->i_sb);
> >>  	return ret;
> >>  }
> >>--
> >>2.1.0
> >>
> 
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

  reply	other threads:[~2014-10-07 18:05 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-02 22:02 [PATCH 0/3] inotify.7, fanotify.7: fallocate triggers no event Heinrich Schuchardt
     [not found] ` <1412287353-5234-1-git-send-email-xypron.glpk-Mmb7MZpHnFY@public.gmane.org>
2014-10-02 22:05   ` [PATCH 1/3] fanotify.7: bugs still not fixed in 3.17 Heinrich Schuchardt
     [not found]     ` <1412287503-5304-1-git-send-email-xypron.glpk-Mmb7MZpHnFY@public.gmane.org>
2014-10-28 11:44       ` Michael Kerrisk (man-pages)
2014-10-02 22:06   ` [PATCH 2/3] fanotify.7: fallocate creates no events Heinrich Schuchardt
     [not found]     ` <1412287571-5352-1-git-send-email-xypron.glpk-Mmb7MZpHnFY@public.gmane.org>
2014-10-28 11:44       ` Michael Kerrisk (man-pages)
2014-10-02 22:06   ` [PATCH 3/3] inotify.7: fallocate does not trigger inotify events Heinrich Schuchardt
2014-10-03  8:19     ` [PATCH 1/1] fallocate: create FAN_MODIFY and IN_MODIFY events Heinrich Schuchardt
2014-10-06 14:12       ` Jan Kara
2014-10-06 19:10         ` Heinrich Schuchardt
2014-10-07 18:05           ` Jan Kara [this message]
2014-10-07 18:24             ` Heinrich Schuchardt
2014-10-14 22:43               ` Andrew Morton
2014-10-17 17:08                 ` [PATCH v2 " Heinrich Schuchardt
     [not found]     ` <1412287587-5392-1-git-send-email-xypron.glpk-Mmb7MZpHnFY@public.gmane.org>
2014-10-28 11:44       ` [PATCH 3/3] inotify.7: fallocate does not trigger inotify events Michael Kerrisk (man-pages)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141007180559.GC30038@quack.suse.cz \
    --to=jack@suse.cz \
    --cc=eparis@parisplace.org \
    --cc=john@johnmccutchan.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtk.manpages@gmail.com \
    --cc=rlove@rlove.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=xypron.glpk@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.