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

Re: Ping²: [PATCH] xen-netback: correct success/error reporting for the SKB-with-fraglist case


  • To: Sander Eikelenboom <sander@xxxxxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Fri, 17 Sep 2021 08:21:51 +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; bh=CMM/97FhbTpeL+vc4edx0Gfl6KNqYqL9R5Sqa0QJDBQ=; b=e07MXve257lbbSQsT3TzrGGxt5aPcRVWE0GB3sf6hbB2i7EllH31r7LBV3z0Q3gg2r0UPEod5BRDlevJap2B+rX5MgtbgdsOJRoXS8Pm7dj1IQ/bTx15SfGaTuIpg4I9oEMXdGHrizG3JU7hARPu4HSP95XI9iBz7tgUqIjpb0XgO0TNS50p7THS8hccRwW+fq1Slk3Okd0TNMHNfR9rLdQLqheDq0pUgbK4kmWoyxlA1wNC5q0tDkp5LbcCBzUJGOGijPS5CJfwwvN22M1kjQvCKPLIhxpqXOwlnODI1yclMEL/lj/F8O8hmF2c/Ja+vJUlGtYgnL91cbHh4fZi7g==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LBuDm9U8ePbj6QZONi6zz7a+671/mr88cytxzCnbdnj27mNGUQe9RK8iHGD5io2sR879wht96NfvtZGwkMKSVX+H2EXxmyPvr9KnzlT2Dk57v/IuClk5f433goKkaGJawA3WE1ucj7FqjEDscIXqcsSal8F5sdYbB+GWwpfVK95fJh5EeFuvy3UzpXBy3IwRtBQPtjfdIVnjFtCNCSkh91HbkwkZssQGncqao/ZMEYk+Bx3g6PWgBG/qxlmZCNWFFgCAfyMajIsKrl641uexdRlyZx8LmhtayUe49URNiLAUDVhm6TTjrjPZ1QHZsAxEPqmF7X39SCW9XaWgx7mZkA==
  • Authentication-results: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=suse.com;
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, paul@xxxxxxx, "netdev@xxxxxxxxxxxxxxx" <netdev@xxxxxxxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Fri, 17 Sep 2021 06:22:05 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 16.09.2021 23:48, Sander Eikelenboom wrote:
> On 16/09/2021 20:34, Paul Durrant wrote:
>> On 16/09/2021 16:45, Jan Beulich wrote:
>>> On 15.07.2021 10:58, Jan Beulich wrote:
>>>> On 20.05.2021 13:46, Jan Beulich wrote:
>>>>> On 25.02.2021 17:23, Paul Durrant wrote:
>>>>>> On 25/02/2021 14:00, Jan Beulich wrote:
>>>>>>> On 25.02.2021 13:11, Paul Durrant wrote:
>>>>>>>> On 25/02/2021 07:33, Jan Beulich wrote:
>>>>>>>>> On 24.02.2021 17:39, Paul Durrant wrote:
>>>>>>>>>> On 23/02/2021 16:29, Jan Beulich wrote:
>>>>>>>>>>> When re-entering the main loop of xenvif_tx_check_gop() a 2nd time, 
>>>>>>>>>>> the
>>>>>>>>>>> special considerations for the head of the SKB no longer apply. 
>>>>>>>>>>> Don't
>>>>>>>>>>> mistakenly report ERROR to the frontend for the first entry in the 
>>>>>>>>>>> list,
>>>>>>>>>>> even if - from all I can tell - this shouldn't matter much as the 
>>>>>>>>>>> overall
>>>>>>>>>>> transmit will need to be considered failed anyway.
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>>>>>>>>>>>
>>>>>>>>>>> --- a/drivers/net/xen-netback/netback.c
>>>>>>>>>>> +++ b/drivers/net/xen-netback/netback.c
>>>>>>>>>>> @@ -499,7 +499,7 @@ check_frags:
>>>>>>>>>>>                                      * the header's copy failed, 
>>>>>>>>>>> and they are
>>>>>>>>>>>                                      * sharing a slot, send an error
>>>>>>>>>>>                                      */
>>>>>>>>>>> -                           if (i == 0 && sharedslot)
>>>>>>>>>>> +                           if (i == 0 && !first_shinfo && 
>>>>>>>>>>> sharedslot)
>>>>>>>>>>>                                             
>>>>>>>>>>> xenvif_idx_release(queue, pending_idx,
>>>>>>>>>>>                                                                
>>>>>>>>>>> XEN_NETIF_RSP_ERROR);
>>>>>>>>>>>                                     else
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I think this will DTRT, but to my mind it would make more sense to 
>>>>>>>>>> clear
>>>>>>>>>> 'sharedslot' before the 'goto check_frags' at the bottom of the 
>>>>>>>>>> function.
>>>>>>>>>
>>>>>>>>> That was my initial idea as well, but
>>>>>>>>> - I think it is for a reason that the variable is "const".
>>>>>>>>> - There is another use of it which would then instead need further
>>>>>>>>>       amending (and which I believe is at least part of the reason for
>>>>>>>>>       the variable to be "const").
>>>>>>>>>
>>>>>>>>
>>>>>>>> Oh, yes. But now that I look again, don't you want:
>>>>>>>>
>>>>>>>> if (i == 0 && first_shinfo && sharedslot)
>>>>>>>>
>>>>>>>> ? (i.e no '!')
>>>>>>>>
>>>>>>>> The comment states that the error should be indicated when the first
>>>>>>>> frag contains the header in the case that the map succeeded but the
>>>>>>>> prior copy from the same ref failed. This can only possibly be the case
>>>>>>>> if this is the 'first_shinfo'
>>>>>>>
>>>>>>> I don't think so, no - there's a difference between "first frag"
>>>>>>> (at which point first_shinfo is NULL) and first frag list entry
>>>>>>> (at which point first_shinfo is non-NULL).
>>>>>>
>>>>>> Yes, I realise I got it backwards. Confusing name but the comment above
>>>>>> its declaration does explain.
>>>>>>
>>>>>>>
>>>>>>>> (which is why I still think it is safe to unconst 'sharedslot' and
>>>>>>>> clear it).
>>>>>>>
>>>>>>> And "no" here as well - this piece of code
>>>>>>>
>>>>>>>                 /* First error: if the header haven't shared a slot 
>>>>>>> with the
>>>>>>>                  * first frag, release it as well.
>>>>>>>                  */
>>>>>>>                 if (!sharedslot)
>>>>>>>                         xenvif_idx_release(queue,
>>>>>>>                                            
>>>>>>> XENVIF_TX_CB(skb)->pending_idx,
>>>>>>>                                            XEN_NETIF_RSP_OKAY);
>>>>>>>
>>>>>>> specifically requires sharedslot to have the value that was
>>>>>>> assigned to it at the start of the function (this property
>>>>>>> doesn't go away when switching from fragments to frag list).
>>>>>>> Note also how it uses XENVIF_TX_CB(skb)->pending_idx, i.e. the
>>>>>>> value the local variable pending_idx was set from at the start
>>>>>>> of the function.
>>>>>>>
>>>>>>
>>>>>> True, we do have to deal with freeing up the header if the first map
>>>>>> error comes on the frag list.
>>>>>>
>>>>>> Reviewed-by: Paul Durrant <paul@xxxxxxx>
>>>>>
>>>>> Since I've not seen this go into 5.13-rc, may I ask what the disposition
>>>>> of this is?
>>>>
>>>> I can't seem to spot this in 5.14-rc either. I have to admit I'm
>>>> increasingly puzzled ...
>>>
>>> Another two months (and another release) later and still nothing. Am
>>> I doing something wrong? Am I wrongly assuming that maintainers would
>>> push such changes up the chain?
>>>
>>
>> It has my R-b so it ought to go in via netdev AFAICT.
>>
>>     Paul
> 
> Could it be the missing "net" or "net-next" designation in the subject 
> [1] which seems to be used and important within their patchwork 
> semi-automated workflow ?

I wouldn't exclude this, but having to play special games there means
I'll try to refrain from fixing any bugs under net/ in the future. I'll
resend following their apparently required pattern.

Jan




 


Rackspace

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