* Linux 6.18
@ 2025-11-30 23:59 Linus Torvalds
2025-12-02 2:39 ` Guenter Roeck
0 siblings, 1 reply; 7+ messages in thread
From: Linus Torvalds @ 2025-11-30 23:59 UTC (permalink / raw)
To: Linux Kernel Mailing List
So I'll have to admit that I'd have been happier with slightly less
bugfixing noise in this last week of the release, but while there's a
few more fixes than I would hope for, there was nothing that made me
feel like this needs more time to cook. So 6.18 is tagged and pushed
out.
Most of the last-minute fixes are minor fixes to drivers, with some
random noise elsewhere (bluetooth, ceph, afs..). Nothing strikes me as
standing out, but hey, there's a shortlog appended if you want to see
the details.
And this obviously means that the merge window will open tomorrow, and
I already have three dozen pull requests pending. Thanks. And as I
already mentioned a couple of weeks ago in one of the rc release
notes, this upcoming release will have the merge window coincide with
the yearly kernel maintainer summit, which means that I'll be
traveling the second week. I hope to have all the bulk of the merge
window done before travels and that it won't be all that noticeable,
but we'll see.
So the actual rc1 release might be delayed by travel, but that will
*not* mean that I would accept late merge window pull requests. It
just means that I might not deal with on-time requests quite as timely
manner as is the norm, and maybe rc1 will be delayed by timezones and
a day or two. Just a heads-up (but I've done the "travel during the
second week of the merge window" thing before, and usually the impact
is fairly low).
And then later in the 6.19 release, we have the holiday season. That
typically delays the release by a week.
Now, when looking at the calendar, I'm not 100% sure an extra week
would be needed for 6.19, because even a regular release schedule
would make it be in February. And people will presumably have gotten
over their food coma by then. But right now my plan is to just make
6.19 go to rc8 just because I don't see much downside to adding that
extra week to make up for any possibly lost time.
Anyway, *today* the important kernel is the newly minted 6.18 release.
Please do keep testing,
Linus
---
Achim Gratz (1):
iio: pressure: bmp280: correct meas_time_us calculation
Alan Borzeszkowski (1):
thunderbolt: Add support for Intel Wildcat Lake
Alan Stern (1):
USB: storage: Remove subclass and protocol overrides from Novatek quirk
Alex Deucher (2):
Revert "drm/amd/display: Move setup_stream_attribute"
drm/amdgpu: fix cyan_skillfish2 gpu info fw handling
Alex Hung (1):
drm/amd/display: Check NULL before accessing
Alexander Stein (1):
MAINTAINERS: Add entry for TQ-Systems AM335 device trees
Alexander Usyskin (1):
mei: fix error flow in probe
Alexandra Winter (1):
s390/net: list Aswin Karuvally as maintainer
Alexey Kodanev (1):
net: sxgbe: fix potential NULL dereference in sxgbe_rx()
Ally Heev (1):
tee: qcomtee: fix uninitialized pointers with free attribute
Amirreza Zarrabi (1):
tee: qcomtee: initialize result before use in release worker
Andrei Vagin (1):
fs/namespace: fix reference leak in grab_requested_mnt_ns
Andy Shevchenko (1):
spi: nxp-fspi: Propagate fwnode in ACPI case as well
AngeloGioacchino Del Regno (1):
pmdomains: mtk-pm-domains: Fix spinlock recursion in probe
Anurag Dutta (2):
spi: spi-cadence-quadspi: Enable pm runtime earlier to avoid imbalance
spi: spi-cadence-quadspi: Remove duplicate
pm_runtime_put_autosuspend() call
Bastien Curutchet (Schneider Electric) (5):
net: dsa: microchip: common: Fix checks on irq_find_mapping()
net: dsa: microchip: ptp: Fix checks on irq_find_mapping()
net: dsa: microchip: Don't free uninitialized ksz_irq
net: dsa: microchip: Free previously initialized ports on init failures
net: dsa: microchip: Fix symetry in ksz_ptp_msg_irq_{setup/free}()
Beleswar Padhi (1):
mailbox: omap-mailbox: Check for pending msgs only when mbox is exclusive
Biju Das (1):
can: rcar_canfd: Fix CAN-FD mode as default
Carlos Llamas (1):
selftests/mm: fix division-by-zero in uffd-unit-tests
Carlos Song (1):
spi: spi-fsl-lpspi: fix watermark truncation caused by type cast
ChiYuan Huang (3):
iio: adc: rtq6056: Correct the sign bit index
regulator: rtq2208: Correct buck group2 phase mapping logic
regulator: rtq2208: Correct LDO2 logic judgment bits
Chris Lu (1):
Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk
iso interface
Christophe JAILLET (1):
iio:common:ssp_sensors: Fix an error handling path ssp_probe()
Claudiu Beznea (1):
usb: renesas_usbhs: Fix synchronous external abort on unbind
Dan Carpenter (2):
platform/x86: intel: punit_ipc: fix memory corruption
timekeeping: Fix error code in tk_aux_sysfs_init()
Daniel Golle (2):
net: phy: mxl-gpy: fix bogus error on USXGMII and integrated PHY
net: phy: mxl-gpy: fix link properties on USXGMII and internal PHYs
Danielle Costantino (1):
net/mlx5e: Fix validation logic in rate limiting
David Howells (2):
afs: Fix delayed allocation of a cell's anonymous key
afs: Fix uninit var in afs_alloc_anon_key()
David Lechner (3):
iio: adc: ad7380: fix SPI offload trigger rate
iio: adc: ad7280a: fix ad7280_store_balance_timer()
iio: adc: ad7124: fix temperature channel
Deepanshu Kartikey (2):
mm/memfd: fix information leak in hugetlb folios
tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs
Desnes Nunes (1):
usb: storage: Fix memory leak in USB bulk transport
Devarsh Thakkar (1):
drm/bridge: sii902x: Fix HDMI detection with
DRM_BRIDGE_ATTACH_NO_CONNECTOR
Dharma Balasubiramani (1):
counter: microchip-tcb-capture: Allow shared IRQ for multi-channel TCBs
Dimitri Fedrau (2):
iio: humditiy: hdc3020: fix units for temperature and humidity measurement
iio: humditiy: hdc3020: fix units for thresholds and hysteresis
Douglas Anderson (1):
Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref
Edward Adam Davis (1):
Bluetooth: hci_sock: Prevent race in socket write iter and sock bind
Eric Dumazet (1):
net: sched: fix TCF_LAYER_TRANSPORT handling in tcf_get_base_ptr()
Fernando Fernandez Mancera (1):
xsk: avoid data corruption on cq descriptor number
Francesco Lavra (2):
iio: imu: st_lsm6dsx: fix array size for st_lsm6dsx_settings fields
spi: tegra114: remove Kconfig dependency on TEGRA20_APB_DMA
Frank Li (2):
arm64: dts: imx8dxl: Correct pcie-ep interrupt number
arm64: dts: imx8dxl-ss-conn: swap interrupts number of eqos
Gui-Dong Han (1):
atm/fore200e: Fix possible data race in fore200e_open()
Gustavo A. R. Silva (2):
iommufd/driver: Fix counter initialization for counted_by annotation
iommufd/iommufd_private.h: Avoid -Wflex-array-member-not-at-end warning
Hang Zhou (1):
spi: bcm63xx: fix premature CS deassertion on RX-only transactions
Haotian Zhang (4):
ALSA: au88x0: Fix incorrect error handling for PCI config reads
spi: amlogic-spifc-a1: Handle devm_pm_runtime_enable() errors
usb: gadget: renesas_usbf: Handle devm_pm_runtime_enable() errors
mailbox: mailbox-test: Fix debugfs_create_dir error checking
Harish Chegondi (1):
drm/xe: Fix conversion from clock ticks to milliseconds
Heikki Krogerus (2):
usb: dwc3: pci: add support for the Intel Nova Lake -S
usb: dwc3: pci: Sort out the Intel device IDs
Heiner Kallweit (1):
r8169: fix RTL8127 hang on suspend/shutdown
Horatiu Vultur (1):
net: lan966x: Fix the initialization of taprio
Ilpo Järvinen (1):
serial: 8250: Fix 8250_rsa symbol loop
Ilya Dryomov (2):
libceph: fix potential use-after-free in have_mon_and_osd_map()
libceph: drop started parameter of __ceph_open_session()
Ilyas Gasanov (1):
ALSA: hda/realtek: Add quirk for HP ProBook 450 G8
Ivan Zhaldak (1):
ALSA: usb-audio: Add DSD quirk for LEAK Stereo 230
Jacob Zhong (1):
ALSA: hda/realtek: add quirk for HP pavilion aero laptop 13z-be200
Jameson Thies (1):
usb: typec: ucsi: psy: Set max current to zero when disconnected
Jamie Iles (2):
drivers/usb/dwc3: fix PCI parent check
mailbox: pcc: don't zero error register
Jason Wang (1):
vhost: rewind next_avail_head while discarding descriptors
Jason-JH Lin (1):
mailbox: mtk-cmdq: Refine DMA address handling for the command buffer
Jens Axboe (1):
io_uring/net: ensure vectored buffer node import is tied to notification
Jeremy Kerr (1):
net: mctp: unconditionally set skb->dev on dst output
Jesper Dangaard Brouer (1):
veth: reduce XDP no_direct return section to fix race
Jiefeng Zhang (1):
net: atlantic: fix fragment overflow handling in RX path
Jimmy Hu (1):
usb: gadget: udc: fix use-after-free in usb_gadget_state_work
Jisheng Zhang (1):
mmc: sdhci-of-dwcmshc: Promote the th1520 reset handling to ip level
Johan Hovold (3):
most: usb: fix double free on late probe failure
drm: sti: fix device leaks at component probe
mailbox: th1520: fix clock imbalance on probe failure
Jon Hunter (1):
pmdomain: tegra: Add GENPD_FLAG_NO_STAY_ON flag
Jon Kohler (2):
virtio-net: avoid unnecessary checksum calculation on guest RX
MAINTAINERS: separate VIRTIO NET DRIVER and add netdev
Jonathan Marek (1):
arm64: proton-pack: Fix hard lockup when !MITIGATE_SPECTRE_BRANCH_HISTORY
Kai-Heng Feng (1):
net: aquantia: Add missing descriptor cache invalidation on ATL2
Khairul Anuar Romli (1):
firmware: stratix10-svc: fix bug in saving controller data
Kiryl Shutsemau (1):
mm/filemap: fix logic around SIGBUS in filemap_map_pages()
Kuen-Han Tsai (1):
usb: gadget: f_eem: Fix memory leak in eem_unwrap
Kuniyuki Iwashima (1):
mptcp: Initialise rcv_mss before calling tcp_send_active_reset()
in mptcp_do_fastclose().
Li Chen (3):
dm-pcache: allow built-in build and rename flush helper
dm-pcache: reuse meta_addr in pcache_meta_find_latest
dm-pcache: zero cache_info before default init
Liam R. Howlett (1):
mm/mmap_lock: reset maple state on lock_vma_under_rcu() retry
Linus Torvalds (3):
Increase the default 32-bit build frame size warning limit to 1280 bytes
Fix Intel Dollar Cove TI battery driver 32-bit build error
Linux 6.18
Linus Walleij (1):
iio: accel: bmc150: Fix irq assumption regression
Lucas De Marchi (1):
drm/xe/guc: Fix stack_depot usage
Luiz Augusto von Dentz (2):
Bluetooth: hci_core: Fix triggering cmd_timer for HCI_OP_NOP
Bluetooth: SMP: Fix not generating mackey and ltk when repairing
Maarten Zanders (1):
ARM: dts: nxp: imx6ul: correct SAI3 interrupt line
Manish Nagar (1):
usb: dwc3: Fix race condition between concurrent
dwc3_remove_requests() call paths
Marc Kleine-Budde (4):
can: gs_usb: gs_usb_xmit_callback(): fix handling of failed
transmitted URBs
can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length
before accessing header
can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length
before accessing data
can: sun4i_can: sun4i_can_interrupt(): fix max irq loop handling
Marc Zyngier (1):
ACPI: GTDT: Correctly number platform devices for MMIO timers
Marcelo Schmitt (1):
iio: adc: ad4030: Fix _scale value for common-mode channels
Marek Szyprowski (1):
iommu/dma: add missing support for DMA_ATTR_MMIO for dma_iova_unlink()
Mario Limonciello (AMD) (2):
drm/amd/display: Don't change brightness for disabled connectors
drm/amd/display: Increase EDID read retries
Mario Tesi (1):
iio: st_lsm6dsx: Fixed calibrated timestamp calculation
Mathias Nyman (3):
xhci: fix stale flag preventig URBs after link state error is cleared
xhci: dbgtty: Fix data corruption when transmitting data form DbC to host
xhci: sideband: Fix race condition in sideband unregister
Matt Coster (1):
drm/imagination: Document pvr_device.power member
Miaoqian Lin (3):
serial: amba-pl011: prefer dma_mapping_error() over explicit
address checking
usb: cdns3: Fix double resource release in cdns3_pci_probe
slimbus: ngd: Fix reference count leak in qcom_slim_ngd_notify_slaves
Michael Chen (1):
drm/amd/amdgpu: reserve vm invalidation engine for uni_mes
Mikulas Patocka (2):
dm: fix failure when empty flush's bi_sector points beyond the device end
dm-verity: fix unreliable memory allocation
Mohsin Bashir (1):
eth: fbnic: Fix counter roll-over issue
NeilBrown (1):
ovl: fail ovl_lock_rename_workdir() if either target is unhashed
Nicolas Frattaroli (1):
mailbox: mtk-gpueb: Add missing 'static' to mailbox ops struct
Nikola Z. Ivanov (1):
team: Move team device type change at the end of team_port_add
Nuno Sá (3):
iio: buffer: support getting dma channel from the buffer
iio: buffer-dma: support getting the DMA channel
iio: buffer-dmaengine: enable .get_dma_dev()
Oleksandr Suvorov (1):
USB: serial: ftdi_sio: add support for u-blox EVK-M101
Olivier Moysan (1):
iio: adc: stm32-dfsdm: fix st,adc-alt-channel property handling
Owen Gu (1):
usb: uas: fix urb unmapping issue when the uas device is remove
during ongoing data transfer
Paolo Abeni (1):
mptcp: clear scheduled subflows on retransmit
Pauli Virtanen (1):
Bluetooth: hci_core: lookup hci_conn on RX path on protocol side
Paulo Alcantara (1):
smb: client: fix memory leak in cifs_construct_tcon()
Pavel Begunkov (1):
io_uring: fix mixed cqe overflow handling
Pranjal Shrivastava (1):
dma-direct: Fix missing sg_dma_len assignment in P2PDMA bus mappings
Pratyush Yadav (1):
MAINTAINERS: add test_kho to KHO's entry
Prike Liang (1):
drm/amdgpu: attach tlb fence to the PTs update
Rafael J. Wysocki (6):
Revert "ACPI: processor: Do not expose global variable acpi_idle_driver"
Revert "ACPI: processor: idle: Redefine two functions as void"
Revert "ACPI: processor: idle: Rearrange declarations in header file"
Revert "ACPI: processor: Remove unused empty stubs of some functions"
Revert "ACPI: processor: idle: Optimize ACPI idle driver registration"
Revert "ACPI: processor: Update cpuidle driver check in
__acpi_processor_start()"
René Rebe (2):
ALSA: hda/cirrus fix cs420x MacPro 6,1 inverted jack detection
ALSA: usb-audio: fix uac2 clock source at terminal parser
Sam Protsenko (1):
mailmap: add entry for Sam Protsenko
Sayooj K Karun (1):
net: atm: fix incorrect cleanup function call in error path
Sebastian Reichel (2):
platform: arm64: thinkpad-t14s-ec: fix IRQ race condition
platform: arm64: thinkpad-t14s-ec: sleep after EC access
Sergey Matyukevich (1):
riscv: dts: allwinner: d1: fix vlenb property
Seungjin Bae (1):
can: kvaser_usb: leaf: Fix potential infinite loop in command parsers
Shaurya Rane (1):
net/sched: em_canid: fix uninit-value in em_canid_match
Shuicheng Lin (1):
drm/xe/guc: Fix resource leak in xe_guc_ct_init_noalloc()
Siddharth Vadapalli (1):
spi: cadence-quadspi: Fix cqspi_probe() error handling for runtime pm
Slark Xiao (1):
net: wwan: mhi: Keep modem name match with Foxconn T99W640
Thomas Bogendoerfer (1):
MIPS: mm: kmalloc tlb_vpn array to avoid stack overflow
Thomas Mühlbacher (1):
can: sja1000: fix max irq loop handling
Thomas Zimmermann (1):
drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup
Tianchu Chen (1):
usb: storage: sddr55: Reject out-of-bound new_pba
Valek Andrej (1):
iio: accel: fix ADXL355 startup race condition
Vanillan Wang (1):
USB: serial: option: add support for Rolling RW101R-GL
Viacheslav Dubeyko (1):
ceph: fix crash in process_v2_sparse_read() for encrypted directories
Ville Syrjälä (1):
drm/i915/psr: Reject async flips when selective fetch is enabled
Vladimir Oltean (1):
net: dsa: sja1105: fix SGMII linking at 10M or 100M but not
passing traffic
Wei Fang (4):
net: fec: cancel perout_timer when PEROUT is disabled
net: fec: do not update PEROUT if it is enabled
net: fec: do not allow enabling PPS and PEROUT simultaneously
net: fec: do not register PPS event for PEROUT
Wei Yang (1):
mm/huge_memory: fix NULL pointer deference when splitting folio
Wentao Guan (1):
nvmem: layouts: fix nvmem_layout_bus_uevent
Will Deacon (1):
Revert "arm64: acpi: Enable ACPI CCEL support"
Xu Yang (1):
arm64: dts: imx8qm-mek: fix mux-controller select/enable-gpios polarity
Youngjun Park (1):
mm: swap: remove duplicate nr_swap_pages decrement in
get_swap_page_of_type()
ziming zhang (2):
libceph: replace BUG_ON with bounds check for map->max_osd
libceph: prevent potential out-of-bounds writes in
handle_auth_session_key()
Łukasz Bartosik (1):
xhci: dbgtty: fix device unregister
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Linux 6.18
2025-11-30 23:59 Linux 6.18 Linus Torvalds
@ 2025-12-02 2:39 ` Guenter Roeck
2025-12-02 4:50 ` Brian Norris
0 siblings, 1 reply; 7+ messages in thread
From: Guenter Roeck @ 2025-12-02 2:39 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List, Brian Norris
On Sun, Nov 30, 2025 at 03:59:17PM -0800, Linus Torvalds wrote:
...
> Anyway, *today* the important kernel is the newly minted 6.18 release.
> Please do keep testing,
>
Build results:
total: 158 pass: 158 fail: 0
Qemu test results:
total: 610 pass: 610 fail: 0
Unit test results:
pass: 666778 fail: 113
In terms of testing, that is worse that it sounds. I enabled
CONFIG_PM_RUNTIME_KUNIT_TEST last week, and it results in widespread
test failures. Picking one (from x86_64):
[ 34.559694] # pm_runtime_error_test: EXPECTATION FAILED at drivers/base/power/runtime-test.c:177
[ 34.559694] Expected 1 == pm_runtime_barrier(dev), but
[ 34.559694] pm_runtime_barrier(dev) == 0 (0x0)
[ 34.563604] # pm_runtime_error_test: pass:0 fail:1 skip:0 total:1
Looks like that fails pretty much on every architecture/platform where
it is enabled. Copying the author (Brian) for feedback.
Guenter
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Linux 6.18
2025-12-02 2:39 ` Guenter Roeck
@ 2025-12-02 4:50 ` Brian Norris
2025-12-02 6:01 ` Guenter Roeck
2025-12-02 14:37 ` Wysocki, Rafael J
0 siblings, 2 replies; 7+ messages in thread
From: Brian Norris @ 2025-12-02 4:50 UTC (permalink / raw)
To: Guenter Roeck
Cc: Linus Torvalds, Linux Kernel Mailing List, Rafael J. Wysocki
On Mon, Dec 01, 2025 at 06:39:49PM -0800, Guenter Roeck wrote:
> On Sun, Nov 30, 2025 at 03:59:17PM -0800, Linus Torvalds wrote:
> ...
> > Anyway, *today* the important kernel is the newly minted 6.18 release.
> > Please do keep testing,
> >
>
> Build results:
> total: 158 pass: 158 fail: 0
> Qemu test results:
> total: 610 pass: 610 fail: 0
> Unit test results:
> pass: 666778 fail: 113
>
> In terms of testing, that is worse that it sounds. I enabled
> CONFIG_PM_RUNTIME_KUNIT_TEST last week, and it results in widespread
> test failures. Picking one (from x86_64):
>
> [ 34.559694] # pm_runtime_error_test: EXPECTATION FAILED at drivers/base/power/runtime-test.c:177
> [ 34.559694] Expected 1 == pm_runtime_barrier(dev), but
> [ 34.559694] pm_runtime_barrier(dev) == 0 (0x0)
> [ 34.563604] # pm_runtime_error_test: pass:0 fail:1 skip:0 total:1
>
> Looks like that fails pretty much on every architecture/platform where
> it is enabled. Copying the author (Brian) for feedback.
I wonder how you manage to be the one who hits all these problems,
because none of the configurations and environments generated by
./tools/testing/kunit/kunit.py seem to hit it naturally. (I tested
hundreds of cycles in various configurations with no failures
previously, and I still didn't reproduce it today.) Do you make special
effort to direct cosmic rays into your test setups while holding an
unlucky charm? :)
But since you pointed out the failure, I *can* induce the failure by
forcing some scheduling delay.
--- a/drivers/base/power/runtime-test.c
+++ b/drivers/base/power/runtime-test.c
@@ -3,6 +3,7 @@
* Copyright 2025 Google, Inc.
*/
+#include <linux/delay.h>
#include <linux/cleanup.h>
#include <linux/pm_runtime.h>
#include <kunit/device.h>
@@ -174,6 +175,7 @@ static void pm_runtime_error_test(struct kunit *test)
KUNIT_EXPECT_TRUE(test, pm_runtime_suspended(dev));
KUNIT_EXPECT_EQ(test, 0, pm_runtime_get(dev));
+ msleep(1000);
KUNIT_EXPECT_EQ(test, 1, pm_runtime_barrier(dev)); /* resume was pending */
pm_runtime_put(dev);
pm_runtime_suspend(dev); /* flush the put(), to suspend */
Looking closer at this part of the API, I think checking the return code
of pm_runtime_barrier() is a bad idea, since it's inherently racy, and
there's really no way to control that race. On the plus side, this test
is the only one that does it. So I can probably just go ahead and make
pm_runtime_barrier() a void function, and stop pretending it's part of
the API surface. One fewer weird part of the runtime PM API to think
about...
Maybe I can get around to that tomorrow.
Also CC Rafael while I'm at it.
Thanks for reporting,
Brian
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Linux 6.18
2025-12-02 4:50 ` Brian Norris
@ 2025-12-02 6:01 ` Guenter Roeck
2025-12-02 20:38 ` Brian Norris
2025-12-02 14:37 ` Wysocki, Rafael J
1 sibling, 1 reply; 7+ messages in thread
From: Guenter Roeck @ 2025-12-02 6:01 UTC (permalink / raw)
To: Brian Norris; +Cc: Linus Torvalds, Linux Kernel Mailing List, Rafael J. Wysocki
Hi Brian,
On 12/1/25 20:50, Brian Norris wrote:
> On Mon, Dec 01, 2025 at 06:39:49PM -0800, Guenter Roeck wrote:
>> On Sun, Nov 30, 2025 at 03:59:17PM -0800, Linus Torvalds wrote:
>> ...
>>> Anyway, *today* the important kernel is the newly minted 6.18 release.
>>> Please do keep testing,
>>>
>>
>> Build results:
>> total: 158 pass: 158 fail: 0
>> Qemu test results:
>> total: 610 pass: 610 fail: 0
>> Unit test results:
>> pass: 666778 fail: 113
>>
>> In terms of testing, that is worse that it sounds. I enabled
>> CONFIG_PM_RUNTIME_KUNIT_TEST last week, and it results in widespread
>> test failures. Picking one (from x86_64):
>>
>> [ 34.559694] # pm_runtime_error_test: EXPECTATION FAILED at drivers/base/power/runtime-test.c:177
>> [ 34.559694] Expected 1 == pm_runtime_barrier(dev), but
>> [ 34.559694] pm_runtime_barrier(dev) == 0 (0x0)
>> [ 34.563604] # pm_runtime_error_test: pass:0 fail:1 skip:0 total:1
>>
>> Looks like that fails pretty much on every architecture/platform where
>> it is enabled. Copying the author (Brian) for feedback.
>
> I wonder how you manage to be the one who hits all these problems,
> because none of the configurations and environments generated by
> ./tools/testing/kunit/kunit.py seem to hit it naturally. (I tested
> hundreds of cycles in various configurations with no failures
> previously, and I still didn't reproduce it today.) Do you make special
> effort to direct cosmic rays into your test setups while holding an
> unlucky charm? :)
>
Neither cosmic rays nor unlucky charm needed (or at least so I hope ;-).
I build the tests into the kernel and run them while booting in qemu.
Most other testbeds run the tests as module after booting and/or
on native machines (not in qemu). That makes a significant difference
in both behavior and timing.
Guenter
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Linux 6.18
2025-12-02 4:50 ` Brian Norris
2025-12-02 6:01 ` Guenter Roeck
@ 2025-12-02 14:37 ` Wysocki, Rafael J
2025-12-02 19:36 ` Brian Norris
1 sibling, 1 reply; 7+ messages in thread
From: Wysocki, Rafael J @ 2025-12-02 14:37 UTC (permalink / raw)
To: Brian Norris
Cc: Linus Torvalds, Linux Kernel Mailing List, Rafael J. Wysocki,
linux-pm@vger.kernel.org, Guenter Roeck
On 12/2/2025 5:50 AM, Brian Norris wrote:
> On Mon, Dec 01, 2025 at 06:39:49PM -0800, Guenter Roeck wrote:
>> On Sun, Nov 30, 2025 at 03:59:17PM -0800, Linus Torvalds wrote:
>> ...
>>> Anyway, *today* the important kernel is the newly minted 6.18 release.
>>> Please do keep testing,
>>>
>> Build results:
>> total: 158 pass: 158 fail: 0
>> Qemu test results:
>> total: 610 pass: 610 fail: 0
>> Unit test results:
>> pass: 666778 fail: 113
>>
>> In terms of testing, that is worse that it sounds. I enabled
>> CONFIG_PM_RUNTIME_KUNIT_TEST last week, and it results in widespread
>> test failures. Picking one (from x86_64):
>>
>> [ 34.559694] # pm_runtime_error_test: EXPECTATION FAILED at drivers/base/power/runtime-test.c:177
>> [ 34.559694] Expected 1 == pm_runtime_barrier(dev), but
>> [ 34.559694] pm_runtime_barrier(dev) == 0 (0x0)
>> [ 34.563604] # pm_runtime_error_test: pass:0 fail:1 skip:0 total:1
>>
>> Looks like that fails pretty much on every architecture/platform where
>> it is enabled. Copying the author (Brian) for feedback.
> I wonder how you manage to be the one who hits all these problems,
> because none of the configurations and environments generated by
> ./tools/testing/kunit/kunit.py seem to hit it naturally. (I tested
> hundreds of cycles in various configurations with no failures
> previously, and I still didn't reproduce it today.) Do you make special
> effort to direct cosmic rays into your test setups while holding an
> unlucky charm? :)
>
> But since you pointed out the failure, I *can* induce the failure by
> forcing some scheduling delay.
>
> --- a/drivers/base/power/runtime-test.c
> +++ b/drivers/base/power/runtime-test.c
> @@ -3,6 +3,7 @@
> * Copyright 2025 Google, Inc.
> */
>
> +#include <linux/delay.h>
> #include <linux/cleanup.h>
> #include <linux/pm_runtime.h>
> #include <kunit/device.h>
> @@ -174,6 +175,7 @@ static void pm_runtime_error_test(struct kunit *test)
> KUNIT_EXPECT_TRUE(test, pm_runtime_suspended(dev));
>
> KUNIT_EXPECT_EQ(test, 0, pm_runtime_get(dev));
> + msleep(1000);
> KUNIT_EXPECT_EQ(test, 1, pm_runtime_barrier(dev)); /* resume was pending */
> pm_runtime_put(dev);
> pm_runtime_suspend(dev); /* flush the put(), to suspend */
>
> Looking closer at this part of the API, I think checking the return code
> of pm_runtime_barrier() is a bad idea, since it's inherently racy, and
> there's really no way to control that race. On the plus side, this test
> is the only one that does it. So I can probably just go ahead and make
> pm_runtime_barrier() a void function, and stop pretending it's part of
> the API surface. One fewer weird part of the runtime PM API to think
> about...
Yes, pm_runtime_barrier() should be void, the return value is a leftover
thing.
> Maybe I can get around to that tomorrow.
I can do it unless you specifically want to take care of it yourself.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Linux 6.18
2025-12-02 14:37 ` Wysocki, Rafael J
@ 2025-12-02 19:36 ` Brian Norris
0 siblings, 0 replies; 7+ messages in thread
From: Brian Norris @ 2025-12-02 19:36 UTC (permalink / raw)
To: Wysocki, Rafael J
Cc: Linus Torvalds, Linux Kernel Mailing List, Rafael J. Wysocki,
linux-pm@vger.kernel.org, Guenter Roeck
On Tue, Dec 02, 2025 at 03:37:58PM +0100, Wysocki, Rafael J wrote:
> On 12/2/2025 5:50 AM, Brian Norris wrote:
> > Looking closer at this part of the API, I think checking the return code
> > of pm_runtime_barrier() is a bad idea, since it's inherently racy, and
> > there's really no way to control that race. On the plus side, this test
> > is the only one that does it. So I can probably just go ahead and make
> > pm_runtime_barrier() a void function, and stop pretending it's part of
> > the API surface. One fewer weird part of the runtime PM API to think
> > about...
>
> Yes, pm_runtime_barrier() should be void, the return value is a leftover
> thing.
Thanks for the confirmation.
> > Maybe I can get around to that tomorrow.
>
> I can do it unless you specifically want to take care of it yourself.
I wrote the (bad) test, so I figured it's good citizenship to fix it.
And anyway, I drafted it most of it yesterday already.
I've submitted a version here
Subject: [PATCH 1/3] PM: runtime: Stop checking pm_runtime_barrier() return code
https://lore.kernel.org/all/20251202193129.1411419-1-briannorris@chromium.org/
Feel free to tweak it or do it in your preferred way though, if you'd
like.
Brian
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Linux 6.18
2025-12-02 6:01 ` Guenter Roeck
@ 2025-12-02 20:38 ` Brian Norris
0 siblings, 0 replies; 7+ messages in thread
From: Brian Norris @ 2025-12-02 20:38 UTC (permalink / raw)
To: Guenter Roeck
Cc: Linus Torvalds, Linux Kernel Mailing List, Rafael J. Wysocki
On Mon, Dec 01, 2025 at 10:01:24PM -0800, Guenter Roeck wrote:
> On 12/1/25 20:50, Brian Norris wrote:
> > On Mon, Dec 01, 2025 at 06:39:49PM -0800, Guenter Roeck wrote:
> > > Looks like that fails pretty much on every architecture/platform where
> > > it is enabled. Copying the author (Brian) for feedback.
> >
> > I wonder how you manage to be the one who hits all these problems,
> > because none of the configurations and environments generated by
> > ./tools/testing/kunit/kunit.py seem to hit it naturally. (I tested
> > hundreds of cycles in various configurations with no failures
> > previously, and I still didn't reproduce it today.) Do you make special
> > effort to direct cosmic rays into your test setups while holding an
> > unlucky charm? :)
> >
>
> Neither cosmic rays nor unlucky charm needed (or at least so I hope ;-).
>
> I build the tests into the kernel and run them while booting in qemu.
> Most other testbeds run the tests as module after booting and/or
> on native machines (not in qemu). That makes a significant difference
> in both behavior and timing.
./tools/testing/kunit/kunit.py runs with either user-mode Linux or QEMU,
with tests built into the kernel and run while booting. That sounds
rather similar to what you run. Previously, the main unique thing I
recalled from your test setups was that you run a much wider array of
ARCHes than I can manage. But that doesn't seem relevant, per your
"pretty much every architecture" note.
Obviously, race conditions are a bit environment / luck dependent, but
I'm just surprised that when it *sounds* like we run something similar,
you get near-100% failure, and I get 0%.
*shrug*
Brian
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2025-12-02 20:38 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-11-30 23:59 Linux 6.18 Linus Torvalds
2025-12-02 2:39 ` Guenter Roeck
2025-12-02 4:50 ` Brian Norris
2025-12-02 6:01 ` Guenter Roeck
2025-12-02 20:38 ` Brian Norris
2025-12-02 14:37 ` Wysocki, Rafael J
2025-12-02 19:36 ` Brian Norris
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).