Netdev Archive on lore.kernel.org
help / color / mirror / Atom feed
* [PATCH] xen-netback: correct success/error reporting for the SKB-with-fraglist case
@ 2021-02-23 16:29 Jan Beulich
  2021-02-24 16:39 ` Paul Durrant
  0 siblings, 1 reply; 12+ messages in thread
From: Jan Beulich @ 2021-02-23 16:29 UTC (permalink / raw)
  To: Wei Liu, Paul Durrant; +Cc: xen-devel, netdev

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@suse.com>

--- 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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] xen-netback: correct success/error reporting for the SKB-with-fraglist case
  2021-02-23 16:29 [PATCH] xen-netback: correct success/error reporting for the SKB-with-fraglist case Jan Beulich
@ 2021-02-24 16:39 ` Paul Durrant
  2021-02-25  7:33   ` Jan Beulich
  0 siblings, 1 reply; 12+ messages in thread
From: Paul Durrant @ 2021-02-24 16:39 UTC (permalink / raw)
  To: Jan Beulich, Wei Liu; +Cc: xen-devel, netdev

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@suse.com>
> 
> --- 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.

   Paul



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] xen-netback: correct success/error reporting for the SKB-with-fraglist case
  2021-02-24 16:39 ` Paul Durrant
@ 2021-02-25  7:33   ` Jan Beulich
  2021-02-25 12:11     ` Paul Durrant
  0 siblings, 1 reply; 12+ messages in thread
From: Jan Beulich @ 2021-02-25  7:33 UTC (permalink / raw)
  To: paul; +Cc: xen-devel, netdev, Wei Liu

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@suse.com>
>>
>> --- 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").

Jan

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] xen-netback: correct success/error reporting for the SKB-with-fraglist case
  2021-02-25  7:33   ` Jan Beulich
@ 2021-02-25 12:11     ` Paul Durrant
  2021-02-25 14:00       ` Jan Beulich
  0 siblings, 1 reply; 12+ messages in thread
From: Paul Durrant @ 2021-02-25 12:11 UTC (permalink / raw)
  To: Jan Beulich; +Cc: xen-devel, netdev, Wei Liu

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@suse.com>
>>>
>>> --- 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' (which is why I still think it is safe to 
unconst 'sharedslot' and clear it).

   Paul


> Jan
> 


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] xen-netback: correct success/error reporting for the SKB-with-fraglist case
  2021-02-25 12:11     ` Paul Durrant
@ 2021-02-25 14:00       ` Jan Beulich
  2021-02-25 16:23         ` Paul Durrant
  0 siblings, 1 reply; 12+ messages in thread
From: Jan Beulich @ 2021-02-25 14:00 UTC (permalink / raw)
  To: paul; +Cc: xen-devel, netdev, Wei Liu

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@suse.com>
>>>>
>>>> --- 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).

> (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.

Jan

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] xen-netback: correct success/error reporting for the SKB-with-fraglist case
  2021-02-25 14:00       ` Jan Beulich
@ 2021-02-25 16:23         ` Paul Durrant
  2021-05-20 11:46           ` Jan Beulich
  0 siblings, 1 reply; 12+ messages in thread
From: Paul Durrant @ 2021-02-25 16:23 UTC (permalink / raw)
  To: Jan Beulich; +Cc: xen-devel, netdev, Wei Liu

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@suse.com>
>>>>>
>>>>> --- 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@xen.org>

> Jan
> 


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] xen-netback: correct success/error reporting for the SKB-with-fraglist case
  2021-02-25 16:23         ` Paul Durrant
@ 2021-05-20 11:46           ` Jan Beulich
  2021-07-15  8:58             ` Ping: " Jan Beulich
  0 siblings, 1 reply; 12+ messages in thread
From: Jan Beulich @ 2021-05-20 11:46 UTC (permalink / raw)
  To: paul, Wei Liu, netdev; +Cc: xen-devel

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@suse.com>
>>>>>>
>>>>>> --- 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@xen.org>

Since I've not seen this go into 5.13-rc, may I ask what the disposition
of this is?

