netdev - Re: [RFC PATCH net-next v5 2/2] net: add netmem to skb_frag

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]

Message-ID: <9c1a6725-c4c3-2bb1-344f-5e71f8ce7e63@huawei.com>
Date: Tue, 16 Jan 2024 19:04:13 +0800
From: Yunsheng Lin <linyunsheng@...wei.com>
To: Jason Gunthorpe <jgg@...dia.com>, Mina Almasry <almasrymina@...gle.com>
CC: <linux-kernel@...r.kernel.org>, <netdev@...r.kernel.org>, "David S.
 Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub
 Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Christian König <christian.koenig@....com>, Shakeel Butt
	<shakeelb@...gle.com>, Willem de Bruijn <willemdebruijn.kernel@...il.com>
Subject: Re: [RFC PATCH net-next v5 2/2] net: add netmem to skb_frag_t

On 2024/1/16 8:01, Jason Gunthorpe wrote:
> On Mon, Jan 15, 2024 at 03:23:33PM -0800, Mina Almasry wrote:
>>>> You did not answer my question that I asked here, and ignoring this
>>>> question is preventing us from making any forward progress on this
>>>> discussion. What do you expect or want skb_frag_page() to do when
>>>> there is no page in the frag?
>>>
>>> I would expect it to do nothing.
>>
>> I don't understand. skb_frag_page() with an empty implementation just
>> results in a compiler error as the function needs to return a page
>> pointer. Do you actually expect skb_frag_page() to unconditionally
>> cast frag->netmem to a page pointer? That was explained as
>> unacceptable over and over again by Jason and Christian as it risks
>> casting devmem to page; completely unacceptable and will get nacked.
>> Do you have a suggestion of what skb_frag_page() should do that will
>> not get nacked by mm?
> 
> WARN_ON and return NULL seems reasonable?

While I am agreed that it may be a nightmare to debug the case of passing
a false page into the mm system, but I am not sure what's the point of
returning NULL to caller if the caller is not expecting or handling the
NULL returning[for example, most of mm API called by the networking does not
seems to handling NULL as input page], isn't the NULL returning will make
the kernel panic anyway? Doesn't it make more sense to just add a BUG_ON()
depending on some configuration like CONFIG_DEBUG_NET or CONFIG_DEVMEM?
As returning NULL seems to be causing a confusion for the caller of
skb_frag_page() as whether to or how to handle the NULL returning case.

For existing cases, the skb_frag_page() is mostly called with below pattern,
it means there may be up to 17 checkings for each skb:
for (i = 0; i < shinfo->nr_frags; i++) {
	skb_frag_t *frag = &sinfo->frags[i];
	....
	calling some function with skb_frag_page(frag);
	.....
}

IMHO, we should avoid this kind of problem at API level, I am not able to
come up with an idea how to do that for now, is there any idea to do that in
your mind?
Even if we can not come up with an idea for now, doesn't it make sense to avoid
this kind of overhead as much as possible even if we have marked the checking
as unlikely() cases?

> 
> Jason
> .
>