From: Eric Paris <eparis@redhat.com>
To: David Drysdale <drysdale@google.com>
Cc: David Miller <davem@davemloft.net>,
Alexander Viro <viro@zeniv.linux.org.uk>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
sparclinux@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: sparc: Clashing values for O_PATH and FMODE_NONOTIFY?
Date: Thu, 20 Nov 2014 19:12:31 +0000 [thread overview]
Message-ID: <1416510751.3116.13.camel@localhost> (raw)
In-Reply-To: <CAHse=S-f5o3vbT+b1D5baEWCWMUnDyLSxM88+vwwymFuLrTirg@mail.gmail.com>
On Thu, 2014-11-20 at 12:12 +0000, David Drysdale wrote:
> [+linux-fsdevel, without the typo this time]
>
> On Wed, Nov 19, 2014 at 8:30 PM, David Miller <davem@davemloft.net> wrote:
> > From: David Drysdale <drysdale@google.com>
> > Date: Tue, 18 Nov 2014 13:13:51 +0000
> >
> >> Hi folks,
> >>
> >> It looks like the value for O_PATH on sparc:
> >>
> >> arch/sparc/include/uapi/asm/fcntl.h:37:#define O_PATH 0x1000000
> >>
> >> clashes with the arch-independent value for __FMODE_NONOTIFY:
> >>
> >> include/linux/fs.h:137:#define FMODE_NONOTIFY ((__force fmode_t)0x1000000)
> >> include/linux/fs.h:2764:#define __FMODE_NONOTIFY ((__force int)
> >> FMODE_NONOTIFY)
> >>
> >> and they are both in the same numbering space, as indicated by the
> >> comment at the top of include/uapi/asm-generic/fcntl.h and the use in
> >> fs/notify/fanotify/fanotify_user.c:715.
> >>
> >> Presumably this could theoretically cause problems (no notifications for
> >> O_PATH files on SPARC?), so would it be a good idea to renumber
> >> FMODE_NONOTIFY? (I *think* that value is entirely kernel-internal.)
> >>
> >> Given that this has happened before (12ed2e36c98aec6c4155 "fanotify:
> >> FMODE_NONOTIFY and __O_SYNC in sparc conflict") it would probably
> >> also be a good idea to add __FMODE_NOTIFY to the uniqueness check in
> >> fs/fcntl.c:fcntl_init().
> >>
> >> Thoughts?
> >
> > I think you will need to change the internal value, to not clash with
> > the sparc exported one, for sure.
>
> Well, I was sort of hoping someone else might volunteer to make the
> change :-) -- I don't use fanotify (or sparc for that matter), I just
> happened to notice the clash in passing.
>
> But I'm happy to have a go, although I can't test much. It would be
> good to hear from the fanotify maintainers first, though -- Eric?
It's totally internal. And was picked to not clash with anyone. I
don't know how to keep it from happening in the future.....
WARNING: multiple messages have this Message-ID (diff)
From: Eric Paris <eparis@redhat.com>
To: David Drysdale <drysdale@google.com>
Cc: David Miller <davem@davemloft.net>,
Alexander Viro <viro@zeniv.linux.org.uk>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
sparclinux@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: sparc: Clashing values for O_PATH and FMODE_NONOTIFY?
Date: Thu, 20 Nov 2014 14:12:31 -0500 [thread overview]
Message-ID: <1416510751.3116.13.camel@localhost> (raw)
In-Reply-To: <CAHse=S-f5o3vbT+b1D5baEWCWMUnDyLSxM88+vwwymFuLrTirg@mail.gmail.com>
On Thu, 2014-11-20 at 12:12 +0000, David Drysdale wrote:
> [+linux-fsdevel, without the typo this time]
>
> On Wed, Nov 19, 2014 at 8:30 PM, David Miller <davem@davemloft.net> wrote:
> > From: David Drysdale <drysdale@google.com>
> > Date: Tue, 18 Nov 2014 13:13:51 +0000
> >
> >> Hi folks,
> >>
> >> It looks like the value for O_PATH on sparc:
> >>
> >> arch/sparc/include/uapi/asm/fcntl.h:37:#define O_PATH 0x1000000
> >>
> >> clashes with the arch-independent value for __FMODE_NONOTIFY:
> >>
> >> include/linux/fs.h:137:#define FMODE_NONOTIFY ((__force fmode_t)0x1000000)
> >> include/linux/fs.h:2764:#define __FMODE_NONOTIFY ((__force int)
> >> FMODE_NONOTIFY)
> >>
> >> and they are both in the same numbering space, as indicated by the
> >> comment at the top of include/uapi/asm-generic/fcntl.h and the use in
> >> fs/notify/fanotify/fanotify_user.c:715.
> >>
> >> Presumably this could theoretically cause problems (no notifications for
> >> O_PATH files on SPARC?), so would it be a good idea to renumber
> >> FMODE_NONOTIFY? (I *think* that value is entirely kernel-internal.)
> >>
> >> Given that this has happened before (12ed2e36c98aec6c4155 "fanotify:
> >> FMODE_NONOTIFY and __O_SYNC in sparc conflict") it would probably
> >> also be a good idea to add __FMODE_NOTIFY to the uniqueness check in
> >> fs/fcntl.c:fcntl_init().
> >>
> >> Thoughts?
> >
> > I think you will need to change the internal value, to not clash with
> > the sparc exported one, for sure.
>
> Well, I was sort of hoping someone else might volunteer to make the
> change :-) -- I don't use fanotify (or sparc for that matter), I just
> happened to notice the clash in passing.
>
> But I'm happy to have a go, although I can't test much. It would be
> good to hear from the fanotify maintainers first, though -- Eric?
It's totally internal. And was picked to not clash with anyone. I
don't know how to keep it from happening in the future.....
next prev parent reply other threads:[~2014-11-20 19:12 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-18 13:13 sparc: Clashing values for O_PATH and FMODE_NONOTIFY? David Drysdale
2014-11-19 20:30 ` David Miller
2014-11-19 20:30 ` David Miller
2014-11-20 12:12 ` David Drysdale
2014-11-20 19:12 ` Eric Paris [this message]
2014-11-20 19:12 ` Eric Paris
2014-11-20 19:31 ` David Drysdale
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=1416510751.3116.13.camel@localhost \
--to=eparis@redhat.com \
--cc=davem@davemloft.net \
--cc=drysdale@google.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sparclinux@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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.