summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-05-22scsi: devinfo: Add BLIST_NO_RSOC for Promise VTrak E310fAlexander Perlis
The extremely slow boots reported July 2014 in bug 79901: https://bugzilla.kernel.org/show_bug.cgi?id=79901 for Promise VTrak E610f 3U 16-bay FC RAID enclosure occur also with the Promise VTrak E310f 2U 12-bay FC RAID enclosure. The 2014 patch: https://bugzilla.kernel.org/attachment.cgi?id=144101&action=diff added support for the BLIST_NO_RSOC flag and specified that flag for the Promise VTrak E610f. This current patch simply adds the E310f to that same list. One curiosity is the additional BLIST_SPARSELUN flag. This was also in the 2014 patch for the E610f, and was already in place for *all* Promise devices since 2007 due to commit e0b2e597d5dd ("[SCSI] stex: fix id mapping issue") which added the line: {"Promise", "", NULL, BLIST_SPARSELUN} The 2007 commit message talks of issues with SuperTrak EX (stex) but the added line did not limit itself to that particular device family. The current patch for E310F, like the 2014 patch for E610f, adds BLIST_NO_RSOC while preserving BLIST_SPARSELUN from 2007. Signed-off-by: Alexander Perlis <aperlis@math.lsu.edu> Suggested-by: Nikkos Svoboda <nsvoboda@math.lsu.edu> Link: https://patch.msgid.link/20260512231254.27530-1-aperlis@math.lsu.edu Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2026-05-22scsi: ufs: ufs-qcom: Use quirk EXTENDED_TX_EQTR_ADAPT_LENGTH_L0L1L2L3Can Guo
Use UFSHCD_QUIRK_EXTENDED_TX_EQTR_ADAPT_LENGTH_L0L1L2L3 for UFS Hosts HW major version 0x7 & minor version 0x1. Signed-off-by: Can Guo <can.guo@oss.qualcomm.com> Reviewed-by: Ziqi Chen <ziqi.chen@oss.qualcomm.com> Reviewed-by: Bean Huo <beanhuo@micron.com> Link: https://patch.msgid.link/20260501131641.826258-3-can.guo@oss.qualcomm.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2026-05-22scsi: ufs: core: Add a quirk for extended TX EQTR Adapt L0L1L2L3 lengthCan Guo
Add a quirk to support TX Equalization Training (EQTR) using Adapt L0L1L2L3 length which is larger than what is allowed by M-PHY spec ver 6.0. Signed-off-by: Can Guo <can.guo@oss.qualcomm.com> Reviewed-by: Bean Huo <beanhuo@micron.com> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Reviewed-by: Peter Wang <peter.wang@mediatek.com> Reviewed-by: Ziqi Chen <ziqi.chen@oss.qualcomm.com> Link: https://patch.msgid.link/20260501131641.826258-2-can.guo@oss.qualcomm.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2026-05-22scsi: scsi_ioctl: Use strnlen() in scsi_ioctl_get_pci()Thorsten Blum
Use strnlen() to limit string scanning to 20 characters. Reformat the code and use tabs instead of spaces while at it. [mkp: tweaked comment formatting] Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Reviewed-by: John Garry <john.g.garry@oracle.com> Link: https://patch.msgid.link/20260517171546.2304-2-thorsten.blum@linux.dev Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2026-05-22scsi: core: Run queues for all non-SDEV_DEL devices from scsi_run_host_queuesDavid Jeffery
While a SCSI host is in a recovery state, scsi_mq_requeue_cmd() will not set the requeue list for a requeued command to be kicked in the future. The expectation is a call to scsi_run_host_queues() will kick all SCSI devices once the recovery state is cleared. However, scsi_run_host_queues() uses shost_for_each_device() which uses scsi_device_get() and so will ignore devices in a partially removed state like SDEV_CANCEL. But these devices may also have requeued requests, leaving their requests stuck from not being kicked and causing the removal process of the device to hang. scsi_run_host_queues() needs to run against more devices than the macro shost_for_each_device() allows. Instead of using the too limiting scsi_device_get() state checks, only ignore devices in SDEV_DEL state or when unable to acquire a reference. Attempt to run the queues for all other devices when scsi_run_host_queues() is called. Fixes: 8b566edbdbfb ("scsi: core: Only kick the requeue list if necessary") Signed-off-by: David Jeffery <djeffery@redhat.com> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Link: https://patch.msgid.link/20260515180941.9698-1-djeffery@redhat.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2026-05-22net/iucv: fix locking in .getsockoptBreno Leitao
Mirror iucv_sock_setsockopt() and wrap the whole switch in lock_sock()/release_sock(). The pre-existing SO_MSGLIMIT-only lock becomes redundant and is removed. Any AF_IUCV HIPER user can potentially crash the kernel by racing recvmsg() with getsockopt(SO_MSGSIZE): the SO_MSGSIZE arm dereferences iucv->hs_dev->mtu after iucv_sock_close() (called from the racing recvmsg()) has set hs_dev to NULL, producing a NULL pointer dereference oops. Suggested-by: Stanislav Fomichev <sdf.kernel@gmail.com> Fixes: 51363b8751a6 ("af_iucv: allow retrieval of maximum message size") Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Alexandra Winter <wintera@linux.ibm.com> Tested-by: Alexandra Winter <wintera@linux.ibm.com> Link: https://patch.msgid.link/20260521-af_iucv_fix2-v1-1-f16b1c510aa9@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-22perf tests: Add test for stat delay option with duration_timeIan Rogers
Add a new test case `test_stat_delay` to `stat.sh` to verify that `duration_time` correctly excludes the delay period when using the delay option (-D). The test runs `perf stat -D 1000 -e duration_time sleep 2` and verifies that `duration_time` is ~1s (excluding the 1s delay), not ~2s. Assisted-by: Antigravity:gemini-3-flash Signed-off-by: Ian Rogers <irogers@google.com> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Francesco Nigro <nigro.fra@gmail.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: James Clark <james.clark@linaro.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Richter <tmricht@linux.ibm.com> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2026-05-22net/smc: Do not re-initialize smc hashtablesAlexandra Winter
INIT_HLIST_HEAD(&smc_v*_hashinfo.ht) are called after smc_nl_init(), proto_register() and sock_register(). This can lead to smc_v*_hashinfo.ht being reset even though hash entries already exist and are being used, possibly resulting in a corrupted list. Remove unnecessary and dangerous re-initialisation of smc_v*_hashinfo.ht in smc_init(); it is implicitly initialised to zero anyhow. Add HLIST_HEAD_INIT to the definitions for clarity. Fixes: f16a7dd5cf27 ("smc: netlink interface for SMC sockets") Suggested-by: Halil Pasic <pasic@linux.ibm.com> Signed-off-by: Alexandra Winter <wintera@linux.ibm.com> Acked-by: Halil Pasic <pasic@linux.ibm.com> Reviewed-by: Mahanta Jambigi <mjambigi@linux.ibm.com> Link: https://patch.msgid.link/20260521145639.10317-1-wintera@linux.ibm.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-22perf tool_pmu: Make tool PMU events respect enable/disableIan Rogers
Tool PMU events (duration_time, user_time, system_time) currently count from when the event is opened to when it is read. This causes issues with features like the delay option (-D) or control fd, where events are opened but should not start counting immediately. Make these events behave more like regular counters by implementing proper enable and disable support. Add accumulated_time to struct evsel to track time while enabled, and implement enable/disable CPU callbacks to start/stop counting. Also generalize userspace PMU mixed group handling. Userspace synthetic PMUs (type > PERF_PMU_TYPE_PE_END) do not have kernel implementations and cannot be grouped in the kernel (opened with group_fd = -1), and are skipped by kernel enable/disable calls. Iterate over group members in userspace and manually enable/disable any members if the leader or the member is a non-perf-event open PMU, and synchronize their disabled flags. Closes: https://lore.kernel.org/linux-perf-users/20260517093650.2540920-1-nigro.fra@gmail.com/ Fixes: b71f46a6a7086175 ("perf stat: Remove hard coded shadow metrics") Reported-by: Francesco Nigro <nigro.fra@gmail.com> Assisted-by: Antigravity:gemini-3-flash Signed-off-by: Ian Rogers <irogers@google.com> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: James Clark <james.clark@linaro.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Richter <tmricht@linux.ibm.com> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2026-05-22net: stmmac: mmc: Remove duplicate mmc_rx crcAbid Ali
MMC_XGMAC_RX_CRC_ERR is clear-on-read, and just a single read would update the mmc_rx_crc_error counter. The duplicate read appears to have been unintentionally introduced in the intial MMC counter implementation [1]. The databook does not mention MMC_XGMAC_RX_CRC_ERR needing the additional read. [1] commit b6cdf09f51c2 ("net: stmmac: xgmac: Implement MMC counters") Signed-off-by: Abid Ali <dev.taqnialabs@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260521-xgmac-mmc_rx_crc-cleanup-v2-1-7d9de09f5898@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-22dpll: change dpll_netdev_pin_handle_size() to assume DPLL_A_PIN_ID will be usedEric Dumazet
We plan to no longer hold RTNL in "ip link show", and use RCU instead. Assume rtnl_fill_dpll_pin() will have to fill DPLL_A_PIN_ID. It is fine to over-estimate skb size (by 8 bytes) in if_nlmsg_size(). Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Link: https://patch.msgid.link/20260521171440.114956-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-22rtnetlink: do not use RTNL in rtnl_af_register() and rtnl_af_unregister()Eric Dumazet
rtnl_af_lookup() does not rely on RTNL anymoe, remove the stale ASSERT_RTNL(). Add a private spinlock (rtnl_af_ops_lock) to protect rtnl_af_ops list instead of using RTNL. Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260521174038.204481-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-22perf doc: Document new IBS capabilities in man pageRavi Bangoria
Include examples of: o Privilege filter with Fetch and Op PMUs, including swfilt approach on Zen5 and older platforms and hardware assisted filter on Zen6 and newer platforms o Streaming store filter with Op PMU o Fetch latency filter with Fetch PMU Signed-off-by: Ravi Bangoria <ravi.bangoria@amd.com> Acked-by: Namhyung Kim <namhyung@kernel.org> Cc: Ananth Narayan <ananth.narayan@amd.com> Cc: Dapeng Mi <dapeng1.mi@linux.intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: James Clark <james.clark@linaro.org> Cc: Manali Shukla <manali.shukla@amd.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Sandipan Das <sandipan.das@amd.com> Cc: Santosh Shukla <santosh.shukla@amd.com> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2026-05-22perf amd ibs: Decode Streaming-store flag in IBS OP raw dumpRavi Bangoria
IBS OP on Zen6 and future platform can tag IBS samples that originate from streaming-store instruction. When the PMU advertises this feature, interpret IBS_OP_DATA2[8] bit as the streaming store indicator and show it in the raw dump output. Signed-off-by: Ravi Bangoria <ravi.bangoria@amd.com> Acked-by: Namhyung Kim <namhyung@kernel.org> Cc: Ananth Narayan <ananth.narayan@amd.com> Cc: Dapeng Mi <dapeng1.mi@linux.intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: James Clark <james.clark@linaro.org> Cc: Manali Shukla <manali.shukla@amd.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Sandipan Das <sandipan.das@amd.com> Cc: Santosh Shukla <santosh.shukla@amd.com> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2026-05-22perf amd ibs: Decode Remote-Socket flag in IBS OP raw dumpRavi Bangoria
IBS OP on Zen6 and future platform can mark a data source as coming from a remote socket. When the PMU advertises this feature, interpret IBS_OP_DATA2[9] bit as the Remote-Socket indicator and show it in the raw dump output. Signed-off-by: Ravi Bangoria <ravi.bangoria@amd.com> Acked-by: Namhyung Kim <namhyung@kernel.org> Cc: Ananth Narayan <ananth.narayan@amd.com> Cc: Dapeng Mi <dapeng1.mi@linux.intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: James Clark <james.clark@linaro.org> Cc: Manali Shukla <manali.shukla@amd.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Sandipan Das <sandipan.das@amd.com> Cc: Santosh Shukla <santosh.shukla@amd.com> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2026-05-22perf amd ibs: Make Fetch status bits dependent on PhyAddrValid for newer ↵Ravi Bangoria
platforms On Zen6 and future platforms, IBS_FETCH_CTL status fields are valid only if IBS_FETCH_CTL[IbsPhyAddrValid] is set. Same for IBS_FETCH_CTL_EXT. Add these checks while decoding IBS MSRs. Unfortunately, there is no CPUID bit to indicate the change. Fallback to Family/Model check. Signed-off-by: Ravi Bangoria <ravi.bangoria@amd.com> Acked-by: Namhyung Kim <namhyung@kernel.org> Cc: Ananth Narayan <ananth.narayan@amd.com> Cc: Dapeng Mi <dapeng1.mi@linux.intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: James Clark <james.clark@linaro.org> Cc: Manali Shukla <manali.shukla@amd.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Sandipan Das <sandipan.das@amd.com> Cc: Santosh Shukla <santosh.shukla@amd.com> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2026-05-22perf amd ibs: Suppress bogus TlbRefillLat and DCPhysAd on Zen4+Ravi Bangoria
On Zen4 (and future) CPUs, IBS_OP_DATA3[TlbRefillLat] is valid only if IBS_OP_DATA3[DcPhyAddrValid] is set. Similarly, IBS_DC_PHYSADDR is valid if IBS_OP_DATA3[DcLinAddrValid] is _also_ set. Add these checks while decoding IBS MSRs. When IBS is triggered by an unprivileged user, the kernel now zeroes PhysAddr before storing raw IBS register values in the perf sample. The perf tool, however, still outputs these zero physical addresses, which serves no purpose. So avoid printing zero physical addresses. Instead of explicit family/model checks use the !zen4_ibs_extensions as a proxy flag to cover Zen 3 and earlier revisions. Signed-off-by: Ravi Bangoria <ravi.bangoria@amd.com> Acked-by: Namhyung Kim <namhyung@kernel.org> Cc: Ananth Narayan <ananth.narayan@amd.com> Cc: Dapeng Mi <dapeng1.mi@linux.intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: James Clark <james.clark@linaro.org> Cc: Manali Shukla <manali.shukla@amd.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Sandipan Das <sandipan.das@amd.com> Cc: Santosh Shukla <santosh.shukla@amd.com> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2026-05-22perf test ibs: Skip privilege test on Zen6 and newer platformsRavi Bangoria
IBS on pre-Zen6 platforms lacked a hardware privilege filter, so the kernel enabled swfilt=1. Zen6 and newer platforms provides privilege filtering via the RIP[63] bit, making swfilt redundant. Skip the perf unit test that assumes IBS has no hardware-assisted privilege filter on Zen6 and newer platforms. swfilt is ignored by kernel on platforms that support RIP[63] bit filter i.e. all amd-ibs-swfilt.sh tests will test hardware assisted privilege filter. Without the patch on Zen6: # sudo ./perf test -vv 77 77: AMD IBS software filtering: --- start --- test child forked, pid 30813 check availability of IBS swfilt run perf record with modifier and swfilt [FAIL] IBS PMU should not accept exclude_kernel ---- end(-1) ---- 77: AMD IBS software filtering : FAILED! With the patch: # ./perf test -vv 77 77: AMD IBS software filtering: --- start --- test child forked, pid 30903 check availability of IBS swfilt run perf record with modifier and swfilt [ perf record: Woken up 2 times to write data ] [ perf record: Captured and wrote 0.000 MB /dev/null ] [ perf record: Woken up 3 times to write data ] [ perf record: Captured and wrote 0.000 MB /dev/null ] [ perf record: Woken up 3 times to write data ] [ perf record: Captured and wrote 0.000 MB /dev/null ] [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.000 MB /dev/null ] check number of samples with swfilt [ perf record: Woken up 4 times to write data ] [ perf record: Captured and wrote 0.051 MB - ] [ perf record: Woken up 4 times to write data ] [ perf record: Captured and wrote 0.063 MB - ] ---- end(0) ---- 77: AMD IBS software filtering : Ok Signed-off-by: Ravi Bangoria <ravi.bangoria@amd.com> Acked-by: Namhyung Kim <namhyung@kernel.org> Cc: Ananth Narayan <ananth.narayan@amd.com> Cc: Dapeng Mi <dapeng1.mi@linux.intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: James Clark <james.clark@linaro.org> Cc: Manali Shukla <manali.shukla@amd.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Sandipan Das <sandipan.das@amd.com> Cc: Santosh Shukla <santosh.shukla@amd.com> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2026-05-22perf tool ibs: Sync AMD IBS header fileRavi Bangoria
IBS_OP_DATA2 register will have two more fields: strm_st and rmt_socket in Zen6 and future AMD platforms. Kernel header file is already updated. Add those fields in tools copy as well. Signed-off-by: Ravi Bangoria <ravi.bangoria@amd.com> Acked-by: Namhyung Kim <namhyung@kernel.org> Cc: Ananth Narayan <ananth.narayan@amd.com> Cc: Dapeng Mi <dapeng1.mi@linux.intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: James Clark <james.clark@linaro.org> Cc: Manali Shukla <manali.shukla@amd.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Sandipan Das <sandipan.das@amd.com> Cc: Santosh Shukla <santosh.shukla@amd.com> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2026-05-22perf test amd ibs: Fix incorrect kernel version checkRavi Bangoria
"AMD IBS sample period" unit test is getting skipped on kernel v7.x. Fix the kernel version >= v6.15 check. Fixes: 21fb366b2f457611 ("perf test amd: Skip amd-ibs-period test on kernel < v6.15") Signed-off-by: Ravi Bangoria <ravi.bangoria@amd.com> Acked-by: Namhyung Kim <namhyung@kernel.org> Cc: Ananth Narayan <ananth.narayan@amd.com> Cc: Dapeng Mi <dapeng1.mi@linux.intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: James Clark <james.clark@linaro.org> Cc: Manali Shukla <manali.shukla@amd.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ravi Bangoria <ravi.bangoria@amd.com> Cc: Sandipan Das <sandipan.das@amd.com> Cc: Santosh Shukla <santosh.shukla@amd.com> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2026-05-22Merge branch 'net-dsa-yt921x-add-port-tbf-support'Jakub Kicinski
David Yang says: ==================== net: dsa: yt921x: Add port TBF support ==================== Link: https://patch.msgid.link/20260521010320.208138-1-mmyangfl@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-22net: dsa: yt921x: Add port TBF supportDavid Yang
React to TC_SETUP_QDISC_TBF and configure the egress shaper as appropriate with the maximum rate and burst size requested by the user. Per queue shaper is possible, though not touched in this commit. Signed-off-by: David Yang <mmyangfl@gmail.com> Link: https://patch.msgid.link/20260521010320.208138-4-mmyangfl@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-22net/sched: tbf: add extack to offload paramsDavid Yang
Drivers might have error messages to propagate to user space. Propagate the netlink extack so that they can inform user space in a verbal way of their limitations. Signed-off-by: David Yang <mmyangfl@gmail.com> Link: https://patch.msgid.link/20260521010320.208138-3-mmyangfl@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-22net/sched: prefer existing extack message in qdisc_offload_graft_helper()David Yang
Use NL_SET_ERR_MSG_WEAK so any existing error message (probably from the underlying driver) is used instead of the generic fallback. Signed-off-by: David Yang <mmyangfl@gmail.com> Link: https://patch.msgid.link/20260521010320.208138-2-mmyangfl@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-22Merge branch ↵Jakub Kicinski
'arcnet-remove-outdated-drivers-and-information-and-unused-code-small-cleanups-and-documentation-improvements' Ethan Nelson-Moore says: ==================== ARCnet: remove outdated drivers and information and unused code; small cleanups and documentation improvements This patch series mainly removes the ISA and PCMCIA ARCnet drivers and documentation for them and hardware they supported. While ARCnet is still used in industrial environments, and cards are still manufactured, it is unlikely anyone is still using it with ISA and PCMCIA cards. Removing these drivers reduces future maintenance burden. While updating the ARCnet documentation to remove references to the removed drivers, I noticed that it contained thousands of lines of outdated and irrelevant information (much of it so outdated that it would not even work on modern kernels). I took the opportunity to remove this information and improve the writing style slightly. I noticed that the BUS_ALIGN macro was always defined to 1, which meant that the custom arcnet_in/out/read/write* I/O macros were unnecessary. I expanded and removed them to make the code more straightforwards. I also corrected some typos and comments. ==================== Link: https://patch.msgid.link/20260521001631.45434-1-enelsonmoore@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-22net: arcnet: com20020-pci: avoid -Wformat-truncation warningEthan Nelson-Moore
When compiling the com20020-pci driver with W=1, I received the following warning: drivers/net/arcnet/com20020-pci.c:224:71: warning: ‘%d’ directive output may be truncated writing between 1 and 11 bytes into a region of size between 10 and 11 [-Wformat-truncation=] 224 | snprintf(dev->name, sizeof(dev->name), "arc%d-%d", dev->dev_id, i); In reality, this does not represent a problem, because i is bounded by the .devcount field in struct com20020_pci_card_info, which is statically defined for each card and very small. Quiet the invalid warning by changing the type of i and the .devcount field to be narrower. Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com> Link: https://patch.msgid.link/20260521001631.45434-8-enelsonmoore@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-22docs: net: arcnet: remove outdated/irrelevant information; improve styleEthan Nelson-Moore
The ARCnet documentation contains a lot of outdated and irrelevant information (such as changes in decades-old driver versions and messages from a former maintainer) and has some writing style issues. Remove this unnecessary information and improve the writing style. Also remove links to pages that no longer exist. Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com> Link: https://patch.msgid.link/20260521001631.45434-7-enelsonmoore@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-22net: arcnet: expand unnecessary I/O abstraction macrosEthan Nelson-Moore
Now that the BUS_ALIGN variable has been removed, the arcnet_in/out/read/write* macros behave identically to the functions they wrap. Expand them and remove their definitions to make the code easier to maintain. Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com> Link: https://patch.msgid.link/20260521001631.45434-6-enelsonmoore@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-22net: arcnet: remove code depending on nonexistent config optionEthan Nelson-Moore
The CONFIG_SA1100_CT6001 option has never existed in the kernel. Remove code in arcdevice.h referring to it. This allows the arcnet_(in|out)(s|)b macros to be simplified by removing the BUS_ALIGN macro. Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com> Link: https://patch.msgid.link/20260521001631.45434-5-enelsonmoore@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-22net: arcnet: remove ISA and PCMCIA support; modernize documentationEthan Nelson-Moore
While ARCnet is still used in industrial environments, and cards are still manufactured, it is unlikely anyone is still using it with ISA and PCMCIA cards. Reduce future maintenance burden by removing all ISA and PCMCIA ARCnet drivers and documentation related to them. Update instructions for loading modules and passing parameters to work on modern kernels and with the com20020_pci driver. Also take the opportunity to document the rest of the module parameters, correct a file path in Documentation/networking/arcnet.rst, and change a reference to /etc/rc.inet1, which no longer exists, to refer to ifconfig. Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com> Link: https://patch.msgid.link/20260521001631.45434-4-enelsonmoore@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-22net: arcnet: fix typos in commentsEthan Nelson-Moore
The ARCnet code contains quite a few typos in comments. Fix them. Initially noticed by inspection, then augmented using codespell. Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com> Link: https://patch.msgid.link/20260521001631.45434-3-enelsonmoore@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-22net: arcnet: com20020: remove misleading references to multicastEthan Nelson-Moore
ARCnet does not support multicast, only unicast and broadcast. In spite of this, the com20020 driver contains several references to multicast in a comment and a function name, including a FIXME that it should be implemented. Adjust the comment to make the lack of multicast support clear and rename com20020_set_mc_list to com20020_set_rx_mode. Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com> Link: https://patch.msgid.link/20260521001631.45434-2-enelsonmoore@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-22Merge branch 'netlink-fixes-for-cross-namespace-nsid-reporting'Jakub Kicinski
Ilya Maximets says: ==================== netlink: fixes for cross-namespace nsid reporting While working on some new features for OVS and OVN we discovered that self-referential NSIDs get unintentionally allocated in the system as well as unexpectedly reported for local events on all-nsid listeners. More details in the patches. They change user-visible behavior, but the current behavior is arguably a bug, as it makes it hard to use all-nsid sockets without a decent amount of extra unrelated work of tracking when new NSIDs are allocated for your local namespace. Tests are added to check the expected behavior and YNL is extended to support all-nsid sockets in the tests. ==================== Link: https://patch.msgid.link/20260520172317.175168-1-i.maximets@ovn.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-22selftests: net: add a test case for nsid in all nsid notificationsIlya Maximets
The test subscribes to link events from all namespaces and makes sure that local events do not carry NSID in their ancillary data (even if there is a self-referential NSID allocated for the local namespace), and remote events do. Signed-off-by: Ilya Maximets <i.maximets@ovn.org> Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Link: https://patch.msgid.link/20260520172317.175168-5-i.maximets@ovn.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-22net: netlink: don't set nsid on local notificationsIlya Maximets
In most cases, notifications on sockets with NETLINK_LISTEN_ALL_NSID do not contain NSID in their ancillary data in case the event is local to the listener. However, when a self-referential NSID is allocated for a namespace, every local notification starts sending this ID to the user space. This is problematic, because the listener cannot tell if those notifications are local or not anymore without making extra requests to figure out if the provided NSID is local or not. The listener can also not figure out the local NSID beforehand as it can be allocated at any point in time by other processes, changing the structure of the future notifications for everyone. The value is practically not useful, since it's the namespace's own ID that the application has to obtain from other sources in order to figure out if it's the same or not. So, for the application it's just an extra busy work with no benefits. Moreover, applications that do not know about this quirk may be mishandling notifications with NSID set as notifications from remote namespaces. This is the case for ovs-vswitchd and the iproute2's 'ip monitor' that stops printing 'current' and starts printing the nsid number mid-session. Lack of clear documentation for this behavior is also not helping. A search though open-source projects doesn't reveal any projects that use NETNSA_NSID_NOT_ASSIGNED and rely on metadata to contain self-referential NSIDs (expected, since the value is not useful). Quite the opposite, as already mentioned, there are few applications that rely on NSID to not be present in local events. Since the value is not useful and actively harmful in some cases, let's not report it for local events, making the notifications more consistent. Also adding some blank lines for readability. Fixes: 59324cf35aba ("netlink: allow to listen "all" netns") Reported-by: Matteo Perin <matteo.perin@canonical.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org> Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Link: https://patch.msgid.link/20260520172317.175168-3-i.maximets@ovn.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-22net: netlink: fix sending unassigned nsid after assigned oneIlya Maximets
If the current skb is not shared, it is re-used directly for all the sockets subscribed to the notification. If we have remote all-nsid socket receiving a message first, then the 'nsid_is_set' will be set to 'true'. If the nsid is NOT_ASSIGNED for the next socket in the list, the 'nsid_is_set' will remain 'true' and the negative value is be delivered to the user space. All subsequent nsid values will be delivered as well, since there is no code path that sets the flag back to 'false'. Fix that by always dropping the flag to 'false' first. Fixes: 7212462fa6fd ("netlink: don't send unknown nsid") Signed-off-by: Ilya Maximets <i.maximets@ovn.org> Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Link: https://patch.msgid.link/20260520172317.175168-2-i.maximets@ovn.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-22perf kwork: Fix memory management of kwork_workIan Rogers
This commit addresses several memory management issues in builtin-kwork.c: 1. Implements a global cleanup function perf_kwork__exit to free all kwork_work and kwork_atom_page objects at the end of the command. 2. Ensures all 'name' fields in struct kwork_work are malloc-ed (or NULL) and properly freed by using strdup and zfree. 3. Fixes memory leaks in top_merge_tasks where kwork_work objects were dropped without being freed. 4. Adds robustness with NULL checks for name fields. 5. Fixes workqueue_work_init to correctly resolve and strdup kernel function names, preventing bad-free errors. Signed-off-by: Ian Rogers <irogers@google.com> Acked-by: Namhyung Kim <namhyung@kernel.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: James Clark <james.clark@linaro.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2026-05-22perf kwork: Fix address sanitizer issuesIan Rogers
There is a double free in the record array due to how parse_options will mutate the array. Fix by keeping an array that isn't mutated. Ensure kwork_usage is freed on all paths. Signed-off-by: Ian Rogers <irogers@google.com> Acked-by: Namhyung Kim <namhyung@kernel.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: James Clark <james.clark@linaro.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2026-05-22perf build: Unconditionally set up libunwind feature build flagsIan Rogers
A "make feature-dump" build does not specify LIBUNWIND=1 because it is run with the default configuration to detect system-wide capabilities. This sets NO_LIBUNWIND := 1, causing Makefile.config to skip setting LIBUNWIND_LIBS and FEATURE_CHECK_LDFLAGS-libunwind. Consequently, when Makefile.feature is included and attempts to run all feature checks (via FEATURE_TESTS := all), the local feature test test-libunwind.bin compiles without the required architecture-specific library flags (-lunwind-x86_64) and fails to link on x86_64. This results in a corrupted cached BUILD_TEST_FEATURE_DUMP showing feature-libunwind=0 even when the host supports it. Subsequent test builds (like make_libunwind_O in the build-test suite) which reuse the feature dump and specify LIBUNWIND=1 will fail to compile due to a mismatch where CONFIG_LIBUNWIND is set (via remote architecture checks which are self-contained) but HAVE_LIBUNWIND_SUPPORT is disabled, causing compiler errors due to missing maps__e_machine definitions in maps.h. Fix this by unconditionally setting up the libunwind library lists and feature check LDFLAGS in Makefile.config so they are always populated and available to the feature detection engine regardless of whether LIBUNWIND=1 is opted-in for the current run. Fixes: 444508cd7c7b4f05 ("perf build: Be more programmatic when setting up libunwind variables") Signed-off-by: Ian Rogers <irogers@google.com> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: James Clark <james.clark@linaro.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2026-05-22Merge tag 'sched_ext-for-7.1-rc4-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tj/sched_ext Pull sched_ext fixes from Tejun Heo: - Spurious WARN in ops_dequeue() racing with concurrent dispatch - Self-deadlock between scheduler disable and a concurrent sub-sched enable * tag 'sched_ext-for-7.1-rc4-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/sched_ext: sched_ext: Fix spurious WARN on stale ops_state in ops_dequeue() sched_ext: Fix deadlock between scx_root_disable() and concurrent forks
2026-05-22KVM: SVM: Only disable x2AVIC WRMSR interception for MSRs that are acceleratedSean Christopherson
When x2AVIC is enabled, disable WRMSR interception only for MSRs that are actually accelerated by hardware. Disabling interception for MSRs that aren't accelerated is functionally "fine", and in some cases a weird "win" for performance, but only for cases that should never be triggered by a well-behaved VM (writes to read-only registers; the #GP will typically occur in the guest without taking a #VMEXIT, even for fault-like exits). But overall, disabling interception for MSRs that aren't accelerated is at best confusing and unintuitive, and at worst introduces avoidable risk, as the APM's documentation is imperfect and contradictory. The table in "15.29.3.1 Virtual APIC Register Accesses" of simply states that such writes generate exits, where as "Section 15.29.10 x2AVIC" says: x2APIC MSR intercept checks and access checks have higher priority than AVIC access permission checks. CPU behavior follows the latter (which makes perfect sense), but all in all there's simply no reason to disable interception just to make a #GP faster. Note, the set of MSRs that are passed through for write is identical to VMX's set when IPI virtualization is enabled. This is not a coincidence, and is another motiviating factor for cleaning up the intercepts, as x2AVIC is functionally equivalent to APICv+IPIv. Fixes: 4d1d7942e36a ("KVM: SVM: Introduce logic to (de)activate x2AVIC mode") Cc: stable@vger.kernel.org Reviewed-by: Naveen N Rao (AMD) <naveen@kernel.org> Link: https://patch.msgid.link/20260514213115.1637082-4-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-22Merge tag 'cgroup-for-7.1-rc4-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup Pull cgroup fixes from Tejun Heo: "Two rstat fixes: - Out-of-bounds access in the css_rstat_updated() BPF kfunc when called with an unchecked user-supplied cpu - Over-strict NMI guard after the recent switch to try_cmpxchg left sparc and ppc64 unable to queue rstat updates from NMI" * tag 'cgroup-for-7.1-rc4-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup: cgroup: rstat: relax NMI guard after switch to try_cmpxchg cgroup/rstat: validate cpu before css_rstat_cpu() access
2026-05-22KVM: SVM: Disable x2AVIC RDMSR interception for MSRs KVM actually supportsSean Christopherson
When toggling x2AVIC on/off, use KVM's curated mask of x2APIC MSRs that can/should be passed through to the guest (or not) when 2AVIC is enabled. Using the effective list provided by the local APIC emulation fixes multiple (classes of) bugs, as the existing hand-coded list of MSRs is wrong on multiple fronts: - ARBPRI isn't supported by KVM, isn't accelerated by AVIC (for read or write), and its #VMEXIT is fault-like, i.e. requires decoding the instruction. Disabling interception is nonsensical and suboptimal. - DFR and ICR2 aren't supported by x2APIC and so don't need their intercepts disabled for performance reasons. While the #GP due to x2APIC being abled has higher priority than the trap-like #VMEXIT, disabling interception of unsupported MSRs is confusing and unnecessary. - RRR is completely unsupported. - AVIC currently fails to pass through the "range of vectors" registers, IRR, ISR, and TMR, as e.g. X2APIC_MSR(APIC_IRR) only affects IRR0, and thus only disables intercept for vectors 31:0 (which are the *least* interesting registers). - TMCCT (the current APIC timer count) isn't accelerated by hardware, and generates a fault-like AVIC_UNACCELERATED_ACCESS #VMEXIT, i.e. requires KVM to decode the instruction to figure out what the guest was trying to access. Note, the only reason this isn't a fatal bug is that the AVIC architecture had the foresight to guard against buggy hypervisors. E.g. if hardware simply read from the virtual APIC page, the guest would get garbage (because the timer is emulated in software). Fixes: 4d1d7942e36a ("KVM: SVM: Introduce logic to (de)activate x2AVIC mode") Cc: stable@vger.kernel.org Reviewed-by: Naveen N Rao (AMD) <naveen@kernel.org> Link: https://patch.msgid.link/20260514213115.1637082-3-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-22KVM: x86: Add dedicated API for getting mask of accelerated x2APIC MSRsSean Christopherson
Add a dedicated local APIC API, kvm_x2apic_disable_intercept_reg_mask(), to provide the mask of x2APIC registers whose MSRs can and should be passed through to the guest when x2APIC virtualization is enable, and use it in lieu of the open-coded equivalent VMX logic. Providing a common helper will allow sharing the logic with SVM (x2AVIC), and as a bonus eliminates the somewhat confusing code where KVM enables interception for MSR_TYPE_RW, even though only the READ case actually needs to be updated. No functional change intended. Cc: stable@vger.kernel.org Reviewed-by: Naveen N Rao (AMD) <naveen@kernel.org> Link: https://patch.msgid.link/20260514213115.1637082-2-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-22Merge tag 'drm-fixes-2026-05-23' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds
Pull drm fixes from Dave Airlie: "Regular fixes pull, amdgpu/xe being the usual, with bonus msm content to bulk things out, otherwise it has the usual scattered changes, with amdxdna dropping a badly thought out userspace api. gem: - clean up LRU locking msm: - Core: - Fixed bindings for SM8650, SM8750 and Eliza - Don't use UTS_RELEASE directly - Fix typo in clock-names property - DPU: - Fixed CWB description on Kaanapali - Fixed scanline strides for YUV UBWC formats - Stopped DSI register dumping to access past the end of region - DSI: - Fix dumping unaligned regions - GPU: - Fix GMEM_BASE for a6xx gen3 - Fix userspace reachable crash on a2xx-a4xx - Fix sysprof_active for counter collection with IFPC enabled GPUs - Fix shrinker lockdep amdgpu: - Userq fixes - VPE fix - SMU 15 fix - Misc fixes - VCE fixes - DC bios parsing fixes - DC aux fix - Mode1 reset fix - RAS fixes amdkfd: - Misc fixes radeon: - CS parser fix xe: - SRIOV related fixes - Fix leak and double-free - Multi-cast register fixes - Multi-queue fix i915: - Fix joiner color pipeline selection [display] - Fix readback for target_rr in Adaptive Sync SDP [dp] - Apply Intel DPCD workaround when SDP on prior line used [psr] amdxdna: - remove mmap and export for ubuf bridge: - chipone-icn6211: managed bridge cleanup - lt66121: acquire reset GPIO - megachips: fix clean up on failed IRQ requests v3d: - fix UAF in error code paths - release GEM-object ref on free'd jobs virtio: - use uninterruptible resv locking in plane updates mediatek: - fix sparse warnings" * tag 'drm-fixes-2026-05-23' of https://gitlab.freedesktop.org/drm/kernel: (78 commits) drm/xe/oa: Fix exec_queue leak on width check in stream open drm/virtio: use uninterruptible resv lock for plane updates drm/amdgpu: fix handling in amdgpu_userq_create drm/radeon/evergreen_cs: Add missing NULL prefix check in surface check drm/amdgpu: userq_va_mapped should remain true once done drm/amdgpu: avoid integer overflow in VA range check drm/amd/ras: Fix UMC error address allocation leak drm/amdgpu: unmap all user mappings of framebuffer and doorbell before mode1 reset drm/amd/display: Validate payload length and link_index in dc_process_dmub_aux_transfer_async drm/amd/display: Validate GPIO pin LUT table size before iterating drm/amd/display: Fix integer overflow in bios_get_image() drm/amdkfd: Check bounds for allocate_sdma_queue restore_sdma_id drm/amdgpu: use atomic operation to achieve lockless serialization drm/amdkfd: Check bounds on allocate_doorbell drm/amdgpu/vce3: Fix VCE 3 firmware size and offsets drm/amdgpu/vce2: Fix VCE 2 firmware size and offsets drm/amdgpu/vce1: Stop using amdgpu_vce_resume drm/amdgpu/vce1: Fix VCE 1 firmware size and offsets drm/amdgpu/vce1: Don't repeat GTT MGR node allocation drm/amdgpu/vce1: Check if VRAM address is lower than GART. ...
2026-05-22Merge tag 'scsi-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "Small fixes, two in drivers and the remaining a sign conversion probem in sd with no user visible consequences (non-zero is error)" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: target: tcm_loop: Fix NULL ptr dereference scsi: isci: Fix use-after-free in device removal path scsi: sd: Fix return code handling in sd_spinup_disk()
2026-05-22Merge tag 'platform-drivers-x86-v7.1-4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86 Pull x86 platform driver fixes from - Add ACPI_HANDLE()/ACPI_COMPANION() NULL checks (many drivers) to handle match overrides gracefully - asus-armoury: - Fix mini-LED mode get/set - Add support for FA401EA, FX607VU, G614FR, and GU605CP - bitland-mifs-wmi: - Add CONFIG_LEDS_CLASS dependency - hp-wmi: - Add thermal support for Omen 16-c0xxx (board 8902) - intel/vsec: - Fix enable_cnt imbalance due to PCIe error recovery - surface/aggregator_registry: - Remove battery & AC nodes on Surface Laptop 7 to avoid duplicated devices - uniwill-laptop: - Handle uninitialized and invalid charging threshold values - Accept charging threshold of 0 through power supply sysfs ABI and clamp it to 1 - Make 'force' parameter to work also when device descriptor is found - Do not enable charging limit despite the 'force' parameter to avoid permanent damage to battery * tag 'platform-drivers-x86-v7.1-4' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: (35 commits) platform/x86: bitland-mifs-wmi: add CONFIG_LEDS_CLASS dependency platform/x86: wireless-hotkey: Check ACPI_COMPANION() against NULL platform/x86: toshiba_haps: Check ACPI_COMPANION() against NULL platform/x86: toshiba_bluetooth: Check ACPI_COMPANION() against NULL platform/x86: toshiba_acpi: Check ACPI_COMPANION() against NULL platform/x86: system76: Check ACPI_COMPANION() against NULL platform/x86: sony-laptop: Check ACPI_COMPANION() against NULL platform/x86: panasonic-laptop: Check ACPI_COMPANION() against NULL platform/x86: lg-laptop: Check ACPI_COMPANION() against NULL platform/x86: intel/smartconnect: Check ACPI_HANDLE() against NULL platform/x86: intel/rst: Check ACPI_COMPANION() against NULL platform/x86: fujitsu-tablet: Check ACPI_COMPANION() against NULL platform/x86: fujitsu: Check ACPI_COMPANION() against NULL platform/x86: eeepc-laptop: Check ACPI_COMPANION() against NULL platform/x86: dell/dell-rbtn: Check ACPI_COMPANION() against NULL platform/x86: asus-laptop: Check ACPI_COMPANION() against NULL platform/x86: acer-wireless: Check ACPI_COMPANION() against NULL platform/x86: asus-armoury: add support for GU605CP platform/x86: asus-armoury: add support for FA401EA platform/x86: asus-armoury: add support for G614FR ...
2026-05-22selftests: tls: use ASSERT_GE in test_mutliprocGeliang Tang
In test_mutliproc(), when send() or recv() returns an error (e.g., -1), the test continues to execute the remaining code and fails repeatedly due to using EXPECT_GE. For example, if a TLS connection is broken and recv() returns -1, EXPECT_GE(res, 0) records a failure but does not stop the test. The test then proceeds with left -= res (where res = -1), causing left to increase unexpectedly, and the loop continues indefinitely. This results in a massive number of identical failure messages: # tls.c:1686:mutliproc_sendpage_writers:Expected res (-1) >= 0 (0) # tls.c:1686:mutliproc_sendpage_writers:Expected res (-1) >= 0 (0) ... (hundreds of identical failures) Fix this by replacing EXPECT_GE with ASSERT_GE. When send() or recv() fails, ASSERT_GE immediately aborts the current test, preventing the subsequent undefined behavior and endless failure messages. Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn> Link: https://patch.msgid.link/0ee9f412b6bd1a260a547d19f979f73b396746ac.1779354585.git.tanggeliang@kylinos.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-23Merge tag 'drm-xe-fixes-2026-05-21' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes - SRIOV related fixes (Wajdeczko, Mohanram) - Fix leak and double-free (Lin) - Multi-cast register fixes (Gustavo) - Multi-queue fix (Niranjana) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/ag9rR5VwCdkA0lzI@intel.com
2026-05-22perf stat: Make metric only column line up with headerAndi Kleen
Since some time the metric-only output columns are messed up and do not line up with the header, which makes it hard to read. I haven't bisected it, but presumably it was broken for some time. There were multiple problems: - The dummy pm invocation at the beginning did print a bogus field - The column computation in pm did not agree with the header length - The color escape strings from highlighting confuse printf's field length computation Fix all those. I simplified the column width computation significantly, ignoring EVNAME_LEN, MGROUP_LEN, config->unit_width which don't seem to be useful in the metric only context. It now only uses the actual unit width as well as config->metric_only_len. The result is more code removed than added. Before: % perf stat --topdown -a -I 1000 + time % tma_backend_bound % tma_frontend_bound % tma_bad_speculation % tma_retiring 1.000190386 45.5 40.0 5.3 9.2 2.005185654 45.3 40.1 5.6 9.0 3.009193207 45.4 39.9 5.6 9.1 After: % perf stat --topdown -a -I 1000 + time % tma_backend_bound % tma_frontend_bound % tma_bad_speculation % tma_retiring 1.000810024 46.3 39.7 5.3 8.7 2.004800656 45.8 39.8 5.4 8.9 3.008804783 46.0 39.6 5.4 9.0 Reviewed-by: Ian Rogers <irogers@google.com> Signed-off-by: Andi Kleen <ak@linux.intel.com> Cc: Namhyung Kim <namhyung@kernel.org> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>