All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: Alexander Viro <viro@zeniv.linux.org.uk>,
	Miklos Szeredi <miklos@szeredi.hu>
Cc: Matthew Wilcox <willy@infradead.org>,
	dhowells@redhat.com, Matthew Wilcox <willy@infradead.org>,
	Ian Kent <raven@themaw.net>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [RFC][PATCH 0/3] vfs: Use an xarray instead of inserted bookmarks to scan mount list
Date: Mon, 15 Mar 2021 12:07:39 +0000	[thread overview]
Message-ID: <161581005972.2850696.12854461380574304411.stgit@warthog.procyon.org.uk> (raw)


Hi Al, Miklós,

Can we consider replacing the "insert cursor" approach we're currently
using for proc files to scan the current namespace's mount list[1] with
something that uses an xarray of mounts indexed by mnt_id?

This has some advantages:

 (1) It's simpler.  We don't need to insert dummy mount objects as
     bookmarks into the mount list and code that's walking the list doesn't
     have to carefully step over them.

 (2) We can use the file position to represent the mnt_id and can jump to
     it directly - ie. using seek() to jump to a mount object by its ID.

 (3) It might make it easier to use RCU in future to dump mount entries
     rather than having to take namespace_sem.  xarray provides for the
     possibility of tagging entries to say that they're viewable to avoid
     dumping incomplete mount objects.

But there are a number of disadvantages:

 (1) We have to allocate memory to maintain the xarray, which becomes more
     of a problem as mnt_id values get scattered.

 (2) We need to preallocate the xarray memory because we're manipulating

 (3) The effect could be magnified because someone mounts an entire
     subtree and propagation has to copy all of it.

David

Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9f6c61f96f2d97cbb5f7fa85607bc398f843ff0f [1]

---
David Howells (3):
      vfs: Use an xarray in the mount namespace to handle /proc/mounts list
      vfs: Use the mounts_to_id array to do /proc/mounts and co.
      vfs: Remove mount list trawling cursor stuff


 fs/mount.h            |  2 +-
 fs/namespace.c        | 66 ++++++++++---------------------------------
 fs/proc_namespace.c   |  3 --
 include/linux/mount.h |  4 +--
 4 files changed, 17 insertions(+), 58 deletions(-)



             reply	other threads:[~2021-03-15 12:08 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-15 12:07 David Howells [this message]
2021-03-15 12:07 ` [PATCH 1/3] vfs: Use an xarray in the mount namespace to handle /proc/mounts list David Howells
2021-03-15 12:07 ` [PATCH 2/3] vfs: Use the mounts_to_id array to do /proc/mounts and co David Howells
2021-03-15 12:54   ` Matthew Wilcox
2021-03-15 12:08 ` [PATCH 3/3] vfs: Remove mount list trawling cursor stuff David Howells
2021-03-15 12:46 ` [RFC][PATCH 0/3] vfs: Use an xarray instead of inserted bookmarks to scan mount list Matthew Wilcox
2021-03-15 13:14 ` Miklos Szeredi
2021-03-15 13:17   ` Matthew Wilcox
2021-03-15 13:41 ` David Howells
2021-03-15 14:22   ` Miklos Szeredi

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=161581005972.2850696.12854461380574304411.stgit@warthog.procyon.org.uk \
    --to=dhowells@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=raven@themaw.net \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    --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.