[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 1/2] xen/netback: don't do grant copy across page boundary


  • To: Juergen Gross <jgross@xxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 28 Mar 2023 09:50:16 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=kn8Isedu5ZHAI5xEhdAg+vLqa0pzkRpjr6Vq35BBG2s=; b=gIL+RdbP/5FM18k8b6j64ytgJuNpdBqdNHbEn4u9jx7Mx7jjoX7I6mQrQeB8PwMaensf+q5ZgWBrKd3cw4qBJfPFdwwUIAXr4rnAL3K8MhRBT5flebtt53FeJtBYS0b2XJANbnPbwi83jHAF/medVBwii0+Fno1LvwZ0vLD8YvGABOd4ZughRH9MRYf4bBoie5H/3tASIkqKsnIycbFJaO0Z59wssW/9esT7iq9pK4VwnMHs/RZ1GYjl2JD9jknFByY9KEC7d+Xdo8yyJWqch+kvdQRR9PpWZ9p+HtpBL6XHiJkoVq6PoDTKWQvstgJARxhDrfsz8wKk/++YiR8Aig==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BfeFYeRvZWNmxHQxrNCgh8W5M1Xo2TpncEYZR4gomCBCms0E1WUc9BxQ7Yt1jUfIZs56mX28pZ7/Gd4UKOeAPBglbr9FpqdUK6/m1v2+piJsickhI3/JYo7RYK00f4qi52+Anv6c4mTRXuaMCjSD1lqDBB5kNzwoPfMhYSgPKNssfQ7yi8RyH5MY+eKFjavqBt0d04bmoxarOIPbp3HOOYyGvtfR/dP4YO5Hpmxb099gUalBOGUnD0ECGTk80LbbspOepfRtTlHWRNEnqDY6IbKazSR0XOk5+PCSsIyxPYSGpxipFC4ZZkiIRVK6TG8djZc7EZagnvW31ssyKQQNYg==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Wei Liu <wei.liu@xxxxxxxxxx>, Paul Durrant <paul@xxxxxxx>, "David S. Miller" <davem@xxxxxxxxxxxxx>, Eric Dumazet <edumazet@xxxxxxxxxx>, Jakub Kicinski <kuba@xxxxxxxxxx>, Paolo Abeni <pabeni@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx, stable@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, netdev@xxxxxxxxxxxxxxx
  • Delivery-date: Tue, 28 Mar 2023 07:50:34 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 27.03.2023 18:22, Juergen Gross wrote:
> On 27.03.23 17:38, Jan Beulich wrote:
>> On 27.03.2023 12:07, Juergen Gross wrote:
>>> On 27.03.23 11:49, Jan Beulich wrote:
>>>> On 27.03.2023 10:36, Juergen Gross wrote:
>>>>> @@ -539,6 +553,13 @@ static int xenvif_tx_check_gop(struct xenvif_queue 
>>>>> *queue,
>>>>>                   pending_idx = copy_pending_idx(skb, i);
>>>>>    
>>>>>                   newerr = (*gopp_copy)->status;
>>>>> +
>>>>> +         /* Split copies need to be handled together. */
>>>>> +         if (XENVIF_TX_CB(skb)->split_mask & (1U << i)) {
>>>>> +                 (*gopp_copy)++;
>>>>> +                 if (!newerr)
>>>>> +                         newerr = (*gopp_copy)->status;
>>>>> +         }
>>>>
>>>> It isn't guaranteed that a slot may be split only once, is it? Assuming a
>>>
>>> I think it is guaranteed.
>>>
>>> No slot can cover more than XEN_PAGE_SIZE bytes due to the grants being
>>> restricted to that size. There is no way how such a data packet could cross
>>> 2 page boundaries.
>>>
>>> In the end the problem isn't the copies for the linear area not crossing
>>> multiple page boundaries, but the copies for a single request slot not
>>> doing so. And this can't happen IMO.
>>
>> You're thinking of only well-formed requests. What about said request
>> providing a large size with only tiny fragments? xenvif_get_requests()
>> will happily process such, creating bogus grant-copy ops. But them failing
>> once submitted to Xen will be only after damage may already have occurred
>> (from bogus updates of internal state; the logic altogether is too
>> involved for me to be convinced that nothing bad can happen).
> 
> There are sanity checks after each relevant RING_COPY_REQUEST() call, which
> will bail out if "(txp->offset + txp->size) > XEN_PAGE_SIZE" (the first one
> is after the call of xenvif_count_requests(), as this call will decrease the
> size of the request, the other check is in xenvif_count_requests()).

Oh, indeed - that's the check I've been overlooking. (The messages logged
there could do with also mentioning "Cross page boundary", like the one
in xenvif_count_requests() does.)

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.