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

Groups > linux.kernel > #1653323 > unrolled thread

Re: [RFC][PATCH 00/23] VFS: Introduce superblock configuration context [ver #4]

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFC][PATCH 00/23] VFS: Introduce superblock configuration context [ver #4] David Howells <dhowells@redhat.com> - 2017-05-30 17:40 +0200
    Re: [RFC][PATCH 00/23] VFS: Introduce superblock configuration  context [ver #4] Miklos Szeredi <mszeredi@redhat.com> - 2017-05-31 10:00 +0200

#1653323 — Re: [RFC][PATCH 00/23] VFS: Introduce superblock configuration context [ver #4]

Al Viro <viro@ZenIV.linux.org.uk> wrote:

> Random notes:
> 	* "sb_config" looks rather odd in the current variant; mount_context,
> perhaps?  Or fs_context, for that matter...  Anyway, that's trivial.

You can argue that one with Miklós.  He argued against mount_context as I had
it originally.  His point is that the same struct may be used when
reconfiguring an sb - which isn't exactly a mount operation (even though we do
it that day today with remount).

> 	* if NFS folks want to play with EXPORT_SYMBOL_GPL, fine, but any
> EXPORT_SYMBOL_GPL in vfs proper is a mistake.  If it's an interface that
> makes sense, just export it; if it's a vewwwy, vewwwy pwiwate interface
> for some specific module - let's figure out how to deal with that layering
> violation rather than exporting it at all.

I agree, but apparently not everyone does.  There are _GPL symbols in the core
VFS that I need to replace.

> 	* what the hell is ms_flags thing doing in __vfs_new_sb_config()?
> It's a really vile mix of unrelated flags and operations we had in existing
> mount(2) ABI.  With MS_KERNMOUNT thrown into that loo^Wmix.  Sure, we need
> to parse the garbage fed to mount(2).  And we need to pass that garbage to
> "legacy" types as well, but let's not inflict it upon the new mechanisms.

I know, but we might get it from mount(2).  I can tamp down the flag mask and
translate it from MS_*, but the MS_* flags are also stored in the superblock
(->s_flags).

I've removed the MNT_* flags from there already.

> 	* what's wrong with simple_pin_fs() as it is?  You keep
> vfs_kern_mount() anyway, so...

I would like to replace vfs_kern_mount() and vfs_submount(), with the _sc
versions but the users would need converting first.  It might make sense to
retain an __init variant of the former though.

> 	* vfs_new_sb_config(): please, move dealing with name into the caller.
> Then you would be able to use it more than once.

Technically, it's used twice, but okay.  I guess I should just rename
__vfs_new_sb_config() to vfs_new_sb_config() and add the extra parameters to
the caller.

> 	* submount side of that thing: do we ever want a type different from
> that of src_sb,

Hmmm...  Good question.  For the moment I've assumed not.  I've killed off the
NFS special types since I can now carry the information in the sb_config
struct that they previously conveyed.

> and how the fuck would methods know what to do with it?

Until I have an example, it's hard to say.
 
> 	* remounts: where (if anywhere) do you call ->validate() for those,

It got moved out of the path that revalidate was invoking.  I need to put it
back.

However, it may be worth leaving this to the filesystem to invoke during
->get_tree() and ->remount_fs() as it then has access to the on-disk fs
metadata if a blockdev is being used, against which it may need to do
validation.

The biggest advantage of having a separate call is that the argument
combination can be validated before taking any locks, opening a blockdev or
sending packets on the network.

> and if you do not, WTF is this
> +       if (cfg->sc.purpose == SB_CONFIG_FOR_REMOUNT)
> +               return 0;
> for?  You know, the only place that ever looks at ->purpose...

That being the only place is true at the moment, but may not remain so as more
filesystems are converted.

> 	* docs need to be brought in sync with code - 'purpose' is called 'mount_type'
> in those, which is especially unpleasant since you do introduce a field called just
> that - NFS-only and in NFS-private part.

Yep.

> 	* you don't need to register filesystem to use kern_mount()

Hmmm...  I'm not sure whether that's actually a problem.

> 	* locking inode in fsmount(2).  What for?

Yeah, I can get rid of that.  The superblock-getting bit used to be done after
this point, so the lock was necessary to prevent a race.

> 	* ->sb_mountpoint().  YALinuxSadoMasochismHook.  Not called on normal
> mount(2) pathway.  Yuck...

That replaces security_sb_kern_mount().  That should move into
do_new_mount_sc().

> 	* could you split whitespace parts off?  Minor, but...

You mean patch 2?  You could just take that one patch and apply it/pass it to
Linus, then I could rebase.

> 	* I'd like to see ipc/mqueue.c dealt with as well; feels like procfs
> counterpart might have too much open-coded.  This would show what might be
> folded into saner helpers...

Okay.  Any other file system types you'd like to see done immediately?
cpuset, maybe?

I still have to finish the ext4 conversion too.

David

[toc] | [next] | [standalone]

#1653938 — Re: [RFC][PATCH 00/23] VFS: Introduce superblock configuration context [ver #4]

On Tue, May 30, 2017 at 5:36 PM, David Howells <dhowells@redhat.com> wrote:
> Al Viro <viro@ZenIV.linux.org.uk> wrote:
>
>> Random notes:
>>       * "sb_config" looks rather odd in the current variant; mount_context,
>> perhaps?  Or fs_context, for that matter...  Anyway, that's trivial.
>
> You can argue that one with Miklós.  He argued against mount_context as I had
> it originally.  His point is that the same struct may be used when
> reconfiguring an sb - which isn't exactly a mount operation (even though we do
> it that day today with remount).

I'm fine with fs_context, just leave "mount" out of this.  Mounting is
the act of attaching the root dentry to the mountpoint. fs_context is
used for obtaining the root, but not for mounting itself, hence
mount_context is misleading IMO.

>>       * what the hell is ms_flags thing doing in __vfs_new_sb_config()?
>> It's a really vile mix of unrelated flags and operations we had in existing
>> mount(2) ABI.  With MS_KERNMOUNT thrown into that loo^Wmix.  Sure, we need
>> to parse the garbage fed to mount(2).  And we need to pass that garbage to
>> "legacy" types as well, but let's not inflict it upon the new mechanisms.
>
> I know, but we might get it from mount(2).  I can tamp down the flag mask and
> translate it from MS_*, but the MS_* flags are also stored in the superblock
> (->s_flags).

Good cleanup would be to just introduce a new set of flags for s_flags
and leave MS_* usage solely for the legacy mount(2) interface.

Thanks,
Miklos

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web