From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3577AC43381 for ; Fri, 15 Feb 2019 03:40:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0963620836 for ; Fri, 15 Feb 2019 03:40:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730694AbfBODkn (ORCPT ); Thu, 14 Feb 2019 22:40:43 -0500 Received: from mx2.suse.de ([195.135.220.15]:33006 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726010AbfBODkn (ORCPT ); Thu, 14 Feb 2019 22:40:43 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 0DA81ACA8 for ; Fri, 15 Feb 2019 03:40:42 +0000 (UTC) From: NeilBrown To: =?utf-8?Q?Aur=C3=A9lien?= Aptel , linux-fsdevel@vger.kernel.org Date: Fri, 15 Feb 2019 14:40:33 +1100 Subject: Re: Duplicate network filesystems In-Reply-To: <87sgwujjgu.fsf@suse.com> References: <87sgwujjgu.fsf@suse.com> Message-ID: <87mumxen2m.fsf@notabene.neil.brown.name> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Mon, Feb 11 2019, Aur=C3=A9lien Aptel wrote: > Hi, > > In fs/namespace.c do_add_mount() we do this check: > > /* Refuse the same filesystem on the same mount point */ > err =3D -EBUSY; > if (path->mnt->mnt_sb =3D=3D newmnt->mnt.mnt_sb && > path->mnt->mnt_root =3D=3D path->dentry) > goto unlock; > > So that mount fails with EBUSY. But for networked filesystems (at least > cifs and nfs) you can do this: > > mount //foo /mnt -o A > mount //foo /mnt -o B # different options > > Since the SB are different it works, fine. > > But mounting a 3rd time with options A succeeds, where from a user POV I > would have expected to fail. Why?=20 > > So to recap: > > mount //foo /mnt -o A > mount //foo /mnt -o A > # EBUSY =3D> expected behaviour > > mount //foo /mnt -o A > mount //foo /mnt -o B > # ok =3D> expected behaviour > > mount //foo /mnt -o A > mount //foo /mnt -o B > mount //foo /mnt -o A > # ok =3D> what? > > Shouldn't we check the stack of filesystems mounted at the path instead of > just the last one? Why? I think that the main reason that -EBUSY is important is that people often run "mount -a" and don't expect filesystems that are already mounted to be mounted again. The current behaviour achieves that. What is your use-case for wanted -EBUSY in some other circumstance? NeilBrown --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEG8Yp69OQ2HB7X0l6Oeye3VZigbkFAlxmNLIACgkQOeye3VZi gblkXg//Z2nfbfR8+GF6dVSACPjk1WYpFIeTnji1P3WOIG02Wtrw2hxS68Bs1kAY wisZPe+IsgovlXucGJlC4UnuU2jSMt27nn8pj26wbY0kdc2Mh5UUHItrA1jbzMHb bQtgu68C81H/9qE4DW9XBgrHlK0rVB991ALkGveY6i4dcLmIAfwRSbzb8PHqDiyN uDCbIl1//Nzd9ngpFDe/7p9opaNKiCr/NQ+OWC3BiJ+uymM1PSFviMdGUYUzh2tP 8slU4S3ywxHAGvXLPQvnH3blI+MM9vm5ZPeZDsIau4IAWFOyFCa3S8EsYNR6DWZT EZljOzaKZozMXZVx/7+txhk36m4IDdyHBbNCMmPwC3A4tqaiSDYrR6DkYpqv081Z EAe+FMBemEdXBgNcm6+j4mxRWW7xqHo8ldp9pV0woTH/YSbosHZ7MyfhdVA0YSFy Y52sP4EWVNn3J9b5LIzlmPSJ1f3l4jPCJzBTbyDvP1g9lcTLPqfZmhY/J2Fxk8E9 vt1yveHwtXAJNw5zNBd+WiX5UnRjLe88EO75eQwACXEu10g+BnX2hAZJ9kdmrsgH oQb/jPh/vppRAyY37/iJxIRhOxkMIt1P4/EOuAfo2Fwa/B3AlWqPD6LI6q2Gl/WS uzFungSrKLvwQ3IRD/iTCWe8S+1f80fYJZ3S1sBux/R7PWub1fM= =fHvy -----END PGP SIGNATURE----- --=-=-=--