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? But in simplest terms - it was, in fact, debugfs that a) changed and b) got the bug report, so I don't have strong objections to going back to the old behavior. -Eric
