On Thu, Jan 16, 2025 at 09:38:07AM -0600, Eric Sandeen wrote: > 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. So far it hasn't lead to any regressions and we had the new behavior for quite a while.
