# git rev-parse -q --verify fa4b851b4ad632dc673627f38a8a552547568a2c^{commit} fa4b851b4ad632dc673627f38a8a552547568a2c already have revision, skipping fetch # git checkout -q -f -B kisskb fa4b851b4ad632dc673627f38a8a552547568a2c # git clean -qxdf # < git log -1 # commit fa4b851b4ad632dc673627f38a8a552547568a2c # Merge: 210ee636c4ad e5d7c1916562 # Author: Linus Torvalds # Date: Sun Mar 10 11:53:21 2024 -0700 # # Merge tag 'trace-ring-buffer-v6.8-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace # # Pull tracing fixes from Steven Rostedt: # # - Do not allow large strings (> 4096) as single write to trace_marker # # The size of a string written into trace_marker was determined by the # size of the sub-buffer in the ring buffer. That size is dependent on # the PAGE_SIZE of the architecture as it can be mapped into user # space. But on PowerPC, where PAGE_SIZE is 64K, that made the limit of # the string of writing into trace_marker 64K. # # One of the selftests looks at the size of the ring buffer sub-buffers # and writes that plus more into the trace_marker. The write will take # what it can and report back what it consumed so that the user space # application (like echo) will write the rest of the string. The string # is stored in the ring buffer and can be read via the "trace" or # "trace_pipe" files. # # The reading of the ring buffer uses vsnprintf(), which uses a # precision "%.*s" to make sure it only reads what is stored in the # buffer, as a bug could cause the string to be non terminated. # # With the combination of the precision change and the PAGE_SIZE of 64K # allowing huge strings to be added into the ring buffer, plus the test # that would actually stress that limit, a bug was reported that the # precision used was too big for "%.*s" as the string was close to 64K # in size and the max precision of vsnprintf is 32K. # # Linus suggested not to have that precision as it could hide a bug if # the string was again stored without a nul byte. # # Another issue that was brought up is that the trace_seq buffer is # also based on PAGE_SIZE even though it is not tied to the # architecture limit like the ring buffer sub-buffer is. Having it be # 64K * 2 is simply just too big and wasting memory on systems with 64K # page sizes. It is now hardcoded to 8K which is what all other # architectures with 4K PAGE_SIZE has. # # Finally, the write to trace_marker is now limited to 4K as there is # no reason to write larger strings into trace_marker. # # - ring_buffer_wait() should not loop. # # The ring_buffer_wait() does not have the full context (yet) on if it # should loop or not. Just exit the loop as soon as its woken up and # let the callers decide to loop or not (they already do, so it's a bit # redundant). # # - Fix shortest_full field to be the smallest amount in the ring buffer # that a waiter is waiting for. The "shortest_full" field is updated # when a new waiter comes in and wants to wait for a smaller amount of # data in the ring buffer than other waiters. But after all waiters are # woken up, it's not reset, so if another waiter comes in wanting to # wait for more data, it will be woken up when the ring buffer has a # smaller amount from what the previous waiters were waiting for. # # - The wake up all waiters on close is incorrectly called frome # .release() and not from .flush() so it will never wake up any waiters # as the .release() will not get called until all .read() calls are # finished. And the wakeup is for the waiters in those .read() calls. # # * tag 'trace-ring-buffer-v6.8-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: # tracing: Use .flush() call to wake up readers # ring-buffer: Fix resetting of shortest_full # ring-buffer: Fix waking up ring buffer readers # tracing: Limit trace_marker writes to just 4K # tracing: Limit trace_seq size to just 8K and not depend on architecture PAGE_SIZE # tracing: Remove precision vsnprintf() check from print event # < /opt/cross/kisskb/korg/gcc-5.5.0-nolibc/powerpc64-linux/bin/powerpc64-linux-gcc --version # < /opt/cross/kisskb/korg/gcc-5.5.0-nolibc/powerpc64-linux/bin/powerpc64-linux-ld --version # < git log --format=%s --max-count=1 fa4b851b4ad632dc673627f38a8a552547568a2c # make -s -j 160 ARCH=powerpc O=/kisskb/build/linus_skiroot_defconfig_powerpc-gcc5 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-5.5.0-nolibc/powerpc64-linux/bin/powerpc64-linux- skiroot_defconfig # < make -s -j 160 ARCH=powerpc O=/kisskb/build/linus_skiroot_defconfig_powerpc-gcc5 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-5.5.0-nolibc/powerpc64-linux/bin/powerpc64-linux- help # make -s -j 160 ARCH=powerpc O=/kisskb/build/linus_skiroot_defconfig_powerpc-gcc5 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-5.5.0-nolibc/powerpc64-linux/bin/powerpc64-linux- olddefconfig # make -s -j 160 ARCH=powerpc O=/kisskb/build/linus_skiroot_defconfig_powerpc-gcc5 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-5.5.0-nolibc/powerpc64-linux/bin/powerpc64-linux- /kisskb/src/fs/btrfs/extent_io.c: In function 'extent_fiemap': /kisskb/src/fs/btrfs/extent_io.c:3165:19: warning: 'last_extent_end' may be used uninitialized in this function [-Wmaybe-uninitialized] if (cache.cached && cache.offset + cache.len >= last_extent_end) { ^ /kisskb/src/fs/btrfs/extent_io.c: At top level: cc1: warning: unrecognized command line option '-Wno-shift-negative-value' cc1: warning: unrecognized command line option '-Wno-shift-negative-value' cc1: warning: unrecognized command line option '-Wno-stringop-overflow' Completed OK # rm -rf /kisskb/build/linus_skiroot_defconfig_powerpc-gcc5 # Build took: 0:02:47.750153