linux-kernel - Re: [PATCH net] net: atlantic: keep rings across suspend/resume

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] [day] [month] [year] [list]

Message-Id: <V8ZFOS.N7LNJ4P9ABW3@brun.one>
Date: Fri, 13 Dec 2024 18:00:31 +0100
From: Lorenz Brun <lorenz@...n.one>
To: Andrew Lunn <andrew@...n.ch>
Cc: Igor Russkikh <irusskikh@...vell.com>, "David S. Miller"
	<davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski
	<kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Manuel Ullmann
	<labre@...teo.de>, netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net] net: atlantic: keep rings across suspend/resume

Am Do, 12. Dez 2024 um 18:20:26 +01:00:00 schrieb Andrew Lunn 
<andrew@...n.ch>:
> On Thu, Dec 12, 2024 at 03:39:24AM +0100, Lorenz Brun wrote:
>>  The rings are order-6 allocations which tend to fail on suspend due 
>> to
>>  fragmentation. As memory is kept during suspend/resume, we don't 
>> need to
>>  reallocate them.
> 
> I don't know this driver. Are there other reasons to reallocate the
> rings? Change of MTU? ethtool settings? If they are also potentially
> going to run into memory fragmentation issues, maybe it would be
> better to use smaller order allocations, or vmalloc, if the hardware
> supports that, etc.
> 
> 	Andrew

ethtool settings do indeed reallocate, but not during unsuspend where 
we have GFP_NOIO. Smaller oder allocations would definitely be better, 
but on systems without IOMMU that would probably pose a problem as 
rings are generally assumed to be contigous by hardware (as far as I 
understand). I don't have access to hardware docs, so I don't know if 
you can make the HW work without physically-contiguous memory.

Linux just really doesn't handle high-order allocations well, I got one 
unsuspend failure with 6GiB (!!) of free space in the relevant region 
(but no order-6 or higher). I have no idea why it doesn't defragment 
before failing the allocation as it clearly has enough memory.

kworker/u97:14: page allocation failure: order:6, 
mode:0x40d00(GFP_NOIO|__GFP_COMP|__GFP_ZERO), 
nodemask=(null),cpuset=/,mems_allowed=0
Node 0 Normal: 787628*4kB (UME) 234026*8kB (UME) 50882*16kB (UME) 
13751*32kB (UME) 35*64kB (UME) 9*128kB (M) 0*256kB 0*512kB 0*1024kB 
1*2048kB (H) 0*4096kB = 6282304kB

Regards,
Lorenz