From: Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>
To: "Michael Kerrisk (man-pages)"
<mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Heinrich Schuchardt <xypron.glpk-Mmb7MZpHnFY@public.gmane.org>,
linux-man <linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Eric Paris <eparis-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>,
lkml <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Al Viro <viro-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
Subject: Re: fanotify API: FMODE_NONOTIFY, FMODE_EXEC, FMODE_NOCMTIME
Date: Tue, 29 Apr 2014 22:10:06 +0200 [thread overview]
Message-ID: <20140429201006.GD29634@quack.suse.cz> (raw)
In-Reply-To: <CAKgNAkiq+yA7_tnvCVXemFy6P5F0eMccw18-GdqFthuzagvF5Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hello,
On Tue 29-04-14 15:29:12, Michael Kerrisk (man-pages) wrote:
> Can you offer any insight on Heinrich's question, below?
>
> On Sun, Apr 13, 2014 at 4:05 PM, Heinrich Schuchardt <xypron.glpk-Mmb7MZpHnFY@public.gmane.org> wrote:
> > On 06.04.2014 14:18, Michael Kerrisk (man-pages) wrote:
> >>>
> >>> ==
> >>> >
> >>> > >> I notice that the FDs returned by read()s from the FAN FD have the
> >>> > >> FMODE_NONOTIFY flag (fcntl(F_GETFL)) flag set. If you know what
> >>> > that's
> >>> > >> about, it would be good to say something about. But, if not, do not
> >>> > >> worry--just place a FIXME in the page source of fanotify(7)
> >>> >
> >>> >Fixed in fanotify.7
> >>> >If the listener accesses the file through the file descriptor provided
> >>> >no additional events are created.
> >>
> >> Ahh -- thanks for filling in that piece. I see that you refer to
> >> fcntl(2) when discussing that flag. But fcntl(2) does not
> >> mention that flag. I would rather see an explanation of this flag
> >> in the fanotify pages.
> >>
> >
> > I wrote a small test program and found:
> >
> > The flag FMODE_NONOTIFY can be read by function fcntl from userspace.
> > int flag = fcntl(fd, F_GETFL)
> >
> > In include/uapi/asm-generic/fcntl.h I found the following comment:
> >
> > /*
> > * FMODE_EXEC is 0x20
> > * FMODE_NONOTIFY is 0x1000000
> > * These cannot be used by userspace O_* until internal and external open
> > * flags are split.
> > * -Eric Paris
> > */
> >
> > The definition of FMODE_NONOTIFY is in include/linux/fs.h but this
> > include is only used to compile the Kernel and not supposed to be used by
> > userspace.
> >
> > I think it is quite annoying that fcntl can return a flag that is not
> > described in the manpage of fcntl and that is not defined in fcntl.h.
> >
> > But FMODE_NONOTIFY is not the only flag:
> >
> > I was able to pass
> > 0x20 (FMODE_EXEC), and
> > 0x800 (FMODE_NOCMTIME)
> > to fanotify_init and received them as flag in the file descriptors for the
> > fanotify events.
> > I wonder why fanotify_init does not check import parameter event_f_flags and
> > return an error if any inappropriate value is set.
It seems to me fanotify_init() should really check event_f_flags have
only valid flags set. In particular exclude FMODE_EXEC, FMODE_NOCMTIME, or
FMODE_NONOTIFY.
> > Should I put this into the BUGS section?
> >
> > Should the name of the flag FMODE_NONOTIFY be mentioned at all in the man
> > pages?
> >
> > Or should we write:
> >
> > .I fd
> > This is an open file descriptor for the object being accessed or
> > .B FAN_NOFD
> > if a queue overflow occurred.
> > The file descriptor can be used to access the contents of the monitored file
> > or
> > directory.
> > It has an internal flag set, that suppresses fanotify event generation.
> > Hence when the receiver of the fanotify event accesses the notified file or
> > directory using this file descriptor no additional events will be created.
> > The reading application is responsible for closing the file descriptor.
So this is what I would prefer. Just mention the file descriptor does not
generate new events. I would even go as far as masking kernel internal
flags like FMODE_EXEC or FMODE_NONOTIFY from the result of F_GETFL. What do
you think Al?
Honza
--
Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>
SUSE Labs, CR
--
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
WARNING: multiple messages have this Message-ID (diff)
From: Jan Kara <jack@suse.cz>
To: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>,
linux-man <linux-man@vger.kernel.org>,
Eric Paris <eparis@redhat.com>, Jan Kara <jack@suse.cz>,
lkml <linux-kernel@vger.kernel.org>,
Al Viro <viro@ZenIV.linux.org.uk>
Subject: Re: fanotify API: FMODE_NONOTIFY, FMODE_EXEC, FMODE_NOCMTIME
Date: Tue, 29 Apr 2014 22:10:06 +0200 [thread overview]
Message-ID: <20140429201006.GD29634@quack.suse.cz> (raw)
In-Reply-To: <CAKgNAkiq+yA7_tnvCVXemFy6P5F0eMccw18-GdqFthuzagvF5Q@mail.gmail.com>
Hello,
On Tue 29-04-14 15:29:12, Michael Kerrisk (man-pages) wrote:
> Can you offer any insight on Heinrich's question, below?
>
> On Sun, Apr 13, 2014 at 4:05 PM, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> > On 06.04.2014 14:18, Michael Kerrisk (man-pages) wrote:
> >>>
> >>> ==
> >>> >
> >>> > >> I notice that the FDs returned by read()s from the FAN FD have the
> >>> > >> FMODE_NONOTIFY flag (fcntl(F_GETFL)) flag set. If you know what
> >>> > that's
> >>> > >> about, it would be good to say something about. But, if not, do not
> >>> > >> worry--just place a FIXME in the page source of fanotify(7)
> >>> >
> >>> >Fixed in fanotify.7
> >>> >If the listener accesses the file through the file descriptor provided
> >>> >no additional events are created.
> >>
> >> Ahh -- thanks for filling in that piece. I see that you refer to
> >> fcntl(2) when discussing that flag. But fcntl(2) does not
> >> mention that flag. I would rather see an explanation of this flag
> >> in the fanotify pages.
> >>
> >
> > I wrote a small test program and found:
> >
> > The flag FMODE_NONOTIFY can be read by function fcntl from userspace.
> > int flag = fcntl(fd, F_GETFL)
> >
> > In include/uapi/asm-generic/fcntl.h I found the following comment:
> >
> > /*
> > * FMODE_EXEC is 0x20
> > * FMODE_NONOTIFY is 0x1000000
> > * These cannot be used by userspace O_* until internal and external open
> > * flags are split.
> > * -Eric Paris
> > */
> >
> > The definition of FMODE_NONOTIFY is in include/linux/fs.h but this
> > include is only used to compile the Kernel and not supposed to be used by
> > userspace.
> >
> > I think it is quite annoying that fcntl can return a flag that is not
> > described in the manpage of fcntl and that is not defined in fcntl.h.
> >
> > But FMODE_NONOTIFY is not the only flag:
> >
> > I was able to pass
> > 0x20 (FMODE_EXEC), and
> > 0x800 (FMODE_NOCMTIME)
> > to fanotify_init and received them as flag in the file descriptors for the
> > fanotify events.
> > I wonder why fanotify_init does not check import parameter event_f_flags and
> > return an error if any inappropriate value is set.
It seems to me fanotify_init() should really check event_f_flags have
only valid flags set. In particular exclude FMODE_EXEC, FMODE_NOCMTIME, or
FMODE_NONOTIFY.
> > Should I put this into the BUGS section?
> >
> > Should the name of the flag FMODE_NONOTIFY be mentioned at all in the man
> > pages?
> >
> > Or should we write:
> >
> > .I fd
> > This is an open file descriptor for the object being accessed or
> > .B FAN_NOFD
> > if a queue overflow occurred.
> > The file descriptor can be used to access the contents of the monitored file
> > or
> > directory.
> > It has an internal flag set, that suppresses fanotify event generation.
> > Hence when the receiver of the fanotify event accesses the notified file or
> > directory using this file descriptor no additional events will be created.
> > The reading application is responsible for closing the file descriptor.
So this is what I would prefer. Just mention the file descriptor does not
generate new events. I would even go as far as masking kernel internal
flags like FMODE_EXEC or FMODE_NONOTIFY from the result of F_GETFL. What do
you think Al?
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
next prev parent reply other threads:[~2014-04-29 20:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-29 13:29 fanotify API: FMODE_NONOTIFY, FMODE_EXEC, FMODE_NOCMTIME Michael Kerrisk (man-pages)
[not found] ` <CAKgNAkiq+yA7_tnvCVXemFy6P5F0eMccw18-GdqFthuzagvF5Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-04-29 20:10 ` Jan Kara [this message]
2014-04-29 20:10 ` Jan Kara
[not found] ` <20140429201006.GD29634-+0h/O2h83AeN3ZZ/Hiejyg@public.gmane.org>
2014-04-29 20:55 ` Eric Paris
2014-04-29 20:55 ` Eric Paris
-- strict thread matches above, loose matches on Subject: below --
2014-03-24 21:23 [PATCH 1/1] Man pages for the fanotify API Michael Kerrisk (man-pages)
2014-04-06 0:01 ` [PATCH 0/1] Manpages " xypron.glpk-Mmb7MZpHnFY
2014-04-06 12:18 ` Michael Kerrisk (man-pages)
[not found] ` <5341461A.3090405-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-04-13 14:05 ` fanotify API: FMODE_NONOTIFY, FMODE_EXEC, FMODE_NOCMTIME Heinrich Schuchardt
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=20140429201006.GD29634@quack.suse.cz \
--to=jack-alswssmvlrq@public.gmane.org \
--cc=eparis-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=viro-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org \
--cc=xypron.glpk-Mmb7MZpHnFY@public.gmane.org \
/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.