[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <174362375580.124554.17129111199347955680.b4-ty@oracle.com>
Date: Wed, 2 Apr 2025 15:56:23 -0400
From: cel@...nel.org
To: linux-nfs@...r.kernel.org,
Trond Myklebust <trondmy@...nel.org>,
Anna Schumaker <anna@...nel.org>,
Jeff Layton <jlayton@...nel.org>,
Eric Biggers <ebiggers@...nel.org>
Cc: Chuck Lever <chuck.lever@...cle.com>,
Neil Brown <neilb@...e.de>,
Olga Kornievskaia <okorniev@...hat.com>,
Dai Ngo <Dai.Ngo@...cle.com>,
Tom Talpey <tom@...pey.com>,
Ard Biesheuvel <ardb@...nel.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] nfs: add missing selections of CONFIG_CRC32
From: Chuck Lever <chuck.lever@...cle.com>
On Tue, 01 Apr 2025 15:02:21 -0700, Eric Biggers wrote:
> nfs.ko, nfsd.ko, and lockd.ko all use crc32_le(), which is available
> only when CONFIG_CRC32 is enabled. But the only NFS kconfig option that
> selected CONFIG_CRC32 was CONFIG_NFS_DEBUG, which is client-specific and
> did not actually guard the use of crc32_le() even on the client.
>
> The code worked around this bug by only actually calling crc32_le() when
> CONFIG_CRC32 is built-in, instead hard-coding '0' in other cases. This
> avoided randconfig build errors, and in real kernels the fallback code
> was unlikely to be reached since CONFIG_CRC32 is 'default y'. But, this
> really needs to just be done properly, especially now that I'm planning
> to update CONFIG_CRC32 to not be 'default y'.
>
> [...]
Applied to nfsd-testing, thanks!
[1/1] nfs: add missing selections of CONFIG_CRC32
commit: 3d28468e53a519bb8adc0675e5000f56f11e0602
--
Chuck Lever
Powered by blists - more mailing lists