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: <20250610070629.0ShU8LLr@linutronix.de>
Date: Tue, 10 Jun 2025 09:06:29 +0200
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: Gal Pressman <gal@...dia.com>
Cc: "David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Andrew Lunn <andrew+netdev@...n.ch>, netdev@...r.kernel.org,
	Aaron Conole <aconole@...hat.com>,
	Eelco Chaudron <echaudro@...hat.com>,
	Ilya Maximets <i.maximets@....org>, Simon Horman <horms@...nel.org>,
	Clark Williams <clrkwllms@...nel.org>,
	Steven Rostedt <rostedt@...dmis.org>, dev@...nvswitch.org,
	linux-rt-devel@...ts.linux.dev
Subject: Re: [PATCH net 0/3] Revert openvswitch per-CPU storage

On 2025-06-10 10:03:08 [+0300], Gal Pressman wrote:
> On 10/06/2025 9:43, Sebastian Andrzej Siewior wrote:
> > On 2025-06-10 09:26:28 [+0300], Gal Pressman wrote:
> >> This patch series reverts a set of changes that consolidated per-CPU
> >> storage structures in the openvswitch module.
> >>
> >> The original changes were intended to improve performance and reduce
> >> complexity by merging three separate per-CPU structures into one, but
> >> they have changed openvswitch to use static percpu allocations, and
> >> exhausted the reserved chunk on module init.
> >> This results in allocation of struct ovs_pcpu_storage (6488 bytes)
> >> failure on ARM.
> >>
> >> The reverts are applied in reverse order of the original commits.
> > 
> > Is the limited per-CPU storage the only problem? If so I would towards a
> > different solution rather than reverting everything.
> 
> I don't know if this is the only problem, we can't load the module
> starting with these patches.
> 
> I suggest continuing with the reverts as I assume your new solution will
> be net-next material, no?

It is a regression in -rc1 so I would try to fix this on top of -rc1
instead of reverting everything.

Sebastian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