kernel/linux.git, branch v6.6.108

Linux 6.6.108

2025-09-25T09:00:10+00:00

Link: https://lore.kernel.org/r/20250922192404.455120315@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Linux Kernel Functional Testing Tested-by: Brett A C Sheffield Tested-by: Peter Schneider Tested-by: Jon Hunter Tested-by: Ron Economos Tested-by: Miguel Ojeda Tested-by: Shuah Khan Tested-by: Hardik Garg Tested-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

Revert "loop: Avoid updating block size under exclusive owner"

2025-09-25T09:00:10+00:00

Revert commit ce8da5d13d8c2a7b30b2fb376a22e8eb1a70b8bb which is commit 7e49538288e523427beedd26993d446afef1a6fb upstream. This reverts commit ce8da5d13d8c ("loop: Avoid updating block size under exclusive owner") for the 6.6 kernel, because if the LTP ioctl_loop06 test is run with this patch in place, the test will fail, it leaves the host unable to kexec into the kernel again (hangs forever) and "losetup -a" will hang on attempting to access the /dev/loopN device that the test has set up. The patch doesn't need to be reverted from 6.12, as it works fine there. Cc: stable@vger.kernel.org # 6.6.x Signed-off-by: Eric Hagberg Signed-off-by: Greg Kroah-Hartman

minmax: add a few more MIN_T/MAX_T users

2025-09-25T09:00:10+00:00

[ Upstream commit 4477b39c32fdc03363affef4b11d48391e6dc9ff ] Commit 3a7e02c040b1 ("minmax: avoid overly complicated constant expressions in VM code") added the simpler MIN_T/MAX_T macros in order to avoid some excessive expansion from the rather complicated regular min/max macros. The complexity of those macros stems from two issues: (a) trying to use them in situations that require a C constant expression (in static initializers and for array sizes) (b) the type sanity checking and MIN_T/MAX_T avoids both of these issues. Now, in the whole (long) discussion about all this, it was pointed out that the whole type sanity checking is entirely unnecessary for min_t/max_t which get a fixed type that the comparison is done in. But that still leaves min_t/max_t unnecessarily complicated due to worries about the C constant expression case. However, it turns out that there really aren't very many cases that use min_t/max_t for this, and we can just force-convert those. This does exactly that. Which in turn will then allow for much simpler implementations of min_t()/max_t(). All the usual "macros in all upper case will evaluate the arguments multiple times" rules apply. We should do all the same things for the regular min/max() vs MIN/MAX() cases, but that has the added complexity of various drivers defining their own local versions of MIN/MAX, so that needs another level of fixes first. Link: https://lore.kernel.org/all/b47fad1d0cf8449886ad148f8c013dae@AcuMS.aculab.com/ Cc: David Laight Cc: Lorenzo Stoakes Signed-off-by: Linus Torvalds Signed-off-by: Eliav Farber Signed-off-by: Greg Kroah-Hartman

minmax: simplify and clarify min_t()/max_t() implementation

2025-09-25T09:00:10+00:00

[ Upstream commit 017fa3e89187848fd056af757769c9e66ac3e93d ] This simplifies the min_t() and max_t() macros by no longer making them work in the context of a C constant expression. That means that you can no longer use them for static initializers or for array sizes in type definitions, but there were only a couple of such uses, and all of them were converted (famous last words) to use MIN_T/MAX_T instead. Cc: David Laight Cc: Lorenzo Stoakes Signed-off-by: Linus Torvalds Signed-off-by: Eliav Farber Signed-off-by: Greg Kroah-Hartman

minmax: avoid overly complicated constant expressions in VM code

2025-09-25T09:00:10+00:00

[ Upstream commit 3a7e02c040b130b5545e4b115aada7bacd80a2b6 ] The minmax infrastructure is overkill for simple constants, and can cause huge expansions because those simple constants are then used by other things. For example, 'pageblock_order' is a core VM constant, but because it was implemented using 'min_t()' and all the type-checking that involves, it actually expanded to something like 2.5kB of preprocessor noise. And when that simple constant was then used inside other expansions: #define pageblock_nr_pages (1UL << pageblock_order) #define pageblock_start_pfn(pfn) ALIGN_DOWN((pfn), pageblock_nr_pages) and we then use that inside a 'max()' macro: case ISOLATE_SUCCESS: update_cached = false; last_migrated_pfn = max(cc->zone->zone_start_pfn, pageblock_start_pfn(cc->migrate_pfn - 1)); the end result was that one statement expanding to 253kB in size. There are probably other cases of this, but this one case certainly stood out. I've added 'MIN_T()' and 'MAX_T()' macros for this kind of "core simple constant with specific type" use. These macros skip the type checking, and as such need to be very sparingly used only for obvious cases that have active issues like this. Reported-by: Lorenzo Stoakes Link: https://lore.kernel.org/all/36aa2cad-1db1-4abf-8dd2-fb20484aabc3@lucifer.local/ Cc: David Laight Signed-off-by: Linus Torvalds Signed-off-by: Eliav Farber Signed-off-by: Greg Kroah-Hartman

mptcp: propagate shutdown to subflows when possible

2025-09-25T09:00:10+00:00

