From: Jamie Lokier <jamie@shareable.org>
To: James Bottomley <James.Bottomley@suse.de>
Cc: akpm@linux-foundation.org, viro@zeniv.linux.org.uk,
linux-fsdevel@vger.kernel.org, fengguang.wu@intel.com,
davem@davemloft.net, eparis@redhat.com, hch@infradead.org,
rdreier@cisco.com, schwab@linux-m68k.org, sfr@canb.auug.org.au
Subject: Re: [patch 2/5] vfs: O_* bit numbers uniqueness check
Date: Fri, 27 Aug 2010 02:27:00 +0100 [thread overview]
Message-ID: <20100827012700.GK3574@shareable.org> (raw)
In-Reply-To: <1282864959.8133.67.camel@mulgrave.site>
James Bottomley wrote:
> On Tue, 2010-07-20 at 15:29 -0700, akpm@linux-foundation.org wrote:
> > From: Wu Fengguang <fengguang.wu@intel.com>
> >
> > The O_* bit numbers are defined in 20+ arch/*, and can silently overlap.
> > Add a compile time check to ensure the uniqueness as suggested by David
> > Miller.
>
> Can we get this reverted or fixed? It's causing the parisc compiles to
> fail. The reason is O_NONBLOCK on parisc has a dual value:
>
> #define O_NONBLOCK 000200004 /* HPUX has separate NDELAY & NONBLOCK */
>
> The fix would be to take O_NONBLOCK out.
A more thoroughly checking fix would be
BUILD_BUG_ON(18 - 1 /* For O_RDONLY being 0 */
+ HWEIGHT32(O_NONBLOCK) /* Because it's 2 bits on parisc */
!= HWEIGHT32( .... all the bits .... ));
Am I allowed to Sign-off handwavy pseudocode? ;-)
-- Jamie
next prev parent reply other threads:[~2010-08-27 1:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-20 22:29 [patch 2/5] vfs: O_* bit numbers uniqueness check akpm
2010-08-26 23:22 ` James Bottomley
2010-08-27 1:27 ` Jamie Lokier [this message]
2010-08-27 5:53 ` James Bottomley
2010-09-04 1:22 ` [PATCH] vfs: take O_NONBLOCK out of the O_* uniqueness test Wu Fengguang
-- strict thread matches above, loose matches on Subject: below --
2010-05-24 19:24 [patch 2/5] vfs: O_* bit numbers uniqueness check akpm
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=20100827012700.GK3574@shareable.org \
--to=jamie@shareable.org \
--cc=James.Bottomley@suse.de \
--cc=akpm@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=eparis@redhat.com \
--cc=fengguang.wu@intel.com \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=rdreier@cisco.com \
--cc=schwab@linux-m68k.org \
--cc=sfr@canb.auug.org.au \
--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.