Jan

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Ping: [PATCH] xen-netback: correct success/error reporting for the SKB-with-fraglist case
  2021-05-20 11:46           ` Jan Beulich
@ 2021-07-15  8:58             ` Jan Beulich
  2021-09-16 15:45               ` Ping²: " Jan Beulich
  0 siblings, 1 reply; 12+ messages in thread
From: Jan Beulich @ 2021-07-15  8:58 UTC (permalink / raw)
  To: paul, Wei Liu, netdev; +Cc: xen-devel

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@suse.com>
>>>>>>>
>>>>>>> --- 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@xen.org>
> 
> 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 ...

Jan


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Ping²: [PATCH] xen-netback: correct success/error reporting for the SKB-with-fraglist case
  2021-07-15  8:58             ` Ping: " Jan Beulich
@ 2021-09-16 15:45               ` Jan Beulich
  2021-09-16 18:34                 ` Paul Durrant
  0 siblings, 1 reply; 12+ messages in thread
From: Jan Beulich @ 2021-09-16 15:45 UTC (permalink / raw)
  To: paul, Wei Liu; +Cc: xen-devel, netdev

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@suse.com>
>>>>>>>>
>>>>>>>> --- 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@xen.org>
>>
>> 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?

Jan


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Ping²: [PATCH] xen-netback: correct success/error reporting for the SKB-with-fraglist case
  2021-09-16 15:45               ` Ping²: " Jan Beulich
@ 2021-09-16 18:34                 ` Paul Durrant
  2021-09-16 21:48                   ` Sander Eikelenboom
  0 siblings, 1 reply; 12+ messages in thread
From: Paul Durrant @ 2021-09-16 18:34 UTC (permalink / raw)
  To: Jan Beulich, Wei Liu; +Cc: xen-devel, netdev

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@suse.com>
>>>>>>>>>
>>>>>>>>> --- 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@xen.org>
>>>
>>> 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


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Ping²: [PATCH] xen-netback: correct success/error reporting for the SKB-with-fraglist case
  2021-09-16 18:34                 ` Paul Durrant
@ 2021-09-16 21:48                   ` Sander Eikelenboom
  2021-09-17  6:21                     ` Jan Beulich
  0 siblings, 1 reply; 12+ messages in thread
From: Sander Eikelenboom @ 2021-09-16 21:48 UTC (permalink / raw)
  To: paul, Jan Beulich, Wei Liu; +Cc: xen-devel, netdev

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@suse.com>
>>>>>>>>>>
>>>>>>>>>> --- 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@xen.org>
>>>>
>>>> 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 ?

--
Sander

[1] 
https://www.kernel.org/doc/html/latest/networking/netdev-FAQ.html#how-do-i-indicate-which-tree-net-vs-net-next-my-patch-should-be-in

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Ping²: [PATCH] xen-netback: correct success/error reporting for the SKB-with-fraglist case
  2021-09-16 21:48                   ` Sander Eikelenboom
@ 2021-09-17  6:21                     ` Jan Beulich
  0 siblings, 0 replies; 12+ messages in thread
From: Jan Beulich @ 2021-09-17  6:21 UTC (permalink / raw)
  To: Sander Eikelenboom; +Cc: xen-devel, paul, netdev, Wei Liu

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@suse.com>
>>>>>>>>>>>
>>>>>>>>>>> --- 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@xen.org>
>>>>>
>>>>> 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


^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2021-09-17  6:22 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-23 16:29 [PATCH] xen-netback: correct success/error reporting for the SKB-with-fraglist case Jan Beulich
2021-02-24 16:39 ` Paul Durrant
2021-02-25  7:33   ` Jan Beulich
2021-02-25 12:11     ` Paul Durrant
2021-02-25 14:00       ` Jan Beulich
2021-02-25 16:23         ` Paul Durrant
2021-05-20 11:46           ` Jan Beulich
2021-07-15  8:58             ` Ping: " Jan Beulich
2021-09-16 15:45               ` Ping²: " Jan Beulich
2021-09-16 18:34                 ` Paul Durrant
2021-09-16 21:48                   ` Sander Eikelenboom
2021-09-17  6:21                     ` Jan Beulich

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).