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
| ||
|
Message-ID: <CAHk-=wihz-GXx66MmEyaADgS1fQE_LDcB9wrHAmkvXkd8nx9tA@mail.gmail.com> Date: Sun, 16 Oct 2022 10:52:21 -0700 From: Linus Torvalds <torvalds@...ux-foundation.org> To: Yury Norov <yury.norov@...il.com> Cc: Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>, Borislav Petkov <bp@...en8.de>, syzbot <syzbot+d0fd2bf0dd6da72496dd@...kaller.appspotmail.com>, syzkaller-bugs@...glegroups.com, Andrew Jones <ajones@...tanamicro.com>, netdev@...r.kernel.org, "David S . Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, 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>, Guo Ren <guoren@...ux.alibaba.com>, "Michael S . Tsirkin" <mst@...hat.com>, Alexander Gordeev <agordeev@...ux.ibm.com>, andriy.shevchenko@...ux.intel.com, linux@...musvillemoes.dk, caraitto@...gle.com, willemb@...gle.com, jonolson@...gle.com, amritha.nambiar@...el.com, linux-kernel@...r.kernel.org Subject: Re: [syzbot] WARNING in c_start On Sat, Oct 15, 2022 at 6:12 PM Yury Norov <yury.norov@...il.com> wrote: > > On Sun, Oct 16, 2022 at 09:24:57AM +0900, Tetsuo Handa wrote: > > > > Again, please do revert "cpumask: fix checking valid cpu range" immediately. > > The revert is already in Jakub's batch for -rc2, AFAIK. Hmm. I've looked at this, and at the discussion, and the various reports, and my gut feel is that the problem is that the whole "cpumask_check()" is completely bogus for all the "starting at bit X" cases. And I think it was wrong even before, and yes, I think the "+1" simplification just made things worse. I think that where it makes sense is in contexts where we actually *use* the bit value as a bit, so cpumask_clear_cpu() doing clear_bit(cpumask_check(cpu), cpumask_bits(dstp)); makes 100% sense and is unequivocally something that merits a warning. An out-of-range cpu number is a serious bug in that context. But all the cases where the function fundamentally already limits things to the number of CPU's (with comments like "Returns >= nr_cpu_ids if no further cpus unset.") should simply not have the cpumask_check() at all. All it results in just moving the onus of testing things into the callers, or just makes for odd complications ("-1 is valid, because it acts as the previous cpu for the beginning because we add one to get the next CPU"). Anyway, since rc1 is fairly imminent, I will just revert it for now - I don't want to have a pending revert wait until -rc2. But I actually suspect that the thing we should really do is to just remove the check entirely for these functions that are already defined in terms of "if no more bits, return nr_cpu_ids". They already basically return an error case, having them *warn* about the error they are going to return is just obnoxious. Linus
Powered by blists - more mailing lists