[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aSiSV9SKClTZAVjy@smile.fi.intel.com>
Date: Thu, 27 Nov 2025 20:03:03 +0200
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Chuck Lever <cel@...nel.org>
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 Thu, Nov 27, 2025 at 12:08:09PM -0500, Chuck Lever wrote:
> 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.
Ah, that's wonderful, thanks!
> > 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.
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists