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.
Best regards,
Christian Schoenebeck
