linux-stable/include
Linus Torvalds e919a3f705 Minor tracing updates:
- Make buffer_percent read/write. The buffer_percent file is how users can
   state how long to block on the tracing buffer depending on how much
   is in the buffer. When it hits the "buffer_percent" it will wake the
   task waiting on the buffer. For some reason it was set to read-only.
   This was not noticed because testing was done as root without SELinux,
   but with SELinux it will prevent even root to write to it without having
   CAP_DAC_OVERRIDE.
 
 - The "touched_functions" was added this merge window, but one of the
   reasons for adding it was not implemented. That was to show what functions
   were not only touched, but had either a direct trampoline attached to
   it, or a kprobe or live kernel patching that can "hijack" the function
   to run a different function. The point is to know if there's functions
   in the kernel that may not be behaving as the kernel code shows. This can
   be used for debugging. TODO: Add this information to kernel oops too.
 -----BEGIN PGP SIGNATURE-----
 
 iIoEABYIADIWIQRRSw7ePDh/lE+zeZMp5XQQmuv6qgUCZFUcrxQccm9zdGVkdEBn
 b29kbWlzLm9yZwAKCRAp5XQQmuv6qgOoAP0U2R6+jvA2ehQFb0UTCH9wEu2uEELA
 g2CkdPNdn6wJjAD+O1+v5nVkqSpsArjHOhv5OGYrgh+VSXK3Z8EpQ9vUVgg=
 =nfoh
 -----END PGP SIGNATURE-----

Merge tag 'trace-v6.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace

Pull more tracing updates from Steven Rostedt:

 - Make buffer_percent read/write.

   The buffer_percent file is how users can state how long to block on
   the tracing buffer depending on how much is in the buffer. When it
   hits the "buffer_percent" it will wake the task waiting on the
   buffer. For some reason it was set to read-only.

   This was not noticed because testing was done as root without
   SELinux, but with SELinux it will prevent even root to write to it
   without having CAP_DAC_OVERRIDE.

 - The "touched_functions" was added this merge window, but one of the
   reasons for adding it was not implemented.

   That was to show what functions were not only touched, but had either
   a direct trampoline attached to it, or a kprobe or live kernel
   patching that can "hijack" the function to run a different function.
   The point is to know if there's functions in the kernel that may not
   be behaving as the kernel code shows. This can be used for debugging.

   TODO: Add this information to kernel oops too.

* tag 'trace-v6.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace:
  ftrace: Add MODIFIED flag to show if IPMODIFY or direct was attached
  tracing: Fix permissions for the buffer_percent file
2023-05-05 13:11:02 -07:00
..
acpi Power management updates for 6.4-rc1 2023-04-25 18:44:10 -07:00
asm-generic Locking changes in v6.4: 2023-05-05 12:56:55 -07:00
clocksource
crypto This update includes the following changes: 2023-04-26 08:32:52 -07:00
drm - Nick Piggin's "shoot lazy tlbs" series, to improve the peformance of 2023-04-27 19:42:02 -07:00
dt-bindings linux-watchdog 6.4-rc1 tag 2023-05-04 18:33:56 -07:00
keys
kunit
kvm s390: 2023-05-01 12:06:20 -07:00
linux Minor tracing updates: 2023-05-05 13:11:02 -07:00
math-emu
media
memory
misc
net 9p patches for 6.4 merge window 2023-05-04 14:37:53 -07:00
pcmcia
ras
rdma
rv
scsi Driver core changes for 6.4-rc1 2023-04-27 11:53:57 -07:00
soc Nothing looks out of the ordinary in this batch of clk driver updates. There 2023-04-29 17:29:39 -07:00
sound ASoC: Updates for v6.4 2023-04-24 15:15:31 +02:00
target
trace NFSD 6.4 Release Notes 2023-04-29 11:04:14 -07:00
uapi dmaengine updates for v6.4 2023-05-03 11:11:56 -07:00
ufs SCSI misc on 20230426 2023-04-26 15:39:25 -07:00
vdso
video
xen