On Mon, Jun 03, 2024 at 10:13:43AM -0500, Eric Sandeen wrote: > On 6/3/24 9:33 AM, Christian Brauner wrote: > > On Mon, Jun 03, 2024 at 09:17:10AM -0500, Eric Sandeen wrote: > >> On 6/3/24 8:31 AM, Christian Brauner wrote: > >>> On Mon, Jun 03, 2024 at 09:24:50AM +0200, Wolfram Sang wrote: > >>>> > >>>>>>> Does that fix it for you? > >>>>>> > >>>>>> Yes, it does, thank you. > >>>>>> > >>>>>> Reported-by: Wolfram Sang <wsa+renesas@xxxxxxxxxxxxxxxxxxxx> > >>>>>> Tested-by: Wolfram Sang <wsa+renesas@xxxxxxxxxxxxxxxxxxxx> > >>>>> > >>>>> Thanks, applied. Should be fixed by end of the week. > >>>> > >>>> It is in -next but not in rc2. rc3 then? > >>> > >>> Yes, it wasn't ready when I sent the fixes for -rc2 as I just put it in > >>> that day. > >>> > >> > >> See my other reply, are you sure we should make this change? From a > >> "keep the old behavior" POV maybe so, but this looks to me like a > >> bug in busybox, passing fstab hint "options" like "auto" as actual mount > >> options being the root cause of the problem. debugfs isn't uniquely > >> affected by this behavior. > >> > >> I'm not dead set against the change, just wanted to point this out. > > > > Hm, it seems I forgot your other mail, sorry. > > No worries! > > > So the issue is that we're breaking existing userspace and it doesn't > > seem like a situation where we can just ignore broken userspace. If > > busybox has been doing that for a long time we might just have to > > accommodate their brokenness. Thoughts? > > Yep, I can totally see that POV. > > It's just that surely every other strict-parsing filesystem is also > broken in this same way, so coding around the busybox bug only in debugfs > seems a little strange. (Surely we won't change every filesystem to accept > unknown options just for busybox's benefit.) > > IOWS: why do we accomodate busybox brokenness only for debugfs, given that > "auto" can be used in fstab for any filesystem? I suspect that not that most filesystems aren't mounted from fstab which is why we've never saw reports.
