From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755237AbdESOF6 (ORCPT ); Fri, 19 May 2017 10:05:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55752 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751481AbdESOF4 (ORCPT ); Fri, 19 May 2017 10:05:56 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com E3CFEA6DE1 Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=dhowells@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com E3CFEA6DE1 Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells In-Reply-To: References: <149486147335.23956.2504187638938281431.stgit@warthog.procyon.org.uk> <149486154888.23956.10260643844119198576.stgit@warthog.procyon.org.uk> <18741.1494952398@warthog.procyon.org.uk> <19461.1495020695@warthog.procyon.org.uk> To: Miklos Szeredi Cc: dhowells@redhat.com, viro , Jeff Layton , linux-fsdevel , linux-nfs@vger.kernel.org, lkml Subject: Re: [PATCH 06/21] VFS: Introduce a superblock configuration context [ver #3] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23331.1495202752.1@warthog.procyon.org.uk> Date: Fri, 19 May 2017 15:05:52 +0100 Message-ID: <23332.1495202752@warthog.procyon.org.uk> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Fri, 19 May 2017 14:05:56 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Miklos Szeredi wrote: > Yes. Current behavior seems to just ignore given options (except > MS_RDONLY) in that case, so we need to keep that possibility. Yeah. I wonder if we really should be consistency checking some parameters in some filesystems - or, at least, offering the opportunity. > Also I think it would be good to allow selecting when superblock is created: > > - non-exclusive create: if exists return it, if not create it > - exclusive create: only create if non-existent > - non-create: only return if exists I quite like that idea. Use O_CREAT and O_EXCL? Probably better to define a new flag space for fsopen() rather than trying to share with open(). I'm not sure how likely it would be to be used, though. > So what I propose is: > > 1) call ->parse_option() > > would get indication what we are trying to do (find and/or > create and/or reconfig) > > this step is optional, the the filesystem type could possibly be > enough for the following steps > > 2) call ->get_tree() > > pass sc containing parsed options and flags controlling the > creation of the superblock (create/exclusive) > > this step is optional, not called if we are given an sb to work > with (i.e. only reconfig) No. We have to call this to get the root dentry. Whether or not it creates a superblock - or even if it creates a superblock in someone else's filesystem (the cpuset fs, for example) - is immaterial. Further, we aren't given information as to whether the superblock was created for us or not - though that can be changed. Even further, I think by the time this returns, the superblock should be live. It will be live if we're reusing it, though we can get s_umount to prevent a race. > 3) call ->reconfig() > > pass sc containing parsed options > > this step is optional, we might be instructed just to find or > create the sb Actually, it's arguable that we *shouldn't* be calling this if the superblock already exists - otherwise we may end up changing the parameters someone else has set. For mount(2), for most filesystems, we have to leave the active parameters unaltered for compatibility. For fsopen() I'm willing to add a consistency check - but there probably has to be a flag to waive that as otherwise you can't mount without determining what the other party's parameters were. > I don't get it. We never passed MNT_* options as strings to the > kernel. You're right. I've moved all those flags over to the forbidden list. > Ah, mnt_devname. The device name as just a special type of option and > as such should be stored in the superblock. I'll leave that for now and deal with it later. We have to be careful not to break userspace by changing what's seen in /proc/mounts. David