Tejun Heo [Fri, 1 May 2026 18:31:22 +0000 (08:31 -1000)]
cgroup: Defer css percpu_ref kill on rmdir until cgroup is depopulated
A chain of commits going back to v7.0 reworked rmdir to satisfy the
controller invariant that a subsystem's ->css_offline() must not run while
tasks are still doing kernel-side work in the cgroup.
[1] d245698d727a ("cgroup: Defer task cgroup unlink until after the task is done switching out")
[2] a72f73c4dd9b ("cgroup: Don't expose dead tasks in cgroup")
[3] 1b164b876c36 ("cgroup: Wait for dying tasks to leave on rmdir")
[4] 4c56a8ac6869 ("cgroup: Fix cgroup_drain_dying() testing the wrong condition")
[5] 13e786b64bd3 ("cgroup: Increment nr_dying_subsys_* from rmdir context")
[1] moved task cset unlink from do_exit() to finish_task_switch() so a
task's cset link drops only after the task has fully stopped scheduling.
That made tasks past exit_signals() linger on cset->tasks until their final
context switch, which led to a series of problems as what userspace expected
to see after rmdir diverged from what the kernel needs to wait for. [2]-[5]
tried to bridge that divergence: [2] filtered the exiting tasks from
cgroup.procs; [3] had rmdir(2) sleep in TASK_UNINTERRUPTIBLE for them; [4]
fixed the wait's condition; [5] made nr_dying_subsys_* visible
synchronously.
The cgroup_drain_dying() wait in [3] turned out to be a dead end. When the
rmdir caller is also the reaper of a zombie that pins a pidns teardown (e.g.
host PID 1 systemd reaping orphan pids that were re-parented to it during
the same teardown), rmdir blocks in TASK_UNINTERRUPTIBLE waiting for those
pids to free, the pids can't free because PID 1 is the reaper and it's stuck
in rmdir, and the system A-A deadlocks. No internal lock ordering breaks
this; the wait itself is the bug.
The css killing side that drove the original reorder, however, can be made
cleanly asynchronous: ->css_offline() is already async, run from
css_killed_work_fn() driven by percpu_ref_kill_and_confirm(). The fix is to
make that chain start only after all tasks have left the cgroup. rmdir's
user-visible side then returns as soon as cgroup.procs and friends are
empty, while ->css_offline() still runs only after the cgroup is fully
drained.
Verified by the original reproducer (pidns teardown + zombie reaper, runs
under vng) which hangs vanilla and succeeds here, and by per-commit
deterministic repros for [2], [3], [4], [5] with a boot parameter that
widens the post-exit_signals() window so each state is reliably reachable.
Some stress tests on top of that.
cgroup_apply_control_disable() has the same shape of pre-existing race:
when a controller is disabled via subtree_control, kill_css() ran
synchronously while tasks past exit_signals() could still be linked to
the cgroup's csets, and ->css_offline() could fire before they drained.
This patch preserves the existing synchronous behavior at that call site
(kill_css_sync() + kill_css_finish() back-to-back) and a follow-up patch
will defer kill_css_finish() there using a per-css trigger.
This seems like the right approach and I don't see problems with it. The
changes are somewhat invasive but not excessively so, so backporting to
-stable should be okay. If something does turn out to be wrong, the fallback
is to revert the entire chain ([1]-[5]) and rework in the development branch
instead.
v2: Pin cgrp across the deferred destroy work with explicit
cgroup_get()/cgroup_put() around queue_work() and the work_fn. v1
wasn't actually broken (ordered cgroup_offline_wq + queue_work order
in cgroup_task_dead() saved it) but the explicit ref removes the
dependency on those non-obvious invariants. Also note the
pre-existing cgroup_apply_control_disable() race in the description;
a follow-up will defer kill_css_finish() there.
David Gow [Sat, 25 Apr 2026 03:41:53 +0000 (11:41 +0800)]
kunit: config: Enable KUNIT_DEBUGFS by default
The KUNIT_DEBUGFS option is currently enabled based on the value of
KUNIT_ALL_TESTS, but it really doesn't have anything to do with the set of
enabled tests, so just enable it by default anyway. In particular, this
shouldn't be only visible if KUNIT_ALL_TESTS is set, which is quite
confusing.
Alexander Dahl [Wed, 29 Apr 2026 12:59:30 +0000 (14:59 +0200)]
memory: atmel-ebi: Allow deferred probing
After removing of_platform_default_populate() calls the atmel-ebi driver
was affected by deferred probing. platform_driver_probe() is
incompatible with deferred probing. This led to atmel-ebi driver
eventually not being probed on at91 sam9x60-curiosity and other sam9x60
based boards. Subsequently the nand-controller driver (nand-controller
being a child node of ebi) on that platform was not probed and thus raw
NAND flash was inaccessible, preventing devices to boot with rootfs on
raw NAND flash (e.g. with UBI/UBIFS).
Nicola Lunghi [Mon, 4 May 2026 14:45:20 +0000 (16:45 +0200)]
ALSA: usb-audio: add clock quirk for Motu 1248
The Motu 1248 (and probably other older Motu AVB interfaces) take more
than 2 seconds to switch clock. During the clock switching process the
device return that the clock is not valid. This is similar to what
already implemented for the Microbook II interface. Add the Motu
1248 usb id to the existing Motu quirk.
Cássio Gabriel [Mon, 4 May 2026 14:08:45 +0000 (11:08 -0300)]
ALSA: usb-audio: midi2: Restart output URBs on resume
USB MIDI 2.0 suspend saves the endpoint running state, clears it and
kills all endpoint URBs. Resume restores the running state, but only
restarts input endpoints.
For a running output endpoint, this leaves the endpoint marked running
with an empty URB queue. Output transfer progress depends on either the
rawmidi trigger path starting the queue or an output completion refilling
it. After suspend there is no completion left, and output data that
remains queued in the raw UMP or legacy rawmidi buffer can stay stalled
until userspace happens to trigger the stream again.
Restore the saved state with atomic accessors, keep input endpoints
restarted as before, and restart output endpoints that were running before
suspend. Clear the saved suspend state after restoring it.
ALSA: hda/realtek: Fix mute and mic-mute LEDs for HP Envy X360 15-fh0xxx
This enables the mute and mic-mute LEDs on the HP Envy X360 15-fh0xxx
2-in-1 laptops.
The quirk 'ALC245_FIXUP_HP_ENVY_X360_15_FH0XXX' has been created and
is now enabled for this device.
This is my first patch, and I'm still getting to grips with the code,
so there's probably a better way to implement this fix.
I apologize for any inconvenience caused by the constant release of
new versions of this patch.
Rong Zhang [Mon, 4 May 2026 11:38:05 +0000 (19:38 +0800)]
ALSA: usb-audio: Add quirk flags for JBL Pebbles
JBL Pebbles is a pair of desktop speakers with UAC interface. Its
Playback and Capture mixers use linear volume with val = 0/999/1 and
0/3996/4. Meanwhile, the reported sample rates are truncated to
multiples of 0x100 (i.e., 44100 => 44032), resulting in noisy kmsg, as a
warning message is printed each time a stream is opened.
Add a quirk table entry matching VID/PID=0x05fc/0x0231 and applying
linear volume and sample rate quirk flags, so that it can work properly.
Also note that the volume control knob on device is an incremental
encoder. It does nothing but sends KEY_VOLUMEUP and KEY_VOLUMEDOWN per
rotation, controlling the UAC Playback volume mixer indirectly. Hence,
the linear volume quirk flags also enable the volume control knob to
function properly.
Quirky device sample:
usb 5-1.1: new full-speed USB device number 12 using xhci_hcd
usb 5-1.1: New USB device found, idVendor=05fc, idProduct=0231, bcdDevice= 1.00
usb 5-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 5-1.1: Product: JBL Pebbles
usb 5-1.1: Manufacturer: Harman International Industries
usb 5-1.1: SerialNumber: 1.0.0
usb-storage 5-1.1:1.0: USB Mass Storage device detected
scsi host0: usb-storage 5-1.1:1.0
usb 5-1.1: Found last interface = 1
usb 5-1.1: 2:1: add audio endpoint 0x5
usb 5-1.1: Creating new data endpoint #5
usb 5-1.1: 2:1 Set sample rate 44100, clock 0
usb 5-1.1: current rate 44032 is different from the runtime rate 44100
usb 5-1.1: 3:1: add audio endpoint 0x84
usb 5-1.1: Creating new data endpoint #84
usb 5-1.1: 3:1 Set sample rate 44100, clock 0
usb 5-1.1: current rate 44032 is different from the runtime rate 44100
usb 5-1.1: [2] FU [PCM Playback Switch] ch = 1, val = 0/1/1
usb 5-1.1: Warning! Unlikely big volume step count (=999), linear volume or wrong cval->res?
usb 5-1.1: [2] FU [PCM Playback Volume] ch = 2, val = 0/999/1
usb 5-1.1: [5] FU [Mic Capture Switch] ch = 1, val = 0/1/1
usb 5-1.1: Warning! Unlikely big volume step count (=999), linear volume or wrong cval->res?
usb 5-1.1: [5] FU [Mic Capture Volume] ch = 2, val = 0/3996/4
input: Harman International Industries JBL Pebbles as /devices/pci0000:00/0000:00:08.3/0000:67:00.3/usb5/5-1/5-1.1/5-1.1:1.4/0003:05FC:0231.0018/input/input55
hid-generic 0003:05FC:0231.0018: input,hidraw2: USB HID v2.01 Device [Harman International Industries JBL Pebbles] on usb-0000:67:00.3-1.1/input4
Cássio Gabriel [Mon, 4 May 2026 00:55:52 +0000 (21:55 -0300)]
ALSA: firewire-tascam: Do not drop unread control events
tscm_hwdep_read_queue() copies as many queued control events as fit in
the userspace buffer. When the buffer is smaller than the current
contiguous queue segment, length is rounded down to the number of bytes
that can be copied.
However, after copying that shortened length, the code advances pull_pos
to the original tail_pos, marking the whole contiguous segment as
consumed. Any events between the copied portion and tail_pos are lost.
Limit tail_pos to the position after the entries actually copied before
updating pull_pos. When the whole segment fits, this is equivalent to the
old tail_pos update; when the buffer is smaller, the remaining events
stay queued for the next read.
Fixes: a8c0d13267a4 ("ALSA: firewire-tascam: notify events of change of state for userspace applications") Cc: stable@vger.kernel.org Suggested-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com> Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Co-developed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260503-alsa-firewire-tascam-read-queue-v2-1-126c6efd7642@gmail.com
Anton Swart [Sun, 3 May 2026 21:15:17 +0000 (23:15 +0200)]
ALSA: usb-audio: Add quirk flags for AlphaTheta EUPHONIA
The AlphaTheta EUPHONIA (VID 0x2b73, PID 0x0047) is a USB Audio
Class 2 DJ mixer that requires implicit feedback for full-duplex
operation. The capture endpoint (0x83 IN, interface 2) acts as the
implicit feedback source for the playback endpoint (0x03 OUT,
interface 1), and the device firmware does not send isochronous
data on the capture endpoint unless the host is simultaneously
sending data on the playback endpoint, i.e. playback must be
started first.
Without QUIRK_FLAG_PLAYBACK_FIRST the kernel waits for capture URBs
before submitting playback URBs, creating a deadlock: the device
waits for playback data and the host waits for capture data.
Without QUIRK_FLAG_GENERIC_IMPLICIT_FB the kernel does not detect
the implicit feedback relationship between the two interfaces.
The same flag combination is already used for the Behringer UMC202HD,
UMC204HD and UMC404HD (0x1397:0x0507/0x0508/0x0509), which exhibit
the identical implicit-feedback topology.
Tested on Raspberry Pi 5 with kernel 6.12.75; continuous full-duplex
streaming at 96 kHz / 24-bit, zero XRUNs.
drm/bridge: tda998x: Return NULL instead of 0 in tda998x_edid_read()
tda998x_edid_read() returns a const struct drm_edid pointer, but when
tda998x_edid_delay_wait() fails (process killed while waiting for the
HPD timeout), the integer literal 0 is returned instead of NULL,
triggering a sparse warning: "Using plain integer as NULL pointer"
Replace 0 with NULL to fix the sparse warning.
Fixes: c76a8be4feec ("drm/bridge: tda998x: Add support for DRM_BRIDGE_ATTACH_NO_CONNECTOR") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202604172257.Imo6GOH9-lkp@intel.com/ Signed-off-by: Kory Maincent (TI) <kory.maincent@bootlin.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://patch.msgid.link/20260417155446.1068893-1-kory.maincent@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
drm/bridge: tda998x: Use __be32 for audio port OF property pointer
of_get_property() returns a pointer to big-endian (__be32) data, but
port_data in tda998x_get_audio_ports() was declared as const u32 *,
causing a sparse endianness type mismatch warning. Fix the declaration
to use const __be32 *.
Fixes: 7e567624dc5a4 ("drm/i2c: tda998x: Register ASoC hdmi-codec and add audio DT binding") Cc: stable@vger.kernel.org Signed-off-by: Kory Maincent (TI) <kory.maincent@bootlin.com> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/20260428090457.121894-1-kory.maincent@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Vincent reports:
> The ath5k driver seems to do an array-index-out-of-bounds access as
> shown by the UBSAN kernel message:
> UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath5k/base.c:1741:20
> index 4 is out of range for type 'ieee80211_tx_rate [4]'
> ...
> Call Trace:
> <TASK>
> dump_stack_lvl+0x5d/0x80
> ubsan_epilogue+0x5/0x2b
> __ubsan_handle_out_of_bounds.cold+0x46/0x4b
> ath5k_tasklet_tx+0x4e0/0x560 [ath5k]
> tasklet_action_common+0xb5/0x1c0
It is real. 'ts->ts_final_idx' can be 3 on 5212, so:
info->status.rates[ts->ts_final_idx + 1].idx = -1;
with the array defined as:
struct ieee80211_tx_rate rates[IEEE80211_TX_MAX_RATES];
while the size is:
#define IEEE80211_TX_MAX_RATES 4
is indeed bogus.
Set this 'idx = -1' sentinel only if the array index is less than the
array size. As mac80211 will not look at rates beyond the size
(IEEE80211_TX_MAX_RATES).
Note: The effect of the OOB write is negligible. It just overwrites the
next member of info->status, i.e. ack_signal.
ath12k_dp_rx_deliver_msdu() currently uses hal_rx_desc_data::peer_id
parsed from mpdu_start descriptor to do peer lookup. However In an A-MSDU
aggregation scenario, hardware only populates mpdu_start descriptor for
the first sub-msdu, but not the following ones. In that case peer_id could
be invalid, leading to peer lookup failure:
ath12k_wifi7_pci 0000:06:00.0: rx skb 00000000c391c041 len 1532 peer (null) 0 ucast sn 0 eht320 rate_idx 12 vht_nss 2 freq 6105 band 3 flag 0x40d1a fcs-err 0 mic-err 0 amsdu-more 0
As a result pubsta is NULL and parts of ieee80211_rx_status structure are
left uninitialized, which may cause unexpected behavior.
Fix it by switching the normal RX path to use ath12k_skb_rxcb::peer_id
which is parsed from REO ring's rx_mpdu_desc and is always valid.
hal_rx_desc_data::peer_id is still used in
ath12k_wifi7_dp_rx_frag_h_mpdu(), which is safe since A-MSDU
aggregation does not occur for fragmented frames. Similarly,
ath12k_skb_rxcb::peer_id may be overwritten by hal_rx_desc_data::peer_id
in ath12k_wifi7_dp_rx_h_mpdu(), which only handles non-aggregated
multicast/broadcast traffic.
wifi: ath12k: initialize RSSI dBm conversion event state
Currently, the RSSI dBm conversion event handler leaves struct
ath12k_wmi_rssi_dbm_conv_info_arg uninitialized on the stack before
calling the TLV parser. If one of the optional sub-TLVs is absent, the
corresponding *_present flag retains stack garbage and later gets read
in ath12k_wmi_update_rssi_offsets(). With UBSAN enabled this triggers an
invalid-load report for _Bool:
UBSAN: invalid-load in drivers/net/wireless/ath/ath12k/wmi.c:9682:15
load of value 9 is not a valid value for type '_Bool'
Call Trace:
ath12k_wmi_rssi_dbm_conversion_params_info_event.cold+0x72/0x85 [ath12k]
ath12k_wmi_op_rx+0x1871/0x2ab0 [ath12k]
ath12k_htc_rx_completion_handler+0x44b/0x810 [ath12k]
ath12k_ce_recv_process_cb+0x554/0x9f0 [ath12k]
ath12k_ce_per_engine_service+0xbe/0xf0 [ath12k]
ath12k_pci_ce_workqueue+0x69/0x120 [ath12k]
Initialize the parsed event state to zero before passing it to the TLV
parser so missing sub-TLVs correctly leave the presence flags false.
Nicolas Escande [Wed, 22 Apr 2026 16:32:58 +0000 (18:32 +0200)]
wifi: ath12k: fix leak in some ath12k_wmi_xxx() functions
Some wmi functions were using plain 'return ath12k_wmi_cmd_send(...)'
without explicitly handling the error code. This leads to leaking the skb
in case of error.
David Carlier [Thu, 23 Apr 2026 12:56:48 +0000 (13:56 +0100)]
mm/memfd_luo: document preservation of file seals
Commit 8a552d68a86e ("mm: memfd_luo: preserve file seals") started
preserving file seals across live update and restoring them via
memfd_add_seals() on retrieve, but the DOC header was not updated and
still listed seals under "Non-Preserved Properties" as being unsealed
on restore.
Move the Seals entry to the "Preserved Properties" section and describe
the actual behavior, including the MEMFD_LUO_ALL_SEALS restriction that
both preserve and retrieve enforce.
memfd_luo_preserve_folios() declares max_folios as unsigned int and
computes it from the inode size, then passes it to memfd_pin_folios()
which itself caps max_folios at unsigned int. For files whose base-page
count exceeds UINT_MAX (larger than 16 TiB with 4 KiB pages), the
assignment truncates silently: only a prefix of the file gets pinned and
preserved, while memfd_luo_preserve() still records the full inode size
in ser->size. On retrieve the inode is restored to the full size but
only the preserved prefix repopulates the page cache, so the tail comes
back as holes and user data is silently lost across the live update.
Reject such files at preserve time with -EFBIG rather than chunk the
pin loop, which would also require enlarging the preserved folios array
well beyond what is practical.
Mark Brown [Mon, 4 May 2026 13:23:04 +0000 (22:23 +0900)]
spi: microchip core-qspi gpio-cs fixes + cleanup
Conor Dooley <conor@kernel.org> says:
v3 with the review comment about the core handing CS_HIGH dealt with.
I noticed that in the same function there was a "raw" BIT(1), which I
replaced with a macro that the patch was already adding for use in the
setup function...
spi: microchip-core-qspi: remove some inline markings
Remove inline markings from a number of functions that are called as
part of mem ops callbacks. None of them are either particularly trivial
or sensitive to overhead of a function call. Just let the compiler
decide what to do with them.
spi: microchip-core-qspi: don't attempt to transmit during emulated read-only dual/quad operations
The core will deal with reads by creating clock cycles itself, there's
no need to generate clock cycles by transmitting garbage data at the
driver level. Further, transmitting garbage data just bricks the transfer
since QSPI doesn't have a dedicated master-out line like MOSI in regular
SPI. I'm not entirely sure if the transfer is bricked because of the
garbage data being transmitted on the bus or because the core loses
track of whether it is supposed to be sending or receiving data.
Fixes: 8f9cf02c88528 ("spi: microchip-core-qspi: Add regular transfers") CC: stable@vger.kernel.org Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/20260430-freezing-saloon-95b1f3d9dad0@spud Signed-off-by: Mark Brown <broonie@kernel.org>
spi: microchip-core-qspi: control built-in cs manually
The coreQSPI IP supports only a single chip select, which is
automagically operated by the hardware - set low when the transmit
buffer first gets written to and set high when the number of bytes
written to the TOTALBYTES field of the FRAMES register have been sent on
the bus. Additional devices must use GPIOs for their chip selects.
It was reported to me that if there are two devices attached to this
QSPI controller that the in-built chip select is set low while linux
tries to access the device attached to the GPIO.
This went undetected as the boards that connected multiple devices to
the SPI controller all exclusively used GPIOs for chip selects, not
relying on the built-in chip select at all. It turns out that this was
because the built-in chip select, when controlled automagically, is set
low when active and high when inactive, thereby ruling out its use for
active-high devices or devices that need to transmit with the chip
select disabled.
Modify the driver so that it controls chip select directly, retaining
the behaviour for mem_ops of setting the chip select active for the
entire duration of the transfer in the exec_op callback. For regular
transfers, implement the set_cs callback for the core to use.
As part of this, the existing setup callback, mchp_coreqspi_setup_op(),
is removed. Modifying the CLKIDLE field is not safe to do during
operation when there are multiple devices, so this code is removed
entirely. Setting the MASTER and ENABLE fields is something that can be
done once at probe, it doesn't need to be re-run for each device.
Instead the new setup callback sets the built-in chip select to its
inactive state for active-low devices, as the reset value of the chip
select in software controlled mode is low.
Fixes: 8f9cf02c88528 ("spi: microchip-core-qspi: Add regular transfers") Fixes: 8596124c4c1bc ("spi: microchip-core-qspi: Add support for microchip fpga qspi controllers") CC: stable@vger.kernel.org Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/20260430-hamstring-busload-f941d0347b5e@spud Signed-off-by: Mark Brown <broonie@kernel.org>
Mark Brown [Mon, 4 May 2026 13:22:18 +0000 (22:22 +0900)]
spi: imx: Three fixes for the i.MX SPI driver
John Madieu <john.madieu@gmail.com> says:
This series independent fixes found in the i.MX SPI driver.
These are:
1/3 fixes a precedence bug in spi_imx_dma_max_wml_find() that makes
the watermark-finding logic effectively dead code. The function
currently always returns wml = 1 because of how the !-operator
binds to the modulo expression.
2/3 fixes a missing return on the package-1 failure path in
spi_imx_dma_data_prepare(). The error path frees the
dma_data array and the package-0 buffers, then falls through
to "return 0" - the caller proceeds with a freed pointer.
3/3 makes spi_imx_setupxfer() propagate the prepare_transfer()
return value. Currently a -EINVAL from mx51_ecspi_prepare_transfer
(e.g. on a word_delay overflow) is silently swallowed and the
transfer proceeds with a partially-configured controller.
mx51_ecspi_prepare_transfer() can return -EINVAL when the requested
word_delay does not fit in MX51_ECSPI_PERIOD_MASK. The error is
detected after a partial set of register writes (CTRL: BL, clkdiv,
SMC), so the controller is left in a partially-configured state and
the transfer is then submitted as if setup succeeded.
Propagate the return value. The other variants' prepare_transfer
callbacks all return 0, so this is a no-op for them.
John Madieu [Fri, 1 May 2026 13:59:50 +0000 (13:59 +0000)]
spi: imx: Fix UAF on package-1 prepare failure in spi_imx_dma_data_prepare()
When transfer->len exceeds MX51_ECSPI_CTRL_MAX_BURST and is not a
multiple of it, spi_imx_dma_data_prepare() splits the transfer into
two DMA packages. If preparing the second package fails:
ret = spi_imx_dma_tx_data_handle(spi_imx, &spi_imx->dma_data[1],
transfer->tx_buf + spi_imx->dma_data[0].data_len,
false);
if (ret) {
kfree(spi_imx->dma_data[0].dma_tx_buf);
kfree(spi_imx->dma_data[0].dma_rx_buf);
kfree(spi_imx->dma_data);
}
}
return 0;
the function frees the package-0 buffers and the dma_data array,
then falls through to `return 0`, telling the caller the prepare
succeeded. The caller then dereferences the freed dma_data array,
producing a use-after-free.
Return the error from the failure path so the caller takes its
existing failure branch.
Fixes: faa8e404ad8e ("spi: imx: support dynamic burst length for ECSPI DMA mode") Signed-off-by: John Madieu <john.madieu@gmail.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260501135951.2416527-3-john.madieu@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
John Madieu [Fri, 1 May 2026 13:59:49 +0000 (13:59 +0000)]
spi: imx: Fix precedence bug in spi_imx_dma_max_wml_find()
The watermark search in spi_imx_dma_max_wml_find() reads:
if (!dma_data->dma_len % (i * bytes_per_word))
break;
The unary ! binds tighter than %, so this parses as:
if ((!dma_data->dma_len) % (i * bytes_per_word))
break;
!dma_data->dma_len is 0 or 1, and `0 % x == 0` for any x; `1 % x` is
0 unless x == 1. The condition is therefore false in every case
except dma_len != 0 with i * bytes_per_word == 1, i.e. i == 1 and
bytes_per_word == 1.
The loop almost always falls through to its end, leaving i == 0,
which the post-loop fallback rewrites to 1:
if (i == 0)
i = 1;
So spi_imx->wml ends up at 1 for essentially every DMA transfer,
defeating the entire purpose of the function. The DMA engine then
requests service after every single FIFO word instead of using
multi-word bursts, hurting throughput on every DMA-capable variant.
Add the missing parentheses so the modulo is computed first, then
negated:
if (!(dma_data->dma_len % (i * bytes_per_word)))
break;
Fixes: faa8e404ad8e ("spi: imx: support dynamic burst length for ECSPI DMA mode") Signed-off-by: John Madieu <john.madieu@gmail.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260501135951.2416527-2-john.madieu@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
Cássio Gabriel [Tue, 28 Apr 2026 03:07:08 +0000 (00:07 -0300)]
ASoC: fsl_xcvr: Fix event generation for cached controls
ALSA controls should return 1 from a put callback when the control
value changes. fsl_xcvr_capds_put() and fsl_xcvr_tx_cs_put() both
update cached control data but always return 0, so ALSA suppresses
change notifications for the Capabilities Data Structure and playback
IEC958 channel status controls.
Compare the old and new cached values before copying the new data,
and return whether the control value changed.
ASoC: cs35l56: Fix out-of-bounds in dev_err() in cs35l56_read_onchip_spkid()
Remove the incorrect use of onchip_spkid_gpios[i] in the dev_err() after
regmap_read() of CS35L56_GPIO_STATUS1 returns an error.
This dev_err() was incorrectly copy-pasted from one inside the for-loop,
where i was valid. The read of CS35L56_GPIO_STATUS1 isn't for a specific
GPIO register, so the use of onchip_spkid_gpios[i] in the error message is
both irrelevant and out-of-bounds here.
ASoC: cs35l56: Fix hibernate write in runtime resume error path
The error path of cs35l56_runtime_resume_common() should only write
the hibernation sequence if can_hibernate is true.
Something has already gone badly wrong if we ever reach the error
path. But triggering hibernate on hardware that does not support it
is likely to make the situation unrecoverable without a full reboot
because there might not be any hardware signal to exit hibernate.
ASoC: spacemit: fix RX DMA params not set when TX is running
When TX is already running (SSCR_SSE is set), the hw_params callback
returns early before setting up DMA parameters for the RX stream. This
prevents the capture path from configuring its DMA data properly.
Move the SSCR_SSE check after DMA parameter setup and format
constraints, so both TX and RX streams get their DMA configuration
regardless of whether the hardware is already enabled. The early return
now only skips the register writes that would disrupt an active stream.
Bruce Johnston [Tue, 28 Apr 2026 18:39:31 +0000 (14:39 -0400)]
dm vdo: use GFP_NOIO for blkdev_issue_zeroout on format path
GFP_NOWAIT is inappropriate when blkdev_issue_zeroout may sleep and
bio_alloc can fail under pressure; use GFP_NOIO for clear_partition and
vdo_clear_layout zeroout calls.
Signed-off-by: Bruce Johnston <bjohnsto@redhat.com> Signed-off-by: Matthew Sakai <msakai@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Fixes: fc1d43826702 ("dm vdo: save the formatted metadata to disk")
Francesco Lavra [Tue, 10 Feb 2026 17:35:45 +0000 (18:35 +0100)]
drm/fb-helper: Fix clipping when damage area spans a single scanline
When the damage area resulting from a dirty memory range spans a single
scanline, the width of the rectangle is calculated dynamically because it
may not coincide with the framebuffer width.
If the dirty range ends exactly at the end of the scanline, the `bit_end`
variable is incorrectly assigned a 0 value, which results in a bogus clip
rectangle where the x2 coordinate is 0. This prevents the dirty scanline
from being flushed to the hardware.
Change the calculation of the `bit_end` value to fix the x2 coordinate
value in the above edge case.
Fixes: ded74cafeea9 ("drm/fb-helper: Clip damage area horizontally") Signed-off-by: Francesco Lavra <flavra@baylibre.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260210173545.733937-1-flavra@baylibre.com
Myeonghun Pak [Fri, 24 Apr 2026 11:25:18 +0000 (20:25 +0900)]
drm/qxl: Fix missing KMS poll cleanup
drm_kms_helper_poll_init() initializes the output polling work and
enables polling for the DRM device. qxl enables polling before calling
drm_dev_register(), but the drm_dev_register() failure path tears down
the modeset and device state without disabling the polling helper.
The remove path also unregisters and shuts down the DRM device without
first disabling the polling helper. Add matching drm_kms_helper_poll_fini()
calls in both paths so the delayed polling work is cancelled before qxl
tears down the associated modeset/device state.
Signed-off-by: Myeonghun Pak <mhun512@gmail.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 5ff91e442652 ("qxl: use drm helper hotplug support") Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260424112543.57819-1-mhun512@gmail.com
anc_configure() passed values from drvdata->anc_fir_values[],
drvdata->anc_iir_values[] and drvdata->sid_fir_values[] as register
offset to snd_soc_component_read(). The content of these arrays are user
controllable via the component controls "ANC FIR Coefficients", "ANC
IIR Coefficients" and "Sidetone FIR Coefficients" which I assume are
supposed to hold register values, not register offsets.
Without a datasheet for that component and given that before commit a201aef1a88b ("ASoC: codecs: ab8500: Fix casting of private data") the
arrays overlapped with driver control structures and thus didn't work
properly since 2012, drop that functionality and let someone repair it
who has an actual need for it.
With the core functionally removed several code parts become essentially
unused and are removed, too.
Cássio Gabriel [Fri, 1 May 2026 17:45:14 +0000 (14:45 -0300)]
ALSA: pcmtest: Return -EFAULT on pattern read copy failure
pattern_write() reports -EFAULT when copy_from_user() fails, but
pattern_read() converts copy_to_user() failures into a zero-length read.
That makes a userspace buffer fault look like EOF instead of reporting the
actual error.
Return -EFAULT from pattern_read() when copying the pattern data to
userspace fails, and update the file offset only after a successful copy.
Weiming Shi [Tue, 14 Apr 2026 17:23:39 +0000 (01:23 +0800)]
i2c: stub: Reject I2C block transfers with invalid length
The I2C_SMBUS_I2C_BLOCK_DATA case in stub_xfer() uses data->block[0]
as the transfer length. The existing check only clamps it to avoid
overrunning the chip->words[256] register array, but does not validate
it against I2C_SMBUS_BLOCK_MAX (32), which is the limit of the union
i2c_smbus_data.block buffer (34 bytes total). The driver is a
development/test tool (CONFIG_I2C_STUB=m, not built by default)
that must be loaded with a chip_addr= parameter.
A local user with access to /dev/i2c-* can issue an I2C_SMBUS ioctl
with I2C_SMBUS_I2C_BLOCK_DATA and data->block[0] > 32, causing
stub_xfer() to read or write past the end of the union
i2c_smbus_data.block buffer:
BUG: KASAN: stack-out-of-bounds in stub_xfer (drivers/i2c/i2c-stub.c:223)
Read of size 1 at addr ffff88800abcfd92 by task exploit/81
Call Trace:
<TASK>
stub_xfer (drivers/i2c/i2c-stub.c:223)
__i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:593)
i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:536)
i2cdev_ioctl_smbus (drivers/i2c/i2c-dev.c:391)
i2cdev_ioctl (drivers/i2c/i2c-dev.c:478)
__x64_sys_ioctl (fs/ioctl.c:583)
do_syscall_64 (arch/x86/entry/syscall_64.c:94)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
</TASK>
The bug exists because i2c-stub implements .smbus_xfer directly,
bypassing the I2C_SMBUS_BLOCK_MAX validation in
i2c_smbus_xfer_emulated(). The I2C_SMBUS_BLOCK_DATA case in the same
function correctly validates against I2C_SMBUS_BLOCK_MAX, but the
I2C_SMBUS_I2C_BLOCK_DATA case does not.
Fix by rejecting transfers with data->block[0] == 0 or
data->block[0] > I2C_SMBUS_BLOCK_MAX with -EINVAL, consistent with
both the I2C_SMBUS_BLOCK_DATA case in the same function and the
I2C_SMBUS_I2C_BLOCK_DATA validation in i2c_smbus_xfer_emulated().
Fixes: 4710317891e4 ("i2c-stub: Implement I2C block support") Reported-by: Xiang Mei <xmei5@asu.edu> Signed-off-by: Weiming Shi <bestswngs@gmail.com> Reviewed-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Ivan Hu [Thu, 30 Apr 2026 07:41:07 +0000 (15:41 +0800)]
x86/efi: Fix graceful fault handling after FPU softirq changes
Since commit d02198550423 ("x86/fpu: Improve crypto performance by
making kernel-mode FPU reliably usable in softirqs"), kernel_fpu_begin()
calls fpregs_lock() which uses local_bh_disable() instead of the
previous preempt_disable(). This sets SOFTIRQ_OFFSET in preempt_count
during the entire EFI runtime service call, causing in_interrupt() to
return true in normal task context.
The graceful page fault handler efi_crash_gracefully_on_page_fault()
uses in_interrupt() to bail out for faults in real interrupt context.
With SOFTIRQ_OFFSET now set, the handler always bails out, leaving EFI
firmware page faults unhandled. This escalates to die() which also sees
in_interrupt() as true and calls panic("Fatal exception in interrupt"),
resulting in a hard system freeze. On systems with buggy firmware that
triggers page faults during EFI runtime calls (e.g., accessing unmapped
memory in GetTime()), this causes an unrecoverable hang instead of the
expected graceful EFI_ABORTED recovery.
Fix by replacing in_interrupt() with !in_task(). This preserves the
original intent of bailing for interrupts or NMI faults, while no longer
falsely triggering from the FPU code path's local_bh_disable().
Fixes: d02198550423 ("x86/fpu: Improve crypto performance by making kernel-mode FPU reliably usable in softirqs") Cc: <stable@vger.kernel.org> Signed-off-by: Ivan Hu <ivan.hu@canonical.com>
[ardb: Sashiko spotted that using 'in_hardirq() || in_nmi()' leaves a
window where a softirq may be taken before fpregs_lock() is
called, but after efi_rts_work.efi_rts_id has been assigned,
and any page faults occurring in that window will then be
misidentified as having been caused by the firmware. Instead,
use !in_task(), which incorporates in_serving_softirq(). ] Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Hongling Zeng [Sun, 3 May 2026 04:17:44 +0000 (12:17 +0800)]
parisc: Fix IRQ leak in LASI driver
When request_irq() succeeds but gsc_common_setup() fails later,
the IRQ is never released. Fix this by adding proper error handling
with goto labels to ensure resources are released in LIFO order.
Detected by Smatch:
drivers/parisc/lasi.c:216 lasi_init_chip() warn: 'lasi->gsc_irq.irq'
from request_irq() not released on lines: 207.
Mingyu Wang [Mon, 27 Apr 2026 02:57:45 +0000 (10:57 +0800)]
i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl
While fuzzing with Syzkaller, a persistent `schedule_timeout: wrong
timeout value` warning was observed, accompanied by SMBus controller
state machine corruption.
The I2C_TIMEOUT ioctl accepts a user-provided timeout in multiples of
10 ms. The user argument is checked against INT_MAX, but it is
subsequently multiplied by 10 before being passed to msecs_to_jiffies().
A malicious user can pass a large value (e.g., 429496729) that passes
the `arg > INT_MAX` check but overflows when multiplied by 10. This
results in a truncated 32-bit unsigned value that bypasses the
internal `(int)m < 0` check in `msecs_to_jiffies()`.
The truncated value is then assigned to `client->adapter->timeout`
(a signed 32-bit int), which is reinterpreted as a negative number.
When passed to wait_for_completion_timeout(), this negative value
undergoes sign extension to a 64-bit unsigned long, triggering the
`schedule_timeout` warning and causing premature returns. This leaves
the SMBus state machine in an unrecoverable state, constituting a
local Denial of Service (DoS).
Fix this by bounding the user argument to `INT_MAX / 10`.
Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn>
[wsa: move the comment as well] Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
i2c: acpi: Add ELAN0678 to i2c_acpi_force_100khz_device_ids
The ELAN0678 touchpad (04F3:3195) found in the Lenovo ThinkPad X13
exhibits excessive smoothing when the I2C bus runs at 400KHz, making
the touchpad feel sluggish when plugged into AC power. This is the
same issue previously fixed for ELAN06FA.
The device's ACPI table (Lenovo TP-R22) specifies 0x00061A80 (400KHz)
for the I2cSerialBusV2 descriptor. Forcing the bus to 100KHz eliminates
the sluggish behavior.
Signed-off-by: Niels Franke <nielsfranke@gmail.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
[wsa: kept the sorting] Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Rajat Gupta [Mon, 4 May 2026 03:51:10 +0000 (20:51 -0700)]
fbdev: udlfb: add vm_ops to dlfb_ops_mmap to prevent use-after-free
dlfb_ops_mmap() uses remap_pfn_range() to map vmalloc framebuffer pages
to userspace but sets no vm_ops on the VMA. This means the kernel cannot
track active mmaps. When dlfb_realloc_framebuffer() replaces the backing
buffer via FBIOPUT_VSCREENINFO, existing mmap PTEs are not invalidated.
On USB disconnect, dlfb_ops_destroy() calls vfree() on the old pages
while userspace PTEs still reference them, resulting in a use-after-free:
the process retains read/write access to freed kernel pages.
Add vm_operations_struct with open/close callbacks that maintain an
atomic mmap_count on struct dlfb_data. In dlfb_realloc_framebuffer(),
check mmap_count and return -EBUSY if the buffer is currently mapped,
preventing buffer replacement while userspace holds stale PTEs.
Tested with PoC using dummy_hcd + raw_gadget USB device emulation.
Janne Grunau [Fri, 20 Mar 2026 12:23:24 +0000 (13:23 +0100)]
dt-bindings: i2c: apple,i2c: Add t8122 compatible
The i2c block on the Apple silicon t8122 (M3) SoC is compatible with the
existing driver. Add "apple,t8122-i2c" as SoC specific compatible under
"apple,t8103-i2c" used by the deriver.
Signed-off-by: Janne Grunau <j@jannau.net> Acked-by: Andi Shyti <andi.shyti@kernel.org> Acked-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Wrap the conditional operation in parentheses to enforce the
correct evaluation order.
Fixes: 93eee2a49c1b ("iommu/amd: Refactor logic to program the host page table in DTE") Signed-off-by: Weinan Liu <wnliu@google.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Marek Vasut [Sat, 2 May 2026 15:31:54 +0000 (17:31 +0200)]
i2c: stm32f7: reinit_completion() per transfer not per msg
Currently, the driver may repeatedly call reinit_completion() during
transfer which contains multiple messages, while another thread is
waiting for the completion.
This happens during transfer with more than 1 message, invoked via
stm32f7_i2c_xfer_core() -> stm32f7_i2c_xfer_msg(). After invoking the
stm32f7_i2c_xfer_msg() to start transfer, stm32f7_i2c_xfer_core()
calls wait_for_completion_timeout() to wait for completion of the
transfer of all messages. When the first message transfer completes,
the hard IRQ handler triggers, and detects transfer completion, which
leads to stm32f7_i2c_isr_event_thread() IRQ thread being started. The
stm32f7_i2c_isr_event_thread() calls stm32f7_i2c_xfer_msg() in case
there are more messages.
Without this change, the second and later stm32f7_i2c_xfer_msg() would
call reinit_completion() on the completion which is still being waited
for in stm32f7_i2c_xfer_core(). Fix this by moving the reinit_completion()
into stm32f7_i2c_xfer_core(), together with wait_for_completion_timeout().
Since stm32f7_i2c_xfer_core() now waits for completion of the entire
transfer, increase the default timeout. This fixes sporadic transfer
timeouts on STM32MP25xx during kernel boot.
Fixes: aeb068c57214 ("i2c: i2c-stm32f7: add driver") Signed-off-by: Marek Vasut <marex@nabladev.com>
[wsa: reworded commit subject] Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Ronald Claveau [Fri, 24 Apr 2026 14:17:33 +0000 (16:17 +0200)]
dt-bindings: i2c: amlogic: Add compatible for T7 SOC
Add the T7 SOC compatible which fallback to AXG compatible.
Acked-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Marco Crivellari [Thu, 30 Apr 2026 09:08:10 +0000 (11:08 +0200)]
i2c: testunit: Replace system_long_wq with system_dfl_long_wq
Currently the code enqueue work items using {queue|mod}_delayed_work(),
using system_long_wq. This workqueue should be used when long works are
expected, but it is a per-cpu workqueue.
This is important because queue_delayed_work() queue the work using:
queue_delayed_work_on(WORK_CPU_UNBOUND, ...);
Note that WORK_CPU_UNBOUND = NR_CPUS.
This would end up calling __queue_delayed_work() that does:
if (housekeeping_enabled(HK_TYPE_TIMER)) {
// [....]
} else {
if (likely(cpu == WORK_CPU_UNBOUND))
add_timer_global(timer);
else
add_timer_on(timer, cpu);
}
So when cpu == WORK_CPU_UNBOUND the timer is global and is
not using a specific CPU. Later, when __queue_work() is called:
if (req_cpu == WORK_CPU_UNBOUND) {
if (wq->flags & WQ_UNBOUND)
cpu = wq_select_unbound_cpu(raw_smp_processor_id());
else
cpu = raw_smp_processor_id();
}
Because the wq is not unbound, it takes the CPU where the timer
fired and enqueue the work on that CPU.
The consequence of all of this is that the work can run anywhere,
depending on where the timer fired.
Recently, a new unbound workqueue specific for long running work has
been added:
c116737e972e ("workqueue: Add system_dfl_long_wq for long unbound works")
So change system_long_wq with system_dfl_long_wq so that the work may
benefit from scheduler task placement.
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
[wsa: remove FIXME as well] Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Revert commit d98c24617a83 ("wifi: cw1200: Fix locking in error paths")
because it introduces a locking bug instead of fixing a locking bug.
cw1200_wow_resume() unlocks priv->conf_mutex. Hence, adding
mutex_unlock(&priv->conf_mutex) just after cw1200_wow_resume() is wrong.
Reported-by: Ben Hutchings <ben@decadent.org.uk> Closes: https://lore.kernel.org/all/408661f69f263266b028713e1412ba36d457e63d.camel@decadent.org.uk/ Fixes: d98c24617a83 ("wifi: cw1200: Fix locking in error paths") Signed-off-by: Bart Van Assche <bvanassche@acm.org> Link: https://patch.msgid.link/20260430174418.1845431-1-bvanassche@acm.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Yufan Chen [Sun, 3 May 2026 17:57:10 +0000 (01:57 +0800)]
io_uring/eventfd: reset deferred signal state
Recursive eventfd wakeups must defer io_uring eventfd signaling because
eventfd_signal_mask() rejects reentry from eventfd wakeup handlers. The
io_ev_fd ops bit tracks an outstanding deferred signal so that the same
rcu_head is not queued twice.
That bit is only set today. Once the first deferred callback runs, later
recursive notifications still see the bit set and skip queueing another
deferred signal. This can leave new completions without a matching
eventfd wake after the first recursive deferral.
Clear the pending bit before issuing the deferred signal. If the wakeup
path recurses while the callback runs, a new signal can be queued for
the next RCU grace period while the current callback keeps its reference
until it returns.
Yufan Chen [Sun, 3 May 2026 17:56:10 +0000 (01:56 +0800)]
io_uring/napi: clear tracked NAPI entries on unregister
IORING_UNREGISTER_NAPI disables NAPI busy polling, but it currently
leaves any previously tracked NAPI IDs on the ring context. The normal
wait path only checks whether the list is empty before entering the busy
poll helper, so an unregistered ring can still observe stale entries and
run an unexpected busy poll pass.
Make unregister switch the context to inactive and free the tracked
entries. Do the same inactive transition while changing the tracking
strategy, and recheck the expected tracking mode under napi_lock before
inserting a newly learned NAPI ID. This prevents a racing poll path from
repopulating the list after unregister or reconfiguration.
Also make the busy poll dispatcher ignore inactive mode explicitly.
smb: client: use kzalloc to zero-initialize security descriptor buffer
Commit 62e7dd0a39c2d ("smb: common: change the data type of num_aces
to le16") split struct smb_acl's __le32 num_aces field into __le16
num_aces and __le16 reserved. The reserved field corresponds to Sbz2
in the MS-DTYP ACL wire format, which must be zero [1].
When building an ACL descriptor in build_sec_desc(), we are using a
kmalloc()'ed descriptor buffer and writing the fields explicitly using
le16() writes now. This never writes to the 2 byte reserved field,
leaving it as uninitialized heap data.
When the reserved field happens to contain non-zero slab garbage,
Samba rejects the security descriptor with "ndr_pull_security_descriptor
failed: Range Error", causing chmod to fail with EINVAL.
Change kmalloc() to kzalloc() to ensure the entire buffer is
zero-initialized.
Fixes: 62e7dd0a39c2d ("smb: common: change the data type of num_aces to le16") Cc: stable@vger.kernel.org Signed-off-by: Bjoern Doebel <doebel@amazon.de> Assisted-by: Kiro:claude-opus-4.6
[1] https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp/20233ed8-a6c6-4097-aafa-dd545ed24428 Signed-off-by: Steve French <stfrench@microsoft.com>
cifs: abort open_cached_dir if we don't request leases
It is possible that SMB2_open_init may not set lease context based
on the requested oplock level. This can happen when leases have been
temporarily or permanently disabled. When this happens, we will have
open_cached_dir making an open without lease context and the response
will anyway be rejected by open_cached_dir (thereby forcing a close to
discard this open). That's unnecessary two round-trips to the server.
This change adds a check before making the open request to the server
to make sure that SMB2_open_init did add the expected lease context
to the open in open_cached_dir.
Cc: <stable@vger.kernel.org> Reviewed-by: Bharath SM <bharathsm@microsoft.com> Signed-off-by: Shyam Prasad N <sprasad@microsoft.com> Signed-off-by: Steve French <stfrench@microsoft.com>
Bibo Mao [Mon, 4 May 2026 01:00:48 +0000 (09:00 +0800)]
LoongArch: KVM: Move unconditional delay into timer clear scenery
When timer interrupt arrives in guest kernel, guest kernel clears the
timer interrupt and program timer with the next incoming event.
During this stage, timer tick is -1 and timer interrupt status is
disabled in ESTAT register. KVM hypervisor need write zero with timer
tick register and wait timer interrupt injection from HW side, and
then clear timer interrupt.
So there is 2 cycle delay in KVM hypervisor to emulate such scenery,
and the delay is unnecessary if there is no need to clear the timer
interrupt.
Here move 2 cycle delay into timer clear scenery and add timer ESTAT
checking after delay, and set max timer expire value if timer interrupt
does not arrive still.
Cc: stable@vger.kernel.org Signed-off-by: Bibo Mao <maobibo@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Bibo Mao [Mon, 4 May 2026 01:00:48 +0000 (09:00 +0800)]
LoongArch: KVM: Fix HW timer interrupt lost when inject interrupt by software
With passthrough HW timer, timer interrupt is injected by HW. When
inject emulated CPU interrupt by software such SIP0/SIP1/IPI, HW timer
interrupt may be lost.
Here check whether there is timer tick value inversion before and after
injecting emulated CPU interrupt by software, timer enabling by reading
timer cfg register is skipped. If the timer tick value is detected with
changing, then timer should be enabled. And inject a timer interrupt by
software if there is.
Bibo Mao [Mon, 4 May 2026 01:00:48 +0000 (09:00 +0800)]
LoongArch: KVM: Move AVEC interrupt injection into switch loop
When AVEC interrupt controller is emulated in user space, AVEC interrupt
is injected by software like SIP0/SIP1/TI/IPI interrupts. Here also move
the AVEC interrupt injection in switch loop.
Cc: stable@vger.kernel.org Signed-off-by: Bibo Mao <maobibo@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Tao Cui [Mon, 4 May 2026 01:00:38 +0000 (09:00 +0800)]
LoongArch: KVM: Use kvm_set_pte() in kvm_flush_pte()
kvm_flush_pte() is the only caller that directly assigns *pte instead
of using the kvm_set_pte() wrapper. Use the wrapper for consistency with
the rest of the file.
No functional change intended.
Cc: stable@vger.kernel.org Reviewed-by: Bibo Mao <maobibo@loongson.cn> Signed-off-by: Tao Cui <cuitao@kylinos.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Tao Cui [Mon, 4 May 2026 01:00:38 +0000 (09:00 +0800)]
LoongArch: KVM: Fix missing EMULATE_FAIL in kvm_emu_mmio_read()
In the ldptr (0x24...0x27) opcode decoding path, the default case only
breaks out but without setting "ret" value to EMULATE_FAIL. This leaves
run->mmio.len uninitialized (stale from a previous MMIO operation) while
"ret" value remains EMULATE_DO_MMIO, causing the code to proceed with an
incorrect MMIO length.
Add "ret = EMULATE_FAIL" to match the other default branches in the same
function (e.g. the 0x28...0x2e and 0x38 cases).
Cc: stable@vger.kernel.org Reviewed-by: Bibo Mao <maobibo@loongson.cn> Signed-off-by: Tao Cui <cuitao@kylinos.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Xianglai Li [Mon, 4 May 2026 01:00:37 +0000 (09:00 +0800)]
LoongArch: KVM: Fix "unreliable stack" for kvm_exc_entry
Insert the appropriate UNWIND hint into the kvm_exc_entry assembly
function to guide the generation of correct ORC table entries, thereby
solving the timeout problem ("unreliable stack") while loading the
livepatch-sample module on a physical machine running virtual machines
with multiple vcpus.
Cc: stable@vger.kernel.org Signed-off-by: Xianglai Li <lixianglai@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Xianglai Li [Mon, 4 May 2026 01:00:37 +0000 (09:00 +0800)]
LoongArch: KVM: Compile switch.S directly into the kernel
If we directly compile the switch.S file into the kernel, the address of
the kvm_exc_entry function will definitely be within the DMW memory area.
Therefore, we will no longer need to perform a copy relocation of the
kvm_exc_entry.
So this patch compiles switch.S directly into the kernel, and then remove
the copy relocation execution logic for the kvm_exc_entry function.
Cc: stable@vger.kernel.org Signed-off-by: Xianglai Li <lixianglai@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Wentao Guan [Mon, 4 May 2026 01:00:20 +0000 (09:00 +0800)]
LoongArch: Fix potential ADE in loongson_gpu_fixup_dma_hang()
The switch case in loongson_gpu_fixup_dma_hang() may not DC2 or DC3, and
readl(crtc_reg) will access with random address, because the "device" is
from "base+PCI_DEVICE_ID", "base" is from "pdev->devfn+1". This is wrong
when my platform inserts a discrete GPU:
Huacai Chen [Mon, 4 May 2026 01:00:20 +0000 (09:00 +0800)]
LoongArch: Use per-root-bridge PCIH flag to skip mem resource fixup
When firmware enables 64-bit PCI host bridge support, some root bridges
already provide valid 64-bit mem resource windows through ACPI.
In this case, the LoongArch-specific mem resource high-bits fixup in
acpi_prepare_root_resources() should not be applied unconditionally.
Otherwise, the kernel may override the native resource layout derived
from firmware, and later BAR assignment can fail to place device BARs
into the intended 64-bit address space correctly.
Add a per-root-bridge ACPI flag, PCIH, and evaluate it from the current
root bridge device scope. When PCIH is set, skip the mem resource high-
bits fixup path and let the kernel use the firmware-provided resource
description directly. When PCIH is absent or cleared, keep the existing
behavior and continue filling the high address bits from the host bridge
address.
This makes the behavior per-root-bridge configurable and avoids breaking
valid 64-bit BAR space allocation on bridges whose 64-bit windows have
already been fully described by firmware.
Huacai Chen [Mon, 4 May 2026 01:00:01 +0000 (09:00 +0800)]
LoongArch: Fix SYM_SIGFUNC_START definition for 32BIT
The SYM_SIGFUNC_START definition should match sigcontext that the length
of GPRs are 8 bytes for both 32BIT and 64BIT. So replace SZREG with 8 to
fix it.
Huacai Chen [Mon, 4 May 2026 01:00:00 +0000 (09:00 +0800)]
LoongArch: Make CONFIG_64BIT as the default option
CONFIG_64BIT is the mandatory option before v7.0, but in v7.1-rc1 both
CONFIG_32BIT and CONFIG_64BIT are selectable and CONFIG_32BIT became the
default option. This breaks existing configurations, so explicitly make
CONFIG_64BIT as the default option to keep existing behavior.
Linus Torvalds [Sun, 3 May 2026 22:25:47 +0000 (15:25 -0700)]
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
Pull kvm fixes from Paolo Bonzini:
"Three bug fixes for x86:
- Check that nEPT/nNPT is enabled in slow flush hypercalls. If it is
not, the hypercalls can be processed as usual even while running a
nested guest
- Fix shadow paging use-after-free due to page tables changing
outside execution of the guest. A bug that is 16 years old and
stems from an imprecision in the very first KVM series
- Scan IRR whenever PID.ON is true, even if PIR is empty, which
avoids a somewhat rare WARN"
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
KVM: x86: Fix shadow paging use-after-free due to unexpected GFN
KVM: x86: Fix misleading variable names and add more comments for PIR=>IRR flow
KVM: x86: Do IRR scan in __kvm_apic_update_irr even if PIR is empty
KVM: x86: check for nEPT/nNPT in slow flush hypercalls
KVM: x86: Fix shadow paging use-after-free due to unexpected GFN
The shadow MMU computes GFNs for direct shadow pages using sp->gfn plus
the SPTE index. This assumption breaks for shadow paging if the guest
page tables are modified between VM entries (similar to commit aad885e77496, "KVM: x86/mmu: Drop/zap existing present SPTE even
when creating an MMIO SPTE", 2026-03-27). The flow is as follows:
- a PDE is installed for a 2MB mapping, and a page in that area is
accessed. KVM creates a kvm_mmu_page consisting of 512 4KB pages;
the kvm_mmu_page is marked by FNAME(fetch) as direct-mapped because
the guest's mapping is a huge page (and thus contiguous).
- the PDE mapping is changed from outside the guest.
- the guest accesses another page in the same 2MB area. KVM installs
a new leaf SPTE and rmap entry; the SPTE uses the "correct" GFN
(i.e. based on the new mapping, as changed in the previous step) but
that GFN is outside of the [sp->gfn, sp->gfn + 511] range; therefore
the rmap entry cannot be found and removed when the kvm_mmu_page
is zapped.
- the memslot that covers the first 2MB mapping is deleted, and the
kvm_mmu_page for the now-invalid GPA is zapped. However, rmap_remove()
only looks at the [sp->gfn, sp->gfn + 511] range established in step 1,
and fails to find the rmap entry that was recorded by step 3.
- any operation that causes an rmap walk for the same page accessed
by step 3 then walks a stale rmap and dereferences a freed kvm_mmu_page.
This includes dirty logging or MMU notifier invalidations (e.g., from
MADV_DONTNEED).
The underlying issue is that KVM's walking of shadow PTEs assumes that
if a SPTE is present when KVM wants to install a non-leaf SPTE, then the
existing kvm_mmu_page must be for the correct gfn. Because the only way
for the gfn to be wrong is if KVM messed up and failed to zap a SPTE...
which shouldn't happen, but *actually* only happens in response to a
guest write.
That bug dates back literally forever, as even the first version of KVM
assumes that the GFN matches and walks into the "wrong" shadow page.
However, that was only an imprecision until 2032a93d66fa ("KVM: MMU:
Don't allocate gfns page for direct mmu pages") came along.
Fix it by checking for a target gfn mismatch and zapping the existing
SPTE. That way the old SP and rmap entries are gone, KVM installs
the rmap in the right location, and everyone is happy.
Fixes: 2032a93d66fa ("KVM: MMU: Don't allocate gfns page for direct mmu pages") Fixes: 6aa8b732ca01 ("kvm: userspace interface") Reported-by: Alexander Bulekov <bkov@amazon.com> Reported-by: Fred Griffoul <fgriffo@amazon.co.uk> Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com> Link: https://patch.msgid.link/20260503201029.106481-1-pbonzini@redhat.com/ Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
KVM: x86: Fix misleading variable names and add more comments for PIR=>IRR flow
Rename kvm_apic_update_irr()'s "irr_updated" and vmx_sync_pir_to_irr()'s
"got_posted_interrupt" to a more accurate "max_irr_is_from_pir", as neither
"irr_updated" nor "got_posted_interrupt" is accurate.
__kvm_apic_update_irr() and thus kvm_apic_update_irr() specifically return
true if and only if the highest priority IRQ, i.e. max_irr, is a "new"
pending IRQ from the PIR. I.e. it's possible for the IRR to be updated,
i.e. for a posted IRQ to be "got", *without* the APIs returning true.
Expand vmx_sync_pir_to_irr()'s comment to explain why it's necessary to
set KVM_REQ_EVENT only if a "new" IRQ was found, and to explain why it's
safe to do so only if a new IRQ is also the highest priority pending IRQ.
Paolo Bonzini [Sun, 3 May 2026 17:19:32 +0000 (19:19 +0200)]
KVM: x86: Do IRR scan in __kvm_apic_update_irr even if PIR is empty
Fall back to apic_find_highest_vector() when PID.ON is set but PIR
turns out to be empty, to correctly report the highest pending interrupt
from the existing IRR.
In a nested VM stress test, the following WARNING fires in
vmx_check_nested_events() when kvm_cpu_has_interrupt() reports a pending
interrupt but the subsequent kvm_apic_has_interrupt() (which invokes
vmx_sync_pir_to_irr() again) returns -1:
The root cause is a race between vmx_sync_pir_to_irr() on the target vCPU
and __vmx_deliver_posted_interrupt() on a sender vCPU. The sender
performs two individually-atomic operations that are not a single
transaction:
1. pi_test_and_set_pir(vector) -- sets the PIR bit
2. pi_test_and_set_on() -- sets PID.ON
The following interleaving triggers the bug:
Sender vCPU (IPI): Target vCPU (1st sync_pir_to_irr):
B1: set PIR[vector]
A1: pi_clear_on()
A2: pi_harvest_pir() -> sees B1 bit
A3: xchg() -> consumes bit, PIR=0
(1st sync returns correct max_irr)
B2: set PID.ON = 1
Target vCPU (2nd sync_pir_to_irr):
C1: pi_test_on() -> TRUE (from B2)
C2: pi_clear_on() -> ON=0
C3: pi_harvest_pir() -> PIR empty
C4: *max_irr = -1, early return
IRR NOT SCANNED
The interrupt is not lost (it resides in the IRR from the first sync and
is recovered on the next vcpu_enter_guest() iteration), but the incorrect
max_irr causes a spurious WARNING and a wasted L2 VM-Enter/VM-Exit cycle.
Paolo Bonzini [Mon, 27 Apr 2026 12:25:40 +0000 (14:25 +0200)]
KVM: x86: check for nEPT/nNPT in slow flush hypercalls
Checking is_guest_mode(vcpu) is incorrect, because translate_nested_gpa()
is only valid if an L2 guest is running *with nested EPT/NPT enabled*.
Instead use the same condition as translate_nested_gpa() itself.
Cc: stable@vger.kernel.org Reviewed-by: Sean Christopherson <seanjc@google.com> Fixes: aee738236dca ("KVM: x86: Prepare kvm_hv_flush_tlb() to handle L2's GPAs", 2022-11-18) Link: https://patch.msgid.link/20260503200905.106077-1-pbonzini@redhat.com/ Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
For eDP low vdiff, the LDO setting depends on the PHY version rather
than being a simple 0x0 or 0x1 value. Introduce a PHY callback to program
the correct LDO setting according to the HPG.
Since SC7280/SC8180X uses different LDO settings from SA8775P/SC8280XP,
introduce qcom_edp_phy_ops_v3 to keep the LDO setting correct.
phy: qcom: edp: Fix AUX_CFG8 programming for DP mode
AUX_CFG8 depends on whether the PHY is operating in eDP or DP mode, not
the selected swing/pre-emphasis table. All supported platforms already
have the proper tables, so remove the unnecessary check.
SC7280 and SC8180X previously shared the same cfg because they did not use
swing/pre-emphasis tables. Add the corresponding tables for these
platforms. Since they have different PHY sub-versions, their eDP/DP mode
tables also differ, so move SC8180X to its own cfg instead of reusing the
SC7280 one.
The eDP PHY supports both eDP/DP modes, each requiring a different
swing/pre-emphasis table. However, the driver currently uses a fixed
static table for eDP programming rather than selecting the appropriate
table based on the current mode. Add separate tables for eDP and DP
modes, and select the appropriate table dynamically based on the
current mode.
Glymur's DP mode table differs from the other platforms, add a
dedicated table for it.
This also fixes the table mismatch for X1E80100 (eDP) and SA8775P (DP).
Cc: stable@vger.kernel.org Fixes: 3f12bf16213c ("phy: qcom: edp: Add support for eDP PHY on SA8775P") Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://patch.msgid.link/20260427-edp_phy-v5-2-3bb876824475@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
Linus Torvalds [Sun, 3 May 2026 15:58:42 +0000 (08:58 -0700)]
Merge tag 'sh-for-v7.1-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/glaubitz/sh-linux
Pull sh fix from John Paul Adrian Glaubitz:
"The ZERO_PAGE consolidation in v7.1, introduced a regression on sh
which made these systems unbootable.
The problem was that on sh, the initial boot parameters were
previously referenced as an array and after 6215d9f4470f ("arch, mm:
consolidate empty_zero_page"), they were referenced as a pointer which
caused wrong code generation and boot hang.
This changes the declaration back to being an array which fixes the
boot hang"
* tag 'sh-for-v7.1-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/glaubitz/sh-linux:
sh: Fix fallout from ZERO_PAGE consolidation
Linus Torvalds [Sun, 3 May 2026 15:19:57 +0000 (08:19 -0700)]
Merge tag 'slab-for-7.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vbabka/slab
Pull slab fixes from Vlastimil Babka:
- Stable fixes for CONFIG_SMP=n where _nolock() allocations in NMI both
at kmalloc and page allocator levels are not properly protected by
the spin_trylock() semantics on !SMP (Harry Yoo)
* tag 'slab-for-7.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vbabka/slab:
mm/slab: return NULL early from kmalloc_nolock() in NMI on UP
mm/page_alloc: return NULL early from alloc_frozen_pages_nolock() in NMI on UP
Linus Torvalds [Sun, 3 May 2026 15:17:09 +0000 (08:17 -0700)]
Merge tag 'locking-urgent-2026-05-03' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull locking fix from Ingo Molnar:
"Fix lockup in requeue-PI during signal/timeout wakeups, by Sebastian
Andrzej Siewior"
* tag 'locking-urgent-2026-05-03' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
futex: Prevent lockup in requeue-PI during signal/ timeout wakeup
Linus Torvalds [Sun, 3 May 2026 15:05:23 +0000 (08:05 -0700)]
Merge tag 'sched-urgent-2026-05-03' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull scheduler fixes from Ingo Molnar:
- Fix the delayed dequeue negative lag increase fix in the
fair scheduler (Peter Zijlstra)
- Fix wakeup_preempt_fair() to do proper delayed dequeue
(Vincent Guittot)
- Clear sched_entity::rel_deadline when initializing
forked entities, which bug can cause all tasks to be
EEVDF-ineligible, causing a NULL pointer dereference
crash in pick_next_entity() (Zicheng Qu)
* tag 'sched-urgent-2026-05-03' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
sched/fair: Clear rel_deadline when initializing forked entities
sched/fair: Fix wakeup_preempt_fair() vs delayed dequeue
sched/fair: Fix the negative lag increase fix
Consolidation of empty_zero_page declarations broke boot on sh.
sh stores its initial boot parameters in a page reserved in
arch/sh/kernel/head_32.S. Before commit 6215d9f4470f ("arch, mm:
consolidate empty_zero_page") this page was referenced in C code
as an array and after that commit it is referenced as a pointer.
This causes wrong code generation and boot hang.
Declare boot_params_page as an array to fix the issue.
Reported-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Tested-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Fixes: 6215d9f4470f ("arch, mm: consolidate empty_zero_page") Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Reviewed-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Artur Rojek <contact@artur-rojek.eu> Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Eliot Courtney [Fri, 1 May 2026 10:49:37 +0000 (19:49 +0900)]
rust: drm: fix unsound initialization in drm::Device::new
If pinned initialization of drm::Device::Data fails, it calls
drm::Device::release via drm_dev_put. This materializes a reference to
&drm::Device, but it's not fully constructed yet, because initializing
`data` failed. It should not be dropped either. Instead, if pinned
initialization fails, make sure drm::Device::release isn't called.
Fixes: 2e9fdbe5ec7a ("rust: drm: device: drop_in_place() the drm::Device in release()") Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260501-fix-drm-1-v2-1-5c4f681837bc@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Guangshuo Li [Mon, 13 Apr 2026 13:46:04 +0000 (21:46 +0800)]
counter: Fix refcount leak in counter_alloc() error path
After device_initialize(), the lifetime of the embedded struct device
is expected to be managed through the device core reference counting.
In counter_alloc(), if dev_set_name() fails after device_initialize(),
the error path removes the chrdev, frees the ID, and frees the backing
allocation directly instead of releasing the device reference with
put_device(). This bypasses the normal device lifetime rules and may
leave the reference count of the embedded struct device unbalanced,
resulting in a refcount leak.
The issue was identified by a static analysis tool I developed and
confirmed by manual review.
Fix this by using put_device() in the dev_set_name() failure path and
let counter_device_release() handle the final cleanup.
Jakub Kicinski [Wed, 29 Apr 2026 22:29:38 +0000 (15:29 -0700)]
net: tls: fix silent data drop under pipe back-pressure
tls_sw_splice_read() uses len when advancing rxm->offset / rxm->full_len
after skb_splice_bits(), rather than copied (the actual number of bytes
successfully spliced into the pipe). When the destination pipe cannot
accept all the requested bytes, splice_to_pipe() returns fewer bytes
than len, and 'len - copied' of data is effectively skipped over.
Jiexun Wang [Mon, 27 Apr 2026 06:43:34 +0000 (14:43 +0800)]
batman-adv: stop tp_meter sessions during mesh teardown
TP meter sessions remain linked on bat_priv->tp_list after the netlink
request has already finished. When the mesh interface is removed,
batadv_mesh_free() currently tears down the mesh without first draining
these sessions.
A running sender thread or a late incoming tp_meter packet can then keep
processing against a mesh instance which is already shutting down.
Synchronize tp_meter with the mesh lifetime by stopping all active
sessions from batadv_mesh_free() and waiting for sender threads to exit
before teardown continues.
Fixes: 33a3bb4a3345 ("batman-adv: throughput meter implementation") Cc: stable@kernel.org Reported-by: Yuan Tan <yuantan098@gmail.com> Reported-by: Yifan Wu <yifanwucs@gmail.com> Reported-by: Juefei Pu <tomapufckgml@gmail.com> Reported-by: Xin Liu <bird@lzu.edu.cn> Co-developed-by: Luxing Yin <tr0jan@lzu.edu.cn> Signed-off-by: Luxing Yin <tr0jan@lzu.edu.cn> Signed-off-by: Jiexun Wang <wangjiexun2025@gmail.com> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn> Signed-off-by: Sven Eckelmann <sven@narfation.org>
projects / thirdparty / linux.git / log
