All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Snitzer <snitzer@kernel.org>
To: Anna Schumaker <anna@kernel.org>
Cc: Niklas Cassel <cassel@kernel.org>,
	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
Date: Mon, 23 Feb 2026 15:19:48 -0500	[thread overview]
Message-ID: <aZy2ZKfttaLhioBV@kernel.org> (raw)
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 <anna.schumaker@oracle.com>
> > 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

      reply	other threads:[~2026-02-23 20:19 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-12 22:06 [GIT PULL] Please Pull NFS Client Updates for Linux 7.0 Anna Schumaker
2026-02-13  2:04 ` pr-tracker-bot
2026-02-16 15:31 ` Niklas Cassel
2026-02-18 16:24   ` Anna Schumaker
2026-02-23 20:19     ` Mike Snitzer [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aZy2ZKfttaLhioBV@kernel.org \
    --to=snitzer@kernel.org \
    --cc=anna@kernel.org \
    --cc=cassel@kernel.org \
    --cc=dlemoal@kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.