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, 16 May 2022 20:33:25 -0700 From: Kees Cook <keescook@...omium.org> To: Peter Zijlstra <peterz@...radead.org> Cc: Christophe de Dinechin <dinechin@...hat.com>, Ingo Molnar <mingo@...hat.com>, Juri Lelli <juri.lelli@...hat.com>, Vincent Guittot <vincent.guittot@...aro.org>, Dietmar Eggemann <dietmar.eggemann@....com>, Steven Rostedt <rostedt@...dmis.org>, Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>, Daniel Bristot de Oliveira <bristot@...hat.com>, linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org Subject: Re: [PATCH v3] sched/core: Address classes via __begin_sched_classes On Mon, May 16, 2022 at 08:00:23PM -0700, Kees Cook wrote: > GCC 12 is very sensitive about array checking, and views all negative > array accesses as unsafe (a not unreasonable position). Redefine > sched_class_highest in terms of its location from __begin_sched_classes, > and redefine sched_class_lowest to the actual lowest sched class instead > of one lower. This also means the for_class_range() must be redefined to > be inclusive, which means its 1 caller must be adjusted to have its > "lowest" argument bumped up one position. Silences this warning: > > In file included from kernel/sched/core.c:81: > kernel/sched/core.c: In function ‘set_rq_online.part.0’: > kernel/sched/sched.h:2197:52: error: array subscript -1 is outside array bounds of ‘struct sched_class[44343134792571037]’ > [-Werror=array-bounds] > 2197 | #define sched_class_lowest (__begin_sched_classes - 1) > | ^ > kernel/sched/sched.h:2200:41: note: in definition of macro ‘for_class_range’ > 2200 | for (class = (_from); class != (_to); class--) > | ^~~ > kernel/sched/sched.h:2203:53: note: in expansion of macro ‘sched_class_lowest’ > 2203 |for_class_range(class, sched_class_highest, sched_class_lowest) > | ^~~~~~~~~~~~~~~~~~ > kernel/sched/core.c:9115:17: note: in expansion of macro ‘for_each_class’ > 9115 | for_each_class(class) { > | ^~~~~~~~~~~~~~ > kernel/sched/sched.h:2193:27: note: at offset -208 into object ‘__begin_sched_classes’ of size [0, 9223372036854775807] > 2193 | extern struct sched_class __begin_sched_classes[]; > | ^~~~~~~~~~~~~~~~~~~~~ > > The introduce and use of sched_class_higher() could just be a bare "+ 1", > but this code's backwards walking and non-inclusive for loop was weird > enough, it seemed back to explicitly describe the manipulation > happening. I just need to start today over. This should read: The introduction and use of sched_class_higher() could just be a bare "+ 1", but this code's backwards-walking and non-inclusive for loop was weird enough, it seemed best to explicitly describe the manipulation happening. -- Kees Cook
Powered by blists - more mailing lists