linux-kernel - Re: [PATCH next V2] 9p: Correct the session info

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aNTuGdJwihpa3Ixh@codewreck.org>
Date: Thu, 25 Sep 2025 16:24:09 +0900
From: Dominique Martinet <asmadeus@...ewreck.org>
To: Eric Sandeen <sandeen@...hat.com>
Cc: Edward Adam Davis <eadavis@...com>, ericvh@...nel.org,
	linux-kernel@...r.kernel.org, linux_oss@...debyte.com,
	lucho@...kov.net,
	syzbot+30c83da54e948f6e9436@...kaller.appspotmail.com,
	syzkaller-bugs@...glegroups.com, v9fs@...ts.linux.dev
Subject: Re: [PATCH next V2] 9p: Correct the session info

Eric Sandeen wrote on Wed, Sep 24, 2025 at 11:29:16PM -0500:
> On 9/24/25 9:17 PM, Dominique Martinet wrote:
> > Using a different struct tailored for mount options is certainly more
> > appropriate if you have the time to do it, but as long as the risk of
> > accessing "the wrong one" goes away I'm fine either way, so if you think
> > nulling fs_private is possible without too much churn I think that's
> > good enough.
> > 
> > What do you think?
> 
> I think that in retrospect, (ab)using the full v9ses was a poor choice by
> me, it clearly caused confusion (for me!)

I definitely won't complain if we get a dedicated struct :)

> > My reading is that we need it, because the super block isn't the fs
> > context, and we need it for v9fs_umount_begin (it doesn't help that the
> > field name is the same between both structs, and that some super_block
> > variables are just 's' and others are 'sb', but I think that's the only
> > place where it's used)
> > 
> > At this point these are both the "real live" v9ses so that should be
> > fine as far as I can see.
> 
> I said remove because sget_fc() does s->s_fs_info = fc->s_fs_info, and
> then v9fs_set_super essentially does s->s_fs_info = fc->s_fs_info again,
> so I think it's redundant but I'll look again when I'm less sleepy. 

Ah, I had missed the setting in sget_fc() -- you're right, we should get
rid of the one in v9fs_set_super()
(or actually, get rid of v9fs_set_super altogether and pass
set_anon_super() directly to sget_fc())


> > Now I understand the lifecycle a bit better I can have another read with
> > that in mind before merging, and we can do the nulling fs_private or
> > other "make sure this bug doesn't come back" later if you don't have
> > time, I'm leaving this up to you.
> 
> Sounds good. Thanks again, and sorry for somehow completely missing this
> thread earlier.

No worry, I should have re-sent a ping earlier as well.

> (Assume we've missed this merge window by now, so I probably won't rush
> on this but will try to do it sooner than later.)

Alright, I don't think we want to rush this, so let's get this next
cycle :)

Thanks,
-- 
Dominique Martinet | Asmadeus