netdev - Re: [PATCH net 0/3] Revert openvswitch per-CPU storage

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: <63dcf1ff-7690-4300-8f76-30595c14fec1@nvidia.com>
Date: Tue, 10 Jun 2025 10:03:08 +0300
From: Gal Pressman <gal@...dia.com>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
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 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?