Re: mount api: Q on behavior of mount_single vs. get_tree_single

[Eric Sandeen <sandeen@redhat.com>]

On 1/16/25 4:28 AM, Christian Brauner wrote:
> On Wed, Jan 15, 2025 at 10:50:31AM -0600, Eric Sandeen wrote:
>> I was finally getting back to some more mount API conversions,
>> and was looking at pstore, which I thought would be straightforward.
>>
>> I noticed that mount options weren't being accepted, and I'm fairly
>> sure that this is because there's some internal or hidden mount of
>> pstore, and mount is actually a remount due to it using a single
>> superblock. (looks like it was some sort of clone mount done under
> 
> Yes, some legacy filesystems behave that way unforunately.

Is it not the case that every current (or past) user of mount_single
behave[sd] this way due to the internals of mount_single()?

gadgetfs, configfs, debugfs, tracefs, efivars, openpromfs and more all
currently call get_tree_single (and used to call mount_single, which did
the reconfigure for them).

Or am I missing something?

...

> I would think we should make this the filesystems problem or add a
> get_tree_single_reconfigure() helper that the few filesystems that need
> this behavior can use. Thoughts?

I wasn't seeing this as individual filesystems needing it, it looked to
me like every filesystem that used to call mount_single() automatically
got the behavior. So was looking at this from a consistency/regression
POV.

While it seems odd to me that mounting any "_single" sb filesystem would
reconfigure all of its current mounts on a new mount, that's the way it
used to work for everyone, as far as I can tell, so I was assuming that
we'd need to keep the behavior. But if it's a question of just fixing it
up per-filesystem, I don't mind going that route either.

Thanks,
-Eric