The code testing for a pointer declaration in process_name() has no actual
effect on subsequent actions; remove it.
Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20250606163438.229916-8-corbet@lwn.net
The entry.descr value used in process_name() is not actually a member of
the KernelEntry class; it is a bit of local state. So just manage it
locally.
A trim_whitespace() helper was added to clean up the code slightly.
Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20250606163438.229916-7-corbet@lwn.net
entry::is_kernel_comment never had anything to do with the entry itself; it
is a bit of local state in one branch of process_name(). It can, in fact,
be removed entirely; rework the code slightly so that it is no longer
needed.
No change in the rendered output.
Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20250606163438.229916-6-corbet@lwn.net
process_name() looks for the first line of a kerneldoc comment. It
contains two nearly identical regular expressions, the second of which only
catches six cases in the kernel, all of the form:
define SOME_MACRO_NAME - description
Simply put the "define" into the regex and discard it, eliminating the loop
and the code to remove it specially.
Note that this still treats these defines as if they were functions, but
that's a separate issue.
There is no change in the generated output.
Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20250606163438.229916-5-corbet@lwn.net
It is only used in one place, so just put the constant string
"Introduction" there so people don't have to go looking for it.
Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20250606163438.229916-4-corbet@lwn.net
Since all of the handlers already nicely have the same prototype, put them
into a table and call them from there and take out the extended
if-then-else series.
Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20250606163438.229916-3-corbet@lwn.net
Replace misspelled "eariler" with "earlier" and drop the stray period
after "example".
Signed-off-by: Runji Liu <runjiliu.tech@gmail.com>
Acked-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20250526134046.1042-1-runjiliu.tech@gmail.com
We have all this fine kernel-doc written, and it's not published
anywhere. Expose it to public view.
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20250604195753.823742-1-willy@infradead.org
Add missing GPIOLIB dependency reported by the LKP test robot.
This fixes the following report:
"
kismet warnings: (new ones prefixed by >>)
>> kismet: WARNING: unmet direct dependencies detected for GPIO_REGMAP when selected by REGULATOR_RASPBERRYPI_TOUCHSCREEN_V2
WARNING: unmet direct dependencies detected for GPIO_REGMAP
Depends on [n]: GPIOLIB [=n]
Selected by [y]:
- REGULATOR_RASPBERRYPI_TOUCHSCREEN_V2 [=y] && REGULATOR [=y] && I2C [=y]
"
Fixes: d49305862f ("regulator: rpi-panel-v2: Add regulator for 7" Raspberry Pi 720x1280")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202506092341.enbNKMOR-lkp@intel.com/
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Link: https://patch.msgid.link/20250609200242.31271-1-marek.vasut+renesas@mailbox.org
Signed-off-by: Mark Brown <broonie@kernel.org>
It is reported that on Acer Nitro V15 suspend only works properly if the
keyboard backlight is turned off. In looking through the issue Acer Nitro
V15 has a GPIO (#8) specified in _AEI but it has no matching notify device
in _EVT. The values for GPIO #8 change as keyboard backlight is turned on
and off.
This makes it seem that GPIO #8 is actually supposed to be solely for
keyboard backlight. Turning off the interrupt for this GPIO fixes the issue.
Add a quirk that does just that.
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4169
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Acked-by: Mika Westerberg <westeri@kernel.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
We are going to want to re-use this before the component is bound, when
we don't yet have the device pointer (but we do have the of node).
v2: use %pOF
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/657705/
To better match add_gpu_components().
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/657700/
The files generated by gen_header.py capture the source path to the
input files and the date. While that can be informative, it varies
based on where and when the kernel was built as the full path is
captured.
Since all of the files that this tool is run on is under the drivers
directory, this modifies the application to strip all of the path before
drivers. Additionally it prints <stripped> instead of the date.
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Viswanath Kraleti <viswanath.kraleti@oss.qualcomm.com>
Acked-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/655599/
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Calling this packet is necessary when we switch contexts because there
are various pieces of state used by userspace to synchronize between BR
and BV that are persistent across submits and we need to make sure that
they are in a "safe" state when switching contexts. Otherwise a
userspace submission in one context could cause another context to
function incorrectly and hang, effectively a denial of service (although
without leaking data). This was missed during initial a7xx bringup.
Fixes: af66706acc ("drm/msm/a6xx: Add skeleton A7xx support")
Signed-off-by: Connor Abbott <cwabbott0@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/654924/
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Based on kgsl.
Fixes: af66706acc ("drm/msm/a6xx: Add skeleton A7xx support")
Signed-off-by: Connor Abbott <cwabbott0@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/654922/
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Improve the usability of the unit_add sysfs attribute by ensuring that
the associated FCP LUN scan processing is completed synchronously. This
enables configuration tooling to consistently determine the end of the
scan process to allow for serialization of follow-on actions.
While the scan process associated with unit_add typically completes
synchronously, it is deferred to an asynchronous background process if
unit_add is used before initial remote port scanning has completed. This
occurs when unit_add is used immediately after setting the associated FCP
device online.
To ensure synchronous unit_add processing, wait for remote port scanning
to complete before initiating the FCP LUN scan.
Cc: stable@vger.kernel.org
Reviewed-by: M Nikhil <nikh1092@linux.ibm.com>
Reviewed-by: Nihar Panda <niharp@linux.ibm.com>
Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Nihar Panda <niharp@linux.ibm.com>
Link: https://lore.kernel.org/r/20250603182252.2287285-2-niharp@linux.ibm.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Correct the error handling goto labels used when host lookup fails in
various flashnode-related event handlers:
- iscsi_new_flashnode()
- iscsi_del_flashnode()
- iscsi_login_flashnode()
- iscsi_logout_flashnode()
- iscsi_logout_flashnode_sid()
scsi_host_put() is not required when shost is NULL, so jumping to the
correct label avoids unnecessary operations. These functions previously
jumped to the wrong goto label (put_host), which did not match the
intended cleanup logic.
Use the correct exit labels (exit_new_fnode, exit_del_fnode, etc.) to
ensure proper error handling. Also remove the unused put_host label
under iscsi_new_flashnode() as it is no longer needed.
No functional changes beyond accurate error path correction.
Fixes: c6a4bb2ef5 ("[SCSI] scsi_transport_iscsi: Add flash node mgmt support")
Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com>
Link: https://lore.kernel.org/r/20250530193012.3312911-1-alok.a.tiwari@oracle.com
Reviewed-by: Mike Christie <michael.christie@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Spelling fixes:
Deocder --> Decoder
Memroy --> Memory
This is a non-functional change aimed at improving code clarity.
Signed-off-by: Ankit Chauhan <ankitchauhan2065@gmail.com>
Link: https://lore.kernel.org/r/20250528110604.59528-1-ankitchauhan2065@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
When things go wrong, the GPU is capable of quickly generating millions
of faulting translation requests per second. When that happens, in the
stall-on-fault model each access will stall until it wins the race to
signal the fault and then the RESUME register is written. This slows
processing page faults to a crawl as the GPU can generate faults much
faster than the CPU can acknowledge them. It also means that all
available resources in the SMMU are saturated waiting for the stalled
transactions, so that other transactions such as transactions generated
by the GMU, which shares translation resources with the GPU, cannot
proceed. This causes a GMU watchdog timeout, which leads to a failed
reset because GX cannot collapse when there is a transaction pending and
a permanently hung GPU.
On older platforms with qcom,smmu-v2, it seems that when one transaction
is stalled subsequent faulting transactions are terminated, which avoids
this problem, but the MMU-500 follows the spec here.
To work around these problems, disable stall-on-fault as soon as we get a
page fault until a cooldown period after pagefaults stop. This allows
the GMU some guaranteed time to continue working. We only use
stall-on-fault to halt the GPU while we collect a devcoredump and we
always terminate the transaction afterward, so it's fine to miss some
subsequent page faults. We also keep it disabled so long as the current
devcoredump hasn't been deleted, because in that case we likely won't
capture another one if there's a fault.
After this commit HFI messages still occasionally time out, because the
crashdump handler doesn't run fast enough to let the GMU resume, but the
driver seems to recover from it. This will probably go away after the
HFI timeout is increased.
Signed-off-by: Connor Abbott <cwabbott0@gmail.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/654891/
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Unused since the previous commit.
Signed-off-by: Connor Abbott <cwabbott0@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/654890/
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
The support for dropping "_noprof" missed dropping the suffix from
exported symbols. That meant that using the :export: feature would
look for kernel-doc for (eg) krealloc_noprof() and not find the
kernel-doc for krealloc().
Fixes: 51a7bf0238 (scripts/kernel-doc: drop "_noprof" on function prototypes)
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20250606141543.1285671-1-willy@infradead.org
Now that we use a threaded IRQ, it should be safe to do this in the
fault handler.
We can also remove fault_info from struct msm_gpu and just pass it
directly.
Signed-off-by: Connor Abbott <cwabbott0@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/654889/
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
put_unused_fd() doesn't free the installed file, if we've already done
fd_install(). So we need to also free the sync_file.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Patchwork: https://patchwork.freedesktop.org/patch/653583/
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
In error paths, we could unref the submit without calling
drm_sched_entity_push_job(), so msm_job_free() will never get
called. Since drm_sched_job_cleanup() will NULL out the
s_fence, we can use that to detect this case.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Patchwork: https://patchwork.freedesktop.org/patch/653584/
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
The dedicated helper is more verbose and effective comparing to
cpumask_first() followed by cpumask_next().
Signed-off-by: Yury Norov [NVIDIA] <yury.norov@gmail.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Ian mentioned a reliably occurred failure in the trace_btf_general test
where he obtained trace output of:
sleep/279619 clock_nanosleep(0, 0, {1,1,}, 0x7ffcd47b6450) = 0
But the regex pattern used for verification is
"^sleep/[0-9]+ clock_nanosleep\(0, 0, \{1,\}, ..."
This lead to a mismatch.
The reason is, different sleep commands use different timespec data to
call clock_nanosleep, on my machine, the value of tv_nsec is 0.
~~~
$ sudo /tmp/perf/perf trace -e clock_nanosleep -- sleep 1
0.000 (1000.196 ms): sleep/54261 clock_nanosleep(rqtp: { .tv_sec:
1, .tv_nsec: 0 }, rmtp: 0x7ffe13529550) = 0
~~~
While Ian had this trace log:
~~~
$ sudo /tmp/perf/perf trace -e clock_nanosleep -- sleep 1
0.000 (1000.208 ms): sleep/1710732 clock_nanosleep(rqtp: {
.tv_sec: 1, .tv_nsec: 1 }, rmtp: 0x7ffc091f4090) = 0
~~~
Because sleep's behavior of setting 'tv_nsec' is not certain, and tv_sec
is most definitely 1, this patch relaxes the key regex pattern to
'\{1,.*\}' for a better chance of matching.
Signed-off-by: Howard Chu <howardchu95@gmail.com>
Tested-by: Namhyung Kim <namhyung@kernel.org>
Link: https://lore.kernel.org/r/20250528191148.89118-7-howardchu95@gmail.com
Reported-by: Ian Rogers <irogers@google.com>
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
The event 'timer:hrtimer_setup' is relatively new, for older kernels,
perf trace enum tests won't run as the event 'timer:hrtimer_setup'
cannot be found.
It was originally called 'timer:hrtimer_init', before being renamed in:
commit 244132c4e5 ("tracing/timers: Rename the hrtimer_init event to hrtimer_setup")
Using timer:hrtimer_start should be enough for current testing, and
hopefully 'start' won't be renamed in the future.
Before:
$ sudo /tmp/perf test enum -vv
107: perf trace enum augmentation tests:
107: perf trace enum augmentation tests : Running
--- start ---
test child forked, pid 786187
Checking if vmlinux exists
Tracing syscall landlock_add_rule
Tracing non-syscall tracepoint timer:hrtimer_setup,timer:hrtimer_start
[tracepoint failure] Failed to trace timer:hrtimer_setup,timer:hrtimer_start tracepoint, output:
event syntax error: 'timer:hrtimer_setup,timer:hrtimer_start'
\___ unknown tracepoint
Error: File /sys/kernel/tracing//events/timer/hrtimer_setup not found.
Hint: Perhaps this kernel misses some CONFIG_ setting to enable this feature?.
Run 'perf list' for a list of valid events
Usage: perf trace [<options>] [<command>]
or: perf trace [<options>] -- <command> [<options>]
or: perf trace record [<options>] [<command>]
or: perf trace record [<options>] -- <command> [<options>]
-e, --event <event> event/syscall selector. use 'perf list' to list available events
---- end(-1) ----
107: perf trace enum augmentation tests : FAILED!
After:
$ sudo /tmp/perf test enum -vv
107: perf trace enum augmentation tests:
107: perf trace enum augmentation tests : Running
--- start ---
test child forked, pid 808547
Checking if vmlinux exists
Tracing syscall landlock_add_rule
Tracing non-syscall tracepoint timer:hrtimer_start
---- end(0) ----
107: perf trace enum augmentation tests : Ok
Signed-off-by: Howard Chu <howardchu95@gmail.com>
Tested-by: Namhyung Kim <namhyung@kernel.org>
Link: https://lore.kernel.org/r/20250528191148.89118-4-howardchu95@gmail.com
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Currently perf test utilizes the set -e option in shell that exit
immediately if a command exits with a non-zero status, this prevents
further error handling and introduces ambiguity. This patch removes set
-e and prints the error message after invoking perf trace during perf
tests.
In my case, the command that exits with a non-zero status is perf
trace instead of grep, because it can't find the 'timer:hrtimer_setup'
tracepoint, see below.
Before:
$ sudo /tmp/perf test enum -vv
107: perf trace enum augmentation tests:
107: perf trace enum augmentation tests : Running
--- start ---
test child forked, pid 783533
Checking if vmlinux exists
Tracing syscall landlock_add_rule
Tracing non-syscall tracepoint syscall
---- end(-1) ----
107: perf trace enum augmentation tests : FAILED!
After:
$ sudo /tmp/perf test enum -vv
107: perf trace enum augmentation tests:
107: perf trace enum augmentation tests : Running
--- start ---
test child forked, pid 851658
Checking if vmlinux exists
Tracing syscall landlock_add_rule
Tracing non-syscall tracepoint timer:hrtimer_setup,timer:hrtimer_start
[tracepoint failure] Failed to trace tracepoint timer:hrtimer_setup,timer:hrtimer_start, output:
event syntax error: 'timer:hrtimer_setup,timer:hrtimer_start'
\___ unknown tracepoint
Error: File /sys/kernel/tracing//events/timer/hrtimer_setup not found.
Hint: Perhaps this kernel misses some CONFIG_ setting to enable this feature?.
Run 'perf list' for a list of valid events
Usage: perf trace [<options>] [<command>]
or: perf trace [<options>] -- <command> [<options>]
or: perf trace record [<options>] [<command>]
or: perf trace record [<options>] -- <command> [<options>]
-e, --event <event> event/syscall selector. use 'perf list' to list available events---- end(-1) ----
107: perf trace enum augmentation tests : FAILED!
Signed-off-by: Howard Chu <howardchu95@gmail.com>
Tested-by: Namhyung Kim <namhyung@kernel.org>
Link: https://lore.kernel.org/r/20250528191148.89118-3-howardchu95@gmail.com
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
To match the style of the existing codebase, no functional changes
were applied.
Signed-off-by: Howard Chu <howardchu95@gmail.com>
Tested-by: Namhyung Kim <namhyung@kernel.org>
Link: https://lore.kernel.org/r/20250528191148.89118-2-howardchu95@gmail.com
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
The --map-dump option was removed in 5e6da6be30 ("perf trace: Migrate
BPF augmentation to use a skeleton"), this patch removes its remaining
documentation.
Fixes: 5e6da6be30 ("perf trace: Migrate BPF augmentation to use a skeleton")
Signed-off-by: Howard Chu <howardchu95@gmail.com>
Link: https://lore.kernel.org/r/20250601173252.717780-1-howardchu95@gmail.com
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Commit 76a97cf2e1 ("perf build: Remove libbpf pre-1.0 feature
tests") removed the libbpf feature test logic used by perf in favor of
using LIBBPF_MAJOR_VERSION. Remove some build targets that should have
been removed as part of that clean up.
Fixes: 76a97cf2e1 ("perf build: Remove libbpf pre-1.0 feature tests")
Signed-off-by: Ian Rogers <irogers@google.com>
Link: https://lore.kernel.org/r/20250603221358.2562167-1-irogers@google.com
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Now the target doesn't have a uid, it is handled through BPF filters,
remove the uid options to thread_map creation. Tidy up the functions
used in tests to avoid passing unused arguments.
Signed-off-by: Ian Rogers <irogers@google.com>
Link: https://lore.kernel.org/r/20250604174545.2853620-11-irogers@google.com
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Gathering threads with a uid by scanning /proc is inherently racy
leading to perf_event_open failures that quit perf. All users of the
functionality now use BPF filters, so remove uid and uid_str from
target.
Signed-off-by: Ian Rogers <irogers@google.com>
Link: https://lore.kernel.org/r/20250604174545.2853620-10-irogers@google.com
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Finding user processes by scanning /proc is inherently racy and
results in perf_event_open failures. Use a BPF filter to drop samples
where the uid doesn't match.
Signed-off-by: Ian Rogers <irogers@google.com>
Link: https://lore.kernel.org/r/20250604174545.2853620-9-irogers@google.com
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Finding user processes by scanning /proc is inherently racy and
results in perf_event_open failures. Use a BPF filter to drop samples
where the uid doesn't match. Ensure adding the BPF filter forces
system-wide.
Signed-off-by: Ian Rogers <irogers@google.com>
Link: https://lore.kernel.org/r/20250604174545.2853620-8-irogers@google.com
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Finding user processes by scanning /proc is inherently racy and
results in perf_event_open failures. Use a BPF filter to drop samples
where the uid doesn't match.
Signed-off-by: Ian Rogers <irogers@google.com>
Link: https://lore.kernel.org/r/20250604174545.2853620-7-irogers@google.com
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Based on the system-wide test with changes around how failure is
handled as BPF permissions are a bigger issue than perf event
paranoia.
Signed-off-by: Ian Rogers <irogers@google.com>
Link: https://lore.kernel.org/r/20250604174545.2853620-6-irogers@google.com
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Finding user processes by scanning /proc is inherently racy and
results in perf_event_open failures. Use a BPF filter to drop samples
where the uid doesn't match. Ensure adding the BPF filter forces
system-wide.
Signed-off-by: Ian Rogers <irogers@google.com>
Link: https://lore.kernel.org/r/20250604174545.2853620-5-irogers@google.com
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Add parse_uid_filter filter as a helper to parse_filter, that
constructs a uid filter string. As uid filters don't work with
tracepoint filters, add a is_possible_tp_filter function so the
tracepoint filter isn't attempted for tracepoint evsels.
Signed-off-by: Ian Rogers <irogers@google.com>
Link: https://lore.kernel.org/r/20250604174545.2853620-4-irogers@google.com
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Allow parse_uid to be called without a struct target. Rather than have
two errors, remove TARGET_ERRNO__USER_NOT_FOUND and use
TARGET_ERRNO__INVALID_UID as the handling is identical.
Signed-off-by: Ian Rogers <irogers@google.com>
Link: https://lore.kernel.org/r/20250604174545.2853620-3-irogers@google.com
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
The BPF filter needs libbpf/BPF-skeleton support and root privilege.
Add error messages to help users understand the problem easily.
When it's not build with BPF support (make BUILD_BPF_SKEL=0).
$ sudo perf record -e cycles --filter "pid != 0" true
Error: BPF filter is requested but perf is not built with BPF.
Please make sure to build with libbpf and BPF skeleton.
Usage: perf record [<options>] [<command>]
or: perf record [<options>] -- <command> [<options>]
--filter <filter>
event filter
When it supports BPF but runs without root or CAP_BPF. Note that it
also checks pinned BPF filters.
$ perf record -e cycles --filter "pid != 0" -o /dev/null true
Error: BPF filter only works for users with the CAP_BPF capability!
Please run 'perf record --setup-filter pin' as root first.
Usage: perf record [<options>] [<command>]
or: perf record [<options>] -- <command> [<options>]
--filter <filter>
event filter
Reviewed-by: Ian Rogers <irogers@google.com>
Link: https://lore.kernel.org/r/20250604174835.1852481-1-namhyung@kernel.org
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
-Wflex-array-member-not-at-end was introduced in GCC-14, and we are
getting ready to enable it, globally.
Use the `DEFINE_RAW_FLEX()` helper for on-stack definitions of
a flexible structure where the size of the flexible-array member
is known at compile-time, and refactor the rest of the code,
accordingly.
So, with these changes, fix the following warnings:
drivers/net/wireless/intel/iwlwifi/mvm/d3.c:124:52: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/intel/iwlwifi/mvm/d3.c:2067:51: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/intel/iwlwifi/mvm/d3.c:2162:43: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/intel/iwlwifi/mvm/d3.c:2225:43: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: Kees Cook <kees@kernel.org>
Acked-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/Z_FxXjiMvG5u73fi@kspp
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Add "Availability" section to Control Group v2 docs. It describes the
meaning of a controller being available in a cgroup, complementing the
existing "Enabling and Disabling" section.
This update improves the clarity of cgroup controller management by
explicitly distinguishing between:
1. Availability – when a controller is supported by the kernel and
listed in "cgroup.controllers", making its interface files accessible
in the cgroup's directory.
2. Enabling – when a controller is enabled via explicitly writing the
name of the controller to "cgroup.subtree_control" to control
distribution of resource across the cgroup's immediate children.
As an example, consider
/sys/fs/cgroup # cat cgroup.controllers
cpuset cpu io memory hugetlb pids misc
/sys/fs/cgroup # cat cgroup.subtree_control # No controllers enabled by default
/sys/fs/cgroup # echo +cpu +memory > cgroup.subtree_control # enabling "cpu" and "memory"
/sys/fs/cgroup # cat cgroup.subtree_control
cpu memory # cpu and memory enabled in /sys/fs/cgroup
/sys/fs/cgroup # mkdir foo_cgrp
/sys/fs/cgroup # cd foo_cgrp/
/sys/fs/cgroup/foo_cgrp # cat cgroup.controllers
cpu memory # cpu and memory available in 'foo_cgrp'
/sys/fs/cgroup/foo_cgrp # cat cgroup.subtree_control # empty by default
/sys/fs/cgroup/foo_cgrp # ls
cgroup.controllers cpu.max.burst memory.numa_stat
cgroup.events cpu.pressure memory.oom.group
cgroup.freeze cpu.stat memory.peak
cgroup.kill cpu.stat.local memory.pressure
cgroup.max.depth cpu.weight memory.reclaim
cgroup.max.descendants cpu.weight.nice memory.stat
cgroup.pressure io.pressure memory.swap.current
cgroup.procs memory.current memory.swap.events
cgroup.stat memory.events memory.swap.high
cgroup.subtree_control memory.events.local memory.swap.max
cgroup.threads memory.high memory.swap.peak
cgroup.type memory.low memory.zswap.current
cpu.idle memory.max memory.zswap.max
cpu.max memory.min memory.zswap.writeback
In this example, "cpu" and "memory" are enabled in the root cgroup,
making them available in "foo_cgrp". This exposes the corresponding
interface files in "foo_cgrp/", allowing resource control of processes
in that cgroup. However, these controllers are not yet enabled in
"foo_cgrp" itself.
Once a controller is available in a cgroup it can be used to resource
control processes of the cgroup.
Acked-by: Michal Koutný <mkoutny@suse.com>
Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com>
Signed-off-by: Vishal Chourasia <vishalc@linux.ibm.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Merge series from Félix Piédallu <felix.piedallu@non.se.com>:
These patches fix the behaviour of the SPI Chip Select of the OMAP2 MCSPI
driver used on TI SoCs.
The omap2-mcspi driver supports the use of multi mode (multichannel in TI
documentation). In this mode, the CS is asserted and deasserted by the
hardware.
The multi mode is disabled for messages when cs_change=0 for all transfers
(e.g when CS is kept asserted between transfers of a same message).
The multi mode also needs to be disabled for messages when cs_change=1 on the
last transfer (e.g when CS is kept asserted after the WHOLE message), and the
message right after.
Currently, that is not the case and it CS is deasserted by hardware when it
shouldn't.
This breaks peripheral drivers that send multiple messages with the CS asserted
in between.
Patch 1 ensures that multi mode is disabled when cs_change=1 on the last
transfer of the message.
Patch 2 ensures that multi mode is disable on a message following one with
cs_change=1 on the last transfer.
This is the case for the TPM TIS SPI driver that uses this logic for flow
control purposes.
Tested on an AM6442 platform with a TPM ST33HTPH2X32AHE4.
