netdev - Re: [PATCH net v3] net: allow skb_datagram_iter to be called from any context

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, 26 Jun 2024 11:23:03 +0300
From: Sagi Grimberg <sagi@...mberg.me>
To: Eric Dumazet <edumazet@...gle.com>
Cc: netdev@...r.kernel.org, Jakub Kicinski <kuba@...nel.org>,
 David Howells <dhowells@...hat.com>, Matthew Wilcox <willy@...radead.org>
Subject: Re: [PATCH net v3] net: allow skb_datagram_iter to be called from any
 context



On 26/06/2024 10:40, Eric Dumazet wrote:
> On Wed, Jun 26, 2024 at 9:00 AM Sagi Grimberg <sagi@...mberg.me> wrote:
>> We only use the mapping in a single context, so kmap_local is sufficient
>> and cheaper. Make sure to use skb_frag_foreach_page as skb frags may
>> contain highmem compound pages and we need to map page by page.
>>
>> Reported-by: kernel test robot <oliver.sang@...el.com>
>> Closes: https://lore.kernel.org/oe-lkp/202406161539.b5ff7b20-oliver.sang@intel.com
>> Signed-off-by: Sagi Grimberg <sagi@...mberg.me>
> Thanks for working on this !
>
> A patch targeting net tree would need a Fixes: tag, so that stable
> teams do not have
> to do archeological digging to find which trees need this fix.

The BUG complaint was exposed by the reverted patch in net-next.

TBH, its hard to tell when this actually was introduced, could skb_frags 
always
have contained high-order pages? or was this introduced with the 
introduction
of skb_copy_datagram_iter? or did it originate in the base implementation it
was copied from skb_copy_datagram_const_iovec?

Its hard for me to tell, and I don't have enough knowledge of the stack.
could use some help here.

>
> If the bug is too old, then maybe this patch should use kmap() instead
> of  kmap_local_page() ?

I honestly don't know.

>
> Then in net-next, (after this fix is merged), perform the conversion
> to kmap_local_page()
>
> Fact that the bug never showed up is a bit strange, are 32bit systems
> still used today ? (apart from bots)...

Not sure.

>
> Do we have a reproducer to test this?

Aside from the robot not that I know of...