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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 328B8C433EF for ; Wed, 6 Apr 2022 02:27:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1848704AbiDFC17 (ORCPT ); Tue, 5 Apr 2022 22:27:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47046 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1355453AbiDEVZH (ORCPT ); Tue, 5 Apr 2022 17:25:07 -0400 Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 8CD3B45781; Tue, 5 Apr 2022 14:05:19 -0700 (PDT) Received: from dread.disaster.area (pa49-180-43-123.pa.nsw.optusnet.com.au [49.180.43.123]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id 192125343E2; Wed, 6 Apr 2022 07:05:15 +1000 (AEST) Received: from dave by dread.disaster.area with local (Exim 4.92.3) (envelope-from ) id 1nbqMT-00ECQO-OU; Wed, 06 Apr 2022 07:05:13 +1000 Date: Wed, 6 Apr 2022 07:05:13 +1000 From: Dave Chinner To: Arnd Bergmann Cc: Geert Uytterhoeven , Linux Kernel Mailing List , linux-xfs Subject: Re: Build regressions/improvements in v5.18-rc1 Message-ID: <20220405210513.GX1544202@dread.disaster.area> References: <20220404074734.1092959-1-geert@linux-m68k.org> <20220404092655.GR1544202@dread.disaster.area> <20220404221605.GS1544202@dread.disaster.area> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.4 cv=deDjYVbe c=1 sm=1 tr=0 ts=624caf0e a=MV6E7+DvwtTitA3W+3A2Lw==:117 a=MV6E7+DvwtTitA3W+3A2Lw==:17 a=kj9zAlcOel0A:10 a=z0gMJWrwH1QA:10 a=tBb2bbeoAAAA:8 a=7-415B0cAAAA:8 a=1b_iF-D28r213wdehakA:9 a=CjuIK1q_8ugA:10 a=Oj-tNtZlA1e06AYgeCfH:22 a=biEYGPWJfzWAr4FL6Ov7:22 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 05, 2022 at 09:08:13AM +0200, Arnd Bergmann wrote: > ?On Tue, Apr 5, 2022 at 8:47 AM Geert Uytterhoeven wrote: > > On Tue, Apr 5, 2022 at 12:16 AM Dave Chinner wrote: > > > So XFS only uses these flags in unsigned int fields that are > > > typed via: > > > > > > typedef unsigned int xfs_buf_flags_t; > > > > > > So on the surface, declaring the flag values as ULONG and then writing > > > them into a UINT field is not a nice thing to be doing. > > > > > > I really don't want to change the xfs_buf_flags_t type to an > > > unsigned long, because that changes the packing of the first > > > cacheline of the struct xfs_buf and the contents of that cacheline > > > are performance critical for the lookup fastpath.... > > > > Hence just use "1u << n" instead of "1ul << n"? > > Right, that avoids the error as well. I picked '1ul' to match the type of > the variable it's assigned to, but as Dave said the intended type is > 'u32', so '1u' is better here. Ok, I'll queue up a patch to make this modification. I'll also need to check all the other trace flags fields we print as well, as they likely have the same issue but there's no warnings from them because they don't use the high bit in the 32 bit field yet... > > > Looking at __print_flags, the internal array type declaration is: > > > > > > struct trace_print_flags { > > > unsigned long mask; > > > const char *name; > > > }; > > > > > > and that's the source of the problem. I notice __print_flags_u64() > > > exists, but __print_flags_u32() does not. Should it? > > It's not the source of the error, as there is no signed integer > overflow when assigning an unsigned int to an unsigned long. Thanks for the clarification! Cheers, Dave. -- Dave Chinner david@fromorbit.com