From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Bottomley Subject: Re: [patch 2/5] vfs: O_* bit numbers uniqueness check Date: Fri, 27 Aug 2010 00:53:44 -0500 Message-ID: <1282888424.8133.386.camel@mulgrave.site> References: <201007202229.o6KMTkEp021831@imap1.linux-foundation.org> <1282864959.8133.67.camel@mulgrave.site> <20100827012700.GK3574@shareable.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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 To: Jamie Lokier Return-path: Received: from cantor.suse.de ([195.135.220.2]:39801 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753494Ab0H0Fxx (ORCPT ); Fri, 27 Aug 2010 01:53:53 -0400 In-Reply-To: <20100827012700.GK3574@shareable.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Fri, 2010-08-27 at 02:27 +0100, Jamie Lokier wrote: > James Bottomley wrote: > > On Tue, 2010-07-20 at 15:29 -0700, akpm@linux-foundation.org wrote: > > > From: Wu Fengguang > > > > > > 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 .... )); Well, it works, but is it wise? There are several missing flags in this expression: O_NDELAY being the most noticeable one. It's defined to be the sames as O_NONBLOCK on some platforms and not on others. Our O_NONBLOCK problem is essentially the same class. > Am I allowed to Sign-off handwavy pseudocode? ;-) Nope ... you'd have to code it as a real patch ... James