Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751965AbdGFPG3 (ORCPT ); Thu, 6 Jul 2017 11:06:29 -0400 Received: from verein.lst.de ([213.95.11.211]:60367 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750922AbdGFPG2 (ORCPT ); Thu, 6 Jul 2017 11:06:28 -0400 Date: Thu, 6 Jul 2017 17:06:27 +0200 From: Christoph Hellwig To: Al Viro Cc: Christoph Hellwig , Linus Torvalds , Linux Kernel Mailing List , linux-fsdevel Subject: Re: [git pull] vfs.git part 3 Message-ID: <20170706150627.GA1835@lst.de> References: <20170705071446.GA10672@ZenIV.linux.org.uk> <20170705223821.GF10672@ZenIV.linux.org.uk> <20170705225235.GA11849@lst.de> <20170705232912.GG10672@ZenIV.linux.org.uk> <20170706144840.GA1400@lst.de> <20170706150330.GQ10672@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170706150330.GQ10672@ZenIV.linux.org.uk> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1445 Lines: 43 On Thu, Jul 06, 2017 at 04:03:30PM +0100, Al Viro wrote: > #define __SC_CAST(t, a) (__force t) a > > in syscalls.h Hmm. > > > index a2d4a8ac94ca..a04adbc70ddf 100644 > > --- a/include/uapi/linux/aio_abi.h > > +++ b/include/uapi/linux/aio_abi.h > > @@ -28,6 +28,7 @@ > > #define __LINUX__AIO_ABI_H > > > > #include > > +#include > > Um... Includes of non-uapi in uapi are wrong. What do you need > fs.h for, anyway? Just put the typedef into uapi/linux/types.h > and be done with that... We automatically get the non-uapi one for userspace. And we do in fact need to write it that way as it will not show up as uapi/ in userspace. But yes, the type could be taken to types.h > > > +#define BLK_STS_OK 0 > > +#define BLK_STS_NOTSUPP ((__force blk_status_t)1) > > +#define BLK_STS_TIMEOUT ((__force blk_status_t)2) > > +#define BLK_STS_NOSPC ((__force blk_status_t)3) > > +#define BLK_STS_TRANSPORT ((__force blk_status_t)4) > > +#define BLK_STS_TARGET ((__force blk_status_t)5) > > +#define BLK_STS_NEXUS ((__force blk_status_t)6) > > WTF is that doing here? If nothing else, it's a userland namespace > pollution; typedefs with such names are OK in the kernel, but not > is something that might be included from userland. And that chunk > doesn't seem to have anything to do with the rest of the patch... It doesn't that was the copy and paste of the __bitwise boilerplate I staeted with..