From: Charalampos Mitrodimas <charmitro@posteo.net>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: Christian Brauner <brauner@kernel.org>,
Eric Sandeen <sandeen@redhat.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Danilo Krummrich <dakr@kernel.org>,
David Howells <dhowells@redhat.com>,
linux-kernel@vger.kernel.org,
linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH] debugfs: fix mount options not being applied
Date: Wed, 13 Aug 2025 23:49:53 +0000 [thread overview]
Message-ID: <87plcyixy9.fsf@posteo.net> (raw)
In-Reply-To: <495848ab-2493-4701-b514-415377fe877b@sandeen.net>
Eric Sandeen <sandeen@sandeen.net> writes:
> On 8/8/25 9:13 AM, Christian Brauner wrote:
>> On Wed, Aug 06, 2025 at 11:33:11AM -0500, Eric Sandeen wrote:
>>> On 8/5/25 12:22 PM, Charalampos Mitrodimas wrote:
>
> ...
>
>>>> Hi, thanks for the review, and yes you're right.
>>>>
>>>> Maybe a potential systemic fix would be to make get_tree_single() always
>>>> call fc->ops->reconfigure() after vfs_get_super() when reusing an
>>>> existing superblock, fixing all affected filesystems at once.
>>>
>>> Yep, I'm looking into that. mount_single used to do this, and IIRC we discussed
>>> it before but for some reason opted not to. It seems a bit trickier than I first
>>> expected, but I might just be dense. ;)
>>
>> If we can make it work generically, we should. I too don't remember what
>> the reasons were for not doing it that way.
>
> Sorry for the long delay here. Talked to dhowells about this and his
> POV (which is convincing, I think) is that even though mount_single used to
> call do_remount_sb for an extant single sb, this was probably Bad(tm).
> Bad, IIUC, because it's not a given that options are safe to be changed
> in this way, and that policy really should be up to each individual
> filesystem.
>
> So while we still need to audit and fix any get_tree_single()
> filesystems that changed behavior with the new mount api, may as well
> fix up debugfs for now since the bug was reported.
What if we add a new flag (.fs_flags), say FS_SINGLE_RECONF, to
file_system_type that makes get_tree_single() automatically call
reconfigure() when reusing an existing superblock? Filesystems could
then just opt-in by adding it to .fs_flags.
>
> Charalampos -
>
> Your patch oopses on boot for me - I think that when you added
>
> sb->s_fs_info = fc->s_fs_info;
Yes, did take notice of this yesterday when I revisited it.
>
> in debugfs_fill_super, you're actually NULLing out the one in the sb,
> because sget_fc has already transferred fc->s_fs_info to sb->s_fs_info,
> and NULLed fc->s_fs_info prior to this. Then when we get to
> _debugfs_apply_options, *fsi = sb->s_fs_info; is also NULL so using it
> there oopses.
>
> If you want to send a V2 with fixed up stable cc: I'd suggest following the
> pattern of what was done for tracefs in e4d32142d1de, which I think works
> OK and would at least lend some consistency, as the code is similar.
>
> If not, let me know and I'll work on an update.
As a matter of fact, I have a v2 exactly like this ready to sent. Doing
so in a bit.
>
> Thanks,
> -Eric
Thanks!
C. Mitrodimas
next prev parent reply other threads:[~2025-08-13 23:49 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-04 14:30 [PATCH] debugfs: fix mount options not being applied Charalampos Mitrodimas
2025-08-04 16:48 ` Greg Kroah-Hartman
2025-08-04 17:22 ` Eric Sandeen
2025-08-05 17:03 ` Eric Sandeen
2025-08-05 17:22 ` Charalampos Mitrodimas
2025-08-06 16:33 ` Eric Sandeen
2025-08-08 14:13 ` Christian Brauner
2025-08-13 22:02 ` Eric Sandeen
2025-08-13 23:49 ` Charalampos Mitrodimas [this message]
2025-08-14 9:05 ` Aleksa Sarai
2025-08-14 13:47 ` Aleksa Sarai
2025-08-14 16:46 ` Eric Sandeen
2025-08-15 0:31 ` Aleksa Sarai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87plcyixy9.fsf@posteo.net \
--to=charmitro@posteo.net \
--cc=brauner@kernel.org \
--cc=dakr@kernel.org \
--cc=dhowells@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=sandeen@redhat.com \
--cc=sandeen@sandeen.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.