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

Message-ID: <aItglBck_Ubo7udq@codewreck.org>
Date: Thu, 31 Jul 2025 21:24:52 +0900
From: asmadeus@...ewreck.org
To: 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
Subject: Re: [PATCH V2 0/4] 9p: convert to the new mount API

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