From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx3-rdu2.redhat.com ([66.187.233.73]:46578 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727136AbeHXDkm (ORCPT ); Thu, 23 Aug 2018 23:40:42 -0400 From: David Howells In-Reply-To: References: <20180823223145.GK6515@ZenIV.linux.org.uk> To: Andy Lutomirski Cc: dhowells@redhat.com, Al Viro , Linus Torvalds , Linux FS Devel , Linux API Subject: Re: [git pull] new mount API MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <24339.1535069316.1@warthog.procyon.org.uk> Date: Fri, 24 Aug 2018 01:08:36 +0100 Message-ID: <24340.1535069316@warthog.procyon.org.uk> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Andy Lutomirski wrote: > Has anything been done to ensure that the behavior when doing > FSCONFIG_CMD_CREATE against an already-mounted block device is > reasonable? For the moment, I've left it as the same behaviour as for mount(2) since mount(2) now uses the same mechanism internally and we aren't permitted to break userspace. I would like to add at least one flag to stipulate that, in the case of an incompatible collision, you can get a failure - but defining what is meant by incompatible isn't necessarily trivial, and would vary by filesystem *and* the LSM. However, I don't want to start reengineering everything this close to the merge window and we don't really need it immediately. David