[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <52260b53-9ed8-400a-aaed-b1dc9e7910e9@kernel.org>
Date: Thu, 27 Nov 2025 12:08:09 -0500
From: Chuck Lever <cel@...nel.org>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: linux-nfs@...r.kernel.org, linux-kernel@...r.kernel.org,
llvm@...ts.linux.dev, Chuck Lever <chuck.lever@...cle.com>,
Jeff Layton <jlayton@...nel.org>, NeilBrown <neil@...wn.name>,
Olga Kornievskaia <okorniev@...hat.com>, Dai Ngo <Dai.Ngo@...cle.com>,
Tom Talpey <tom@...pey.com>, Nathan Chancellor <nathan@...nel.org>,
Nick Desaulniers <nick.desaulniers+lkml@...il.com>,
Bill Wendling <morbo@...gle.com>, Justin Stitt <justinstitt@...gle.com>
Subject: Re: [PATCH v1 1/1] nfsd: Mark variable __maybe_unused to avoid W=1
build break
On 11/27/25 11:55 AM, Andy Shevchenko wrote:
> On Thu, Nov 27, 2025 at 11:20:16AM -0500, Chuck Lever wrote:
>> On 11/27/25 2:50 AM, Andy Shevchenko wrote:
>>> On Mon, Nov 17, 2025 at 08:49:29AM -0500, Chuck Lever wrote:
>>>> On Thu, 13 Nov 2025 09:31:31 +0100, Andy Shevchenko wrote:
>>>>> Clang is not happy about set but (in some cases) unused variable:
>>>>>
>>>>> fs/nfsd/export.c:1027:17: error: variable 'inode' set but not used [-Werror,-Wunused-but-set-variable]
>>>>>
>>>>> since it's used as a parameter to dprintk() which might be configured
>>>>> a no-op. To avoid uglifying code with the specific ifdeffery just mark
>>>>> the variable __maybe_unused.
>
> [...]
>
>>>> Applied to nfsd-testing, thanks!
>>>>
>>>> [1/1] nfsd: Mark variable __maybe_unused to avoid W=1 build break
>>>> commit: 56e9f88b25abf08de6f2b1bfbbb2ddc4e6622d1e
>>>
>>> Thanks, but still no appearance in Linux Next and problem seems to be present.
>>>
>>
>> The usual practice is to keep patches in nfsd-testing for four
>> weeks to allow NFSD and community CI processes to work, and to
>> enable extended review before it is merged. Both the community
>> CI processes (eg, zero-day bots) and the availability of
>> reviewers are not something I have control over.
>>
>> It will be available for upstream merge after December 11. You
>> seem to be suggesting there is a sense of urgency so I will
>> direct it towards v6.20-rc as soon as it is merge-ready.
Oops:
s/v6.20-rc/v6.19-rc/
> Since it's (not so critical TBH, but still) a build breakage I supposed this to
> go via the respective -fixes path.
Yes, what I meant above was I will submit it just after the
v6.19 merge window closes in a few weeks.
> But okay, your call.
It's just a build warning, but I know such issues affect the
Fedora and Red Hat kernel build pipelines, as they enable the
"warning => error" compile option.
However, those distributions enable SunRPC debugging, which
means they won't see it. So I think this problem is not likely
to be pervasive.
--
Chuck Lever
Powered by blists - more mailing lists