public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Juergen Gross <jgross@suse.com>
Cc: Wei Liu <wei.liu@kernel.org>, Paul Durrant <paul@xen.org>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	xen-devel@lists.xenproject.org, stable@vger.kernel.org,
	linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH 1/2] xen/netback: don't do grant copy across page boundary
Date: Tue, 28 Mar 2023 09:50:16 +0200	[thread overview]
Message-ID: <4992e7c4-e424-1fce-b508-ff9eaf2fbf2a@suse.com> (raw)
In-Reply-To: <f94dbfe9-f690-8c3e-c251-b0d5f93d32f9@suse.com>

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

  reply	other threads:[~2023-03-28  7:50 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-27  8:36 [PATCH 0/2] xen/netback: fix issue introduced recently Juergen Gross
2023-03-27  8:36 ` [PATCH 1/2] xen/netback: don't do grant copy across page boundary Juergen Gross
2023-03-27  9:04   ` Paul Durrant
2023-03-27  9:49   ` Jan Beulich
2023-03-27 10:07     ` Juergen Gross
2023-03-27 15:38       ` Jan Beulich
2023-03-27 16:22         ` Juergen Gross
2023-03-28  7:50           ` Jan Beulich [this message]
2023-03-27  8:36 ` [PATCH 2/2] xen/netback: remove not needed test in xenvif_tx_build_gops() Juergen Gross
2023-03-27  9:04   ` Paul Durrant
2023-03-28 13:30 ` [PATCH 0/2] xen/netback: fix issue introduced recently patchwork-bot+netdevbpf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4992e7c4-e424-1fce-b508-ff9eaf2fbf2a@suse.com \
    --to=jbeulich@suse.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=jgross@suse.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=paul@xen.org \
    --cc=stable@vger.kernel.org \
    --cc=wei.liu@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox