From: Oliver Sang <oliver.sang@intel.com>
To: NeilBrown <neil@brown.name>
Cc: Amir Goldstein <amir73il@gmail.com>,
Christian Brauner <brauner@kernel.org>,
Jeff Layton <jlayton@kernel.org>, <oe-lkp@lists.linux.dev>,
<lkp@intel.com>, <netfs@lists.linux.dev>,
<linux-fsdevel@vger.kernel.org>, <linux-nfs@vger.kernel.org>,
<linux-unionfs@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<oliver.sang@intel.com>
Subject: Re: [linux-next:master] [VFS/nfsd/cachefiles/ovl] 7ab96df840: WARNING:at_fs/dcache.c:#umount_check
Date: Thu, 27 Nov 2025 12:58:33 +0800 [thread overview]
Message-ID: <aSfaeaUN3H8ozEbF@xsang-OptiPlex-9020> (raw)
In-Reply-To: <176419027888.634289.8284458326359928729@noble.neil.brown.name>
hi, NeilBrown,
On Thu, Nov 27, 2025 at 07:51:18AM +1100, NeilBrown wrote:
> On Wed, 26 Nov 2025, Amir Goldstein wrote:
> > On Wed, Nov 26, 2025 at 11:42 AM Christian Brauner <brauner@kernel.org> wrote:
> > >
> > > On Tue, Nov 25, 2025 at 09:48:18PM +0800, kernel test robot wrote:
> > > >
> > > > Hello,
> > > >
> > > > kernel test robot noticed "WARNING:at_fs/dcache.c:#umount_check" on:
> > > >
> > > > commit: 7ab96df840e60eb933abfe65fc5fe44e72f16dc0 ("VFS/nfsd/cachefiles/ovl: add start_creating() and end_creating()")
> > > > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
> > > >
> > > > [test failed on linux-next/master d724c6f85e80a23ed46b7ebc6e38b527c09d64f5]
> > >
> > > Neil, can you please take a look at this soon?
> > > I plan on sending the batch of PRs for this cycle on Friday.
> > >
> > > >
> > > > in testcase: filebench
> > > > version: filebench-x86_64-22620e6-1_20251009
> > > > with following parameters:
> > > >
> > > > disk: 1SSD
> > > > fs: ext4
> > > > fs2: nfsv4
> > > > test: ratelimcopyfiles.f
> > > > cpufreq_governor: performance
> > > >
> >
> > Test is copying to nfsv4 so that's the immediate suspect.
> > WARN_ON is in unmount of ext4, but I suspect that nfs
> > was loop mounted for the test.
> >
> > FWIW, nfsd_proc_create() looks very suspicious.
> >
> > nfsd_create_locked() does end_creating() internally (internal API change)
> > but nfsd_create_locked() still does end_creating() regardless.
>
> Thanks for looking at this Amir. That omission in nfsproc.c is
> certainly part of the problem but not all of it.
> By skipping the end_creating() there, we avoid a duplicate unlock, but
> also lose a dput() which we need. Both callers of nfsd_create_locked()
> have the same problem.
> I think this should fix it. The resulting code is a bit ugly but I can
> fix that with the nfsd team once this gets upstream.
>
> (FYI nfsd_proc_create() is only used for NFSv2 and as it was an nfsv4 test,
> that could wouldn't have been run)
>
> Thanks,
> NeilBrown
we tested below patch, confirmed it could fix the issues in our original
reports. thanks!
Tested-by: kernel test robot <oliver.sang@intel.com>
>
> diff --git a/fs/nfsd/nfsproc.c b/fs/nfsd/nfsproc.c
> index 28f03a6a3cc3..481e789a7697 100644
> --- a/fs/nfsd/nfsproc.c
> +++ b/fs/nfsd/nfsproc.c
> @@ -407,6 +407,9 @@ nfsd_proc_create(struct svc_rqst *rqstp)
> /* File doesn't exist. Create it and set attrs */
> resp->status = nfsd_create_locked(rqstp, dirfhp, &attrs, type,
> rdev, newfhp);
> + /* nfsd_create_locked() unlocked the parent */
> + dput(dchild);
> + goto out_write;
> } else if (type == S_IFREG) {
> dprintk("nfsd: existing %s, valid=%x, size=%ld\n",
> argp->name, attr->ia_valid, (long) attr->ia_size);
> diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
> index 145f1c8d124d..4688f3fd59e2 100644
> --- a/fs/nfsd/vfs.c
> +++ b/fs/nfsd/vfs.c
> @@ -1633,16 +1633,14 @@ nfsd_create(struct svc_rqst *rqstp, struct svc_fh *fhp,
> return nfserrno(host_err);
>
> err = fh_compose(resfhp, fhp->fh_export, dchild, fhp);
> - /*
> - * We unconditionally drop our ref to dchild as fh_compose will have
> - * already grabbed its own ref for it.
> - */
> if (err)
> goto out_unlock;
> err = fh_fill_pre_attrs(fhp);
> if (err != nfs_ok)
> goto out_unlock;
> err = nfsd_create_locked(rqstp, fhp, attrs, type, rdev, resfhp);
> + /* nfsd_create_locked() unlocked the parent */
> + dput(dchild);
> return err;
>
> out_unlock:
next prev parent reply other threads:[~2025-11-27 4:58 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-25 13:48 kernel test robot
2025-11-26 10:42 ` Christian Brauner
2025-11-26 12:29 ` Amir Goldstein
2025-11-26 20:51 ` NeilBrown
2025-11-27 4:58 ` Oliver Sang [this message]
2025-11-27 10:53 ` Christian Brauner
2025-11-27 11:03 ` NeilBrown
2025-11-27 2:41 ` Oliver Sang
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=aSfaeaUN3H8ozEbF@xsang-OptiPlex-9020 \
--to=oliver.sang@intel.com \
--cc=amir73il@gmail.com \
--cc=brauner@kernel.org \
--cc=jlayton@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=lkp@intel.com \
--cc=neil@brown.name \
--cc=netfs@lists.linux.dev \
--cc=oe-lkp@lists.linux.dev \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®