On Thu, 14 May 2020, Christian Schoenebeck wrote: > On Donnerstag, 14. Mai 2020 17:51:27 CEST Stefano Stabellini wrote: > > On Thu, 14 May 2020, Christian Schoenebeck wrote: > > > Looks like this issue will still take quite some time to be fixed with > > > Xen. If you don't mind I'll send out a patch to revert truncation on > > > virtio side, so that at least this bug is fixed with virtio ASAP. > > > > Let me answer to this quickly so that if you want to get the patch out > > today you can. > > > > > > Yes, I think it is OK to revert truncation in virtio now. > > Good > > > Only one > > thing: would there still be any value in doing for Xen: > > > > + if (pdu->id + 1 == P9_RREAD) { > > + /* size[4] Rread tag[2] count[4] data[count] */ > > + const size_t hdr_size = 11; > > + /* > > + * If current transport buffer size is smaller than actually > > required + * for this Rreaddir response, then truncate the response > > to the + * currently available transport buffer size, however only > > if it would + * at least allow to return 1 payload byte to client. > > + */ > > + if (buf_size < hdr_size + 1) { > > > > > > like your patch here does? Although not a complete solution it looks > > like it would still be a good improvement over the current situation for > > Xen. > > IMO in its current form, no. It would just move the problematic from a > clearly > visible 9pfs server termination with error, towards a silent data loss > (without any error) on client side. Remember: this patch does not roll back > the filesystem driver's read position.
OK