(sigh, I'm tired -- said I'd add Christian in Ccs and promply forgot to do it. Sorry for double send to everyone else.) +Christian Schoenebeck in Ccs as that concerns qemu as well. The patch I'm replying to is at https://lkml.kernel.org/r/20220622041552.737754-1-viro@xxxxxxxxxxxxxxxxxx Al Viro wrote on Wed, Jun 22, 2022 at 05:15:09AM +0100: > p9_client_zc_rpc()/p9_check_zc_errors() are playing fast > and loose with copy_from_iter_full(). > > Reading from file is done by sending Tread request. Response > consists of fixed-sized header (including the amount of data actually > read) followed by the data itself. > > For zero-copy case we arrange the things so that the first > 11 bytes of reply go into the fixed-sized buffer, with the rest going > straight into the pages we want to read into. > > What makes the things inconvenient is that sglist describing > what should go where has to be set *before* the reply arrives. As > the result, if reply is an error, the things get interesting. On success > we get > size[4] Rread tag[2] count[4] data[count] > For error layout varies depending upon the protocol variant - > in original 9P and 9P2000 it's > size[4] Rerror tag[2] len[2] error[len] > in 9P2000.U > size[4] Rerror tag[2] len[2] error[len] errno[4] > in 9P2000.L > size[4] Rlerror tag[2] errno[4] > > The last case is nice and simple - we have an 11-byte response > that fits into the fixed-sized buffer we hoped to get an Rread into. > In other two, though, we get a variable-length string spill into the > pages we'd prepared for the data to be read. > > Had that been in fixed-sized buffer (which is actually 4K), > we would've dealt with that the same way we handle non-zerocopy case. > However, for zerocopy it doesn't end up there, so we need to copy it > from those pages. > > The trouble is, by the time we get around to that, the > references to pages in question are already dropped. As the result, > p9_zc_check_errors() tries to get the data using copy_from_iter_full(). > Unfortunately, the iov_iter it's trying to read from might *NOT* be > capable of that. It is, after all, a data destination, not data source. > In particular, if it's an ITER_PIPE one, copy_from_iter_full() will > simply fail. > > In ->zc_request() itself we do have those pages and dealing with > the problem in there would be a simple matter of memcpy_from_page() > into the fixed-sized buffer. Moreover, it isn't hard to recognize > the (rare) case when such copying is needed. That way we get rid of > p9_zc_check_errors() entirely - p9_check_errors() can be used instead > both for zero-copy and non-zero-copy cases. > > Signed-off-by: Al Viro <viro@xxxxxxxxxxxxxxxxxx> I ran basic tests with this, should be ok given the code path is never used on normal (9p2000.L) workloads. I also tried 9p2000.u for principle and ... I have no idea if this works but it didn't seem to blow up there at least. The problem is that 9p2000.u just doesn't work well even without these patches, so I still stand by what I said about 9p2000.u and virtio (zc interface): we really can (and I think should) just say virtio doesn't support 9p2000.u. (and could then further simplify this) If you're curious, 9p2000.u hangs without your patch on at least two different code paths (trying to read a huge buffer aborts sending a reply because msize is too small instead of clamping it, that one has a qemu warning message; but there are others ops like copyrange that just fail silently and I didn't investigate) I'd rather not fool someone into believing we support it when nobody has time to maintain it and it fails almost immediately when user requests some unusual IO patterns... And I definitely don't have time to even try fixing it. I'll suggest the same thing to qemu lists if we go that way. Anyway, for anything useful: Reviewed-by: Dominique Martinet <asmadeus@xxxxxxxxxxxxx> Tested-by: Dominique Martinet <asmadeus@xxxxxxxxxxxxx> -- Dominique
