| Age | Commit message (Collapse) | Author |
|---|
|
When working on nolibc, debug information is very valuable.
I find myself adding this flag in many patchsets.
Enable debug information unconditionally, as there is no downside to it.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Acked-by: Willy Tarreau <w@1wt.eu>
Link: https://patch.msgid.link/20260707-nolibc-debug-v1-1-31619ec94bbd@weissschuh.net
|
|
The capability counter fields in struct ib_device_attr are declared
as signed int, but these values are inherently non-negative. Drivers
maintain their cached caps as u32 and assign them directly into these
int fields; if a cap exceeds INT_MAX the implicit narrowing yields a
negative value visible to the IB core.
Change the signed int capability fields to u32 to match the
underlying nature of the data. Also update consumers across the IB
core, ULPs, NVMe-oF target, RDS, and NFS/RDMA so the new u32 values
are not forced back through signed int or u8 via min()/min_t() or
narrowing local variables.
The nvmet-rdma consumer of max_srq clamps it against
ib_device.num_comp_vectors, which stays a signed int, so that site
uses min_t() instead of min() to handle the signed/unsigned mismatch.
Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Erni Sri Satya Vennela <ernis@linux.microsoft.com>
Link: https://patch.msgid.link/20260709055211.2498307-1-ernis@linux.microsoft.com
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Stefan Metzmacher <metze@samba.org> # smbdirect
Signed-off-by: Leon Romanovsky <leon@kernel.org>
|
|
In hns_roce_v2_set_hem() the HEM address indices are computed from
i, j and k (the base-chunk_ba_num decomposition of the 32-bit
table_idx) in 32-bit arithmetic and then assigned to u64 fields.
The recombined value always equals table_idx and cannot exceed
U32_MAX, so this is not a reachable overflow and has no user-visible
impact. Declare i, j and k as u64 so the calculation is done in
64-bit and the pattern no longer trips static analyzers.
No functional change intended.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Suggested-by: David Laight <david.laight.linux@gmail.com>
Signed-off-by: Alexander Chesnokov <Alexander.Chesnokov@kaspersky.com>
Link: https://patch.msgid.link/20260709050327.3547237-1-Alexander.Chesnokov@kaspersky.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
|
|
On create AH, first check if the AH cache entry already exists and if
so, returns the already stored AH number. If the entry doesn't exist,
the driver creates it and calls the device to create the AH. A per-entry
mutex serializes concurrent device commands on the same AH cache entry,
ensuring only one thread issues the device create while others wait and
reuse the result. If the device create fails, the entry's user count
remains zero so subsequent threads will retry the device create.
On destroy AH, the user count is decremented under the entry mutex. If
it reaches zero, the driver issues the device destroy command. After
the device destroy completes, it removes the entry from the hashtable
and frees it if no other references exist. If new users arrived during
the destroy, the entry remains in the hashtable for reuse.
Reviewed-by: Firas Jahjah <firasj@amazon.com>
Reviewed-by: Michael Margolin <mrgolin@amazon.com>
Signed-off-by: Yonatan Nachum <ynachum@amazon.com>
Link: https://patch.msgid.link/20260706170008.1039417-3-ynachum@amazon.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
|
|
New EFA devices don't support the creation of multiple address handles
to the same remote on the same PD.
To overcome this limitation, introduce an AH cache rhashtable which will
store the user refcounts of the same AH creation on the same PD and will
allow the driver to manage AH reuse. The hashtable key is the
combination of PD and GID. Add initialization and teardown logic for the
rhashtable.
Each entry holds a refcount to manage the entry lifetime in the
hashtable and a user count that indicates how many users are using the
address handle.
Reviewed-by: Firas Jahjah <firasj@amazon.com>
Reviewed-by: Michael Margolin <mrgolin@amazon.com>
Signed-off-by: Yonatan Nachum <ynachum@amazon.com>
Link: https://patch.msgid.link/20260706170008.1039417-2-ynachum@amazon.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
|
|
IPoIB reclamation completions can be signaled from inside an RCU callback.
Teardown can wake before the callback returns and unload ib_ipoib while its
code is still executing.
Client registration failure can also remove already-added devices and queue
callbacks. Wait after client and workqueue teardown.
Fixes: b63b70d87741 ("IPoIB: Use a private hash table for path lookup in xmit path")
Reported-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Closes: https://lore.kernel.org/linux-rdma/20260708092316.Qb39F_B0@linutronix.de/
Link: https://patch.msgid.link/20260709-unload-rcu-v1-3-fccd27211e5a@nvidia.com
Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
|
|
devx_free_subscription() can remain queued after the last DevX event file
drops its module reference or an auxiliary driver detaches its devices.
mlx5_ib can then unload before the callback runs.
Registration error unwind has the same risk because driver registration
can attach existing devices before failing. Wait after all drivers have
stopped.
Fixes: 6898d1c661d7 ("RDMA/mlx5: Use RCU and direct refcounts to keep memory alive")
Reported-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Closes: https://lore.kernel.org/linux-rdma/20260708092316.Qb39F_B0@linutronix.de/
Link: https://patch.msgid.link/20260709-unload-rcu-v1-2-fccd27211e5a@nvidia.com
Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
|
|
put_gid_ndev() is queued with call_rcu() and implemented in ib_core.
Stopping the workqueues does not drain callbacks already queued, so RCU
could invoke it after the module code has been unloaded.
synchronize_rcu() does not wait for callbacks. Wait for them after all
producers have stopped.
Fixes: 943bd984b108 ("RDMA/core: Allow detaching gid attribute netdevice for RoCE")
Reported-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Closes: https://lore.kernel.org/linux-rdma/20260708092316.Qb39F_B0@linutronix.de/
Link: https://patch.msgid.link/20260709-unload-rcu-v1-1-fccd27211e5a@nvidia.com
Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
|
|
In many cases, a driver op accepts no input data and provides
no response. This helper can be used in those handlers to
adhere to the uAPI forward/backward compat rules by failing
early if invalid udata is provided (whether input or output).
Signed-off-by: Jacob Moroni <jmoroni@google.com>
Link: https://patch.msgid.link/20260702170652.4159201-2-jmoroni@google.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
|
|
rtl8xxxu arms rx_urb_wq from the RX completion path:
rtl8xxxu_rx_complete() hands the URB to rtl8xxxu_queue_rx_urb(), which
queues it on rx_urb_pending_list and, once the list grows past
RTL8XXXU_RX_URB_PENDING_WATER, schedules rx_urb_wq. The worker
rtl8xxxu_rx_urb_work() drains rx_urb_pending_list, recovers priv through
container_of, and resubmits each URB through rtl8xxxu_submit_rx_urb(),
which anchors it on rx_anchor and dereferences priv->udev.
rtl8xxxu_stop() cancels the sibling work items (c2hcmd_work, ra_watchdog,
update_beacon_work) but never cancels rx_urb_wq, so a worker armed during
the last burst of RX traffic can run rtl8xxxu_rx_urb_work() after
rtl8xxxu_disconnect() has called ieee80211_free_hw(), which frees priv,
producing a use-after-free. The window opens under active RX traffic
(pending count above the watermark) followed by a disconnect.
There are two teardown races to close:
* rtl8xxxu_queue_rx_urb() decided whether to enqueue under rx_urb_lock
but called schedule_work() after dropping the lock. A completion
that observed shutdown == false and released the lock could then call
schedule_work() after rtl8xxxu_stop() had set shutdown and
cancel_work_sync() had already returned, arming the worker to run
after the teardown. Move schedule_work() under the same !shutdown
branch so the arming decision is atomic with the shutdown check.
* rtl8xxxu_rx_urb_work() anchors every URB it drained back onto
rx_anchor through rtl8xxxu_submit_rx_urb(). A worker still running
when usb_kill_anchored_urbs(&priv->rx_anchor) returned would submit a
URB that escaped the kill. In rtl8xxxu_stop(), call
cancel_work_sync(&priv->rx_urb_wq) before the kill so the worker is
drained first.
After priv->shutdown is set under rx_urb_lock, completions can no longer
queue rx_urb_wq. cancel_work_sync() then drains the last queued or running
worker, and the following usb_kill_anchored_urbs() kills the URBs it may
have submitted.
rtl8xxxu_disconnect() is covered because ieee80211_unregister_hw()
guarantees .stop() runs for a live interface before ieee80211_free_hw()
frees priv. The probe error path needs no cancel: rx_urb_wq is
INIT_WORK()'d there but cannot have been scheduled, since no URB is
submitted before ieee80211_register_hw() succeeds.
This bug was found by static analysis.
Fixes: 26f1fad29ad9 ("New driver: rtl8xxxu (mac80211)")
Cc: stable@vger.kernel.org
Signed-off-by: Fan Wu <fanwu01@zju.edu.cn>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260630033117.3377-1-fanwu01@zju.edu.cn
|
|
cmdline_find_option() returns the full length of the parsed acpi_rsdp=
value. get_cmdline_acpi_rsdp() then silently truncates values which do
not fit in the val[] buffer.
Prevent boot_kstrtoul() from parsing a truncated value and then the
kernel from silently using the wrong RSDP address, see discussion in
Link:.
Issue a warning so that the user is aware that s/he supplied a malformed
value and can get feedback instead of silent crashes.
[ bp: Make commit message more precise. ]
Fixes: 3c98e71b42a7 ("x86/boot: Add "acpi_rsdp=" early parsing")
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/all/20260617130417.36651-4-thorsten.blum@linux.dev
|
|
Reading the in_accel_scale attribute on the DMARD09 has always returned
-EINVAL: the channels advertise scale via info_mask_shared_by_type so the
IIO core exposes the attribute, but dmard09_read_raw() only handles
IIO_CHAN_INFO_RAW, so a SCALE read falls through to 'default: return
-EINVAL':
$ cat .../iio:deviceX/in_accel_scale
cat: in_accel_scale: Invalid argument
leaving userspace with raw counts it cannot convert to m/s^2.
The driver was written from a vendor source [1] without a datasheet, and
the scale was declared but never implemented. The vendor source carries
the sensitivity: its conversion is
acc = raw * GRAVITY_EARTH_1000 / sensitivity (then / 1000 -> m/s^2)
with sensitivity = 32 and GRAVITY_EARTH_1000 = 9807 ("about
(9.80665)*1000"), i.e. 32 counts correspond to 1 g.
That sensitivity applies to the value this driver already reports as raw:
the vendor reduces each 16-bit sample to a signed 9-bit value, and the
preparation in dmard09_read_raw() yields the same value. It is
self-consistent: 256 counts / 32 = 8 g full scale, matching the +/-8g
range.
Implement the scale derived from that sensitivity using standard gravity:
scale = 9.80665 / 32 = 0.3064578125 m/s^2 per LSB
Link: https://github.com/minstrelsy/mediatek/blob/1f49d8c87b839651bc89afc870277e8e0f2e2d55/custom/common/kernel/accelerometer/dmard09/dmard09.c [1]
Fixes: a4fa6509dda4 ("iio: accel: add support for the Domintech DMARD09 3-axis accelerometer")
Signed-off-by: Mert Seftali <mertsftl@gmail.com>
Reviewed-by: Joshua Crofts <joshua.crofts1@gmail.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
The early chips including RTL8852A, RTL8851B, RTL8852B and RTL8852C have
driver built-in tables, which are not preferred. New firmware is prepared
with corresponding tables in firmware elements, so we can start to
transition. After this patch, old firmware is still usable, but add a
prompt text for users to update firmware.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260707091056.42771-16-pkshih@realtek.com
|
|
There are two struct to access TX power track tables. One is to access
driver built-in tables, and the other one is to access the tables in fw
element. As we are going to remove the built-in tables from driver, unify
to use the struct as fw element style.
The precedence is to use tables in fw element if present, and then
built-in tables.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260707091056.42771-15-pkshih@realtek.com
|
|
Initialize NCTL hardware and check the state before downloading NCTL.
Otherwise, the following RF calibrations relying on NCTL may fail.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260707091056.42771-14-pkshih@realtek.com
|
|
8852A uses the average beacon RSSI to smooth the RSSI. However, before
the average beacon RSSI is available, the RSSI should use the PPDU
status RSSI of the received packet to avoid reporting the RSSI as -110 dBm.
Fixes: f0f3bf4b370c ("wifi: rtw89: 8852a: report average RSSI to avoid unnecessary scanning")
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260707091056.42771-13-pkshih@realtek.com
|
|
Update the per-MCS calibration values of RX scaling factors on RX path
(1R or 2R) for BCC and LDPC coding schemes.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260707091056.42771-12-pkshih@realtek.com
|
|
To power save, change the clock of ANA hardware from 12MHz to 500KHz.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260707091056.42771-11-pkshih@realtek.com
|
|
The temperature is rising when WiFi does high throughput, and reduce
voltage is a way to ease temperature.
The existing method to do thermal protect is to reduce TX duty, which
can affect throughput obviously. Before doing reduce TX duty (with -20
thermal value offset), driver does voltage reduction first, which doesn't
affect throughput but lower power consumption.
The voltage gram of register is 0.01 voltage, and the suggested maximum
reduction is 6 grams, which driver defines 6 as maximum voltage level.
When thermal value is over threshold, driver will try to adjust level and
corresponding register value. It should be adjust grams one by one with
additional 50 ms delay to ensure hardware work properly.
A note that the voltage must reset to normal value before entering power
save mode, otherwise WiFi card might get lost. Since it takes 50 ms delay
for each gram to adjust voltage, we stop to enter power save if protect
level is not zero.
By the way, adjust thermal threshold to 0xB4 as desired.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260707091056.42771-10-pkshih@realtek.com
|
|
In order to lower temperature when WiFi is running, reduce the digital
voltage for the purpose.
The calibration values of digital voltage are programmed in efuse. One is
for normal use, which driver stores it into hal->thermal_prot_vmax. The
other is the minimum voltage, which is stored into hal->thermal_prot_vmin.
These two values define a range of supported voltage, which latter patch
uses them to adjust voltage depends on thermal value (temperature).
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260707091056.42771-9-pkshih@realtek.com
|
|
The thermal calibration value programmed in efuse is the offset to adjust
thermal value read from hardware, so that output will be accurate.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260707091056.42771-8-pkshih@realtek.com
|
|
The consumer of rtw89_efuse_read_ecv_be() is in the same ko. No need to
export it.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260707091056.42771-7-pkshih@realtek.com
|
|
The total number of TX compensation registers is 22, including 7 base and
15 ones according to operating channel.
The v0 is 22 ones per channel. To reduce array size, v1 treats 7 base as
common part across all conditions. However, we can fine tune the base part
to yield better performance, so divide base into two sets according to NSS.
Summarize dimensions as follows
base (7) vals(15)
v0 nss * band * path nss * band * path
v1 1 nss * band * path
v2 nss nss * band * path
Currently, v1 and v2 can present in a file, but only one fw element with
a specific format will be used for specific RFE type.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260707091056.42771-6-pkshih@realtek.com
|
|
Correct 2.4GHz bandwidth 40MHz bandedge check: pri_ch 5/9 instead of 3/11.
Remove stale 6GHz bandedge case; no restricted band borders 6GHz range.
Signed-off-by: Eric Huang <echuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260707091056.42771-5-pkshih@realtek.com
|
|
Assert BB reset in the intermediate "switch to 1+1" step of the EMLSR
switch sequence for all three MLO mode transitions by updating the
B_EMLSR_SWITCH_BE4 intermediate value from 0xAFFF to 0x3BAB.
Without the BB reset in this step, the baseband can be left in an
inconsistent state before settling into the final MLO configuration.
Signed-off-by: Eric Huang <echuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260707091056.42771-4-pkshih@realtek.com
|
|
Add support for path difference based channel smoothing for RTL8922D chip.
This feature measures the ratio of NDP frames and uses a moving average
filter to decide whether to enable beamforming channel smoothing. Tone
index selection is dynamically adjusted based on bandwidth and link mode
(HE/EHT vs VHT). The feature is only enabled for RTL8922D_CID7090 variant.
Signed-off-by: Eric Huang <echuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260707091056.42771-3-pkshih@realtek.com
|
|
Remove the 40MHz bandwidth compensation from CCK efuse gain calculation.
The design no longer requires the +3dB compensation for 40MHz channels.
Signed-off-by: Eric Huang <echuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260707091056.42771-2-pkshih@realtek.com
|
|
Co-RX means Wi-Fi & Bluetooth can be able to RX in the same time. This
patch is for judging the Wi-Fi/Bluetooth condition could be Co-RX or not,
and how to set the gain and power.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260706025445.18428-10-pkshih@realtek.com
|
|
Update WiFi status to each Bluetooth & collect status from the two
Bluetooth adapter by non-stop power zone register. To correct the meaning
of variable, redefine the naming for the variables.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260706025445.18428-9-pkshih@realtek.com
|
|
Because the two MAC should have their own individual using, they will
need different TDMA mechanism. This patch will bind TDMA with MAC index,
and also the corresponding antenna, hardware grant signal setting.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260706025445.18428-8-pkshih@realtek.com
|
|
To bind Wi-Fi/Bluetooth with which adapter, in which band.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260706025445.18428-7-pkshih@realtek.com
|
|
Dual Bluetooth the each of Bluetooth may use different RX gain by their
condition.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260706025445.18428-6-pkshih@realtek.com
|
|
Dual Bluetooth the each of Bluetooth may use different TX power by their
condition.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260706025445.18428-5-pkshih@realtek.com
|
|
Support for UMC CPUs was removed in
7d328c5de43a ("x86/cpu: Remove CPU_SUP_UMC_32 support"),
but a Makefile rule for the support code remained. Remove it.
Fixes: 7d328c5de43a ("x86/cpu: Remove CPU_SUP_UMC_32 support")
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Ahmed S. Darwish <darwi@linutronix.de>
Link: https://patch.msgid.link/20260610033252.164571-1-enelsonmoore@gmail.com
|
|
The mechanism needs information to know which MAC is coexisting with which
Bluetooth and when to enable TDMA with which MAC. So change an variable to
describe the binding target.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260706025445.18428-4-pkshih@realtek.com
|
|
Separate these two type of initialize entry. Because Wi-Fi power save
leaving will also call the initializing, but don't have to reset all the
stored variables.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260706025445.18428-3-pkshih@realtek.com
|
|
The version 10 Init info add I/O offload type & variable Bluetooth
function (EX: Zigbee/Thread...etc) into the structure definition.
Firmware need to synchronize these information to do corresponding
setting.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260706025445.18428-2-pkshih@realtek.com
|
|
If an empty firmware file is supplied via CONFIG_EXTRA_FIRMWARE, the
build currently succeeds but creates an empty section. While the
firmware loader will not return such sections it is better to avoid
adding them in the first place.
Add a compile-time size check to the filechk_fwbin macro to abort the
build early if a 0-size firmware is encountered.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://patch.msgid.link/20260426043041.649202-2-dmitry.torokhov@gmail.com
[ Use 'exit 1' to properly fail the build. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Leon Hwang says:
====================
bpf: Fix WARNING in bpf_trampoline_multi_detach
Since tracing_multi link does not set ftrace_managed, it would fail to
release the tracing_multi link when attaching tracing_multi link and
then attaching fentry link.
[ 3.714215] WARNING: kernel/bpf/trampoline.c:1727 at bpf_trampoline_multi_detach+0x20b/0x240, CPU#1: test_progs/97
...
[ 3.733170] bpf_tracing_multi_link_release+0x14/0x30
[ 3.733890] bpf_link_free+0x58/0x130
[ 3.734414] bpf_link_release+0x23/0x30
Fix it by setting 'ftrace_managed = true' in register_fentry_multi().
Note: the reason of targeting bpf-next tree is I'm planning to add
tracing_multi link support for bpf progs, that would rely on the fix and
have code conflict with the test.
Changes:
v1 -> v2:
* Collect Acked-by from Jiri, thanks.
* Check arg using tracing_multi_arg_check() in bpf prog in test.
(per Sashiko)
* v1: https://lore.kernel.org/bpf/20260710144734.78203-1-leon.hwang@linux.dev/
====================
Link: https://patch.msgid.link/20260711124822.29406-1-leon.hwang@linux.dev
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
|
|
Verify that there's no any issue to attach tracing_multi link, then attach
fentry link.
Assisted-by: Codex:gpt-5.6-sol
Signed-off-by: Leon Hwang <leon.hwang@linux.dev>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Link: https://lore.kernel.org/bpf/20260711124822.29406-3-leon.hwang@linux.dev
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
|
|
Since tracing_multi link does not set ftrace_managed, it would fail to
release the tracing_multi link when attaching tracing_multi link and
then attaching fentry link.
[ 3.714215] WARNING: kernel/bpf/trampoline.c:1727 at bpf_trampoline_multi_detach+0x20b/0x240, CPU#1: test_progs/97
...
[ 3.733170] bpf_tracing_multi_link_release+0x14/0x30
[ 3.733890] bpf_link_free+0x58/0x130
[ 3.734414] bpf_link_release+0x23/0x30
Fix it by setting 'ftrace_managed = true' in register_fentry_multi().
Fixes: aef4dfa790b2 ("bpf: Add bpf_trampoline_multi_attach/detach functions")
Signed-off-by: Leon Hwang <leon.hwang@linux.dev>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Link: https://lore.kernel.org/bpf/20260711124822.29406-2-leon.hwang@linux.dev
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
|
|
Nicholas Dudar says:
====================
bpf: require an owned cpumask for bpf_cpumask_populate()
bpf_cpumask_populate() writes its destination with bitmap_copy() but
types it as struct cpumask *, so the verifier accepts a borrowed,
read-only cpumask (for example from scx_bpf_get_online_cpumask()) as a
writable destination. Fix it and add a selftest for coverage.
Changelog:
----------
v2 -> v3 (v1/v2 were a private report to security@kernel.org)
* Split the fix and selftest into separate patches.
* Target bpf-next instead of bpf.
====================
Link: https://patch.msgid.link/20260709182800.2037938-1-main.kalliope@gmail.com
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
|
|
bpf_cpumask_populate() now takes a struct bpf_cpumask *, so update the
kfunc declaration and drop the struct cpumask * casts in the existing
populate tests. Add test_populate_borrowed_destination, which passes a
borrowed task->cpus_ptr and asserts the verifier rejects it as a writable
destination.
Signed-off-by: Nicholas Dudar <main.kalliope@gmail.com>
Acked-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com>
Link: https://lore.kernel.org/bpf/20260709182800.2037938-3-main.kalliope@gmail.com
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
|
|
bpf_cpumask_populate() writes to its destination with bitmap_copy(), but
the destination is typed as struct cpumask *. That allows the verifier to
accept borrowed cpumask pointers returned by read-only kfuncs, such as
scx_bpf_get_online_cpumask(), as a writable destination.
Make the destination a struct bpf_cpumask * so populate follows the same
ownership rule as the other mutating cpumask kfuncs. Query kfuncs continue
to accept const struct cpumask * inputs.
Fixes: 950ad93df2fc ("bpf: add kfunc for populating cpumask bits")
Signed-off-by: Nicholas Dudar <main.kalliope@gmail.com>
Acked-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com>
Link: https://lore.kernel.org/bpf/20260709182800.2037938-2-main.kalliope@gmail.com
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
|
|
Currently, the builtin firmware loader allows 0-size firmware to be
returned successfully to drivers. This differs from all other loading
mechanisms (filesystem, sysfs fallback) which reject 0-byte files, and
forces drivers to add boilerplate size checks.
Modify firmware_request_builtin() to reject 0-size firmware. This will
also result in firmware loader falling back to other mechanisms if an
empty built-in firmware is present.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://patch.msgid.link/20260426043041.649202-1-dmitry.torokhov@gmail.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
In preparation for removing the strlcat() API[1], replace its uses in
i8042-acpipnpio.h.
i8042_pnp_id_to_string() accumulates a variable number of PNP ids in
a loop, which is what seq_buf is for. The kbd and aux probe functions
build a name from at most three parts that are all known up front, so
the whole construction becomes a single scnprintf() there.
Link: https://github.com/KSPP/linux/issues/370 [1]
Signed-off-by: Ian Bridges <icb@fastmail.org>
Link: https://patch.msgid.link/akyW4xkvCCROM0SE@dev
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
|
|
If enabling VIO fails after VDD has been enabled, runtime resume
returns without disabling VDD. Likewise, if device reinitialization
fails, both supplies remain enabled. The runtime PM core keeps the
device suspended when its resume callback fails, so the supplies must
be restored to the suspended state.
Disable the supplies enabled by the callback before returning an error.
Fixes: 97d642e23037 ("iio: light: Add a driver for Sharp GP2AP002x00F")
Assisted-by: Codex:gpt-5
Signed-off-by: Laxman Acharya Padhya <acharyalaxman8848@gmail.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
Pull input fixes from Dmitry Torokhov:
- fix MELFAS MMS114 touchscreen driver to reject invalid touch IDs and
avoid multi-touch slot corruption
- fix a crash in the Sega Dreamcast (Maple) mouse driver when opening
the device, caused by missing driver data
- fixes for Maple drivers (keyboard, mouse, joystick) to properly order
setting driver data and device registration to avoid races
* tag 'input-for-v7.2-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
Input: mms114 - fix multi-touch slot corruption
Input: maple_keyb - set driver data before registering input device
Input: maplecontrol - set driver data before registering input device
Input: maplemouse - set driver data before registering input device
Input: maplemouse - fix NULL pointer dereference in open()
|
|
rpr0521_runtime_suspend() powers the device down and marks the regmap
cache dirty. rpr0521_runtime_resume() syncs the cache before restoring
enabled ALS/PXS channels, but currently ignores a regcache_sync()
failure and can still return success.
Return the regcache_sync() error so resume does not hide a failed
register restore.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
vcnl4035_runtime_suspend() marks the regmap cache dirty before runtime
suspend. vcnl4035_runtime_resume() then syncs the cache before re-
enabling ALS, but currently ignores a regcache_sync() failure and can
still report resume success.
Return the regcache_sync() error so the PM core sees the failed register
restore.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
