From: Krister Johansen <kjlx@templeofstupid.com>
To: Miklos Szeredi <miklos@szeredi.hu>, linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org,
German Maglione <gmaglione@redhat.com>,
Greg Kurz <groug@kaod.org>, Max Reitz <mreitz@redhat.com>
Subject: [RFC PATCH 0/2] virtiofs submounts forgotten after client memory pressure
Date: Mon, 10 Jul 2023 18:37:03 -0700 [thread overview]
Message-ID: <cover.1689038902.git.kjlx@templeofstupid.com> (raw)
Hi,
I recently ran into a situation where a virtiofs client began
encountering EBADF after the client system had an OOM. After
reproducing the issue and debugging, it appears that the problem is
caused by a virtiofsd submount being forgotten once the dentry
referencing that submount is killed by the shrinker. In this particular
case, the submount had been bind mounted into a container's mount
namespace. The reference count on the original dentry was 0, making it
eligible for eviction. However, because this dentry was also the last
reference the client knew it had, it sent a forget message to the
server. This caused all future references to the FUSE node-id from
virtiofsd perspective to become invalid. Subsequent attempts to used
the node-id received an EBADF from the server.
This pair of patches modifies the virtiofs submount code to perform a
lookup on the nodeid that forms the root of the submount. The patch
before this pulls the revalidate lookup code into a helper function that
can be used both in revalidate and submount superblock fill.
I'm not enamored with this approach, but was hard pressed to think of a
more clever idea.
In the meantime, it's been tested via:
- fstests for virtiofs
- fstests for fuse (against passthrough_ll)
- manual testing to watch how refcounts change between client and server
in response to filesytem access, umount, and eviction by the shrinker.
Thanks,
-K
Krister Johansen (2):
fuse: revalidate: move lookup into a separate function
fuse: ensure that submounts lookup their root
fs/fuse/dir.c | 87 +++++++++++++++++++++++++++++++++---------------
fs/fuse/fuse_i.h | 6 ++++
fs/fuse/inode.c | 32 +++++++++++++++---
3 files changed, 94 insertions(+), 31 deletions(-)
--
2.25.1
next reply other threads:[~2023-07-11 1:37 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-11 1:37 Krister Johansen [this message]
2023-07-11 1:37 ` [RFC PATCH 1/2] fuse: revalidate: move lookup into a separate function Krister Johansen
2023-07-11 1:37 ` [RFC PATCH 2/2] fuse: ensure that submounts lookup their root Krister Johansen
2023-07-24 23:16 ` Bernd Schubert
2023-08-17 0:23 ` Krister Johansen
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=cover.1689038902.git.kjlx@templeofstupid.com \
--to=kjlx@templeofstupid.com \
--cc=gmaglione@redhat.com \
--cc=groug@kaod.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=mreitz@redhat.com \
/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