Re: [PATCH 2/2] 9pfs: fix init_in_iov_from_pdu truncating size

[Christian Schoenebeck <qemu_oss@crudebyte.com>]

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