On Mon, 29 Sep 2014 10:49:15 +0200 Yann Droneaud <[email protected]> wrote:
> According to commit 80af258867648 ('fanotify: groups can specify
> their f_flags for new fd'), file descriptors created as part of
> file access notification events inherit flags from the
> event_f_flags argument passed to syscall fanotify_init(2).
>
> So while it is legal for userspace to call fanotify_init() with
> O_CLOEXEC as part of its second argument, O_CLOEXEC is currently
> silently ignored.
>
> Indeed event_f_flags are only given to dentry_open(), which only
> seems to care about O_ACCMODE and O_PATH in do_dentry_open(),
> O_DIRECT in open_check_o_direct() and O_LARGEFILE in
> generic_file_open().
>
> But it seems logical to set close-on-exec flag on the file
> descriptor if userspace is allowed to request it with O_CLOEXEC.
>
> In fact, according to some lookup on http://codesearch.debian.net/
> and various search engine, there's already some userspace code
> requesting it:
>
> - in systemd's readahead[2]:
>
> fanotify_fd = fanotify_init(FAN_CLOEXEC|FAN_NONBLOCK, O_RDONLY|O_LARGEFILE|O_CLOEXEC|O_NOATIME);
>
> - in clsync[3]:
>
> #define FANOTIFY_EVFLAGS (O_LARGEFILE|O_RDONLY|O_CLOEXEC)
>
> int fanotify_d = fanotify_init(FANOTIFY_FLAGS, FANOTIFY_EVFLAGS);
>
> - in examples [4] from "Filesystem monitoring in the Linux
> kernel" article[5] by Aleksander Morgado:
>
> if ((fanotify_fd = fanotify_init (FAN_CLOEXEC,
> O_RDONLY | O_CLOEXEC | O_LARGEFILE)) < 0)
So we have a number of apps which are setting O_CLOEXEC, but it doesn't
actually work. With this change it *will* work, so the behaviour of
those apps might change, possibly breaking them?
Hi,
Le mercredi 01 octobre 2014 à 15:36 -0700, Andrew Morton a écrit :
> On Mon, 29 Sep 2014 10:49:15 +0200 Yann Droneaud <[email protected]> wrote:
>
> > According to commit 80af258867648 ('fanotify: groups can specify
> > their f_flags for new fd'), file descriptors created as part of
> > file access notification events inherit flags from the
> > event_f_flags argument passed to syscall fanotify_init(2).
> >
> > So while it is legal for userspace to call fanotify_init() with
> > O_CLOEXEC as part of its second argument, O_CLOEXEC is currently
> > silently ignored.
> >
> > Indeed event_f_flags are only given to dentry_open(), which only
> > seems to care about O_ACCMODE and O_PATH in do_dentry_open(),
> > O_DIRECT in open_check_o_direct() and O_LARGEFILE in
> > generic_file_open().
> >
> > But it seems logical to set close-on-exec flag on the file
> > descriptor if userspace is allowed to request it with O_CLOEXEC.
> >
> > In fact, according to some lookup on http://codesearch.debian.net/
> > and various search engine, there's already some userspace code
> > requesting it:
> >
> > - in systemd's readahead[2]:
> >
> > fanotify_fd = fanotify_init(FAN_CLOEXEC|FAN_NONBLOCK, O_RDONLY|O_LARGEFILE|O_CLOEXEC|O_NOATIME);
> >
> > - in clsync[3]:
> >
> > #define FANOTIFY_EVFLAGS (O_LARGEFILE|O_RDONLY|O_CLOEXEC)
> >
> > int fanotify_d = fanotify_init(FANOTIFY_FLAGS, FANOTIFY_EVFLAGS);
> >
> > - in examples [4] from "Filesystem monitoring in the Linux
> > kernel" article[5] by Aleksander Morgado:
> >
> > if ((fanotify_fd = fanotify_init (FAN_CLOEXEC,
> > O_RDONLY | O_CLOEXEC | O_LARGEFILE)) < 0)
>
> So we have a number of apps which are setting O_CLOEXEC, but it doesn't
> actually work. With this change it *will* work, so the behaviour of
> those apps might change, possibly breaking them?
>
In the other hand, not enabling close-on-exec might expose unwanted file
descriptor to childs, creating security issues. YMMV.
--
Yann Droneaud
OPTEYA
On Thu, 02 Oct 2014 08:20:55 +0200 Yann Droneaud wrote:
> Hi,
>
> Le mercredi 01 octobre 2014 à 15:36 -0700, Andrew Morton a écrit :
> > On Mon, 29 Sep 2014 10:49:15 +0200 Yann Droneaud <[email protected]> wrote:
> >
> > > According to commit 80af258867648 ('fanotify: groups can specify
> > > their f_flags for new fd'), file descriptors created as part of
> > > file access notification events inherit flags from the
> > > event_f_flags argument passed to syscall fanotify_init(2).
> > >
> > > So while it is legal for userspace to call fanotify_init() with
> > > O_CLOEXEC as part of its second argument, O_CLOEXEC is currently
> > > silently ignored.
> > >
> > > Indeed event_f_flags are only given to dentry_open(), which only
> > > seems to care about O_ACCMODE and O_PATH in do_dentry_open(),
> > > O_DIRECT in open_check_o_direct() and O_LARGEFILE in
> > > generic_file_open().
> > >
> > > But it seems logical to set close-on-exec flag on the file
> > > descriptor if userspace is allowed to request it with O_CLOEXEC.
> > >
> > > In fact, according to some lookup on http://codesearch.debian.net/
> > > and various search engine, there's already some userspace code
> > > requesting it:
> > >
> > > - in systemd's readahead[2]:
> > >
> > > fanotify_fd = fanotify_init(FAN_CLOEXEC|FAN_NONBLOCK, O_RDONLY|O_LARGEFILE|O_CLOEXEC|O_NOATIME);
> > >
> > > - in clsync[3]:
> > >
> > > #define FANOTIFY_EVFLAGS (O_LARGEFILE|O_RDONLY|O_CLOEXEC)
> > >
> > > int fanotify_d = fanotify_init(FANOTIFY_FLAGS, FANOTIFY_EVFLAGS);
> > >
> > > - in examples [4] from "Filesystem monitoring in the Linux
> > > kernel" article[5] by Aleksander Morgado:
> > >
> > > if ((fanotify_fd = fanotify_init (FAN_CLOEXEC,
> > > O_RDONLY | O_CLOEXEC | O_LARGEFILE)) < 0)
> >
> > So we have a number of apps which are setting O_CLOEXEC, but it doesn't
> > actually work. With this change it *will* work, so the behaviour of
> > those apps might change, possibly breaking them?
> >
>
> In the other hand, not enabling close-on-exec might expose unwanted file
> descriptor to childs, creating security issues. YMMV.
>
As someone who uses fanotify for content introspection, I can say that
I am _explicitly_ marking the fd obtained via read() as O_CLOEXEC,
because I have encountered a situation where a child managed to create
a deadlock because it kept the fd open after the main application
responded with FAN_ALLOW.
--
Mihai Donțu
In order to not potentially break applications which were
requesting O_CLOEXEC on event file descriptors but which
actually need it to be not effective as the kernel currently
ignore the flag, so the file descriptor is inherited accross
exec regardless of O_CLOEXEC (please forgive me for the
wording), this patch introduces FAN_FD_CLOEXEC flag to
fanotify_init() so that application can request O_CLOEXEC
to be effective.
Newer application would use FAN_FD_CLOEXEC flag along
O_CLOEXEC to enable close on exec on newly created
file descriptor:
fd = fanotify_init(FAN_CLOEXEC|FAN_NONBLOCK|FAN_FD_CLOEXEC,
O_RDONLY|O_LARGEFILE|O_CLOEXEC|O_NOATIME);
Signed-off-by: Yann Droneaud <[email protected]>
---
Hi Andrew,
While I believe fanotify_init() must enable close-on-exec
when requested by userspace to prevent unwelcomed security
issue, I understand your concerns regarding the possible
breakage on userspace application requesting O_CLOEXEC
but relying on it not being enable on file descriptor
created for the events.
So with a new flag to fanotify_init(), we could allow
newer applications to really enable O_CLOEXEC.
But I feel bad to have to force application to specify
twice they want close on exec:
- are you sure ?
- are you really sure ?
- is this your final answer ?
...
Regards.
Yann Droneaud
OPTEYA
fs/notify/fanotify/fanotify_user.c | 6 +++++-
include/uapi/linux/fanotify.h | 5 ++++-
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c
index c991616acca9..3c1fb1412f37 100644
--- a/fs/notify/fanotify/fanotify_user.c
+++ b/fs/notify/fanotify/fanotify_user.c
@@ -78,7 +78,7 @@ static int create_fd(struct fsnotify_group *group,
pr_debug("%s: group=%p event=%p\n", __func__, group, event);
- client_fd = get_unused_fd_flags(group->fanotify_data.f_flags);
+ client_fd = get_unused_fd_flags(group->fanotify_data.f_flags & O_CLOEXEC);
if (client_fd < 0)
return client_fd;
@@ -706,6 +706,10 @@ SYSCALL_DEFINE2(fanotify_init, unsigned int, flags, unsigned int, event_f_flags)
return -EINVAL;
}
+ if ((event_f_flags & O_CLOEXEC) &&
+ !(flags & FAN_FD_CLOEXEC))
+ event_f_flags ^= O_CLOEXEC;
+
user = get_current_user();
if (atomic_read(&user->fanotify_listeners) > FANOTIFY_DEFAULT_MAX_LISTENERS) {
free_uid(user);
diff --git a/include/uapi/linux/fanotify.h b/include/uapi/linux/fanotify.h
index 030508d195d3..f2d517be3152 100644
--- a/include/uapi/linux/fanotify.h
+++ b/include/uapi/linux/fanotify.h
@@ -36,7 +36,10 @@
#define FAN_UNLIMITED_QUEUE 0x00000010
#define FAN_UNLIMITED_MARKS 0x00000020
-#define FAN_ALL_INIT_FLAGS (FAN_CLOEXEC | FAN_NONBLOCK | \
+/* flags used for fanotify_init() too */
+#define FAN_FD_CLOEXEC 0x00000100
+
+#define FAN_ALL_INIT_FLAGS (FAN_CLOEXEC | FAN_NONBLOCK | FAN_FD_CLOEXEC | \
FAN_ALL_CLASS_BITS | FAN_UNLIMITED_QUEUE |\
FAN_UNLIMITED_MARKS)
--
1.9.3
On 10/02/2014 08:52 AM, Yann Droneaud wrote:
> In order to not potentially break applications which were
> requesting O_CLOEXEC on event file descriptors but which
> actually need it to be not effective as the kernel currently
> ignore the flag, so the file descriptor is inherited accross
> exec regardless of O_CLOEXEC (please forgive me for the
> wording), this patch introduces FAN_FD_CLOEXEC flag to
> fanotify_init() so that application can request O_CLOEXEC
> to be effective.
> Newer application would use FAN_FD_CLOEXEC flag along
> O_CLOEXEC to enable close on exec on newly created
> file descriptor:
>
> fd = fanotify_init(FAN_CLOEXEC|FAN_NONBLOCK|FAN_FD_CLOEXEC,
> O_RDONLY|O_LARGEFILE|O_CLOEXEC|O_NOATIME);
Ugh really?
IMHO there should be widespread or at least known breakage with
O_CLOEXEC before adding messiness like this.
It seems surprising to me that apps that would depend on
O_CLOEXEC being ineffective.
please reconsider this one.
thanks,
P?draig.
On Wed 01-10-14 15:36:21, Andrew Morton wrote:
> On Mon, 29 Sep 2014 10:49:15 +0200 Yann Droneaud <[email protected]> wrote:
>
> > According to commit 80af258867648 ('fanotify: groups can specify
> > their f_flags for new fd'), file descriptors created as part of
> > file access notification events inherit flags from the
> > event_f_flags argument passed to syscall fanotify_init(2).
> >
> > So while it is legal for userspace to call fanotify_init() with
> > O_CLOEXEC as part of its second argument, O_CLOEXEC is currently
> > silently ignored.
> >
> > Indeed event_f_flags are only given to dentry_open(), which only
> > seems to care about O_ACCMODE and O_PATH in do_dentry_open(),
> > O_DIRECT in open_check_o_direct() and O_LARGEFILE in
> > generic_file_open().
> >
> > But it seems logical to set close-on-exec flag on the file
> > descriptor if userspace is allowed to request it with O_CLOEXEC.
> >
> > In fact, according to some lookup on http://codesearch.debian.net/
> > and various search engine, there's already some userspace code
> > requesting it:
> >
> > - in systemd's readahead[2]:
> >
> > fanotify_fd = fanotify_init(FAN_CLOEXEC|FAN_NONBLOCK, O_RDONLY|O_LARGEFILE|O_CLOEXEC|O_NOATIME);
> >
> > - in clsync[3]:
> >
> > #define FANOTIFY_EVFLAGS (O_LARGEFILE|O_RDONLY|O_CLOEXEC)
> >
> > int fanotify_d = fanotify_init(FANOTIFY_FLAGS, FANOTIFY_EVFLAGS);
> >
> > - in examples [4] from "Filesystem monitoring in the Linux
> > kernel" article[5] by Aleksander Morgado:
> >
> > if ((fanotify_fd = fanotify_init (FAN_CLOEXEC,
> > O_RDONLY | O_CLOEXEC | O_LARGEFILE)) < 0)
>
> So we have a number of apps which are setting O_CLOEXEC, but it doesn't
> actually work. With this change it *will* work, so the behaviour of
> those apps might change, possibly breaking them?
Possibly. OTOH I'd dare to say that most of the apps specifying O_CLOEXEC
want that behavior and their security may be weakened by the fact that
O_CLOEXEC is ignored. So we are weighting possible security issues for apps
doing things right (and Mihai mentioned in this thread that at least he has
an application which needs O_CLOEXEC working) against possible breakage for
apps which just randomly set O_CLOEXEC without wanting. So I'm really for
fixing O_CLOEXEC behavior.
Honza
--
Jan Kara <[email protected]>
SUSE Labs, CR
On Thu, Oct 2, 2014 at 11:13 AM, Pádraig Brady <[email protected]> wrote:
> On 10/02/2014 08:52 AM, Yann Droneaud wrote:
>> In order to not potentially break applications which were
>> requesting O_CLOEXEC on event file descriptors but which
>> actually need it to be not effective as the kernel currently
>> ignore the flag, so the file descriptor is inherited accross
>> exec regardless of O_CLOEXEC (please forgive me for the
>> wording), this patch introduces FAN_FD_CLOEXEC flag to
>> fanotify_init() so that application can request O_CLOEXEC
>> to be effective.
>> Newer application would use FAN_FD_CLOEXEC flag along
>> O_CLOEXEC to enable close on exec on newly created
>> file descriptor:
>>
>> fd = fanotify_init(FAN_CLOEXEC|FAN_NONBLOCK|FAN_FD_CLOEXEC,
>> O_RDONLY|O_LARGEFILE|O_CLOEXEC|O_NOATIME);
>
> Ugh really?
> IMHO there should be widespread or at least known breakage with
> O_CLOEXEC before adding messiness like this.
> It seems surprising to me that apps that would depend on
> O_CLOEXEC being ineffective.
>
> please reconsider this one.
Agreed. The number of applications for which there are silent (not
*yet* observed) breakages because O_CLOEXEC is not working as expected
is likely rather larger than the set of applications that randomly
specify O_CLOEXEC and then somehow get broken as a result.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
Hi,
Le jeudi 02 octobre 2014 à 10:13 +0100, Pádraig Brady a écrit :
> On 10/02/2014 08:52 AM, Yann Droneaud wrote:
> > In order to not potentially break applications which were
> > requesting O_CLOEXEC on event file descriptors but which
> > actually need it to be not effective as the kernel currently
> > ignore the flag, so the file descriptor is inherited accross
> > exec regardless of O_CLOEXEC (please forgive me for the
> > wording), this patch introduces FAN_FD_CLOEXEC flag to
> > fanotify_init() so that application can request O_CLOEXEC
> > to be effective.
> > Newer application would use FAN_FD_CLOEXEC flag along
> > O_CLOEXEC to enable close on exec on newly created
> > file descriptor:
> >
> > fd = fanotify_init(FAN_CLOEXEC|FAN_NONBLOCK|FAN_FD_CLOEXEC,
> > O_RDONLY|O_LARGEFILE|O_CLOEXEC|O_NOATIME);
>
> Ugh really?
> IMHO there should be widespread or at least known breakage with
> O_CLOEXEC before adding messiness like this.
You should have read the other part of my message:
> > While I believe fanotify_init() must enable close-on-exec
> > when requested by userspace to prevent unwelcomed security
> > issue, I understand your concerns regarding the possible
> > breakage on userspace application requesting O_CLOEXEC
> > but relying on it not being enable on file descriptor
> > created for the events.
>
> > So with a new flag to fanotify_init(), we could allow
> > newer applications to really enable O_CLOEXEC.
>
> > But I feel bad to have to force application to specify
> > twice they want close on exec:
> > - are you sure ?
> > - are you really sure ?
> > - is this your final answer ?
> > ...
I'm not really fond of this option.
> It seems surprising to me that apps that would depend on
> O_CLOEXEC being ineffective.
>
We have seen userspace developers making mistakes, and those mistakes
were mistakenly ignored by the kernel until someone try to fix the
mistake on kernel side, which broke the existing userspace application.
> please reconsider this one.
>
I'm not going to promote this patch as it's a quick and dirty hack to
demonstrate what would be the other option.
Regards.
--
Yann Droneaud
OPTEYA
On Thu, 2 Oct 2014 12:44:10 +0200 Jan Kara <[email protected]> wrote:
> On Wed 01-10-14 15:36:21, Andrew Morton wrote:
> > On Mon, 29 Sep 2014 10:49:15 +0200 Yann Droneaud <[email protected]> wrote:
> >
> > > According to commit 80af258867648 ('fanotify: groups can specify
> > > their f_flags for new fd'), file descriptors created as part of
> > > file access notification events inherit flags from the
> > > event_f_flags argument passed to syscall fanotify_init(2).
> > >
> > > So while it is legal for userspace to call fanotify_init() with
> > > O_CLOEXEC as part of its second argument, O_CLOEXEC is currently
> > > silently ignored.
> > >
> > > Indeed event_f_flags are only given to dentry_open(), which only
> > > seems to care about O_ACCMODE and O_PATH in do_dentry_open(),
> > > O_DIRECT in open_check_o_direct() and O_LARGEFILE in
> > > generic_file_open().
> > >
> > > But it seems logical to set close-on-exec flag on the file
> > > descriptor if userspace is allowed to request it with O_CLOEXEC.
> > >
> > > In fact, according to some lookup on http://codesearch.debian.net/
> > > and various search engine, there's already some userspace code
> > > requesting it:
> > >
> > > - in systemd's readahead[2]:
> > >
> > > fanotify_fd = fanotify_init(FAN_CLOEXEC|FAN_NONBLOCK, O_RDONLY|O_LARGEFILE|O_CLOEXEC|O_NOATIME);
> > >
> > > - in clsync[3]:
> > >
> > > #define FANOTIFY_EVFLAGS (O_LARGEFILE|O_RDONLY|O_CLOEXEC)
> > >
> > > int fanotify_d = fanotify_init(FANOTIFY_FLAGS, FANOTIFY_EVFLAGS);
> > >
> > > - in examples [4] from "Filesystem monitoring in the Linux
> > > kernel" article[5] by Aleksander Morgado:
> > >
> > > if ((fanotify_fd = fanotify_init (FAN_CLOEXEC,
> > > O_RDONLY | O_CLOEXEC | O_LARGEFILE)) < 0)
> >
> > So we have a number of apps which are setting O_CLOEXEC, but it doesn't
> > actually work. With this change it *will* work, so the behaviour of
> > those apps might change, possibly breaking them?
> Possibly. OTOH I'd dare to say that most of the apps specifying O_CLOEXEC
> want that behavior and their security may be weakened by the fact that
> O_CLOEXEC is ignored. So we are weighting possible security issues for apps
> doing things right (and Mihai mentioned in this thread that at least he has
> an application which needs O_CLOEXEC working) against possible breakage for
> apps which just randomly set O_CLOEXEC without wanting. So I'm really for
> fixing O_CLOEXEC behavior.
Fair enough, it sounds like the risk is acceptable.
Can we get a new version sent out with all this new info appropriately
changelogged?
According to commit 80af258867648 ('fanotify: groups can specify
their f_flags for new fd'), file descriptors created as part of
file access notification events inherit flags from the
event_f_flags argument passed to syscall fanotify_init(2)[1].
Unfortunately O_CLOEXEC is currently silently ignored.
Indeed, event_f_flags are only given to dentry_open(), which only
seems to care about O_ACCMODE and O_PATH in do_dentry_open(),
O_DIRECT in open_check_o_direct() and O_LARGEFILE in
generic_file_open().
It's a pity, since, according to some lookup on various search
engines and http://codesearch.debian.net/, there's already some
userspace code which use O_CLOEXEC:
- in systemd's readahead[2]:
fanotify_fd = fanotify_init(FAN_CLOEXEC|FAN_NONBLOCK, O_RDONLY|O_LARGEFILE|O_CLOEXEC|O_NOATIME);
- in clsync[3]:
#define FANOTIFY_EVFLAGS (O_LARGEFILE|O_RDONLY|O_CLOEXEC)
int fanotify_d = fanotify_init(FANOTIFY_FLAGS, FANOTIFY_EVFLAGS);
- in examples [4] from "Filesystem monitoring in the Linux
kernel" article[5] by Aleksander Morgado:
if ((fanotify_fd = fanotify_init (FAN_CLOEXEC,
O_RDONLY | O_CLOEXEC | O_LARGEFILE)) < 0)
Additionally, since commit 48149e9d3a7e ('fanotify: check file
flags passed in fanotify_init'). having O_CLOEXEC as part of
fanotify_init() second argument is expressly allowed.
So it seems expected to set close-on-exec flag on the file
descriptors if userspace is allowed to request it with O_CLOEXEC.
But Andrew Morton raised[6] the concern that enabling now
close-on-exec might break existing applications which ask for
O_CLOEXEC but expect the file descriptor to be inherited
across exec().
In the other hand, as reported by Mihai Donțu[7], not setting
close-on-exec on the file descriptor returned as part of file
access notify can break applications due to deadlock.
So close-on-exec is needed for most applications.
More, applications asking for close-on-exec are likely expecting
it to be enabled, relying on O_CLOEXEC being effective. If not,
it might weaken their security, as noted by Jan Kara[8].
So this patch replaces call to macro get_unused_fd() by a call
to function get_unused_fd_flags() with event_f_flags value as
argument. This way O_CLOEXEC flag in the second argument of
fanotify_init(2) syscall is interpreted and close-on-exec
get enabled when requested.
[1] http://man7.org/linux/man-pages/man2/fanotify_init.2.html
[2] http://cgit.freedesktop.org/systemd/systemd/tree/src/readahead/readahead-collect.c?id=v208#n294
[3] https://github.com/xaionaro/clsync/blob/v0.2.1/sync.c#L1631
https://github.com/xaionaro/clsync/blob/v0.2.1/configuration.h#L38
[4] http://www.lanedo.com/~aleksander/fanotify/fanotify-example.c
[5] http://www.lanedo.com/2013/filesystem-monitoring-linux-kernel/
[6] http://lkml.kernel.org/r/[email protected]
[7] http://lkml.kernel.org/r/20141002095046.3715eb69@mdontu-l
[8] http://lkml.kernel.org/r/[email protected]
Link: http://lkml.kernel.org/r/[email protected]
Cc: Mihai Donțu <[email protected]>
Cc: Pádraig Brady <[email protected]>
Cc: Heinrich Schuchardt <[email protected]>
Cc: Jan Kara <[email protected]>
Cc: Valdis Kletnieks <[email protected]>
Cc: Michael Kerrisk-manpages <[email protected]>
Cc: Lino Sanfilippo <[email protected]>
Cc: Richard Guy Briggs <[email protected]>
Cc: Eric Paris <[email protected]>
Cc: Al Viro <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: [email protected]
Cc: [email protected]
Reviewed-by: Jan Kara <[email protected]>
Reviewed by: Heinrich Schuchardt <[email protected]>
Tested-by: Heinrich Schuchardt <[email protected]>
Signed-off-by: Yann Droneaud <[email protected]>
---
Hi Andrew,
> Fair enough, it sounds like the risk is acceptable.
>
OK.
> Can we get a new version sent out with all this new info appropriately
> changelogged?
>
Of course !
Please find an updated patch with revamped commit message.
Changes from v8.1:
- added more Cc:
- added Reviewed-by:
- rewrote commit message.
fs/notify/fanotify/fanotify_user.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c
index b13992a41bd9..c991616acca9 100644
--- a/fs/notify/fanotify/fanotify_user.c
+++ b/fs/notify/fanotify/fanotify_user.c
@@ -78,7 +78,7 @@ static int create_fd(struct fsnotify_group *group,
pr_debug("%s: group=%p event=%p\n", __func__, group, event);
- client_fd = get_unused_fd();
+ client_fd = get_unused_fd_flags(group->fanotify_data.f_flags);
if (client_fd < 0)
return client_fd;
--
1.9.3