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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 3 Oct 2022 17:07:31 -0700 From: Yury Norov <yury.norov@...il.com> To: Jakub Kicinski <kuba@...nel.org> Cc: netdev@...r.kernel.org, "David S . Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, Sebastian Andrzej Siewior <bigeasy@...utronix.de>, Menglong Dong <imagedong@...cent.com>, Kuniyuki Iwashima <kuniyu@...zon.com>, Petr Machata <petrm@...dia.com> Subject: Re: [PATCH 0/4] net: drop netif_attrmask_next*() On Mon, Oct 03, 2022 at 04:25:56PM -0700, Jakub Kicinski wrote: > On Mon, 3 Oct 2022 11:11:05 -0700 Yury Norov wrote: > > On Mon, Oct 03, 2022 at 09:50:48AM -0700, Jakub Kicinski wrote: > > > On Sun, 2 Oct 2022 08:16:58 -0700 Yury Norov wrote: > > > > netif_attrmask_next_and() generates warnings if CONFIG_DEBUG_PER_CPU_MAPS > > > > is enabled. > > > > > > Could you describe the nature of the warning? Is it a false positive > > > or a legit warning? > > > > > > If the former perhaps we should defer until after the next merge window. > > > > The problem is that netif_attrmask_next_and() is called with > > n == nr_cpu_ids-1, which triggers cpu_max_bits_warn() after this: > > > > https://lore.kernel.org/netdev/20220926103437.322f3c6c@kernel.org/ > > I see. Is that patch merged and on it's way? This patch is already in pull request. > Perhaps we can just revert it and try again after the merge window? I don't understand this. To me it looks fairly normal - the check has been fixed and merged (likely) in -rc1. After that we have 2 month to spot, fix and test all issues discovered with correct cpumask_check(). I'm not insisting in moving this series in -rc1. Let's give it review and careful testing, and merge in -rc2, 3 or whatever is appropriate. Regarding cpumask_check() patch - I'd like to have it in -rc1 because it will give people enough time to test their code... Would it work? Thanks, Yury
Powered by blists - more mailing lists