All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: torvalds@linux-foundation.org
Cc: dhowells@redhat.com, Jeffle Xu <jefflexu@linux.alibaba.com>,
	jlayton@kernel.org, Jan Kara <jack@suse.cz>,
	Matthew Wilcox <willy@infradead.org>,
	"Darrick J. Wong" <djwong@kernel.org>,
	linux-cachefs@redhat.com, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: [GIT PULL] netfs: Potential deadlock and error handling fixes
Date: Tue, 07 Dec 2021 21:35:05 +0000	[thread overview]
Message-ID: <2420479.1638912905@warthog.procyon.org.uk> (raw)

Hi Linus,

Could you pull these fixes for the netfs lib?  There are two:

 (1) Fix a lockdep warning and potential deadlock.  This is takes the
     simple approach of offloading the write-to-cache done from within a
     network filesystem read to a worker thread to avoid taking the
     sb_writer lock from the cache backing filesystem whilst holding the
     mmap lock on an inode from the network filesystem.

     Jan Kara posits a scenario whereby this can cause deadlock[1], though
     it's quite complex and I think requires someone in userspace to
     actually do I/O on the cache files.  Matthew Wilcox isn't so certain,
     though[2].

     An alternative way to fix this, suggested by Darrick Wong, might be to
     allow cachefiles to prevent userspace from performing I/O upon the
     file - something like an exclusive open - but that's beyond the scope
     of a fix here if we do want to make such a facility in the future.

 (2) In some of the error handling paths where netfs_ops->cleanup() is
     called, the arguments are transposed[3].  gcc doesn't complain because
     one of the parameters is void* and one of the values is void*.

David

Link: https://lore.kernel.org/r/20210922110420.GA21576@quack2.suse.cz/ [1]
Link: https://lore.kernel.org/r/Ya9eDiFCE2fO7K/S@casper.infradead.org/ [2]
Link: https://lore.kernel.org/r/20211207031449.100510-1-jefflexu@linux.alibaba.com/ [3]

---
The following changes since commit 0fcfb00b28c0b7884635dacf38e46d60bf3d4eb1:

  Linux 5.16-rc4 (2021-12-05 14:08:22 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git tags/netfs-fixes-20211207

for you to fetch changes up to 3cfef1b612e15a0c2f5b1c9d3f3f31ad72d56fcd:

  netfs: fix parameter of cleanup() (2021-12-07 15:47:09 +0000)

----------------------------------------------------------------
netfslib fixes

----------------------------------------------------------------
David Howells (1):
      netfs: Fix lockdep warning from taking sb_writers whilst holding mmap_lock

Jeffle Xu (1):
      netfs: fix parameter of cleanup()

 fs/netfs/read_helper.c | 21 ++++++++-------------
 1 file changed, 8 insertions(+), 13 deletions(-)


             reply	other threads:[~2021-12-07 21:35 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-07 21:35 David Howells [this message]
2021-12-09 19:35 ` [GIT PULL] netfs: Potential deadlock and error handling fixes pr-tracker-bot

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=2420479.1638912905@warthog.procyon.org.uk \
    --to=dhowells@redhat.com \
    --cc=djwong@kernel.org \
    --cc=jack@suse.cz \
    --cc=jefflexu@linux.alibaba.com \
    --cc=jlayton@kernel.org \
    --cc=linux-cachefs@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=willy@infradead.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.