Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp195073pxb; Tue, 23 Feb 2021 22:53:15 -0800 (PST) X-Google-Smtp-Source: ABdhPJxw+cUOFPcMTcncUUIRKM2zQg71Qo/BpRoK5Az0rupvduzLSIFevvZLLdE/B0zc+nvhjAx1 X-Received: by 2002:a05:6402:ca2:: with SMTP id cn2mr23277215edb.73.1614149595078; Tue, 23 Feb 2021 22:53:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614149595; cv=none; d=google.com; s=arc-20160816; b=bafKXoDrM/NAVOUtYNgun+CBRS3zTJrWXLgXhtfhRnClArokhy3AB9tZfxmKC9E0mN FWy52edXF/cLVU6ki6cP5cAqR3xCB30MSWCl/UiA1D9z1Llv7ZlBTknyQ9Yr+M+B/CMQ d9ErZH5LCADCae2MOhBPicglIbvAZm8oEk9qQaRnil34tcbe99Q9Naj4ZTZ7+iWFF+/N jk/8mCb/g7fRpp9K6HY/r2iQ4aNoquAhnDzTQnRNRR79vFt1L3d5RbCoNiqV5FMWlk7R 4TYz+rc4kJ9vOVi240PkdO1LYPfCgei/GXLAgHU7toRO636hBQu4KGQ5Me61D9zwnAZk gBJg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature:dkim-filter; bh=oN7IRg3W9fn8dx2VR7makKAXxb9/wBxnTjP722qMAhs=; b=BXDmIPLa/r6VR1+HX0RIX8bWdAd/MQGTpDSuPjpKxcTpQcure2VfUeyY4qIcWCAV6z 5J0hIT0SMbD7YNGyK+uguB3ZJBcGD6erlbDWsd29GEK40Jimp84Urfor9SW9KbAc/LXQ hSgYO2P2LVXZkbyIh/2Y7b332vXZAhGfb/Fe2QGA1aRYh0SDGwNM79UcPRluin55+4Xx 25VDBBsFrCDY4gQiuNX/+eoflvFVM+B5GD3LBB9C2TixyZtuaUl+mUhejDfc9uqwHbIA ebNGuZElm64DXRv70rzynOJXWyOrIU26iF98knyD6TH8u7nIttmNRnZh6j7pd1foERIz DYoA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b=YWBPty69; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bf13si585794edb.426.2021.02.23.22.52.51; Tue, 23 Feb 2021 22:53:15 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b=YWBPty69; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232350AbhBXB66 (ORCPT + 99 others); Tue, 23 Feb 2021 20:58:58 -0500 Received: from conssluserg-02.nifty.com ([210.131.2.81]:19425 "EHLO conssluserg-02.nifty.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231787AbhBXB65 (ORCPT ); Tue, 23 Feb 2021 20:58:57 -0500 Received: from mail-pf1-f181.google.com (mail-pf1-f181.google.com [209.85.210.181]) (authenticated) by conssluserg-02.nifty.com with ESMTP id 11O1vhIv021809; Wed, 24 Feb 2021 10:57:43 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-02.nifty.com 11O1vhIv021809 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.com; s=dec2015msa; t=1614131863; bh=oN7IRg3W9fn8dx2VR7makKAXxb9/wBxnTjP722qMAhs=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=YWBPty69kNzqLAcSjQa1GPIfQfK32pxy29IBm4KOe8RC5Nb7SLeag76l7NMP+p8db I+VXHZZHA14rS63qq5ELg7GVb6nx8ZqatFwPTJMFeFudXkyIzzY5vitaXdemFO+1nF yfTVWsFvYJtQ4/3mXMKZurd/IMHrLpJpRPny95AWoGLjgR/VJW79AyMl14VqY3JXdJ 8JFlLUoQsS62/zAuoT7ZPWHBltG/24DfpKBseG6N1LXsacpMWnGxGDkOBOa+ydfMgR HCljnx669LZ0Alwb50A1XHmd1P1qUJNk/YBb0JpNjXm0nqmm8UUHJ7AMs3a3xA31ya 19vDostmEl5PQ== X-Nifty-SrcIP: [209.85.210.181] Received: by mail-pf1-f181.google.com with SMTP id w18so256378pfu.9; Tue, 23 Feb 2021 17:57:43 -0800 (PST) X-Gm-Message-State: AOAM53133ncd2P+RhbNk+9HAaIBRh0IXfIr65mxwfbQxYNWyY9KA2Vb+ NSHtULX3SezH88NicCdvllj+0s4hI9d127n1Ttc= X-Received: by 2002:a63:cc4f:: with SMTP id q15mr11813294pgi.47.1614131862821; Tue, 23 Feb 2021 17:57:42 -0800 (PST) MIME-Version: 1.0 References: <20210223100619.798698-1-masahiroy@kernel.org> In-Reply-To: From: Masahiro Yamada Date: Wed, 24 Feb 2021 10:57:05 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] asm-generic/ioctl.h: use BUILD_BUG_ON_ZERO() for type check To: Arnd Bergmann Cc: Andrew Morton , Arnd Bergmann , "linux-kernel@vger.kernel.org" , linux-arch Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 24, 2021 at 5:04 AM Arnd Bergmann wrote: > > On Tue, Feb 23, 2021 at 11:06 AM Masahiro Yamada wrote: > > > > > -#ifdef __CHECKER__ > > -#define _IOC_TYPECHECK(t) (sizeof(t)) > > -#else > > /* provoke compile error for invalid uses of size argument */ > > -extern unsigned int __invalid_size_argument_for_IOC; > > +#undef _IOC_TYPECHECK > > #define _IOC_TYPECHECK(t) \ > > - ((sizeof(t) == sizeof(t[1]) && \ > > - sizeof(t) < (1 << _IOC_SIZEBITS)) ? \ > > - sizeof(t) : __invalid_size_argument_for_IOC) > > -#endif > > + BUILD_BUG_ON_ZERO(sizeof(t) != sizeof(t[1]) || \ > > + sizeof(t) >= (1 << _IOC_SIZEBITS)) > > Using BUILD_BUG_ON_ZERO sounds like a good idea > > > #endif /* _ASM_GENERIC_IOCTL_H */ > > diff --git a/include/uapi/asm-generic/ioctl.h b/include/uapi/asm-generic/ioctl.h > > index a84f4db8a250..d50bd39ec3e3 100644 > > --- a/include/uapi/asm-generic/ioctl.h > > +++ b/include/uapi/asm-generic/ioctl.h > > @@ -72,9 +72,8 @@ > > ((nr) << _IOC_NRSHIFT) | \ > > ((size) << _IOC_SIZESHIFT)) > > > > -#ifndef __KERNEL__ > > -#define _IOC_TYPECHECK(t) (sizeof(t)) > > -#endif > > +#define _IOC_TYPECHECK(t) 0 > > +#define _IOC_SIZE_WITH_TYPECHECK(t) (sizeof(t) + _IOC_TYPECHECK(t)) > > But I think replacing the #ifndef with an #undef in the other file makes it > harder to understand when reading through it and trying to understand > what it would do when this gets included from kernel and user space. > > Arnd My intention is to improve the UAPI/KAPI decoupling to decrease the task of scripts/headers_install.sh Ideally, we could export UAPI headers with almost no modification. It is true that scripts/unifdef can remove #ifndef __KERNEL__ blocks, but having the kernel-space code in UAPI headers does not make sense. Otherwise, our initial motivation "separate them by directory structure" would be lost. So, I believe redefining _IOC_TYPECHECK is the right direction. I can add comments if this is not clear. -- Best Regards Masahiro Yamada