Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1639218

Re: [PATCH 06/14] VFS: Introduce a superblock configuration context

From Al Viro <viro@ZenIV.linux.org.uk>
Newsgroups linux.kernel
Subject Re: [PATCH 06/14] VFS: Introduce a superblock configuration context
Date 2017-05-11 09:30 +0200
Message-ID <tFQHT-3k5-11@gated-at.bofh.it> (permalink)
References <tFCvf-2Uw-1@gated-at.bofh.it> <tFCEW-2YC-11@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Wed, May 10, 2017 at 05:19:19PM +0100, David Howells wrote:
> + (*) struct mnt_namespace *mnt_ns
> +
> +     This is a subset of the namespaces in use by the invoking process.  This
> +     retains a ref on each namespace.  The subscribed namespaces may be
> +     replaced by the filesystem to reflect other sources, such as the parent
> +     mount superblock on an automount.

I don't think it's a good idea.  No comments on userns stuff, but what's
the situation when you want it to play with the real namespace?  Details,
please...

> + (*) int (*fill_super)(struct super_block *s, struct sb_config *sc);
> +
> +     This is available to be used by things like mount_ns_mc() that are called
> +     by ->mount() to transfer information/resources from the superblock configuration context to
> +     the superblock.

        Don't.  This kind of stuff can bloody well be an explicit callback.
Methods of that kind are trouble - we had that sort of PITA quite a few
times, and it had always been a headache when we eventually had to kill them
off.  Starting with ->read_inode(), if you remember that one...

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[RFC][PATCH 00/14] VFS: Introduce superblock configuration context David Howells <dhowells@redhat.com> - 2017-05-10 18:20 +0200
  [PATCH 01/14] Provide a function to create a NUL-terminated string  from unterminated data David Howells <dhowells@redhat.com> - 2017-05-10 18:20 +0200
  [PATCH 07/14] Implement fsopen() to prepare for a mount David Howells <dhowells@redhat.com> - 2017-05-10 18:30 +0200
    Re: [PATCH 07/14] Implement fsopen() to prepare for a mount Sargun Dhillon <sargun@sargun.me> - 2017-05-11 00:10 +0200
      Re: [PATCH 07/14] Implement fsopen() to prepare for a mount David Howells <dhowells@redhat.com> - 2017-05-11 16:40 +0200
    Re: [PATCH 07/14] Implement fsopen() to prepare for a mount Jeff Layton <jlayton@redhat.com> - 2017-05-11 16:40 +0200
  [PATCH 08/14] Implement fsmount() to effect a pre-configured mount David Howells <dhowells@redhat.com> - 2017-05-10 18:30 +0200
  [PATCH 11/14] proc: Add superblock config support to procfs David Howells <dhowells@redhat.com> - 2017-05-10 18:30 +0200
  [PATCH 13/14] Support legacy filesystems David Howells <dhowells@redhat.com> - 2017-05-10 18:30 +0200
  [PATCH 03/14] VFS: Make get_mnt_ns() return the namespace David Howells <dhowells@redhat.com> - 2017-05-10 18:30 +0200
  [PATCH 05/14] VFS: Provide empty name qstr David Howells <dhowells@redhat.com> - 2017-05-10 18:30 +0200
  [PATCH 02/14] Clean up whitespace in fs/namespace.c David Howells <dhowells@redhat.com> - 2017-05-10 18:30 +0200
  [PATCH 10/14] procfs: Move proc_fill_super() to fs/proc/root.c David Howells <dhowells@redhat.com> - 2017-05-10 18:30 +0200
  [PATCH 09/14] Sample program for driving fsopen/fsmount David Howells <dhowells@redhat.com> - 2017-05-10 18:30 +0200
  [PATCH 04/14] VFS: Make get_filesystem() return the affected  filesystem David Howells <dhowells@redhat.com> - 2017-05-10 18:30 +0200
  Re: [PATCH 06/14] VFS: Introduce a superblock configuration context Al Viro <viro@ZenIV.linux.org.uk> - 2017-05-11 09:30 +0200
  Re: [PATCH 14/14] Add commands to create or update a superblock Al Viro <viro@ZenIV.linux.org.uk> - 2017-05-11 09:40 +0200
    Re: [PATCH 14/14] Add commands to create or update a superblock Miklos Szeredi <mszeredi@redhat.com> - 2017-05-11 10:20 +0200

csiph-web