Re: kernel BUG at fs/nfsd/nfs4recover.c:534 Oops: invalid opcode: 0000

[Chuck Lever <chuck.lever@oracle.com>]

On 12/26/24 11:24 AM, Salvatore Bonaccorso wrote:
> Hi Jur,
> 
> On Mon, Dec 09, 2024 at 04:50:05PM +0000, Jur van der Burg via Bugspray Bot wrote:
>> Jur van der Burg writes via Kernel.org Bugzilla:
>>
>> I tried kernel 6.10.1 and that one is ok. In the mean time I
>> upgraded nfs-utils from 2.5.1 to 2.8.1 which seems to fix the issue.
>> Sorry for the noise, case closed.
>>
>> View: https://bugzilla.kernel.org/show_bug.cgi?id=219580#c2
>> You can reply to this message to join the discussion.
> 
> Are you sure this is solved? I got hit by this today after trying to
> check the report from another Debian user:
> 
> https://bugs.debian.org/1091439
> the earlier report was
> https://bugs.debian.org/1087900
> 
> Surprisingly I managed to hit this, after:
> 
> Doing a fresh Debian installation with Debian unstable, rebooting
> after installation. The running kernel is 6.12.6-1 (but now believe it
> might be hit in any sufficient earlier version):
> 
> Notably, in kernel-log I see as well
> 
> [   50.295209] RPC: Registered tcp NFSv4.1 backchannel transport module.
> [   52.158301] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
> [   52.158333] NFSD: Using legacy client tracking operations.

Hi Salvatore,

If you no longer provision nfsdcltrack in user space, then you want to
set CONFIG_NFSD_LEGACY_CLIENT_TRACKING to 'N' in your kernel config.

Otherwise, Scott Mayhew is the area expert (cc'd).


> [   52.158337] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
> 
> Normally it should have been (if using the more modern client racking
> operations):
> 
> 
> [  145.851951] RPC: Registered tcp NFSv4.1 backchannel transport module.
> [  146.891838] NFSD: Using nfsdcld client tracking operations.
> [  146.891844] NFSD: no clients to reclaim, skipping NFSv4 grace period (net f0000000)
> 
> I can reproduce it if I do in following order:
> 
> Install Debian unstable, reboot after installation.
> 
> Install nfs-kernel-server package with its dependencies.
> 
> In our case this is nfs-utils upstream already at 2.8.2.
> 
> I notice the following observation: When installing under this
> condition the package freshly there is not yet a valid:
> 
> /var/lib/nfs/nfsdcld/main.sqlite
> 
> for the nfsdcld, and so it used the legacy client tracking.
> 
> At this point we get the splat. if before installing the packages I
> initialize /var/lib/nfs/nfsdcld/main.sqlite:
> 
> mkdir -p /var/lib/nfs/nfsdcld
> chmod -c 0700 /var/lib/nfs/nfsdcld/
> 
> and
> 
> sqlite3 /var/lib/nfs/nfsdcld/main.sqlite <<SQL
> CREATE TABLE parameters (key TEXT PRIMARY KEY, value TEXT);
> CREATE TABLE grace (current INTEGER , recovery INTEGER);
> INSERT OR FAIL INTO grace values (1, 0);
> INSERT OR FAIL INTO parameters values ("version", "4");
> INSERT OR FAIL INTO parameters values ("first_time", "1");
> SQL
> 
> So to me it looks that the problem arises from actually starting the
> services were we have to fallback to the legacy method as we cannot
> use yet nfsdcld.
> 
> One other observation: if while installing the package the nfsdcltrack
> utility is available and the these NFS client tracking methods are
> availabe, it seems that the issue is not hit, and dmesg shows
> 
> [  216.206678] RPC: Registered tcp NFSv4.1 backchannel transport module.
> [  218.215961] NFSD: Using UMH upcall client tracking operations.
> [  218.218074] NFSD: Using UMH upcall client tracking operations.
> [  218.218078] NFSD: starting 90-second grace period (net f0000000)
> 
> In the most recent nfs-utils packages we do actually not install
> nfsdcltrack anymore as as I understand it's encouraged to move away
> form it as nfsdcld is available.
> 
> Regards,
> Salvatore


-- 
Chuck Lever