linux-kernel - Re: [PATCH V2 0/4] 9p: convert to the new mount API

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <6e965060-7b1b-4bbf-b99b-fc0f79b860f8@sandeen.net>
Date: Thu, 14 Aug 2025 11:55:20 -0500
From: Eric Sandeen <sandeen@...deen.net>
To: asmadeus@...ewreck.org, Eric Sandeen <sandeen@...hat.com>
Cc: v9fs@...ts.linux.dev, linux-fsdevel@...r.kernel.org,
 linux-kernel@...r.kernel.org, ericvh@...nel.org, lucho@...kov.net,
 linux_oss@...debyte.com, dhowells@...hat.com,
 Christian Brauner <brauner@...nel.org>
Subject: Re: [PATCH V2 0/4] 9p: convert to the new mount API

On 7/30/25 5:21 PM, asmadeus@...ewreck.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