Christian Brauner <christian@xxxxxxxxxx> 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
