Hello Andrew,
please, add the patch described in
https://lkml.org/lkml/2014/9/24/967
to the MM tree.
I have tested kernel 3.17.0-rc6 with and without the patch and it fixes
the described error.
As the patch is valid independent of the rest of the patch set, there is
no reason to wait for the rest to be merged.
You may add
Reviewed by: Heinrich Schuchardt <xypron.glpk@xxxxxx>
Best regards
Heinrich Schuchardt
On 26.09.2014 10:58, Yann Droneaud wrote:
Hi,
Le jeudi 25 septembre 2014 à 22:57 +0200, Heinrich Schuchardt a écrit :
On 24.09.2014 15:11, Yann Droneaud 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().
I tested on kernel 3.17.0-rc5. I passed O_CLOEXEC in event_f_flags.
When I called fcnt(event_metadata->fd, F_GETFD) it did not return
FD_CLOEXEC. So I can confirm your observation that O_CLOEXEC is not
working as expected.
I found this definition
#define get_unused_fd() get_unused_fd_flags(0)
So essentially when get_unused_fd() is called for a fanotify event
O_CLOEXEC is ignored.
This is what your patch fixes.
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
