[PATCH 0/3] inotify.7, fanotify.7: fallocate triggers no event

[PATCH 0/3] inotify.7, fanotify.7: fallocate triggers no event

[Heinrich Schuchardt]

the fanotify.7 and inotify.7 manpages do not describe whether fallocate.2 will
create events (FAN_MODIFY, IN_MODIFY).
Looking at fs/open.c no event seems to be created.
I ran a test program and could not detect any FAN_MODIFY event.

Heinrich Schuchardt (3):
  fanotify.7: bugs still not fixed in 3.17
  fanotify.7: fallocate creates no events
  inotify.7: fallocate does not trigger inotify events

 man7/fanotify.7 | 6 +++++-
 man7/inotify.7  | 4 ++++
 2 files changed, 9 insertions(+), 1 deletion(-)

-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3] fanotify.7: bugs still not fixed in 3.17

[Heinrich Schuchardt]

I bumped the Linux version number in the BUGS section to 3.17.

Signed-off-by: Heinrich Schuchardt <xypron.glpk-Mmb7MZpHnFY@public.gmane.org>
---
 man7/fanotify.7 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/man7/fanotify.7 b/man7/fanotify.7
index b6456d5..bc5a11c 100644
--- a/man7/fanotify.7
+++ b/man7/fanotify.7
@@ -485,7 +485,7 @@ Monitoring mounts offers the capability to monitor a whole directory tree.
 The event queue can overflow.
 In this case, events are lost.
 .SH BUGS
-As of Linux 3.15,
+As of Linux 3.17,
 the following bugs exist:
 .IP * 3
 .\" FIXME . A patch was proposed.
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/3] fanotify.7: fallocate creates no events

[Heinrich Schuchardt]

fallocate(2) should create FAN_MODIFY events but does not.

Signed-off-by: Heinrich Schuchardt <xypron.glpk-Mmb7MZpHnFY@public.gmane.org>
---
 man7/fanotify.7 | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/man7/fanotify.7 b/man7/fanotify.7
index bc5a11c..e718249 100644
--- a/man7/fanotify.7
+++ b/man7/fanotify.7
@@ -488,6 +488,10 @@ In this case, events are lost.
 As of Linux 3.17,
 the following bugs exist:
 .IP * 3
+Calling
+.BR fallocate (2)
+does not create any fanotify events.
+.IP *
 .\" FIXME . A patch was proposed.
 When an event is generated,
 no check is made to see whether the user ID of the
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/3] inotify.7: fallocate does not trigger inotify events

[Heinrich Schuchardt]

Calling fallocate.2 does not result in inotify events.

Signed-off-by: Heinrich Schuchardt <xypron.glpk-Mmb7MZpHnFY@public.gmane.org>
---
 man7/inotify.7 | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/man7/inotify.7 b/man7/inotify.7
index a0e2528..7f45ba9 100644
--- a/man7/inotify.7
+++ b/man7/inotify.7
@@ -752,6 +752,10 @@ and also the possibility that there may not be any
 .B IN_MOVED_TO
 event.
 .SH BUGS
+As of kernel 3.17, calling
+.BR fallocate (2) 
+does not create any inotify events.
+
 .\" FIXME . kernel commit 611da04f7a31b2208e838be55a42c7a1310ae321
 .\" implies that unmount events were buggy 2.6.11 to 2.6.36
 .\"
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/1] fallocate: create FAN_MODIFY and IN_MODIFY events

[Heinrich Schuchardt]

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.

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

Re: [PATCH 1/1] fallocate: create FAN_MODIFY and IN_MODIFY events

[Jan Kara]

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...

								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

Re: [PATCH 1/1] fallocate: create FAN_MODIFY and IN_MODIFY events

[Heinrich Schuchardt]

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.

Best regards

Heinrich Schuchardt
>
>> 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
>>

Re: [PATCH 1/1] fallocate: create FAN_MODIFY and IN_MODIFY events

[Jan Kara]

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

Re: [PATCH 1/1] fallocate: create FAN_MODIFY and IN_MODIFY events

[Heinrich Schuchardt]

Hello Andrew,

the patch in
https://lkml.org/lkml/2014/10/3/56
and cited below was reviewed by Jan Kara.

Please, add it to the MM tree.

Best regards

Heinrich Schuchardt

On 07.10.2014 20:05, Jan Kara wrote:
> 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
>>>>
>>

Re: [PATCH 1/1] fallocate: create FAN_MODIFY and IN_MODIFY events

[Andrew Morton]

On Tue, 07 Oct 2014 20:24:02 +0200 Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:

