This is an updated attempt to convert 9p to the new mount API. 9p is
one of the last conversions needed, possibly because it is one of the
trickier ones!

I was able to test this to some degree, but I am not sure how to test
all transports; there may well be bugs here. It would be great to get
some feedback on whether this approach seems reasonable, and of course
any further review or testing would be most welcome.

V2: Address "make W=1" warnings from kernel test robot, comments from
dhowells, and some kernel-doc comments for changed arguments.

Thanks,
-Eric

Hi Eric,

Eric Sandeen wrote on Wed, Jul 30, 2025 at 02:18:51PM -0500:
> This is an updated attempt to convert 9p to the new mount API. 9p is
> one of the last conversions needed, possibly because it is one of the
> trickier ones!

Thanks for this work!

I think the main contention point here is that we're moving some opaque
logic that was in each transport into the common code, so e.g. an out of
tree transport can no longer have its own options (not that I'm aware of
such a transport existing anyway, so we probably don't have to worry
about this)

OTOH this is also a blessing because 9p used to silently ignore unknown
options, and will now properly refuse them (although it'd still silently
ignore e.g. rdma options being set for a virtio mount -- I guess there's
little harm in that as long as typos are caught?)

So I think I'm fine with the approach.

> I was able to test this to some degree, but I am not sure how to test
> all transports; there may well be bugs here. It would be great to get
> some feedback on whether this approach seems reasonable, and of course
> any further review or testing would be most welcome.

I still want to de-dust my test setup with rdma over siw for lack of
supported hardware, so I'll try to give it a try, but don't necessarily
wait for me as I don't know when that'll be..

-- 
Dominique Martinet | Asmadeus

On 7/30/25 5:21 PM, asmadeus@codewreck.org wrote:
> Hi Eric,
> 
> Eric Sandeen wrote on Wed, Jul 30, 2025 at 02:18:51PM -0500:
>> This is an updated attempt to convert 9p to the new mount API. 9p is
>> one of the last conversions needed, possibly because it is one of the
>> trickier ones!
> 
> Thanks for this work!
> 
> I think the main contention point here is that we're moving some opaque
> logic that was in each transport into the common code, so e.g. an out of
> tree transport can no longer have its own options (not that I'm aware of
> such a transport existing anyway, so we probably don't have to worry
> about this)
> 
> OTOH this is also a blessing because 9p used to silently ignore unknown
> options, and will now properly refuse them (although it'd still silently
> ignore e.g. rdma options being set for a virtio mount -- I guess there's
> little harm in that as long as typos are caught?)
> 
> So I think I'm fine with the approach.
> 
>> I was able to test this to some degree, but I am not sure how to test
>> all transports; there may well be bugs here. It would be great to get
>> some feedback on whether this approach seems reasonable, and of course
>> any further review or testing would be most welcome.
> 
> I still want to de-dust my test setup with rdma over siw for lack of
> supported hardware, so I'll try to give it a try, but don't necessarily
> wait for me as I don't know when that'll be..
> 

Any news on testing? :)

As for "waiting for you," I assume that's more for your maintainer peers
than for me? I'm not sure if this would go through Christian (cc'd) or
through you?

Thanks,
-Eric

Eric Sandeen wrote on Thu, Aug 14, 2025 at 11:55:20AM -0500:
> >> I was able to test this to some degree, but I am not sure how to test
> >> all transports; there may well be bugs here. It would be great to get
> >> some feedback on whether this approach seems reasonable, and of course
> >> any further review or testing would be most welcome.
> > 
> > I still want to de-dust my test setup with rdma over siw for lack of
> > supported hardware, so I'll try to give it a try, but don't necessarily
> > wait for me as I don't know when that'll be..
> 
> Any news on testing? :)

Thanks for the prompting, that's the kind of things I never get around
to if not reminded...

I got this to run with a fedora-based host (unlike debian siw is
built-in):

- host side
```
$ sudo modprobe siw
$ sudo rdma link add siw0 type siw netdev br0
(sanity check)
$ ibv_devices
    device          	  node GUID
    ------          	----------------
    siw0            	020000fffe000001
( https://github.com/chaos/diod build)
$ ./configure --enable-rdma --disable-auth && make -j
(diod run, it runs rdma by default; not squashing as root fails with
  rdma because of the ib_safe_file_access check:
  [611503.258375] uverbs_write: process 1490213 (diod) changed security contexts after opening file descriptor, this is not allowed.
)
$ sudo ./diod -f -e /tmp/linux-test/ --no-auth -U root -S 
```
- guest side (with -net user)
```
# modprobe siw
# rdma link add siw0 type siw netdev eth0
# mount -t 9p -o trans=rdma,aname=/tmp/linux-test <hostip> /mnt
```

