From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752112AbdJ0QDI (ORCPT ); Fri, 27 Oct 2017 12:03:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45510 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751472AbdJ0QDG (ORCPT ); Fri, 27 Oct 2017 12:03:06 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 8CAE26A7C8 Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=dhowells@redhat.com 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: <150730494491.6182.5139368907374172391.stgit@warthog.procyon.org.uk> <150730496982.6182.10042997820796149075.stgit@warthog.procyon.org.uk> <28791.1509035055@warthog.procyon.org.uk> <29611.1509114932@warthog.procyon.org.uk> To: Miklos Szeredi Cc: dhowells@redhat.com, viro , linux-fsdevel , linux-nfs@vger.kernel.org, lkml , Jeff Layton , Linux API Subject: Re: [PATCH 03/14] VFS: Implement a filesystem superblock creation/configuration context [ver #6] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3053.1509120184.1@warthog.procyon.org.uk> Date: Fri, 27 Oct 2017 17:03:04 +0100 Message-ID: <3054.1509120184@warthog.procyon.org.uk> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Fri, 27 Oct 2017 16:03:06 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Miklos Szeredi wrote: > Yes I did mean vfs_parse_sb_flag_option(). > > Yes, I understand its purpose, but it would be cleaner if all the > option parsing was done in fc->ops->parse_option(). > > It might be worth introducing the vfs_parse_sb_flag_option(), to be > called from ->parse_option(). I was trying to relieve the filesystem of the requirement to have to deal with common stuff and also the need to talk directly to the LSM. > > Btw, how would it affect the LSM? > > LSM would have to reject a "reset" if not enough privileges to > *create* a new fs instance, since it essentially requires creating a > new config, which is what is done when creating an fs instance. That's not what I'm asking. Would the reset change LSM state? Reset security labels and options? > > Sorry, how does the new, clean one do it without handling these options? > > There is no MS_* mask passed in, except to fsmount(). > > The new one certainly should. Should what? > Ignoring unknown flags/options is generally a bad idea. They're not unknown - just not of interest to the filesystem. David