From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f65.google.com ([209.85.221.65]:46546 "EHLO mail-wr1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728984AbeIXTUa (ORCPT ); Mon, 24 Sep 2018 15:20:30 -0400 Received: by mail-wr1-f65.google.com with SMTP id z3-v6so7821266wrr.13 for ; Mon, 24 Sep 2018 06:18:20 -0700 (PDT) Date: Mon, 24 Sep 2018 15:18:16 +0200 From: Christian Brauner To: David Howells Cc: Miklos Szeredi , Al Viro , aviro@redhat.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 5/6] fsmount: do not use legacy MS_ flags Message-ID: <20180924131815.76topcqqh3spyvvp@brauner.io> References: <20180922132106.wfa6xaxwbu276qka@brauner.io> <20180921155455.flkf5vdrm3vgn6do@brauner.io> <20180920151214.15484-6-mszeredi@redhat.com> <20180920151214.15484-1-mszeredi@redhat.com> <17157.1537542475@warthog.procyon.org.uk> <20311.1537548756@warthog.procyon.org.uk> <8221.1537631312@warthog.procyon.org.uk> <3868.1537742717@warthog.procyon.org.uk> <30364.1537771838@warthog.procyon.org.uk> <29956.1537792665@warthog.procyon.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ouaxp4t3sd3or2bq" Content-Disposition: inline In-Reply-To: <29956.1537792665@warthog.procyon.org.uk> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: --ouaxp4t3sd3or2bq Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 24, 2018 at 01:37:45PM +0100, David Howells wrote: > Christian Brauner wrote: >=20 > > I have thought a little more about splitting up the mount flags into > > sensible sets. I think the following four sets make sense: > > > > enum { > > MOUNT_ATTR_PROPAGATION =3D 1, > > MOUNT_ATTR_SECURITY, > > MOUNT_ATTR_SYNC, > > MOUNT_ATTR_TIME, > > }; >=20 > Al (I think it was) has been against splitting them up before (I've previ= ously > proposed splitting the topology propagation flags from the mount attribut= es). Right, that request could probably be fulfilled by the first draft for this idea that I had but didn't send out. Basically, having a sequential enum that only ever gets bumped when we run out of flags in a set, i.e. enum { MOUNT_ATTR_SET_1 =3D 1, MOUNT_ATTR_SET_2 =3D 2, MOUNT_ATTR_SET_3 =3D 3, . . . }; Then we would currently only define a single set enum { MOUNT_ATTR_SET_1 =3D 1, }; dump all the current mount flags we would like to support in there and call it a day until we run out of flags at which point we introduce MOUNT_ATTR_SET_2. But honestly, I find defining cuts by forming sets of logically related flags to be more intuitive and transparent for kernel- and userspace. But I'm just another muppet with an opinion. :) >=20 > > #define MOUNT_ATTR_NOATIME (1<<1) > > #define MOUNT_ATTR_RELATIME (1<<3) > > #define MOUNT_ATTR_STRICTATIME (1<<4) >=20 > These aren't independent, but are actually settings on the same dial, so I > would suggest that they shouldn't be separate flags. I'm not sure about > LAZYTIME though. So what you or Miklos suggested before, namely making them an enum too? >=20 > > enum { > > MOUNT_ATTR_PROPAGATION =3D 1, > > MOUNT_ATTR_SECURITY, > > MOUNT_ATTR_SECURITY_1 =3D MOUNT_ATTR_SECURITY, > > MOUNT_ATTR_SYNC, > > MOUNT_ATTR_TIME, > > MOUNT_ATTR_SECURITY_2, > > }; >=20 > In UAPI headers, always explicitly number your symbols, even in an enum, = just > to make sure that the numbers don't get transparently changed by accident. +1 and thanks for the tip! >=20 > > These flags will likely become AT_* flags or be tied to a syscall > > afaict. > > > > #define MS_REMOUNT 32 > > #define MS_BIND 4096 > > #define MS_MOVE 8192 > > #define MS_REC 16384 >=20 > MS_REMOUNT: fd =3D fspick(); fscommand(fd, FSCONFIG_CMD_RECONFIGURE); >=20 > MS_REMOUNT|MS_BIND: mount_setattr(). >=20 > MS_BIND: fd =3D open_tree(..., OPEN_TREE_CLONE); move_mount(fd, "", ...); >=20 > MS_MOVE: fd =3D open_tree(..., 0); move_mount(fd, "", ...); >=20 > MS_REC: AT_RECURSIVE >=20 > > Internal sb flags will not be part of the new mount attr sets. (They > > should - imho - not be exposed to userspace at all.): >=20 > Agreed. >=20 > > What remains is an odd duck that probably could be thrown into security > > but also *shrug* > > > > #define MS_I_VERSION (1<<23) >=20 > Um. I think it would probably belong with atime settings. >=20 > David --ouaxp4t3sd3or2bq Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE7btrcuORLb1XUhEwjrBW1T7ssS0FAluo5BcACgkQjrBW1T7s sS0O5w//UJUVK32uvIzX3Bbr7rxqWvq7kBRP952YMXnbqFhQFVE3C2oLRZ4EE4NT w1N+1MZQ4Rrf7Q5627Z529hyYCe0BfJSHyf3fkGyWX2wvdt1DOQtzW4PSdIFKZ4Z bF9h92cZtHGJwipRkMFZFKbpy93A87QKYrwtTDN1Rz0+OlwEF6vyewVk0gLSjrdw 7CR8OnebLVjquhZXdunbkGkewh4Dz8OHmTWILXzqUEHkVxY62KljzCsuUn+fZsGn y+vKmCWRsTP8JXLzjD6yZqi031uy/LDv5evhQn3tmt9w8kJl5KLUNDaRYUwSmjS/ ih6BPmFp5xcuRdC+eAg2T3A6dgK9fg2nXp4OP7e3JWS89BdzmyYng8H31JXES9l9 tAcK6UZdgOPwSrQY2dhATKS5lnybA3tqa3wcbS/oLuGZxGraU208tRGcfjZiXHVf G2XgWkvdxYY+nSpJdWKTLhQQnyDy+oMCcKp/m8kB1jjAz9HrsuP5TF/OSUnSzJz3 bniuNK6h38UZi8xvF5G8JhFrKLPzclKZog4lguSEt/1EYmLANbZTcj+pC7iZxri8 YEHL20IIcrB+Q98RqCbrOB4lSO0+3ksacLYGky1On9qddvjaa1/Qbn+pNaRjgfAr HrRpQiJ1sw8q2U3iHRN/j3G6+/9dUz5e3DsjSTXwfwGuYMGnurk= =zvds -----END PGP SIGNATURE----- --ouaxp4t3sd3or2bq--