> Hello Andrew,
> 
> the patch in
> https://lkml.org/lkml/2014/10/3/56
> and cited below was reviewed by Jan Kara.
> 

Jan wondered why we generate events for FALLOC_FL_KEEP_SIZE, so other
people will wonder the same thing.  We should tell them.  Via code
comments and/or changelogging.

Any question which a reviewer asks should be viewed as a defect in the
patch.  The patch isn't finished until people can read it without
having questions.

[PATCH v2 1/1] fallocate: create FAN_MODIFY and IN_MODIFY events

[Heinrich Schuchardt]

:: Andrew Morton wrote:
::
:: Jan wondered why we generate events for FALLOC_FL_KEEP_SIZE, so other
:: people will wonder the same thing.  We should tell them.  Via code
:: comments and/or changelogging.
:: 
:: Any question which a reviewer asks should be viewed as a defect in the
:: patch. The patch isn't finished until people can read it without
:: having questions.

Please, find below a new version of the patch with an updated message and
additional comment lines in the code.



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
different outcomes of a subsequent write depending on the values of
offset and len.

Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
---
 fs/open.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/fs/open.c b/fs/open.c
index d6fd3ac..550d464 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -295,6 +295,17 @@ 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.
+	 *
+	 * 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;
 }
-- 
2.1.1

Re: [PATCH 1/3] fanotify.7: bugs still not fixed in 3.17

[Michael Kerrisk (man-pages)]

Thanks, Heinrich.

Applied.

Cheers,

Michael

On 10/03/2014 12:05 AM, Heinrich Schuchardt wrote:
> I bumped the Linux version number in the BUGS section to 3.17.
> 
> Signed-off-by: Heinrich Schuchardt <xypron.glpk-Mmb7MZpHnFY@public.gmane.org>
> ---
>  man7/fanotify.7 | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/man7/fanotify.7 b/man7/fanotify.7
> index b6456d5..bc5a11c 100644
> --- a/man7/fanotify.7
> +++ b/man7/fanotify.7
> @@ -485,7 +485,7 @@ Monitoring mounts offers the capability to monitor a whole directory tree.
>  The event queue can overflow.
>  In this case, events are lost.
>  .SH BUGS
> -As of Linux 3.15,
> +As of Linux 3.17,
>  the following bugs exist:
>  .IP * 3
>  .\" FIXME . A patch was proposed.
> 


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] fanotify.7: fallocate creates no events

[Michael Kerrisk (man-pages)]

Thanks, Heinrich.

Applied.

Cheers,

Michael

On 10/03/2014 12:06 AM, Heinrich Schuchardt wrote:
> fallocate(2) should create FAN_MODIFY events but does not.
> 
> Signed-off-by: Heinrich Schuchardt <xypron.glpk-Mmb7MZpHnFY@public.gmane.org>
> ---
>  man7/fanotify.7 | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/man7/fanotify.7 b/man7/fanotify.7
> index bc5a11c..e718249 100644
> --- a/man7/fanotify.7
> +++ b/man7/fanotify.7
> @@ -488,6 +488,10 @@ In this case, events are lost.
>  As of Linux 3.17,
>  the following bugs exist:
>  .IP * 3
> +Calling
> +.BR fallocate (2)
> +does not create any fanotify events.
> +.IP *
>  .\" FIXME . A patch was proposed.
>  When an event is generated,
>  no check is made to see whether the user ID of the
> 


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] inotify.7: fallocate does not trigger inotify events

[Michael Kerrisk (man-pages)]

Thanks, Heinrich.

Applied.

Cheers,

Michael


On 10/03/2014 12:06 AM, Heinrich Schuchardt wrote:
> Calling fallocate.2 does not result in inotify events.
> 
> Signed-off-by: Heinrich Schuchardt <xypron.glpk-Mmb7MZpHnFY@public.gmane.org>
> ---
>  man7/inotify.7 | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/man7/inotify.7 b/man7/inotify.7
> index a0e2528..7f45ba9 100644
> --- a/man7/inotify.7
> +++ b/man7/inotify.7
> @@ -752,6 +752,10 @@ and also the possibility that there may not be any
>  .B IN_MOVED_TO
>  event.
>  .SH BUGS
> +As of kernel 3.17, calling
> +.BR fallocate (2) 
> +does not create any inotify events.
> +
>  .\" FIXME . kernel commit 611da04f7a31b2208e838be55a42c7a1310ae321
>  .\" implies that unmount events were buggy 2.6.11 to 2.6.36
>  .\"
> 


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html