Buildresult: linus/um-defconfig/um-x86_64-gcc12 built on Mar 16 2023, 05:59

kisskb

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

Status:	OK
Date/Time:	Mar 16 2023, 05:59
Duration:	0:07:25.523547
Builder:	blade4b
Revision:	sched_getaffinity: don't assume 'cpumask_size()' is fully initialized (`6015b1aca1a233379625385feb01dd014aca60b5)`
Target:	linus/um-defconfig/um-x86_64-gcc12
Branch:	linus
Compiler:	um-x86_64-gcc12 (x86_64-linux-gcc.br_real (Buildroot 2021.11-4428-g6b6741b) 12.2.0 / GNU ld (GNU Binutils) 2.39)
Config:	defconfig (download)
Log:	Download original No warnings found in log. Full Log # git gc # 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/x86-64--glibc--bleeding-edge-2022.08-1/bin/x86_64-linux-gcc --version # < /opt/cross/kisskb/x86-64--glibc--bleeding-edge-2022.08-1/bin/x86_64-linux-ld --version # < git log --format=%s --max-count=1 6015b1aca1a233379625385feb01dd014aca60b5 # < make -s -j 24 ARCH=um O=/kisskb/build/linus_um-defconfig_um-x86_64-gcc12 CROSS_COMPILE=/opt/cross/kisskb/x86-64--glibc--bleeding-edge-2022.08-1/bin/x86_64-linux- SUBARCH=x86_64 defconfig # < make -s -j 24 ARCH=um O=/kisskb/build/linus_um-defconfig_um-x86_64-gcc12 CROSS_COMPILE=/opt/cross/kisskb/x86-64--glibc--bleeding-edge-2022.08-1/bin/x86_64-linux- SUBARCH=x86_64 help # make -s -j 24 ARCH=um O=/kisskb/build/linus_um-defconfig_um-x86_64-gcc12 CROSS_COMPILE=/opt/cross/kisskb/x86-64--glibc--bleeding-edge-2022.08-1/bin/x86_64-linux- SUBARCH=x86_64 olddefconfig # make -s -j 24 ARCH=um O=/kisskb/build/linus_um-defconfig_um-x86_64-gcc12 CROSS_COMPILE=/opt/cross/kisskb/x86-64--glibc--bleeding-edge-2022.08-1/bin/x86_64-linux- SUBARCH=x86_64 LINK linux Completed OK # rm -rf /kisskb/build/linus_um-defconfig_um-x86_64-gcc12 # Build took: 0:07:25.523547

© Michael Ellerman 2006-2018.