On 2025-08-12, Askar Safin <safinaskar@xxxxxxxxxxxx> wrote: > fsmount: > > Unlike open_tree(2) with OPEN_TREE_CLONE, fsmount() can only be called once in the lifetime of a filesystem instance to produce a mount object. > > I don't understand what you meant here. This phrase in its current form is wrong. > Consider this scenario: we did this: > fsopen(...) > fsconfig(..., FSCONFIG_SET_STRING, "source", ...) > fsconfig(..., FSCONFIG_CMD_CREATE, ...) > fsmount(...) > fsopen(...) > fsconfig(..., FSCONFIG_SET_STRING, "source", ...) > fsconfig(..., FSCONFIG_CMD_CREATE, ...) > fsmount(...) > > We used FSCONFIG_CMD_CREATE here as opposed to FSCONFIG_CMD_CREATE_EXCL, thus > it is possible that second fsmount will return mount for the same superblock. > Thus that statement "fsmount() can only be called once in the lifetime of a filesystem instance to produce a mount object" > is not true. Yeah, the superblock reuse behaviour makes this description less coherent than what I was going for. My thinking was that a reused superblock is (to userspace) conceptually a new filesystem instance because they create it the same way as any other filesystem instance. (In fact, the rest of the VFS treats them the same way too -- only sget_fc() knows about superblock reuse.) But yeah, "filesystem context" is more accurate here, so probably just: Unlike open_tree(2) with OPEN_TREE_CLONE, fsmount() can only be called once in the lifetime of a filesystem context. Though maybe we should mention that it's fsopen(2)-only (even though it's mentioned earlier in the DESCRIPTION)? If you read the sentence in isolation you might get the wrong impression. Do you have any alternative suggestions? FWIW, superblock reuse is one of those things that is a fairly hairy implementation detail of the VFS, and as such it has quite odd semantics. I probably wouldn't have documented it as heavily if it wasn't for the addition of FSCONFIG_CMD_CREATE_EXCL (maybe an entry in BUGS or CAVEATS at most -- this behaviour has an even worse impact on mount(2) but it's completely undocumented there). -- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/
Attachment:
signature.asc
Description: PGP signature
