linux-kernel - Re: [PATCH RFC v2] 9p/virtio: convert to extract_iter_to

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: <22933653.EfDdHjke4D@weasel>
Date: Sat, 13 Dec 2025 19:02:00 +0100
From: Christian Schoenebeck <linux_oss@...debyte.com>
To: Christoph Hellwig <hch@...radead.org>,
 Eric Van Hensbergen <ericvh@...nel.org>, Latchesar Ionkov <lucho@...kov.net>,
 asmadeus@...ewreck.org, Dominique Martinet <asmadeus@...ewreck.org>
Cc: v9fs@...ts.linux.dev, linux-kernel@...r.kernel.org,
 David Howells <dhowells@...hat.com>, Matthew Wilcox <willy@...radead.org>,
 linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH RFC v2] 9p/virtio: convert to extract_iter_to_sg()

On Saturday, 13 December 2025 16:07:40 CET Dominique Martinet via B4 Relay wrote:
> From: Dominique Martinet <asmadeus@...ewreck.org>
> 
> This simplifies the code quite a bit and should fix issues with
> blowing up when iov_iter points at kmalloc data
> 
> RFC - Not really tested yet!!

TBH, that bothers me. Also considering the huge amount of changes; again, what
was actually wrong with the previously suggested simple patch v1 [1]? All I
can see is a discussion about the term "folio" being misused in the commit log
message, but nothing about the patch being wrong per se.

[1] https://lore.kernel.org/all/20251210-virtio_trans_iter-v1-1-92eee6d8b6db@codewreck.org/

> This brings two major changes to how we've always done things with
> virtio 9p though:
> - We no longer fill in "chan->sg" with user data, but instead allocate a
>   scatterlist; this should not be a problem nor a slowdown as previous
>   code would allocate a page list instead, the main difference is that
>   this might eventually lead to lifting the 512KB msize limit if
>   compatible with virtio?

Remember that I already had a patch set for lifting the msize limit [2], which
was *heavily* tested and will of course break with these changes BTW, and the
reason why I used a custom struct virtqueue_sg instead of the shared sg_table
API was that the latter could not be resized (see commit log of patch 3).

[2] https://lore.kernel.org/all/cover.1657920926.git.linux_oss@crudebyte.com/

/Christian