summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-06-27Merge tag 'libcrypto-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux Pull crypto library fix from Eric Biggers: "Fix a regression where the purgatory code sometimes fails to build" * tag 'libcrypto-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux: lib/crypto: sha256: Mark sha256_choose_blocks as __always_inline
2025-06-27dpaa2-eth: fix xdp_rxq_info leakFushuai Wang
The driver registered xdp_rxq_info structures via xdp_rxq_info_reg() but failed to properly unregister them in error paths and during removal. Fixes: d678be1dc1ec ("dpaa2-eth: add XDP_REDIRECT support") Signed-off-by: Fushuai Wang <wangfushuai@baidu.com> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Ioana Ciornei <ioana.ciornei@nxp.com> Link: https://patch.msgid.link/20250626133003.80136-1-wangfushuai@baidu.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-27ethernet: atl1: Add missing DMA mapping error checks and count errorsThomas Fourier
The `dma_map_XXX()` functions can fail and must be checked using `dma_mapping_error()`. This patch adds proper error handling for all DMA mapping calls. In `atl1_alloc_rx_buffers()`, if DMA mapping fails, the buffer is deallocated and marked accordingly. In `atl1_tx_map()`, previously mapped buffers are unmapped and the packet is dropped on failure. If `atl1_xmit_frame()` drops the packet, increment the tx_error counter. Fixes: f3cc28c79760 ("Add Attansic L1 ethernet driver.") Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com> Link: https://patch.msgid.link/20250625141629.114984-2-fourier.thomas@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-27Merge branch 'octeontx2-pf-extend-link-modes-support'Jakub Kicinski
Hariprasad Kelam says: ==================== Octeontx2-pf: extend link modes support This series of patches adds multi advertise mode support along with other improvements in link mode management code flow. Patch1: Currently all SGMII modes 10/100/1000baseT are mapped with single firmware mode. This patch updates these link modes with corresponding firmware modes. Patch2: Due to limitation in current kernel <-> firmware communication, link modes are divided into multiple groups, and identified with their group index. Patch3: Adds support for multi advertise mode. ==================== Link: https://patch.msgid.link/20250625092107.9746-1-hkelam@marvell.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-27Octeontx2-pf: ethtool: support multi advertise modeHariprasad Kelam
Current implementation considers only first advertise mode and passes the same to firmware to process. This patch extends code such that user can advertise multiple modes on the given interface. Below are high level changes: 1. Remove unnecessary speed/duplex/autoneg validation as its already verified as part of "set_link_ksettings" 2. Since scratch csr framework designed to support single mode at a time, use "shared firmware data" for multi mode support. Signed-off-by: Hariprasad Kelam <hkelam@marvell.com> Link: https://patch.msgid.link/20250625092107.9746-4-hkelam@marvell.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-27Octeontx2-af: Introduce mode group indexHariprasad Kelam
Kernel and firmware communicates via scratch register which is 64 bit in size. [MODE_ID PORT AUTONEG DUPLEX SPEED CMD_ID OWNERSHIP ] 63-22 21-14 13 12 11-8 7-2 1-0 The existing MODE_ID bitmap can only support up to 42 modes. To resolve the issue, the unused port field is modified as below uint64_t reserved2:6; uint64_t mode_group_idx:2; 'mode_group_idx' categorize the mode ID range to accommodate more modes. To specify mode ID range of 0 - 41, this field will be 0. To specify mode ID range of 42 - 83, this field will be 1. mode ID will be still mentioned as 1 << (0 - 41). But the mode_group_idx decides the actual mode range Signed-off-by: Hariprasad Kelam <hkelam@marvell.com> Link: https://patch.msgid.link/20250625092107.9746-3-hkelam@marvell.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-27Octeontx-pf: Update SGMII mode mappingHariprasad Kelam
Current implementation maps ethtool link modes 10baseT/100baseT/1000baseT to single firmware mode SGMII. This create a problem for end users who want to advertise only one speed among them. This patch addresses the issue by mapping each ethtool link mode to a corresponding firmware mode also updates new modes supported by firmware. Signed-off-by: Hariprasad Kelam <hkelam@marvell.com> Link: https://patch.msgid.link/20250625092107.9746-2-hkelam@marvell.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-27Merge branch 'dpll-add-reference-sync-feature'Jakub Kicinski
Arkadiusz Kubalewski says: ==================== dpll: add Reference SYNC feature The device may support the Reference SYNC feature, which allows the combination of two inputs into a input pair. In this configuration, clock signals from both inputs are used to synchronize the DPLL device. The higher frequency signal is utilized for the loop bandwidth of the DPLL, while the lower frequency signal is used to syntonize the output signal of the DPLL device. This feature enables the provision of a high-quality loop bandwidth signal from an external source. A capable input provides a list of inputs that can be bound with to create Reference SYNC. To control this feature, the user must request a desired state for a target pin: use ``DPLL_PIN_STATE_CONNECTED`` to enable or ``DPLL_PIN_STATE_DISCONNECTED`` to disable the feature. An input pin can be bound to only one other pin at any given time. Verify pins bind state/capabilities: $ ./tools/net/ynl/pyynl/cli.py \ --spec Documentation/netlink/specs/dpll.yaml \ --do pin-get \ --json '{"id":0}' {'board-label': 'CVL-SDP22', 'id': 0, [...] 'reference-sync': [{'id': 1, 'state': 'disconnected'}], [...]} Bind the pins by setting connected state between them: $ ./tools/net/ynl/pyynl/cli.py \ --spec Documentation/netlink/specs/dpll.yaml \ --do pin-set \ --json '{"id":0, "reference-sync":{"id":1, "state":"connected"}}' Verify pins bind state: $ ./tools/net/ynl/pyynl/cli.py \ --spec Documentation/netlink/specs/dpll.yaml \ --do pin-get \ --json '{"id":0}' {'board-label': 'CVL-SDP22', 'id': 0, [...] 'reference-sync': [{'id': 1, 'state': 'connected'}], [...]} Unbind the pins by setting disconnected state between them: $ ./tools/net/ynl/pyynl/cli.py \ --spec Documentation/netlink/specs/dpll.yaml \ --do pin-set \ --json '{"id":0, "reference-sync":{"id":1, "state":"disconnected"}}' ==================== Link: https://patch.msgid.link/20250626135219.1769350-1-arkadiusz.kubalewski@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-27ice: add ref-sync dpll pinsArkadiusz Kubalewski
Implement reference sync input pin get/set callbacks, allow user space control over dpll pin pairs capable of reference sync support. Reviewed-by: Milena Olech <milena.olech@intel.com> Signed-off-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Link: https://patch.msgid.link/20250626135219.1769350-4-arkadiusz.kubalewski@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-27dpll: add reference sync get/setArkadiusz Kubalewski
Define function for reference sync pin registration and callback ops to set/get current feature state. Implement netlink handler to fill netlink messages with reference sync pin configuration of capable pins (pin-get). Implement netlink handler to call proper ops and configure reference sync pin state (pin-set). Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Reviewed-by: Milena Olech <milena.olech@intel.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Link: https://patch.msgid.link/20250626135219.1769350-3-arkadiusz.kubalewski@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-27dpll: add reference-sync netlink attributeArkadiusz Kubalewski
Add new netlink attribute to allow user space configuration of reference sync pin pairs, where both pins are used to provide one clock signal consisting of both: base frequency and sync signal. Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Reviewed-by: Milena Olech <milena.olech@intel.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Link: https://patch.msgid.link/20250626135219.1769350-2-arkadiusz.kubalewski@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-27Merge branch '100GbE' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue Tony Nguyen says: ==================== ice: remaining TSPLL cleanups These are the remaining patches from the "ice: Separate TSPLL from PTP and cleanup" series [1] with control flow macros removed. What remains are cleanups and some minor improvements. [1] https://lore.kernel.org/netdev/20250618174231.3100231-1-anthony.l.nguyen@intel.com/ * '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue: ice: default to TIME_REF instead of TXCO on E825-C ice: move TSPLL init calls to ice_ptp.c ice: fall back to TCXO on TSPLL lock fail ice: wait before enabling TSPLL ice: add multiple TSPLL helpers ice: use bitfields instead of unions for CGU regs ice: read TSPLL registers again before reporting status ice: clear time_sync_en field for E825-C during reprogramming ==================== Link: https://patch.msgid.link/20250626162921.1173068-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-27eth: bnxt: take page size into account for page pool recycling ringsJakub Kicinski
The Rx rings are filled with Rx buffers. Which are supposed to fit packet headers (or MTU if HW-GRO is disabled). The aggregation buffers are filled with "device pages". Adjust the sizes of the page pool recycling ring appropriately, based on ratio of the size of the buffer on given ring vs system page size. Otherwise on a system with 64kB pages we end up with >700MB of memory sitting in every single page pool cache. Correct the size calculation for the head_pool. Since the buffers there are always small I'm pretty sure I meant to cap the size at 1k, rather than make it the lowest possible size. With 64k pages 1k cache with a 1k ring is 64x larger than we need. Reviewed-by: Michael Chan <michael.chan@broadcom.com> Link: https://patch.msgid.link/20250626165441.4125047-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-27Merge branch 'tcp-fix-dsack-bug-with-non-contiguous-ranges'Jakub Kicinski
Eric Dumazet says: ==================== tcp: fix DSACK bug with non contiguous ranges This series combines a fix from xin.guo and a new packetdrill test. ==================== Link: https://patch.msgid.link/20250626123420.1933835-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-27selftests/net: packetdrill: add tcp_dsack_mult.pktEric Dumazet
Test DSACK behavior with non contiguous ranges. Without prior fix (tcp: fix tcp_ofo_queue() to avoid including too much DUP SACK range) this would fail with: tcp_dsack_mult.pkt:37: error handling packet: bad value outbound TCP option 5 script packet: 0.100682 . 1:1(0) ack 6001 <nop,nop,sack 1001:3001 7001:8001> actual packet: 0.100679 . 1:1(0) ack 6001 win 1097 <nop,nop,sack 1001:6001 7001:8001> Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: xin.guo <guoxin0309@gmail.com> Link: https://patch.msgid.link/20250626123420.1933835-3-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-27tcp: fix tcp_ofo_queue() to avoid including too much DUP SACK rangexin.guo
If the new coming segment covers more than one skbs in the ofo queue, and which seq is equal to rcv_nxt, then the sequence range that is duplicated will be sent as DUP SACK, the detail as below, in step6, the {501,2001} range is clearly including too much DUP SACK range, in violation of RFC 2883 rules. 1. client > server: Flags [.], seq 501:1001, ack 1325288529, win 20000, length 500 2. server > client: Flags [.], ack 1, [nop,nop,sack 1 {501:1001}], length 0 3. client > server: Flags [.], seq 1501:2001, ack 1325288529, win 20000, length 500 4. server > client: Flags [.], ack 1, [nop,nop,sack 2 {1501:2001} {501:1001}], length 0 5. client > server: Flags [.], seq 1:2001, ack 1325288529, win 20000, length 2000 6. server > client: Flags [.], ack 2001, [nop,nop,sack 1 {501:2001}], length 0 After this fix, the final ACK is as below: 6. server > client: Flags [.], ack 2001, options [nop,nop,sack 1 {501:1001}], length 0 [edumazet] added a new packetdrill test in the following patch. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: xin.guo <guoxin0309@gmail.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20250626123420.1933835-2-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-27Merge branch 'tcp-remove-rtx_syn_ack-and-inet_rtx_syn_ack'Jakub Kicinski
Eric Dumazet says: ==================== tcp: remove rtx_syn_ack and inet_rtx_syn_ack() After DCCP removal, we can cleanup SYNACK retransmits a bit. ==================== Link: https://patch.msgid.link/20250626153017.2156274-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-27tcp: remove inet_rtx_syn_ack()Eric Dumazet
inet_rtx_syn_ack() is a simple wrapper around tcp_rtx_synack(), if we move req->num_retrans update. Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Neal Cardwell <ncardwell@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20250626153017.2156274-3-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-27tcp: remove rtx_syn_ack fieldEric Dumazet
Now inet_rtx_syn_ack() is only used by TCP, it can directly call tcp_rtx_synack() instead of using an indirect call to req->rsk_ops->rtx_syn_ack(). Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Neal Cardwell <ncardwell@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20250626153017.2156274-2-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-27doc: tls: socket needs to be established to enable ulpUlrich Weber
To enable TLS ulp socket needs to be in established state. This was added in commit d91c3e17f75f ("net/tls: Only attach to sockets in ESTABLISHED state"), in 2018. Signed-off-by: Ulrich Weber <ulrich.weber@gmail.com> Link: https://patch.msgid.link/20250626145618.15464-1-ulrich.weber@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-27docs: netdev: correct the heading level for co-posting selftestsJakub Kicinski
"Co-posting selftests" belongs in the "netdev patch review" section, same as "co-posting changes to user space components". It was erroneously added as its own section. Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com> Link: https://patch.msgid.link/20250626182055.4161905-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-27Merge branch 'net-dsa-ks8995-fix-up-bindings'Jakub Kicinski
Linus Walleij says: ==================== net: dsa: ks8995: Fix up bindings After looking at the datasheets for KS8995 I realized this is a DSA switch and need to have DT bindings as such and be implemented as such. This series just fixes up the bindings and the offending device tree. The existing kernel driver which is in drivers/net/phy/spi_ks8995.c does not implement DSA. It can be forgiven for this because it was merged in 2011 and the DSA framework was not widely established back then. It continues to probe fine but needs to be rewritten to use the special DSA tag and moved to drivers/net/dsa as time permits. (I hope I can do this.) It's fine for the networking tree to merge both patches, I maintain ixp4xx as well. But I can also carry the second patch through the SoC tree if so desired. v1: https://lore.kernel.org/20250624-ks8995-dsa-bindings-v1-0-71a8b4f63315@linaro.org ==================== Link: https://patch.msgid.link/20250625-ks8995-dsa-bindings-v2-0-ce71dce9be0b@linaro.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-27ARM: dts: Fix up wrv54g device treeLinus Walleij
Fix up the KS8995 switch and PHYs the way that is most likely: - Phy 1-4 is certainly the PHYs of the KS8995 (mask 0x1e in the outoftree code masks PHYs 1,2,3,4). - Phy 5 is the MII-P5 separate WAN phy of the KS8995 directly connected to EthC. - The EthB MII is probably connected as CPU interface to the KS8995. Properly integrate the KS8995 switch using the new bindings. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250625-ks8995-dsa-bindings-v2-2-ce71dce9be0b@linaro.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-27dt-bindings: dsa: Rewrite Micrel KS8995 in schemaLinus Walleij
After studying the datasheets for some of the KS8995 variants it becomes pretty obvious that this is a straight-forward and simple MII DSA switch with one port in (CPU) and four outgoing ports, and it even supports custom tags by setting a bit in a special register, and elaborate VLAN handling as all DSA switches do. What is a bit odd with KS8995 is that it uses an extra MII-P5 port to access one of the PHYs separately, on the side of the switch fabric, such as when using a WAN port separately from a LAN switch in a home router. Rewrite the terse bindings to YAML, and move to the proper subdirectory. Include a verbose example to make things clear. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20250625-ks8995-dsa-bindings-v2-1-ce71dce9be0b@linaro.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-27MAINTAINERS: update smc sectionJan Karcher
Due to changes of my responsibilities within IBM i can no longer act as maintainer for smc. As a result of the co-operation with Alibaba over the last years we decided to, once more, give them more responsibility for smc by appointing D. Wythe <alibuda@linux.alibaba.com> and Dust Li <dust.li@linux.alibaba.com> as maintainers as well. Within IBM Sidraya Jayagond <sidraya@linux.ibm.com> and Mahanta Jambigi <mjambigi@linux.ibm.com> are going to take over the maintainership for smc. Signed-off-by: Jan Karcher <jaka@linux.ibm.com> Reviewed-by: Wenjia Zhang <wenjia@linux.ibm.com> Link: https://patch.msgid.link/20250626051653.4259-1-jaka@linux.ibm.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-27dt-bindings: net: sun8i-emac: Add A100 EMAC compatiblePaul Kocialkowski
The Allwinner A100/A133 has an Ethernet MAC (EMAC) controller that is compatible with the A64 one. It features the same syscon registers for control of the top-level integration of the unit. Signed-off-by: Paul Kocialkowski <paulk@sys-base.io> Acked-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20250626080923.632789-4-paulk@sys-base.io Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-27Merge branch 'nfc-trf7970a-add-option-to-reduce-antenna-gain'Jakub Kicinski
Paul Geurts says: ==================== NFC: trf7970a: Add option to reduce antenna gain The TRF7970a device is sensitive to RF disturbances, which can make it hard to pass some EMC immunity tests. By reducing the RX antenna gain, the device becomes less sensitive to EMC disturbances, as a trade-off against antenna performance. ==================== Link: https://patch.msgid.link/20250626141242.3749958-1-paul.geurts@prodrive-technologies.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-27NFC: trf7970a: Create device-tree parameter for RX gain reductionPaul Geurts
The TRF7970a device is sensitive to RF disturbances, which can make it hard to pass some EMC immunity tests. By reducing the RX antenna gain, the device becomes less sensitive to EMC disturbances, as a trade-off against antenna performance. Add a device tree option to select RX gain reduction to improve EMC performance. Selecting a communication standard in the ISO control register resets the RX antenna gain settings. Therefore set the RX gain reduction everytime the ISO control register changes, when the option is used. Signed-off-by: Paul Geurts <paul.geurts@prodrive-technologies.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://patch.msgid.link/20250626141242.3749958-3-paul.geurts@prodrive-technologies.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-27dt-bindings: net/nfc: ti,trf7970a: Add ti,rx-gain-reduction-db optionPaul Geurts
Add option to reduce the RX antenna gain to be able to reduce the sensitivity. Signed-off-by: Paul Geurts <paul.geurts@prodrive-technologies.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://patch.msgid.link/20250626141242.3749958-2-paul.geurts@prodrive-technologies.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-27dt-bindings: net: convert lpc-eth.txt yaml formatFrank Li
Convert lpc-eth.txt yaml format. Signed-off-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20250624202028.2516257-1-Frank.Li@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-28Merge tag 'drm-misc-fixes-2025-06-26' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes drm-misc-fixes for v6.16-rc4: - Fix function signature of drm_writeback_connector_cleanup. - Use correct HDMI audio bridge in drm_connector_hdmi_audio_init. - Make HPD work on SN65DSI86. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://lore.kernel.org/r/3dd1d5e1-73b6-4b0c-a208-f7d6235cf530@linux.intel.com
2025-06-27Merge branch 'ref_tracker-fix'Jakub Kicinski
Merge a fix from Jeff from a stable commit ID: * ref_tracker: do xarray and workqueue job initializations earlier Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-27ref_tracker: do xarray and workqueue job initializations earlierJeff Layton
The kernel test robot reported an oops that occurred when attempting to deregister a dentry from the xarray during subsys_initcall(). The ref_tracker xarrays and workqueue job are being initialized in late_initcall() which is too late. Move those to postcore_initcall() instead. Fixes: 65b584f53611 ("ref_tracker: automatically register a file in debugfs for a ref_tracker_dir") Reported-by: kernel test robot <oliver.sang@intel.com> Closes: https://lore.kernel.org/oe-lkp/202506251406.c28f2adb-lkp@intel.com Signed-off-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org> Link: https://patch.msgid.link/20250626-reftrack-dbgfs-v1-1-812102e2a394@kernel.org
2025-06-27tracing: Fix filter logic errorEdward Adam Davis
If the processing of the tr->events loop fails, the filter that has been added to filter_head will be released twice in free_filter_list(&head->rcu) and __free_filter(filter). After adding the filter of tr->events, add the filter to the filter_head process to avoid triggering uaf. Link: https://lore.kernel.org/tencent_4EF87A626D702F816CD0951CE956EC32CD0A@qq.com Fixes: a9d0aab5eb33 ("tracing: Fix regression of filter waiting a long time on RCU synchronization") Reported-by: syzbot+daba72c4af9915e9c894@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=daba72c4af9915e9c894 Tested-by: syzbot+daba72c4af9915e9c894@syzkaller.appspotmail.com Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by: Edward Adam Davis <eadavis@qq.com> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2025-06-27Merge tag 'acpi-6.16-rc4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI fix from Rafael Wysocki: "Revert a commit that attempted to fix a memory leak in an error code path and introduced a different issue (Zhe Qiao)" * tag 'acpi-6.16-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: Revert "PCI/ACPI: Fix allocated memory release on error in pci_acpi_scan_root()"
2025-06-27Bluetooth: HCI: Set extended advertising data synchronouslyChristian Eggers
Currently, for controllers with extended advertising, the advertising data is set in the asynchronous response handler for extended adverstising params. As most advertising settings are performed in a synchronous context, the (asynchronous) setting of the advertising data is done too late (after enabling the advertising). Move setting of adverstising data from asynchronous response handler into synchronous context to fix ordering of HCI commands. Signed-off-by: Christian Eggers <ceggers@arri.de> Fixes: a0fb3726ba55 ("Bluetooth: Use Set ext adv/scan rsp data if controller supports") Cc: stable@vger.kernel.org v2: https://lore.kernel.org/linux-bluetooth/20250626115209.17839-1-ceggers@arri.de/ Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2025-06-27Bluetooth: MGMT: mesh_send: check instances prior disabling advertisingChristian Eggers
The unconditional call of hci_disable_advertising_sync() in mesh_send_done_sync() also disables other LE advertisings (non mesh related). I am not sure whether this call is required at all, but checking the adv_instances list (like done at other places) seems to solve the problem. Fixes: b338d91703fa ("Bluetooth: Implement support for Mesh") Cc: stable@vger.kernel.org Signed-off-by: Christian Eggers <ceggers@arri.de> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2025-06-27Bluetooth: MGMT: set_mesh: update LE scan interval and windowChristian Eggers
According to the message of commit b338d91703fa ("Bluetooth: Implement support for Mesh"), MGMT_OP_SET_MESH_RECEIVER should set the passive scan parameters. Currently the scan interval and window parameters are silently ignored, although user space (bluetooth-meshd) expects that they can be used [1] [1] https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/mesh/mesh-io-mgmt.c#n344 Fixes: b338d91703fa ("Bluetooth: Implement support for Mesh") Cc: stable@vger.kernel.org Signed-off-by: Christian Eggers <ceggers@arri.de> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2025-06-27Bluetooth: hci_sync: revert some mesh modificationsChristian Eggers
This reverts minor parts of the changes made in commit b338d91703fa ("Bluetooth: Implement support for Mesh"). It looks like these changes were only made for development purposes but shouldn't have been part of the commit. Fixes: b338d91703fa ("Bluetooth: Implement support for Mesh") Cc: stable@vger.kernel.org Signed-off-by: Christian Eggers <ceggers@arri.de> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2025-06-27Bluetooth: Prevent unintended pause by checking if advertising is activeYang Li
When PA Create Sync is enabled, advertising resumes unexpectedly. Therefore, it's necessary to check whether advertising is currently active before attempting to pause it. < HCI Command: LE Add Device To... (0x08|0x0011) plen 7 #1345 [hci0] 48.306205 Address type: Random (0x01) Address: 4F:84:84:5F:88:17 (Resolvable) Identity type: Random (0x01) Identity: FC:5B:8C:F7:5D:FB (Static) < HCI Command: LE Set Address Re.. (0x08|0x002d) plen 1 #1347 [hci0] 48.308023 Address resolution: Enabled (0x01) ... < HCI Command: LE Set Extended A.. (0x08|0x0039) plen 6 #1349 [hci0] 48.309650 Extended advertising: Enabled (0x01) Number of sets: 1 (0x01) Entry 0 Handle: 0x01 Duration: 0 ms (0x00) Max ext adv events: 0 ... < HCI Command: LE Periodic Adve.. (0x08|0x0044) plen 14 #1355 [hci0] 48.314575 Options: 0x0000 Use advertising SID, Advertiser Address Type and address Reporting initially enabled SID: 0x02 Adv address type: Random (0x01) Adv address: 4F:84:84:5F:88:17 (Resolvable) Identity type: Random (0x01) Identity: FC:5B:8C:F7:5D:FB (Static) Skip: 0x0000 Sync timeout: 20000 msec (0x07d0) Sync CTE type: 0x0000 Fixes: ad383c2c65a5 ("Bluetooth: hci_sync: Enable advertising when LL privacy is enabled") Signed-off-by: Yang Li <yang.li@amlogic.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2025-06-27Merge tag 'block-6.16-20250626' of git://git.kernel.dk/linuxLinus Torvalds
Pull block fixes from Jens Axboe: - Fixes for ublk: - fix C++ narrowing warnings in the uapi header - update/improve UBLK_F_SUPPORT_ZERO_COPY comment in uapi header - fix for the ublk ->queue_rqs() implementation, limiting a batch to just the specific task AND ring - ublk_get_data() error handling fix - sanity check more arguments in ublk_ctrl_add_dev() - selftest addition - NVMe pull request via Christoph: - reset delayed remove_work after reconnect - fix atomic write size validation - Fix for a warning introduced in bdev_count_inflight_rw() in this merge window * tag 'block-6.16-20250626' of git://git.kernel.dk/linux: block: fix false warning in bdev_count_inflight_rw() ublk: sanity check add_dev input for underflow nvme: fix atomic write size validation nvme: refactor the atomic write unit detection nvme: reset delayed remove_work after reconnect ublk: setup ublk_io correctly in case of ublk_get_data() failure ublk: update UBLK_F_SUPPORT_ZERO_COPY comment in UAPI header ublk: fix narrowing warnings in UAPI header selftests: ublk: don't take same backing file for more than one ublk devices ublk: build batch from IOs in same io_ring_ctx and io task
2025-06-27Merge tag 'io_uring-6.16-20250626' of git://git.kernel.dk/linuxLinus Torvalds
Pull io_uring fixes from Jens Axboe: - Two tweaks for a recent fix: fixing a memory leak if multiple iovecs were initially mapped but only the first was used and hence turned into a UBUF rathan than an IOVEC iterator, and catching a case where a retry would be done even if the previous segment wasn't full - Small series fixing an issue making the vm unhappy if debugging is turned on, hitting a VM_BUG_ON_PAGE() - Fix a resource leak in io_import_dmabuf() in the error handling case, which is a regression in this merge window - Mark fallocate as needing to be write serialized, as is already done for truncate and buffered writes * tag 'io_uring-6.16-20250626' of git://git.kernel.dk/linux: io_uring/kbuf: flag partial buffer mappings io_uring/net: mark iov as dynamically allocated even for single segments io_uring: fix resource leak in io_import_dmabuf() io_uring: don't assume uaddr alignment in io_vec_fill_bvec io_uring/rsrc: don't rely on user vaddr alignment io_uring/rsrc: fix folio unpinning io_uring: make fallocate be hashed work
2025-06-27Merge tag 'ata-6.16-rc4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux Pull ata fix from Niklas Cassel: - Use the correct DMI identifier for ASUSPRO-D840SA LPM quirk such that the quirk actually gets applied (me) * tag 'ata-6.16-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux: ata: ahci: Use correct DMI identifier for ASUSPRO-D840SA LPM quirk
2025-06-27Merge tag 's390-6.16-3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 fixes from Alexander Gordeev: - Fix incorrectly dropped dereferencing of the stack nth entry introduced with a previous KASAN false positive fix - Use a proper memdup_array_user() helper to prevent overflow in a protected key size calculation * tag 's390-6.16-3' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/ptrace: Fix pointer dereferencing in regs_get_kernel_stack_nth() s390/pkey: Prevent overflow in size calculation for memdup_user()
2025-06-27Merge tag 'sound-6.16-rc4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "A collection of small fixes again: - A regression fix for hibernation bug in ASoC SoundWire - Fixes for the new Qualcomm USB offload stuff - A potential OOB access fix in USB-audio - A potential memleadk fix in ASoC Intel - Quirks for HD-audio and ASoC AMD ACP" * tag 'sound-6.16-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: ALSA: hda/realtek: Fix built-in mic on ASUS VivoBook X507UAR ALSA: usb: qcom: fix NULL pointer dereference in qmi_stop_session ASoC: SOF: Intel: hda: Use devm_kstrdup() to avoid memleak. ASoC: rt721-sdca: fix boost gain calculation error ALSA: qc_audio_offload: Fix missing error code in prepare_qmi_response() ALSA: hda/realtek: Add mic-mute LED setup for ASUS UM5606 ALSA: usb-audio: Fix out-of-bounds read in snd_usb_get_audioformat_uac3() ALSA: hda/realtek: fix mute/micmute LEDs for HP EliteBook 6 G1a ASoC: amd: ps: fix for soundwire failures during hibernation exit sequence ASoC: amd: yc: Add DMI quirk for Lenovo IdeaPad Slim 5 15 ASoC: amd: yc: add quirk for Acer Nitro ANV15-41 internal mic ASoC: qcom: sm8250: Fix possibly undefined reference ALSA: hda/realtek - Enable mute LED on HP Pavilion Laptop 15-eg100 ALSA: hda/realtek: Add quirks for some Clevo laptops
2025-06-27xfs: fix unmount hang with unflushable inodes stuck in the AILDave Chinner
Unmount of a shutdown filesystem can hang with stale inode cluster buffers in the AIL like so: [95964.140623] Call Trace: [95964.144641] __schedule+0x699/0xb70 [95964.154003] schedule+0x64/0xd0 [95964.156851] xfs_ail_push_all_sync+0x9b/0xf0 [95964.164816] xfs_unmount_flush_inodes+0x41/0x70 [95964.168698] xfs_unmountfs+0x7f/0x170 [95964.171846] xfs_fs_put_super+0x3b/0x90 [95964.175216] generic_shutdown_super+0x77/0x160 [95964.178060] kill_block_super+0x1b/0x40 [95964.180553] xfs_kill_sb+0x12/0x30 [95964.182796] deactivate_locked_super+0x38/0x100 [95964.185735] deactivate_super+0x41/0x50 [95964.188245] cleanup_mnt+0x9f/0x160 [95964.190519] __cleanup_mnt+0x12/0x20 [95964.192899] task_work_run+0x89/0xb0 [95964.195221] resume_user_mode_work+0x4f/0x60 [95964.197931] syscall_exit_to_user_mode+0x76/0xb0 [95964.201003] do_syscall_64+0x74/0x130 $ pstree -N mnt |grep umount |-check-parallel---nsexec---run_test.sh---753---umount It always seems to be generic/753 that triggers this, and repeating a quick group test run triggers it every 10-15 iterations. Hence it generally triggers once up every 30-40 minutes of test time. just running generic/753 by itself or concurrently with a limited group of tests doesn't reproduce this issue at all. Tracing on a hung system shows the AIL repeating every 50ms a log force followed by an attempt to push pinned, aborted inodes from the AIL (trimmed for brevity): xfs_log_force: lsn 0x1c caller xfsaild+0x18e xfs_log_force: lsn 0x0 caller xlog_cil_flush+0xbd xfs_log_force: lsn 0x1c caller xfs_log_force+0x77 xfs_ail_pinned: lip 0xffff88826014afa0 lsn 1/37472 type XFS_LI_INODE flags IN_AIL|ABORTED xfs_ail_pinned: lip 0xffff88814000a708 lsn 1/37472 type XFS_LI_INODE flags IN_AIL|ABORTED xfs_ail_pinned: lip 0xffff88810b850c80 lsn 1/37472 type XFS_LI_INODE flags IN_AIL|ABORTED xfs_ail_pinned: lip 0xffff88810b850af0 lsn 1/37472 type XFS_LI_INODE flags IN_AIL|ABORTED xfs_ail_pinned: lip 0xffff888165cf0a28 lsn 1/37472 type XFS_LI_INODE flags IN_AIL|ABORTED xfs_ail_pinned: lip 0xffff88810b850bb8 lsn 1/37472 type XFS_LI_INODE flags IN_AIL|ABORTED .... The inode log items are marked as aborted, which means that either: a) a transaction commit has occurred, seen an error or shutdown, and called xfs_trans_free_items() to abort the items. This should happen before any pinning of log items occurs. or b) a dirty transaction has been cancelled. This should also happen before any pinning of log items occurs. or c) AIL insertion at journal IO completion is marked as aborted. In this case, the log item is pinned by the CIL until journal IO completes and hence needs to be unpinned. This is then done after the ->iop_committed() callback is run, so the pin count should be balanced correctly. Yet none of these seemed to be occurring. Further tracing indicated this: d) Shutdown during CIL pushing resulting in log item completion being called from checkpoint abort processing. Items are unpinned and released without serialisation against each other, journal IO completion or transaction commit completion. In this case, we may still have a transaction commit in flight that holds a reference to a xfs_buf_log_item (BLI) after CIL insertion. e.g. a synchronous transaction will flush the CIL before the transaction is torn down. The concurrent CIL push then aborts insertion it and drops the commit/AIL reference to the BLI. This can leave the transaction commit context with the last reference to the BLI which is dropped here: xfs_trans_free_items() ->iop_release xfs_buf_item_release xfs_buf_item_put if (XFS_LI_ABORTED) xfs_trans_ail_delete xfs_buf_item_relse() Unlike the journal completion ->iop_unpin path, this path does not run stale buffer completion process when it drops the last reference, hence leaving the stale inodes attached to the buffer sitting the AIL. There are no other references to those inodes, so there is no other mechanism to remove them from the AIL. Hence unmount hangs. The buffer lock context for stale buffers is passed to the last BLI reference. This is normally the last BLI unpin on journal IO completion. The unpin then processes the stale buffer completion and releases the buffer lock. However, if the final unpin from journal IO completion (or CIL push abort) does not hold the last reference to the BLI, there -must- still be a transaction context that references the BLI, and so that context must perform the stale buffer completion processing before the buffer is unlocked and the BLI torn down. The fix for this is to rework the xfs_buf_item_relse() path to run stale buffer completion processing if it drops the last reference to the BLI. We still hold the buffer locked, so the buffer owner and lock context is the same as if we passed the BLI and buffer to the ->iop_unpin() context to finish stale process on journal commit. However, we have to be careful here. In a shutdown state, we can be freeing dirty BLIs from xfs_buf_item_put() via xfs_trans_brelse() and xfs_trans_bdetach(). The existing code handles this case by considering shutdown state as "aborted", but in doing so largely masks the failure to clean up stale BLI state from the xfs_buf_item_relse() path. i.e regardless of the shutdown state and whether the item is in the AIL, we must finish the stale buffer cleanup if we are are dropping the last BLI reference from the ->iop_relse path in transaction commit context. Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Signed-off-by: Carlos Maiolino <cem@kernel.org>
2025-06-27xfs: factor out stale buffer item completionDave Chinner
The stale buffer item completion handling is currently only done from BLI unpinning. We need to perform this function from where-ever the last reference to the BLI is dropped, so first we need to factor this code out into a helper. Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Signed-off-by: Carlos Maiolino <cem@kernel.org>
2025-06-27xfs: rearrange code in xfs_buf_item.cDave Chinner
The code to initialise, release and free items is all the way down the bottom of the file. Upcoming fixes need to these functions earlier in the file, so move them to the top. There is one code change in this move - the parameter to xfs_buf_item_relse() is changed from the xfs_buf to the xfs_buf_log_item - the thing that the function is releasing. Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Signed-off-by: Carlos Maiolino <cem@kernel.org>
2025-06-27xfs: add tracepoints for stale pinned inode state debugDave Chinner
I needed more insight into how stale inodes were getting stuck on the AIL after a forced shutdown when running fsstress. These are the tracepoints I added for that purpose. Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Signed-off-by: Carlos Maiolino <cem@kernel.org>
2025-06-27xfs: avoid dquot buffer pin deadlockDave Chinner
On shutdown when quotas are enabled, the shutdown can deadlock trying to unpin the dquot buffer buf_log_item like so: [ 3319.483590] task:kworker/20:0H state:D stack:14360 pid:1962230 tgid:1962230 ppid:2 task_flags:0x4208060 flags:0x00004000 [ 3319.493966] Workqueue: xfs-log/dm-6 xlog_ioend_work [ 3319.498458] Call Trace: [ 3319.500800] <TASK> [ 3319.502809] __schedule+0x699/0xb70 [ 3319.512672] schedule+0x64/0xd0 [ 3319.515573] schedule_timeout+0x30/0xf0 [ 3319.528125] __down_common+0xc3/0x200 [ 3319.531488] __down+0x1d/0x30 [ 3319.534186] down+0x48/0x50 [ 3319.540501] xfs_buf_lock+0x3d/0xe0 [ 3319.543609] xfs_buf_item_unpin+0x85/0x1b0 [ 3319.547248] xlog_cil_committed+0x289/0x570 [ 3319.571411] xlog_cil_process_committed+0x6d/0x90 [ 3319.575590] xlog_state_shutdown_callbacks+0x52/0x110 [ 3319.580017] xlog_force_shutdown+0x169/0x1a0 [ 3319.583780] xlog_ioend_work+0x7c/0xb0 [ 3319.587049] process_scheduled_works+0x1d6/0x400 [ 3319.591127] worker_thread+0x202/0x2e0 [ 3319.594452] kthread+0x20c/0x240 The CIL push has seen the deadlock, so it has aborted the push and is running CIL checkpoint completion to abort all the items in the checkpoint. This calls ->iop_unpin(remove = true) to clean up the log items in the checkpoint. When a buffer log item is unpined like this, it needs to lock the buffer to run io completion to correctly fail the buffer and run all the required completions to fail attached log items as well. In this case, the attempt to lock the buffer on unpin is hanging because the buffer is already locked. I suspected a leaked XFS_BLI_HOLD state because of XFS_BLI_STALE handling changes I was testing, so I went looking for pin events on HOLD buffers and unpin events on locked buffer. That isolated this one buffer with these two events: xfs_buf_item_pin: dev 251:6 daddr 0xa910 bbcount 0x2 hold 2 pincount 0 lock 0 flags DONE|KMEM recur 0 refcount 1 bliflags HOLD|DIRTY|LOGGED liflags DIRTY .... xfs_buf_item_unpin: dev 251:6 daddr 0xa910 bbcount 0x2 hold 4 pincount 1 lock 0 flags DONE|KMEM recur 0 refcount 1 bliflags DIRTY liflags ABORTED Firstly, bbcount = 0x2, which means it is not a single sector structure. That rules out every xfs_trans_bhold() case except one: dquot buffers. Then hung task dumping gave this trace: [ 3197.312078] task:fsync-tester state:D stack:12080 pid:2051125 tgid:2051125 ppid:1643233 task_flags:0x400000 flags:0x00004002 [ 3197.323007] Call Trace: [ 3197.325581] <TASK> [ 3197.327727] __schedule+0x699/0xb70 [ 3197.334582] schedule+0x64/0xd0 [ 3197.337672] schedule_timeout+0x30/0xf0 [ 3197.350139] wait_for_completion+0xbd/0x180 [ 3197.354235] __flush_workqueue+0xef/0x4e0 [ 3197.362229] xlog_cil_force_seq+0xa0/0x300 [ 3197.374447] xfs_log_force+0x77/0x230 [ 3197.378015] xfs_qm_dqunpin_wait+0x49/0xf0 [ 3197.382010] xfs_qm_dqflush+0x55/0x460 [ 3197.385663] xfs_qm_dquot_isolate+0x29e/0x4d0 [ 3197.389977] __list_lru_walk_one+0x141/0x220 [ 3197.398867] list_lru_walk_one+0x10/0x20 [ 3197.402713] xfs_qm_shrink_scan+0x6a/0x100 [ 3197.406699] do_shrink_slab+0x18a/0x350 [ 3197.410512] shrink_slab+0xf7/0x430 [ 3197.413967] drop_slab+0x97/0xf0 [ 3197.417121] drop_caches_sysctl_handler+0x59/0xc0 [ 3197.421654] proc_sys_call_handler+0x18b/0x280 [ 3197.426050] proc_sys_write+0x13/0x20 [ 3197.429750] vfs_write+0x2b8/0x3e0 [ 3197.438532] ksys_write+0x7e/0xf0 [ 3197.441742] __x64_sys_write+0x1b/0x30 [ 3197.445363] x64_sys_call+0x2c72/0x2f60 [ 3197.449044] do_syscall_64+0x6c/0x140 [ 3197.456341] entry_SYSCALL_64_after_hwframe+0x76/0x7e Yup, another test run by check-parallel is running drop_caches concurrently and the dquot shrinker for the hung filesystem is running. That's trying to flush a dirty dquot from reclaim context, and it waiting on a log force to complete. xfs_qm_dqflush is called with the dquot buffer held locked, and so we've called xfs_log_force() with that buffer locked. Now the log force is waiting for a workqueue flush to complete, and that workqueue flush is waiting of CIL checkpoint processing to finish. The CIL checkpoint processing is aborting all the log items it has, and that requires locking aborted buffers to cancel them. Now, normally this isn't a problem if we are issuing a log force to unpin an object, because the ->iop_unpin() method wakes pin waiters first. That results in the pin waiter finishing off whatever it was doing, dropping the lock and then xfs_buf_item_unpin() can lock the buffer and fail it. However, xfs_qm_dqflush() is waiting on the -dquot- unpin event, not the dquot buffer unpin event, and so it never gets woken and so does not drop the buffer lock. Inodes do not have this problem, as they can only be written from one spot (->iop_push) whilst dquots can be written from multiple places (memory reclaim, ->iop_push, xfs_dq_dqpurge, and quotacheck). The reason that the dquot buffer has an attached buffer log item is that it has been recently allocated. Initialisation of the dquot buffer logs the buffer directly, thereby pinning it in memory. We then modify the dquot in a separate operation, and have memory reclaim racing with a shutdown and we trigger this deadlock. check-parallel reproduces this reliably on 1kB FSB filesystems with quota enabled because it does all of these things concurrently without having to explicitly write tests to exercise these corner case conditions. xfs_qm_dquot_logitem_push() doesn't have this deadlock because it checks if the dquot is pinned before locking the dquot buffer and skipping it if it is pinned. This means the xfs_qm_dqunpin_wait() log force in xfs_qm_dqflush() never triggers and we unlock the buffer safely allowing a concurrent shutdown to fail the buffer appropriately. xfs_qm_dqpurge() could have this problem as it is called from quotacheck and we might have allocated dquot buffers when recording the quota updates. This can be fixed by calling xfs_qm_dqunpin_wait() before we lock the dquot buffer. Because we hold the dquot locked, nothing will be able to add to the pin count between the unpin_wait and the dqflush callout, so this now makes xfs_qm_dqpurge() safe against this race. xfs_qm_dquot_isolate() can also be fixed this same way but, quite frankly, we shouldn't be doing IO in memory reclaim context. If the dquot is pinned or dirty, simply rotate it and let memory reclaim come back to it later, same as we do for inodes. This then gets rid of the nasty issue in xfs_qm_flush_one() where quotacheck writeback races with memory reclaim flushing the dquots. We can lift xfs_qm_dqunpin_wait() up into this code, then get rid of the "can't get the dqflush lock" buffer write to cycle the dqlfush lock and enable it to be flushed again. checking if the dquot is pinned and returning -EAGAIN so that the dquot walk will revisit the dquot again later. Finally, with xfs_qm_dqunpin_wait() lifted into all the callers, we can remove it from the xfs_qm_dqflush() code. Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Signed-off-by: Carlos Maiolino <cem@kernel.org>