From: bfields@fieldses.org (J. Bruce Fields)
To: "J. Bruce Fields" <bfields@redhat.com>
Cc: linux-nfs@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 1/2] nfsd: allow fh_want_write to be called twice
Date: Sat, 18 May 2019 16:04:11 -0400 [thread overview]
Message-ID: <20190518200411.GB32684@fieldses.org> (raw)
In-Reply-To: <1557969619-17157-2-git-send-email-bfields@redhat.com>
Ugh, sorry, ignore the two old patches that got sent with the new
series.
--b.
On Wed, May 15, 2019 at 09:20:06PM -0400, J. Bruce Fields wrote:
> From: "J. Bruce Fields" <bfields@redhat.com>
>
> A fuzzer recently triggered lockdep warnings about potential sb_writers
> deadlocks caused by fh_want_write().
>
> Looks like we aren't careful to pair each fh_want_write() with an
> fh_drop_write().
>
> It's not normally a problem since fh_put() will call fh_drop_write() for
> us. And was OK for NFSv3 where we'd do one operation that might call
> fh_want_write(), and then put the filehandle.
>
> But an NFSv4 protocol fuzzer can do weird things like call unlink twice
> in a compound, and then we get into trouble.
>
> I'm a little worried about this approach of just leaving everything to
> fh_put(). But I think there are probably a lot of
> fh_want_write()/fh_drop_write() imbalances so for now I think we need it
> to be more forgiving.
>
> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
> ---
> fs/nfsd/vfs.h | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/fs/nfsd/vfs.h b/fs/nfsd/vfs.h
> index a7e107309f76..db351247892d 100644
> --- a/fs/nfsd/vfs.h
> +++ b/fs/nfsd/vfs.h
> @@ -120,8 +120,11 @@ void nfsd_put_raparams(struct file *file, struct raparms *ra);
>
> static inline int fh_want_write(struct svc_fh *fh)
> {
> - int ret = mnt_want_write(fh->fh_export->ex_path.mnt);
> + int ret;
>
> + if (fh->fh_want_write)
> + return 0;
> + ret = mnt_want_write(fh->fh_export->ex_path.mnt);
> if (!ret)
> fh->fh_want_write = true;
> return ret;
> --
> 2.21.0
next prev parent reply other threads:[~2019-05-18 20:04 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-16 1:20 [PATCH 00/12] exposing knfsd state to userspace J. Bruce Fields
2019-05-16 1:20 ` [PATCH 1/2] nfsd: allow fh_want_write to be called twice J. Bruce Fields
2019-05-18 20:04 ` J. Bruce Fields [this message]
2019-05-16 1:20 ` [PATCH 01/12] nfsd: persist nfsd filesystem across mounts J. Bruce Fields
2019-05-16 1:20 ` [PATCH 2/2] nfsd: fh_drop_write in nfsd_unlink J. Bruce Fields
2019-05-16 1:20 ` [PATCH 02/12] nfsd: rename cl_refcount J. Bruce Fields
2019-05-16 1:20 ` [PATCH 03/12] nfsd4: use reference count to free client J. Bruce Fields
2019-05-16 1:20 ` [PATCH 04/12] nfsd: add nfsd/clients directory J. Bruce Fields
2019-05-16 1:20 ` [PATCH 05/12] nfsd: make client/ directory names small ints J. Bruce Fields
2019-05-16 1:20 ` [PATCH 06/12] nfsd4: add a client info file J. Bruce Fields
2019-05-16 1:20 ` [PATCH 07/12] nfsd: copy client's address including port number to cl_addr J. Bruce Fields
2019-05-16 1:20 ` [PATCH 08/12] nfsd: add more information to client info file J. Bruce Fields
2019-05-16 1:20 ` [PATCH 09/12] nfsd4: add file to display list of client's opens J. Bruce Fields
2019-05-16 1:20 ` [PATCH 10/12] nfsd: show lock and deleg stateids J. Bruce Fields
2019-05-16 1:20 ` [PATCH 11/12] nfsd4: show layout stateids J. Bruce Fields
2019-05-16 1:20 ` [PATCH 12/12] nfsd: allow forced expiration of NFSv4 clients J. Bruce Fields
-- strict thread matches above, loose matches on Subject: below --
2019-05-13 15:27 [PATCH 0/2] nfsd shoudn't call mnt_want_write twice J. Bruce Fields
2019-05-13 15:27 ` [PATCH 1/2] nfsd: allow fh_want_write to be called twice J. Bruce Fields
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=20190518200411.GB32684@fieldses.org \
--to=bfields@fieldses.org \
--cc=bfields@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).