[ Upstream commit f755be0b1ff429a2ecf709beeb1bcd7abc111c2b ] When the MPTCP DATA FIN have been ACKed, there is no more MPTCP related metadata to exchange, and all subflows can be safely shutdown. Before this patch, the subflows were actually terminated at 'close()' time. That's certainly fine most of the time, but not when the userspace 'shutdown()' a connection, without close()ing it. When doing so, the subflows were staying in LAST_ACK state on one side -- and consequently in FIN_WAIT2 on the other side -- until the 'close()' of the MPTCP socket. Now, when the DATA FIN have been ACKed, all subflows are shutdown. A consequence of this is that the TCP 'FIN' flag can be set earlier now, but the end result is the same. This affects the packetdrill tests looking at the end of the MPTCP connections, but for a good reason. Note that tcp_shutdown() will check the subflow state, so no need to do that again before calling it. Fixes: 3721b9b64676 ("mptcp: Track received DATA_FIN sequence number and add related helpers") Cc: stable@vger.kernel.org Fixes: 16a9a9da1723 ("mptcp: Add helper to process acks of DATA_FIN") Reviewed-by: Mat Martineau Reviewed-by: Geliang Tang Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20250912-net-mptcp-fix-sft-connect-v1-1-d40e77cbbf02@kernel.org Signed-off-by: Jakub Kicinski [ Adjust context ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

rtc: pcf2127: fix SPI command byte for PCF2131 backport

2025-09-25T09:00:10+00:00

When commit fa78e9b606a472495ef5b6b3d8b45c37f7727f9d upstream was backported to LTS branches linux-6.12.y and linux-6.6.y, the SPI regmap config fix got applied to the I2C regmap config. Most likely due to a new RTC get/set parm feature introduced in 6.14 causing regmap config sections in the buttom of the driver to move. LTS branch linux-6.1.y and earlier does not have PCF2131 device support. Issue can be seen in buttom of this diff in stable/linux.git tree: git diff master..linux-6.12.y -- drivers/rtc/rtc-pcf2127.c Fixes: ee61aec8529e ("rtc: pcf2127: fix SPI command byte for PCF2131") Fixes: 5cdd1f73401d ("rtc: pcf2127: fix SPI command byte for PCF2131") Cc: stable@vger.kernel.org Cc: Alexandre Belloni Cc: Elena Popa Cc: Hugo Villeneuve Signed-off-by: Bruno Thomsen Signed-off-by: Greg Kroah-Hartman

iommu/amd/pgtbl: Fix possible race while increase page table level

2025-09-25T09:00:10+00:00

[ Upstream commit 1e56310b40fd2e7e0b9493da9ff488af145bdd0c ] The AMD IOMMU host page table implementation supports dynamic page table levels (up to 6 levels), starting with a 3-level configuration that expands based on IOVA address. The kernel maintains a root pointer and current page table level to enable proper page table walks in alloc_pte()/fetch_pte() operations. The IOMMU IOVA allocator initially starts with 32-bit address and onces its exhuasted it switches to 64-bit address (max address is determined based on IOMMU and device DMA capability). To support larger IOVA, AMD IOMMU driver increases page table level. But in unmap path (iommu_v1_unmap_pages()), fetch_pte() reads pgtable->[root/mode] without lock. So its possible that in exteme corner case, when increase_address_space() is updating pgtable->[root/mode], fetch_pte() reads wrong page table level (pgtable->mode). It does compare the value with level encoded in page table and returns NULL. This will result is iommu_unmap ops to fail and upper layer may retry/log WARN_ON. CPU 0 CPU 1 ------ ------ map pages unmap pages alloc_pte() -> increase_address_space() iommu_v1_unmap_pages() -> fetch_pte() pgtable->root = pte (new root value) READ pgtable->[mode/root] Reads new root, old mode Updates mode (pgtable->mode += 1) Since Page table level updates are infrequent and already synchronized with a spinlock, implement seqcount to enable lock-free read operations on the read path. Fixes: 754265bcab7 ("iommu/amd: Fix race in increase_address_space()") Reported-by: Alejandro Jimenez Cc: stable@vger.kernel.org Cc: Joao Martins Cc: Suravee Suthikulpanit Signed-off-by: Vasant Hegde Signed-off-by: Joerg Roedel [ Adapted pgtable->mode and pgtable->root to use domain->iop.mode and domain->iop.root ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

xhci: dbc: Fix full DbC transfer ring after several reconnects

2025-09-25T09:00:10+00:00

[ Upstream commit a5c98e8b1398534ae1feb6e95e2d3ee5215538ed ] Pending requests will be flushed on disconnect, and the corresponding TRBs will be turned into No-op TRBs, which are ignored by the xHC controller once it starts processing the ring. If the USB debug cable repeatedly disconnects before ring is started then the ring will eventually be filled with No-op TRBs. No new transfers can be queued when the ring is full, and driver will print the following error message: "xhci_hcd 0000:00:14.0: failed to queue trbs" This is a normal case for 'in' transfers where TRBs are always enqueued in advance, ready to take on incoming data. If no data arrives, and device is disconnected, then ring dequeue will remain at beginning of the ring while enqueue points to first free TRB after last cancelled No-op TRB. s Solve this by reinitializing the rings when the debug cable disconnects and DbC is leaving the configured state. Clear the whole ring buffer and set enqueue and dequeue to the beginning of ring, and set cycle bit to its initial state. Cc: stable@vger.kernel.org Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver") Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20250902105306.877476-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

xhci: dbc: decouple endpoint allocation from initialization

2025-09-25T09:00:10+00:00

[ Upstream commit 220a0ffde02f962c13bc752b01aa570b8c65a37b ] Decouple allocation of endpoint ring buffer from initialization of the buffer, and initialization of endpoint context parts from from the rest of the contexts. It allows driver to clear up and reinitialize endpoint rings after disconnect without reallocating everything. This is a prerequisite for the next patch that prevents the transfer ring from filling up with cancelled (no-op) TRBs if a debug cable is reconnected several times without transferring anything. Cc: stable@vger.kernel.org Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver") Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20250902105306.877476-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman