linux-kernel - Re: [PATCH] xen/netback: fix build warning

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 7 Dec 2022 11:26:39 +0100
From:   Jan Beulich <jbeulich@...e.com>
To:     Juergen Gross <jgross@...e.com>
Cc:     Wei Liu <wei.liu@...nel.org>, Paul Durrant <paul@....org>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        xen-devel@...ts.xenproject.org, linux-kernel@...r.kernel.org,
        netdev@...r.kernel.org, Ross Lagerwall <ross.lagerwall@...rix.com>
Subject: Re: [PATCH] xen/netback: fix build warning

On 07.12.2022 11:18, Juergen Gross wrote:
> On 07.12.22 10:25, Jan Beulich wrote:
>> On 07.12.2022 08:23, Juergen Gross wrote:
>>> Commit ad7f402ae4f4 ("xen/netback: Ensure protocol headers don't fall in
>>> the non-linear area") introduced a (valid) build warning.
>>>
>>> Fix it.
>>>
>>> Fixes: ad7f402ae4f4 ("xen/netback: Ensure protocol headers don't fall in the non-linear area")
>>> Signed-off-by: Juergen Gross <jgross@...e.com>
>>
>> Reviewed-by: Jan Beulich <jbeulich@...e.com>
>>
>>> --- a/drivers/net/xen-netback/netback.c
>>> +++ b/drivers/net/xen-netback/netback.c
>>> @@ -530,7 +530,7 @@ static int xenvif_tx_check_gop(struct xenvif_queue *queue,
>>>   	const bool sharedslot = nr_frags &&
>>>   				frag_get_pending_idx(&shinfo->frags[0]) ==
>>>   				    copy_pending_idx(skb, copy_count(skb) - 1);
>>> -	int i, err;
>>> +	int i, err = 0;
>>>   
>>>   	for (i = 0; i < copy_count(skb); i++) {
>>>   		int newerr;
>>
>> I'm afraid other logic (below here) is now slightly wrong as well, in
>> particular
>>
>> 				/* If the mapping of the first frag was OK, but
>> 				 * the header's copy failed, and they are
>> 				 * sharing a slot, send an error
>> 				 */
>> 				if (i == 0 && !first_shinfo && sharedslot)
>> 					xenvif_idx_release(queue, pending_idx,
>> 							   XEN_NETIF_RSP_ERROR);
>> 				else
>> 					xenvif_idx_release(queue, pending_idx,
>> 							   XEN_NETIF_RSP_OKAY);
>>
>> which looks to be intended to deal with _only_ failure of the one shared
>> part of the header, whereas "err" now can indicate an error on any earlier
>> part as well.
> 
> The comment at the end of that loop seems to imply this is the desired
> behavior:
> 
> 		/* Remember the error: invalidate all subsequent fragments. */
> 		err = newerr;
> 	}

This says "subsequent", whereas I was describing a situation where e.g.
the first piece of header copying failed, the 2nd (shared part) succeeded,
and the mapping of the rest of the shared part also succeeded. At the
very least the comment in the code fragment I did quote then has become
stale. Furthermore, if "all subsequent" really meant all, then in the
new first loop this isn't followed either - an error response is sent
only for the pieces where copying failed.

Jan