I've tested both the new and old mount api (with util-linux mount and
busybox mount) and it all seems in order to me;
as discussed in the other part of the thread we're now failing on
unknown options but I think that's a feature and we can change that if
someone complains.

> As for "waiting for you," I assume that's more for your maintainer peers
> than for me? I'm not sure if this would go through Christian (cc'd) or
> through you?

Sorry, I wasn't paying attention and confused you with another Eric
(Van Hensbergen) who is a 9p maintainer, so I was thinking you'd take
the patches, but that wasn't correct.
And that's after seeing your name all the time in #xfs, I'm sorry..

Christian is "just" a reviewer (for now!), and none of the other
maintainers pick much up lately, so I'll give this a second look and
take the patches.
Linus just closed up 6.17-rc1 so I guess this will get in 6.18 in the
next cycle, unless there'd be a reason to hurry?

Thanks,
-- 
Dominique Martinet | Asmadeus

On Fri, Aug 15, 2025 at 10:49:48AM +0900, Dominique Martinet wrote:
> Eric Sandeen wrote on Thu, Aug 14, 2025 at 11:55:20AM -0500:
> > >> I was able to test this to some degree, but I am not sure how to test
> > >> all transports; there may well be bugs here. It would be great to get
> > >> some feedback on whether this approach seems reasonable, and of course
> > >> any further review or testing would be most welcome.
> > > 
> > > I still want to de-dust my test setup with rdma over siw for lack of
> > > supported hardware, so I'll try to give it a try, but don't necessarily
> > > wait for me as I don't know when that'll be..
> > 
> > Any news on testing? :)
> 
> Thanks for the prompting, that's the kind of things I never get around
> to if not reminded...
> 
> I got this to run with a fedora-based host (unlike debian siw is
> built-in):
> 
> - host side
> ```
> $ sudo modprobe siw
> $ sudo rdma link add siw0 type siw netdev br0
> (sanity check)
> $ ibv_devices
>     device          	  node GUID
>     ------          	----------------
>     siw0            	020000fffe000001
> ( https://github.com/chaos/diod build)
> $ ./configure --enable-rdma --disable-auth && make -j
> (diod run, it runs rdma by default; not squashing as root fails with
>   rdma because of the ib_safe_file_access check:
>   [611503.258375] uverbs_write: process 1490213 (diod) changed security contexts after opening file descriptor, this is not allowed.
> )
> $ sudo ./diod -f -e /tmp/linux-test/ --no-auth -U root -S 
> ```
> - guest side (with -net user)
> ```
> # modprobe siw
> # rdma link add siw0 type siw netdev eth0
> # mount -t 9p -o trans=rdma,aname=/tmp/linux-test <hostip> /mnt
> ```
> 
> I've tested both the new and old mount api (with util-linux mount and
> busybox mount) and it all seems in order to me;
> as discussed in the other part of the thread we're now failing on
> unknown options but I think that's a feature and we can change that if
> someone complains.
> 
> > As for "waiting for you," I assume that's more for your maintainer peers
> > than for me? I'm not sure if this would go through Christian (cc'd) or
> > through you?
> 
> Sorry, I wasn't paying attention and confused you with another Eric
> (Van Hensbergen) who is a 9p maintainer, so I was thinking you'd take
> the patches, but that wasn't correct.
> And that's after seeing your name all the time in #xfs, I'm sorry..
> 
> Christian is "just" a reviewer (for now!), and none of the other
> maintainers pick much up lately, so I'll give this a second look and
> take the patches.

Fyi, Eric (Sandeen) is talking about me, Christian Brauner, whereas you
seem to be thinking of Christian Schoenebeck...

Christian Brauner wrote on Fri, Aug 15, 2025 at 03:55:13PM +0200:
> Fyi, Eric (Sandeen) is talking about me, Christian Brauner, whereas you
> seem to be thinking of Christian Schoenebeck...

Ah, yes.. (He's also in cc, although is name doesn't show up in his
linux_oss@crudebyte mail)

Well, that makes more sense; I've picked up the patches now so I think
it's fine as it is but happy to drop the set if you have any reason to
want them, just let me know.
-- 
Dominique

On 8/15/25 3:53 PM, Dominique Martinet wrote:
> Christian Brauner wrote on Fri, Aug 15, 2025 at 03:55:13PM +0200:
>> Fyi, Eric (Sandeen) is talking about me, Christian Brauner, whereas you
>> seem to be thinking of Christian Schoenebeck...
> 
> Ah, yes.. (He's also in cc, although is name doesn't show up in his
> linux_oss@crudebyte mail)
> 
> Well, that makes more sense; I've picked up the patches now so I think
> it's fine as it is but happy to drop the set if you have any reason to
> want them, just let me know.

Hi Dominique - not to be pushy, but any chance for this in the current
merge window, if it's had enough soak time? If not it's not really urgent,
I just don't want it to get lost.

Thanks,
-Eric

Eric Sandeen wrote on Tue, Sep 23, 2025 at 05:21:14PM -0500:
> On 8/15/25 3:53 PM, Dominique Martinet wrote:
> > Christian Brauner wrote on Fri, Aug 15, 2025 at 03:55:13PM +0200:
> >> Fyi, Eric (Sandeen) is talking about me, Christian Brauner, whereas you
> >> seem to be thinking of Christian Schoenebeck...
> > 
> > Ah, yes.. (He's also in cc, although is name doesn't show up in his
> > linux_oss@crudebyte mail)
> > 
> > Well, that makes more sense; I've picked up the patches now so I think
> > it's fine as it is but happy to drop the set if you have any reason to
> > want them, just let me know.
> 
> Hi Dominique - not to be pushy, but any chance for this in the current
> merge window, if it's had enough soak time? If not it's not really urgent,
> I just don't want it to get lost.

Thanks for the mail;

This ran into a syzbot bug a while ago and I've been meaning to check
the v9ses setup as I wrote here:
https://lkml.kernel.org/r/aKlg5Ci4WC11GZGz@codewreck.org

Unfortunately I still haven't gotten around to it; my feeling is that
Edward's patch only papers over the issue and there's a problem with two
sessions hanging around when we really only should have one to avoid
such "woops I'm looking at the wrong one" errors.

If we can clear that up this week I'll happily retake the patches and I
think it can still make it this window, but I honestly don't think I'll
have time to look on my end sorry

-- 
Dominique

> On Sep 23, 2025, at 21:55, Dominique Martinet <asmadeus@codewreck.org> wrote:
> 
> Eric Sandeen wrote on Tue, Sep 23, 2025 at 05:21:14PM -0500:
>>> On 8/15/25 3:53 PM, Dominique Martinet wrote:
>>> Christian Brauner wrote on Fri, Aug 15, 2025 at 03:55:13PM +0200:
>>>> Fyi, Eric (Sandeen) is talking about me, Christian Brauner, whereas you
>>>> seem to be thinking of Christian Schoenebeck...
>>> 
>>> Ah, yes.. (He's also in cc, although is name doesn't show up in his
>>> linux_oss@crudebyte mail)
>>> 
>>> Well, that makes more sense; I've picked up the patches now so I think
>>> it's fine as it is but happy to drop the set if you have any reason to
>>> want them, just let me know.
>> 
>> Hi Dominique - not to be pushy, but any chance for this in the current
>> merge window, if it's had enough soak time? If not it's not really urgent,
>> I just don't want it to get lost.
> 
> Thanks for the mail;
> 
> This ran into a syzbot bug a while ago and I've been meaning to check
> the v9ses setup as I wrote here:
> https://lkml.kernel.org/r/aKlg5Ci4WC11GZGz@codewreck.org
> 
Ah, I had missed that so now it’s my turn to say sorry, didn’t mean to ignore. I’ll take a look and see if I can help.

-Eric S

On 8/14/25 8:49 PM, Dominique Martinet wrote:
> Eric Sandeen wrote on Thu, Aug 14, 2025 at 11:55:20AM -0500:

...

>> Any news on testing? :)
> 
> Thanks for the prompting, that's the kind of things I never get around
> to if not reminded...
> 
> I got this to run with a fedora-based host (unlike debian siw is
> built-in):
> 
> - host side
> ```
> $ sudo modprobe siw
> $ sudo rdma link add siw0 type siw netdev br0
> (sanity check)
> $ ibv_devices
>     device          	  node GUID
>     ------          	----------------
>     siw0            	020000fffe000001
> ( https://github.com/chaos/diod build)
> $ ./configure --enable-rdma --disable-auth && make -j
> (diod run, it runs rdma by default; not squashing as root fails with
>   rdma because of the ib_safe_file_access check:
>   [611503.258375] uverbs_write: process 1490213 (diod) changed security contexts after opening file descriptor, this is not allowed.
> )
> $ sudo ./diod -f -e /tmp/linux-test/ --no-auth -U root -S 
> ```
> - guest side (with -net user)
> ```
> # modprobe siw
> # rdma link add siw0 type siw netdev eth0
> # mount -t 9p -o trans=rdma,aname=/tmp/linux-test <hostip> /mnt
> ```
> 
> I've tested both the new and old mount api (with util-linux mount and
> busybox mount) and it all seems in order to me;
> as discussed in the other part of the thread we're now failing on
> unknown options but I think that's a feature and we can change that if
> someone complains.

