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

[Dominique Martinet]

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