Messages in this thread | | | From | David Howells <> | Subject | Re: [PATCH 5/6] fsmount: do not use legacy MS_ flags | Date | Mon, 24 Sep 2018 13:37:45 +0100 |
| |
Christian Brauner <christian@brauner.io> wrote:
> 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 = 1, > MOUNT_ATTR_SECURITY, > MOUNT_ATTR_SYNC, > MOUNT_ATTR_TIME, > };
Al (I think it was) has been against splitting them up before (I've previously proposed splitting the topology propagation flags from the mount attributes).
> #define MOUNT_ATTR_NOATIME (1<<1) > #define MOUNT_ATTR_RELATIME (1<<3) > #define MOUNT_ATTR_STRICTATIME (1<<4)
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.
> enum { > MOUNT_ATTR_PROPAGATION = 1, > MOUNT_ATTR_SECURITY, > MOUNT_ATTR_SECURITY_1 = MOUNT_ATTR_SECURITY, > MOUNT_ATTR_SYNC, > MOUNT_ATTR_TIME, > MOUNT_ATTR_SECURITY_2, > };
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.
> 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
MS_REMOUNT: fd = fspick(); fscommand(fd, FSCONFIG_CMD_RECONFIGURE);
MS_REMOUNT|MS_BIND: mount_setattr().
MS_BIND: fd = open_tree(..., OPEN_TREE_CLONE); move_mount(fd, "", ...);
MS_MOVE: fd = open_tree(..., 0); move_mount(fd, "", ...);
MS_REC: AT_RECURSIVE
> Internal sb flags will not be part of the new mount attr sets. (They > should - imho - not be exposed to userspace at all.):
Agreed.
> What remains is an odd duck that probably could be thrown into security > but also *shrug* > > #define MS_I_VERSION (1<<23)
Um. I think it would probably belong with atime settings.
David
| |