Buildresult: linus/or1ksim_defconfig/or32-gcc9 built on Mar 15 2023, 16:41

kisskb

Revisions | Branches | Compilers | Configs | Build Results | Build Failures |

Status:	OK
Date/Time:	Mar 15 2023, 16:41
Duration:	0:00:24.616258
Builder:	ka4
Revision:	sched_getaffinity: don't assume 'cpumask_size()' is fully initialized (`6015b1aca1a233379625385feb01dd014aca60b5)`
Target:	linus/or1ksim_defconfig/or32-gcc9
Branch:	linus
Compiler:	or32-gcc9 (or1k-linux-gcc (GCC) 9.4.0 / GNU ld (GNU Binutils) 2.36.1)
Config:	or1ksim_defconfig (download)
Log:	Download original No warnings found in log. Full Log # git rev-parse -q --verify 6015b1aca1a233379625385feb01dd014aca60b5^{commit} 6015b1aca1a233379625385feb01dd014aca60b5 already have revision, skipping fetch # git checkout -q -f -B kisskb 6015b1aca1a233379625385feb01dd014aca60b5 # git clean -qxdf # < git log -1 # commit 6015b1aca1a233379625385feb01dd014aca60b5 # Author: Linus Torvalds <torvalds@linux-foundation.org> # Date: Tue Mar 14 19:32:38 2023 -0700 # # sched_getaffinity: don't assume 'cpumask_size()' is fully initialized # # The getaffinity() system call uses 'cpumask_size()' to decide how big # the CPU mask is - so far so good. It is indeed the allocation size of a # cpumask. # # But the code also assumes that the whole allocation is initialized # without actually doing so itself. That's wrong, because we might have # fixed-size allocations (making copying and clearing more efficient), but # not all of it is then necessarily used if 'nr_cpu_ids' is smaller. # # Having checked other users of 'cpumask_size()', they all seem to be ok, # either using it purely for the allocation size, or explicitly zeroing # the cpumask before using the size in bytes to copy it. # # See for example the ublk_ctrl_get_queue_affinity() function that uses # the proper 'zalloc_cpumask_var()' to make sure that the whole mask is # cleared, whether the storage is on the stack or if it was an external # allocation. # # Fix this by just zeroing the allocation before using it. Do the same # for the compat version of sched_getaffinity(), which had the same logic. # # Also, for consistency, make sched_getaffinity() use 'cpumask_bits()' to # access the bits. For a cpumask_var_t, it ends up being a pointer to the # same data either way, but it's just a good idea to treat it like you # would a 'cpumask_t'. The compat case already did that. # # Reported-by: Ryan Roberts <ryan.roberts@arm.com> # Link: https://lore.kernel.org/lkml/7d026744-6bd6-6827-0471-b5e8eae0be3f@arm.com/ # Cc: Yury Norov <yury.norov@gmail.com> # Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> # < /opt/cross/kisskb/korg/gcc-9.4.0-nolibc/or1k-linux/bin/or1k-linux-gcc --version # < /opt/cross/kisskb/korg/gcc-9.4.0-nolibc/or1k-linux/bin/or1k-linux-ld --version # < git log --format=%s --max-count=1 6015b1aca1a233379625385feb01dd014aca60b5 # < make -s -j 40 ARCH=openrisc O=/kisskb/build/linus_or1ksim_defconfig_or32-gcc9 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-9.4.0-nolibc/or1k-linux/bin/or1k-linux- or1ksim_defconfig # < make -s -j 40 ARCH=openrisc O=/kisskb/build/linus_or1ksim_defconfig_or32-gcc9 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-9.4.0-nolibc/or1k-linux/bin/or1k-linux- help # make -s -j 40 ARCH=openrisc O=/kisskb/build/linus_or1ksim_defconfig_or32-gcc9 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-9.4.0-nolibc/or1k-linux/bin/or1k-linux- olddefconfig # make -s -j 40 ARCH=openrisc O=/kisskb/build/linus_or1ksim_defconfig_or32-gcc9 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-9.4.0-nolibc/or1k-linux/bin/or1k-linux- Completed OK # rm -rf /kisskb/build/linus_or1ksim_defconfig_or32-gcc9 # Build took: 0:00:24.616258

© Michael Ellerman 2006-2018.