From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C51ACC433C1 for ; Mon, 22 Mar 2021 08:58:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 74E8A61972 for ; Mon, 22 Mar 2021 08:58:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229941AbhCVI61 convert rfc822-to-8bit (ORCPT ); Mon, 22 Mar 2021 04:58:27 -0400 Received: from eu-smtp-delivery-151.mimecast.com ([185.58.86.151]:34332 "EHLO eu-smtp-delivery-151.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229508AbhCVI6T (ORCPT ); Mon, 22 Mar 2021 04:58:19 -0400 Received: from AcuMS.aculab.com (156.67.243.126 [156.67.243.126]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-245-4lZc9m03OW2Pu2atP1wGzw-1; Mon, 22 Mar 2021 08:58:12 +0000 X-MC-Unique: 4lZc9m03OW2Pu2atP1wGzw-1 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b:0:994c:f5c2:35d6:9b65) by AcuMS.aculab.com (fd9f:af1c:a25b:0:994c:f5c2:35d6:9b65) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 22 Mar 2021 08:58:11 +0000 Received: from AcuMS.Aculab.com ([fe80::994c:f5c2:35d6:9b65]) by AcuMS.aculab.com ([fe80::994c:f5c2:35d6:9b65%12]) with mapi id 15.00.1497.012; Mon, 22 Mar 2021 08:58:11 +0000 From: David Laight To: 'Herbert Xu' , "menglong8.dong@gmail.com" CC: "andy.shevchenko@gmail.com" , "kuba@kernel.org" , "linux@roeck-us.net" , "davem@davemloft.net" , "dong.menglong@zte.com.cn" , "viro@zeniv.linux.org.uk" , "axboe@kernel.dk" , "linux-kernel@vger.kernel.org" , "netdev@vger.kernel.org" Subject: RE: [PATCH net-next 2/2] net: socket: change MSG_CMSG_COMPAT to BIT(21) Thread-Topic: [PATCH net-next 2/2] net: socket: change MSG_CMSG_COMPAT to BIT(21) Thread-Index: AQHXHlCgGHDgaZN5KE6t5P14se4atKqPtAlQ Date: Mon, 22 Mar 2021 08:58:11 +0000 Message-ID: References: <20210321123929.142838-1-dong.menglong@zte.com.cn> <20210321123929.142838-3-dong.menglong@zte.com.cn> <20210321124906.GA14333@gondor.apana.org.au> In-Reply-To: <20210321124906.GA14333@gondor.apana.org.au> Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C51A453 smtp.mailfrom=david.laight@aculab.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Herbert Xu > Sent: 21 March 2021 12:49 > > On Sun, Mar 21, 2021 at 08:39:29PM +0800, menglong8.dong@gmail.com wrote: > > > > diff --git a/include/linux/socket.h b/include/linux/socket.h > > index d5ebfe30d96b..317b2933f499 100644 > > --- a/include/linux/socket.h > > +++ b/include/linux/socket.h > > @@ -312,17 +312,18 @@ struct ucred { > > * plain text and require encryption > > */ > > > > +#if defined(CONFIG_COMPAT) > > +#define MSG_CMSG_COMPAT BIT(21) /* This message needs 32 bit fixups */ > > +#else > > +#define MSG_CMSG_COMPAT 0 /* We never have 32 bit fixups */ > > +#endif > > + > > #define MSG_ZEROCOPY BIT(26) /* Use user data in kernel path */ > > #define MSG_FASTOPEN BIT(29) /* Send data in TCP SYN */ > > #define MSG_CMSG_CLOEXEC BIT(30) /* Set close_on_exec for file > > * descriptor received through > > * SCM_RIGHTS > > */ > > -#if defined(CONFIG_COMPAT) > > -#define MSG_CMSG_COMPAT BIT(31) /* This message needs 32 bit fixups */ > > -#else > > -#define MSG_CMSG_COMPAT 0 /* We never have 32 bit fixups */ > > -#endif > > Shouldn't you add some comment here to stop people from trying to > use BIT(31) in the future? You'd also be better using BIT(30) - ie the other end of the free space from the user-visible bits. It has to be said that the entire impossibility of writing BIT(n) safely almost makes it worse that just defining appropriate constants. Personally I like the hex constants. The make it much easier to work out which bits are set in a diagnostic print (or memory hexdump). The only time I've really found BIT() type macros useful is when defining values that have to match hardware specs that define bit numbers backwards starting from 1. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)