From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A2158192B7D for ; Mon, 23 Feb 2026 20:19:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771877990; cv=none; b=uYmAFYmqDO/SlPrEdua/KoSAF0zj8OdO04bhDFEbm1E9RnoVDzyfSl+tifWK9LcoVFE/5E9iCeLXigILtJNHdo7mvsREIlcIGysZnKIa4zXuZ1z2RLad0kAXbqBpWu/M2QT3mAtH8Hbw5xqZ/HOo8OvbPc68wQeShd4xrgkbyxc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771877990; c=relaxed/simple; bh=O6kaJ6BqoSgo2YWlp/Ph32I5Ra/YPQ2Pvj+/ly6tr1Q=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=h+y+37v4ZZJ0PE6cDdUtfWymP0IiLnduJJfEPaIKmZf/UAgvLpGr5bdfF0OIYa9KxBdu3oQvGzI7/66Irg6/5C/zdPTVoxv1j9fBLyH8mlR+Z5R09OF25R1RZ/2FgX93f5PVbGQYGL/zM5MEPeglIL950mvFCr+t3IrVKpV67Us= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=LaxyuNoo; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="LaxyuNoo" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AAFE0C116C6; Mon, 23 Feb 2026 20:19:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1771877990; bh=O6kaJ6BqoSgo2YWlp/Ph32I5Ra/YPQ2Pvj+/ly6tr1Q=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=LaxyuNoo1ePRejwSrX1HXatf9uNcmA9RJSqku1TGepzVQBOXYou3rRFi6n+hIj4dZ aBhV68FIMmhgZm+96PK8w2Ggr1o8noIVpeRRAp9u9ldYAotFYsqgBcPT6wfbPKTM9B dGMNhkKMOlStgnWRJ1ewRDfAoTzuBACDoujH8l2n74F8GpnXhKcQPz6nxm+J7b16XM IAu1WX760uncsqVjzGHZUIR/ZpW2tDt1TeUT6OnWtPdRk8yO7YJpwdEpDyBUpVib7+ dWg6IxQ5NhHq6ePr5S8EB+80ImoLz+m8F8PQ78IDGIIM+t4R93j6hZFC+xTNRX4Yix ONdNW6xpOxlng== Date: Mon, 23 Feb 2026 15:19:48 -0500 From: Mike Snitzer To: Anna Schumaker Cc: Niklas Cassel , linux-nfs@vger.kernel.org, torvalds@linux-foundation.org, dlemoal@kernel.org Subject: Re: [GIT PULL] Please Pull NFS Client Updates for Linux 7.0 Message-ID: References: <20260212220625.358550-1-anna@kernel.org> <537b11ee-575a-4d03-8100-fc70afbefd5d@app.fastmail.com> Precedence: bulk X-Mailing-List: linux-nfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <537b11ee-575a-4d03-8100-fc70afbefd5d@app.fastmail.com> On Wed, Feb 18, 2026 at 11:24:42AM -0500, Anna Schumaker wrote: > > > On Mon, Feb 16, 2026, at 10:31 AM, Niklas Cassel wrote: > > On Thu, Feb 12, 2026 at 05:06:25PM -0500, Anna Schumaker wrote: > >> Hi Linus, > >> > >> The following changes since commit 24d479d26b25bce5faea3ddd9fa8f3a6c3129ea7: > >> > >> Linux 6.19-rc6 (2026-01-18 15:42:45 -0800) > >> > >> are available in the Git repository at: > >> > >> git://git.linux-nfs.org/projects/anna/linux-nfs.git tags/nfs-for-7.0-1 > >> > >> for you to fetch changes up to dd2fdc3504592d85e549c523b054898a036a6afe: > >> > >> SUNRPC: fix gss_auth kref leak in gss_alloc_msg error path (2026-02-09 16:39:50 -0500) > >> > >> ---------------------------------------------------------------- > >> NFS Client Updates for Linux 7.0 > >> > >> New Features: > >> * Use an LRU list for returning unused delegations > >> * Introduce a KConfig option to disable NFS v4.0 and make NFS v4.1 the default > >> > >> Bugfixes: > >> * NFS/localio: Handle short writes by retrying > >> * NFS/localio: prevent direct reclaim recursion into NFS via nfs_writepages > >> * NFS/localio: use GFP_NOIO and non-memreclaim workqueue in nfs_local_commit > >> * NFS/localio: remove -EAGAIN handling in nfs_local_doio() > >> * pNFS: fix a missing wake up while waiting on NFS_LAYOUT_DRAIN > >> * fs/nfs: Fix a readdir slow-start regression > >> * SUNRPC: fix gss_auth kref leak in gss_alloc_msg error path > >> > >> Other Cleanups and Improvements: > >> * A few other NFS/localio cleanups > >> * Various other delegation handling cleanups from Christoph > >> * Unify security_inode_listsecurity() calls > >> * Improvements to NFSv4 lease handling > >> * Clean up SUNRPC *_debug fields when CONFIG_SUNRPC_DEBUG is not set > >> > >> Thanks, > >> Anna > > > > Hello Anna, > > > > This seems to break my setup: > > > > [ 103.402033] VFS: Unable to mount root fs via NFS. > > [ 103.402476] devtmpfs: mounted > > [ 103.406171] Freeing unused kernel memory: 4352K > > [ 103.406633] Run /sbin/init as init process > > [ 103.406993] with arguments: > > [ 103.407253] /sbin/init > > [ 103.407491] with environment: > > [ 103.407767] HOME=/ > > [ 103.407976] TERM=linux > > [ 103.408228] Run /etc/init as init process > > [ 103.408580] with arguments: > > [ 103.408841] /etc/init > > [ 103.409071] with environment: > > [ 103.409346] HOME=/ > > [ 103.409553] TERM=linux > > [ 103.409802] Run /bin/init as init process > > [ 103.410153] with arguments: > > [ 103.410414] /bin/init > > [ 103.410644] with environment: > > [ 103.410920] HOME=/ > > [ 103.411128] TERM=linux > > [ 103.411367] Run /bin/sh as init process > > [ 103.411703] with arguments: > > [ 103.411963] /bin/sh > > [ 103.412179] with environment: > > [ 103.412454] HOME=/ > > [ 103.412662] TERM=linux > > [ 103.412904] Kernel panic - not syncing: No working init found. Try > > passing init= option to kernel. See Linux > > Documentation/admin-guide/init.rst for guidance. > > > > > > Doing a git bisect results in: > > > > commit 4e0269352534715915aae3fb84dd4d3bb3ff3738 > > Author: Anna Schumaker > > Date: Fri Nov 21 14:53:50 2025 -0500 > > > > NFS: Add a way to disable NFS v4.0 via KConfig > > > > I introduce NFS4_MIN_MINOR_VERSION as a parallel to > > NFS4_MAX_MINOR_VERSION to check if NFS v4.0 has been compiled in and > > return an appropriate error if not. > > > > > > > > Before commit above my config has: > > CONFIG_NFS_FS=y > > CONFIG_NFS_V4=y > > CONFIG_NFS_V4_1=y > > CONFIG_NFS_V4_2=y > > > > after commit above (with make olddefconfig), my config has: > > CONFIG_NFS_FS=y > > CONFIG_NFS_V4=y > > # CONFIG_NFS_V4_0 is not set > > CONFIG_NFS_V4_1=y > > CONFIG_NFS_V4_2=y > > > > > > > > My kernel command line has: > > nfsroot=192.168.1.10:/srv/nfs/rootfs,nfsvers=4 > > > > > > I notice that I am probably stupid who has the above, as I assumed that > > it meant use the best NFS 4.x version supported by the kernel. > > > > > > If I change it to: > > nfsroot=192.168.1.10:/srv/nfs/rootfs,nfsvers=4.2 > > > > The config: > > CONFIG_NFS_FS=y > > CONFIG_NFS_V4=y > > # CONFIG_NFS_V4_0 is not set > > CONFIG_NFS_V4_1=y > > CONFIG_NFS_V4_2=y > > > > successfully mounts my rootfs. > > > > > > So AFAICT, it seems that nfsvers=4 actually means nfsvers=4.0 > > > > I am probably not the only person to who has "nfsvers=4" on the kernel > > command line. > > > > > > > > Possible solutions I can see: > > > > If the intention is for commit 4e0269352534 ("NFS: Add a way to disable > > NFS v4.0 via KConfig") to allow people to disable NFS 4.0, we could > > change the new "config NFS_V4_0" to be either "default y". > > This is what I intended, actually. I don't know how the missing "default y" > slipped through the cracks for this long. Thanks for pointing it out, I'll > get this fixed up! > > Anna > > > > > or > > > > Perhaps we could modify "nfsvers=4" to actually mean "use whatever highest > > NFS 4.x version supported by the kernel", rather than use NFS 4.0 and only > > 4.0. Another related problem I just encountered, when doing a bisect that pivoted from 7.0-rc1 back down to 6.19, is that "make olddefconfig" using the 7.0-rc1's .config as starting point against 6.19 kernel results in: # CONFIG_NFS_V4_1 is not set # CONFIG_NFS_V4_2 is not set CONFIG_PNFS_FLEXFILE_LAYOUT=m doesn't exist, etc. So this change seriously breaks NFS bisect-ability. Feels like the new CONFIG_NFS_V4_0 control should be standalone and CONFIG_NFS_V4_1 shouldn't be removed. But the devil is in the details I'm sure... Mike