Super, thanks.

>> As for "waiting for you," I assume that's more for your maintainer peers
>> than for me? I'm not sure if this would go through Christian (cc'd) or
>> through you?
> 
> Sorry, I wasn't paying attention and confused you with another Eric
> (Van Hensbergen) who is a 9p maintainer, so I was thinking you'd take
> the patches, but that wasn't correct.
> And that's after seeing your name all the time in #xfs, I'm sorry..

No worries! I don't mind being confused with awesome people ;)

> Christian is "just" a reviewer (for now!), and none of the other
> maintainers pick much up lately, so I'll give this a second look and
> take the patches.
> Linus just closed up 6.17-rc1 so I guess this will get in 6.18 in the
> next cycle, unless there'd be a reason to hurry?

No reason to hurry. This has been a long process, and a little longer will
not hurt.

Thanks!
-Eric (Sandeen)

> Thanks,

On 7/30/25 5:21 PM, asmadeus@codewreck.org wrote:
> Hi Eric,
> 
> Eric Sandeen wrote on Wed, Jul 30, 2025 at 02:18:51PM -0500:
>> This is an updated attempt to convert 9p to the new mount API. 9p is
>> one of the last conversions needed, possibly because it is one of the
>> trickier ones!
> 
> Thanks for this work!
> 
> I think the main contention point here is that we're moving some opaque
> logic that was in each transport into the common code, so e.g. an out of
> tree transport can no longer have its own options (not that I'm aware of
> such a transport existing anyway, so we probably don't have to worry
> about this)

I had not thought about out of tree transports. And I was a little unsure
about moving everything into fs/9p/* but I'm not sure I saw any other way
to do it in the new framework. @dhowells?

> OTOH this is also a blessing because 9p used to silently ignore unknown
> options, and will now properly refuse them (although it'd still silently
> ignore e.g. rdma options being set for a virtio mount -- I guess there's
> little harm in that as long as typos are caught?)

Well, that might be considered a regression. Such conversions have burned
us before, so if you want, it might be possible to keep the old more
permissive behavior ... I'd have to look, not sure.

> So I think I'm fine with the approach.
> 
>> I was able to test this to some degree, but I am not sure how to test
>> all transports; there may well be bugs here. It would be great to get
>> some feedback on whether this approach seems reasonable, and of course
>> any further review or testing would be most welcome.
> 
> I still want to de-dust my test setup with rdma over siw for lack of
> supported hardware, so I'll try to give it a try, but don't necessarily
> wait for me as I don't know when that'll be..

Cool, thanks.

-Eric

Eric Sandeen wrote on Wed, Jul 30, 2025 at 08:38:17PM -0500:
> > I think the main contention point here is that we're moving some opaque
> > logic that was in each transport into the common code, so e.g. an out of
> > tree transport can no longer have its own options (not that I'm aware of
> > such a transport existing anyway, so we probably don't have to worry
> > about this)
> 
> I had not thought about out of tree transports. And I was a little unsure
> about moving everything into fs/9p/* but I'm not sure I saw any other way
> to do it in the new framework. @dhowells?

I've had a quick look as well and I don't see either -- parameters are
parsed one at a time so we can't do the two passes needed to first get
the transport out of the arguments and then instantiate a transport and
parse again.
I really think it's fine in practice, just something to remember.

> > OTOH this is also a blessing because 9p used to silently ignore unknown
> > options, and will now properly refuse them (although it'd still silently
> > ignore e.g. rdma options being set for a virtio mount -- I guess there's
> > little harm in that as long as typos are caught?)
> 
> Well, that might be considered a regression. Such conversions have burned
> us before, so if you want, it might be possible to keep the old more
> permissive behavior ... I'd have to look, not sure.

From my understanding we just need to make v9fs_parse_param return 0
instead of 'opt' if fs_parse() < 0, but I think it's fine to error on
unknown options (more in line with other filesystems at least)
We can reconsider this and make it a non-error when or if someone
complains about it.

-- 
Dominique Martinet | Asmadeus