summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
5 daysxfs: check for fragments when full-extent sharing matchesDarrick J. Wong
LOLLM noticed that xchk_refcountbt_process_rmap_fragments returns early if there are enough rmap records that overlap the space referenced by a refcountbt record to match the refcount in that refcountbt record. Unfortunately, it never checks the fragment list in this case, so it won't find the discrepancy between the rmap and refcount btrees. Cc: stable@vger.kernel.org # v4.16 Fixes: dbde19da963706 ("xfs: cross-reference the rmapbt data with the refcountbt") Signed-off-by: Darrick J. Wong <djwong@kernel.org> Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Carlos Maiolino <cem@kernel.org>
5 daysxfs: only written file data blocks can be sharedDarrick J. Wong
LOLLM noticed that xchk_refcountbt_rmap_check (and its rt equivalent) will count any rmap owner towards the shared count. However, the only blocks that can be shared between xfs files are written file data blocks; and the only blocks that can have single-refcount entries are COW staging extents. Fix the checking code. Cc: stable@vger.kernel.org # v4.16 Fixes: dbde19da963706 ("xfs: cross-reference the rmapbt data with the refcountbt") Signed-off-by: Darrick J. Wong <djwong@kernel.org> Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Carlos Maiolino <cem@kernel.org>
5 daysxfs: don't queue rmap update twice when reaping a forkDarrick J. Wong
LOLLM noticed that xrep_reap_bmapi_iter calls xfs_bmap_unmap_extent and xfs_rmap_unmap_extent to remove a mapping from a file fork and its reverse mapping. However, xfs_bmap_del_extent_real also queues a deferred rmap removal log item, which means that we incorrectly queue two rmap removal operations. Fix that by removing the extra call and updating the comment to mention this subtlety that I forgot, having written the code. :P Cc: stable@vger.kernel.org # v6.10 Fixes: 5befb047b9f4de ("xfs: add the ability to reap entire inode forks") Signed-off-by: Darrick J. Wong <djwong@kernel.org> Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Carlos Maiolino <cem@kernel.org>
5 daysxfs: reduce new btree slack factor if free space is negativeDarrick J. Wong
LOLLM points out that if the incore fdblocks counter is negative, the assignment to uint64_t will mask this possibly low space situation and we don't pack the btree blocks as tightly as we probably ought to. If it's the case that there's some free space and fdblocks is too low due to an error in the superblock field, then we can end up failing btree rebuilds due to ENOSPC unnecessarily. This is a corner case, but let's fix it anyway. Cc: stable@vger.kernel.org # v6.8 Fixes: be408417630427 ("xfs: implement block reservation accounting for btrees we're staging") Signed-off-by: Darrick J. Wong <djwong@kernel.org> Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Carlos Maiolino <cem@kernel.org>
5 daysxfs: avoid oversized space allocations when regenerating metadataDarrick J. Wong
LOLLM notices that the btree block preallocation code can be asked to allocate more than XFS_MAX_BMBT_EXTLEN blocks. If the allocation succeeds, the reservation will be stored in a single autoreap record. Unfortunately, the autoreap code uses deferred frees to get rid of unused space and that code complains if it's given too much space to get rid of all once. Fix this theoretical problem by constraining the allocation size since it's unlikely that we're going to need that much space for a btree. We don't fix the core code because the runtime users of deferred frees are freeing file space or single btree blocks and we want to catch problems there. Signed-off-by: Darrick J. Wong <djwong@kernel.org> Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Carlos Maiolino <cem@kernel.org>
5 daysxfs: fix data fork block count check in xrep_inode_blockcountsDarrick J. Wong
LOLLM notices that for non-reflink realtime files, the @count output of xchk_inode_count_blocks includes both the file blocks on the realtime volume and the bmap btree blocks on the data volume. Therefore, we must compare this value to rblocks + dblocks to avoid unnecessary failure. Cc: stable@vger.kernel.org # v6.8 Fixes: 2d295fe65776d1 ("xfs: repair inode records") Signed-off-by: Darrick J. Wong <djwong@kernel.org> Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Carlos Maiolino <cem@kernel.org>
5 daysxfs: don't overrun incore inode when cleaning attr forksDarrick J. Wong
LOLLM noticed that xrep_dinode_check_afork doesn't check for a di_forkoff value that is so large that the attr fork would begin after the end of the inode space. This causes afork_{ptr,size} to be nonsense. What we really ought to do here is zap the attr fork. Cc: stable@vger.kernel.org # v6.8 Fixes: e744cef2060559 ("xfs: zap broken inode forks") Signed-off-by: Darrick J. Wong <djwong@kernel.org> Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Carlos Maiolino <cem@kernel.org>
5 daysthermal/drivers/rzg3e: Propagate reset assertion failure from suspendPengpeng Hou
rzg3e_thermal_suspend() powers off an active sensor and then ignores failure to assert its reset. System sleep can therefore continue without the clean reset state expected by resume. Return the reset error and, when the sensor had been active, try to restore power before failing suspend. This is best-effort recovery: reset assertion failure may leave partial hardware state, so restoring power is not guaranteed to succeed. Preserve the original reset error. The issue was found by our static-analysis tool and manually reviewed. Fixes: dc67521c20b7 ("thermal/drivers/renesas/rzg3e: Fix add thermal driver for the Renesas RZ/G3E SoC") Assisted-by: gpt 5 Signed-off-by: Pengpeng Hou <hppiscas@163.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org> Reviewed-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Link: https://patch.msgid.link/20261014031814.7230-1-hppiscas@163.com
5 daysthermal: ti-soc-thermal: Fix the return value in ↵Karl Mehltretter
ti_bandgap_get_sensor_data() kernel-doc ti_bandgap_get_sensor_data() returns an ERR_PTR() if the bandgap instance or sensor ID is invalid. Otherwise it returns the stored sensor data, which can be NULL if no data has been set or the stored value has been cleared. This mismatch was already present in omap_bandgap_get_sensor_data() when the driver was introduced in staging. Document the validation errors while retaining NULL as a possible stored value. Fixes: 8feaf0ce1a04 ("staging: OMAP4+: thermal: introduce bandgap temperature sensor") Assisted-by: LLM Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org> Link: https://patch.msgid.link/20260912062252.42762-1-kmehltretter@gmail.com
5 daysthermal/fw: Fix kernel-doc parameter namesAryan Sinha
The kernel-doc for thermal_fwnode_cooling_device_register() still names the old device tree arguments np and of_index, and devm_thermal_fwnode_cooling_device_register() documents fw_index rather than fwn_index. Rename them to match the code and reword the device tree reference as a firmware node one. Signed-off-by: Aryan Sinha <sinha.aryan03@gmail.com> Link: https://patch.msgid.link/20261012152037.33461-1-sinha.aryan03@gmail.com Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org>
5 daysthermal/qcom/tsens: Add support for MSM8952 tsensMuzaffer Kadir
Add support for tsens v1 block that exists on MSM8952 with 11 tsens sensors. Sensor Offsets are taken from downstream. Signed-off-by: Muzaffer Kadir <muzafferkadir@mainlining.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://android.googlesource.com/kernel/msm.git/+/refs/tags/android-wear-7.0.0_r0.3/drivers/thermal/msm-tsens.c#1621 Link: https://patch.msgid.link/20261011-msm8952-initial-support-v5-4-1857074992ec@mainlining.org
5 daysdt-bindings: thermal: tsens: Add MSM8952Muzaffer Kadir
Add compatible string for tsens block found in MSM8952. Signed-off-by: Muzaffer Kadir <muzafferkadir@mainlining.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20261011-msm8952-initial-support-v5-3-1857074992ec@mainlining.org
5 daysthermal/drivers/amlogic: Switch to clk_bulk API to support multiple clocksRonald Claveau
The t7-thermal variant now exposes two clocks (bus and core) in its devicetree binding, but the driver only knows how to get and manage a single struct clk. Using devm_clk_get() would silently ignore the second clock, so switch to devm_clk_bulk_get_all() and the matching clk_bulk_prepare_enable()/clk_bulk_disable_unprepare() calls. This lets the driver transparently handle however many clocks a given compatible declares, without needing per-variant clock-handling code, and keeps working for existing SoCs that only have one. Fixes: 18d65de8157c ("thermal/drivers/amlogic: Add support for secure monitor calibration readout") Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr> Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org> Link: https://patch.msgid.link/20260923-fix-t7-thermal-clock-v2-2-bff7a09eb487@aliel.fr
5 daysdt-bindings: thermal: amlogic: describe bus clock for t7-thermalRonald Claveau
The t7 thermal sensor needs a bus clock, in addition to the existing functional clock, to gate register access to the sensor. This bus clock is specific to each sensor, unlike the functional clock which is shared between sensors. The current binding only describes a single unnamed clock and therefore cannot represent this hardware requirement, so add a second clock entry and clock-names for clarity. Make the second clock mandatory for the t7-thermal compatible only, via an additional if/then/else, to avoid breaking other Amlogic SoCs that still use a single clock. Update the t7 example to match. Fixes: b1c8ccdbd4e9 ("dt-bindings: thermal: amlogic: Add support for T7") Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr> Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260923-fix-t7-thermal-clock-v2-1-bff7a09eb487@aliel.fr
5 daystools/thermal/tmon: Fix string truncation warning in optarg copyFlorian Fainelli
GCC warns about possible string truncation with -Wstringop-truncation: tmon.c: In function ‘main’: tmon.c:233:25: warning: ‘__builtin_strncpy’ specified bound 20 equals destination size [-Wstringop-truncation] 233 | strncpy(ctrl_cdev, optarg, CDEV_NAME_SIZE); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Replace strncpy() with snprintf() to guarantee NUL-termination and silence the compiler warning. Fixes: 94f69966faf8 ("tools/thermal: Introduce tmon, a tool for thermal subsystem") Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org> Link: https://patch.msgid.link/20260929201951.408456-1-florian.fainelli@broadcom.com
5 daysthermal/drivers/airoha: Register a thermal zone per AN7583 sensorVitaliy Sochnev
AN7583 has three temperature sensors and the driver has constants for all of them, but it registers one zone and reads only the bandgap sensor. Register a zone per sensor; the thermal sensor cell selects it. A device tree may describe fewer zones than sensors. EN7581 still registers one zone. Idle and with both cores loaded on a Nokia XG-040G-MF: bandgap 56.9 C -> 59.3 C GbE 58.7 C -> 61.5 C CPU 57.0 C -> 61.1 C Signed-off-by: Vitaliy Sochnev <sochnev.v.74@gmail.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org> Link: https://patch.msgid.link/20260929165209.69669-5-sochnev.v.74@gmail.com
5 daysdt-bindings: arm: airoha: Use one thermal sensor cell for AN7583Vitaliy Sochnev
AN7583 has three temperature sensors behind the chip SCU: bandgap, GbE and CPU. With no cells a thermal zone can only refer to the bandgap sensor. Use one cell to select the sensor. The AN7583 compatible is new in 7.3-rc1 and no device tree uses the property yet. Signed-off-by: Vitaliy Sochnev <sochnev.v.74@gmail.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260929165209.69669-4-sochnev.v.74@gmail.com
5 daysthermal/drivers/airoha: Serialise access to the shared ADCVitaliy Sochnev
A read selects the sensor and walks three diodes with a 10 ms settle on each. The zone lock serialises reads of one zone. With a zone per AN7583 sensor, added later in this series, reads of different zones interleave and convert samples taken at another mux position. Mux writes are dropped silently unless PLLRG_PROTECT is lifted, and its save and restore do not nest. The cached TADC value also skips a write after another reader has moved the mux. With the AN7583 sensors read as parallel zones during CPU frequency changes, a zone crossed its critical trip on a chip at 55 C and the board shut down. Serialise the sequence, drop the cache, check the selection after writing and after sampling, and return -EAGAIN if it does not hold. Signed-off-by: Vitaliy Sochnev <sochnev.v.74@gmail.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org> Link: https://patch.msgid.link/20260929165209.69669-3-sochnev.v.74@gmail.com
5 daysthermal/drivers/airoha: Fix AN7583 ADC mux field mappingVitaliy Sochnev
On AN7583, bits 3:1 of 0x2e4 select the sensor (0 bandgap, 5 GbE, 6 CPU) and bits 3:2 of 0x2a0 select the diode (0 D0, 1 ZERO, 2 D1). The driver names them the other way round: MUX_TADC is 0x2e4, MUX_SENSOR is 0x2a0. v5 of the AN7583 series swapped the airoha_set_thermal_mux() arguments to match these names. The diode index now goes to the sensor selector, so the zone reads mux positions 1, 0 and 2 (PAD_AVS, bandgap, core voltage) instead of the bandgap diodes. On a Nokia XG-040G-MF the result crosses the critical trip and the board powers off during boot. Swap the field definitions. MUX_TADC then selects the diode, as on EN7581, and the existing call order is correct. Fixes: b20d9782756a ("thermal/drivers/airoha: Add support for AN7583 Thermal Sensor") Signed-off-by: Vitaliy Sochnev <sochnev.v.74@gmail.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org> Link: https://patch.msgid.link/20260929165209.69669-2-sochnev.v.74@gmail.com
5 daysthermal/drivers/sprd: validate the sensor id from the device treeWeigang He
sprd_thm_probe() reads each sensor child node's "reg" property into sen->id and uses it without validation: to compute the sensor's register offsets in sprd_thm_sensor_init(), as the thermal zone id, and finally as an index into thm->sensor[], which has SPRD_THM_MAX_SENSOR (8) entries: ret = of_property_read_u32(sen_child, "reg", &sen->id); ... thm->sensor[sen->id] = sen; Only the number of sensor nodes is checked against SPRD_THM_MAX_SENSOR. A "reg" value of 8 or more, or one that is negative once stored in the int sen->id, makes the register offsets point outside the sensor range and the final store land outside thm->sensor[], overwriting the fields that follow it in struct sprd_thermal_data or other memory. Reject an out-of-range id right after reading it, before it is used. This does not address sparse ids, such as a single sensor with id 7: they leave holes in thm->sensor[] that the later loops over 0..nr_sensors-1 dereference. That needs a separate fix. Found by static analysis tool CodeQL. Fixes: 554fdbaf19b1 ("thermal: sprd: Add Spreadtrum thermal driver support") Assisted-by: LLM codeql Signed-off-by: Weigang He <geoffreyhe2@gmail.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org> Link: https://patch.msgid.link/20260926042757.2109927-1-geoffreyhe2@gmail.com
5 daysxfs: complain loudly when dirtree checker finds broken linksDarrick J. Wong
LOLLM observed that the directory tree walk code bails out if it finds broken parent pointers along the way. However, it flattens the return code to zero, which means that we can end up in the repair code having not completed the scan. We should never proceed with a repair in this state, so let's mark the scrub incomplete and exit. Cc: stable@vger.kernel.org # v6.10 Fixes: 928b721a11789a ("xfs: teach online scrub to find directory tree structure problems") Signed-off-by: Darrick J. Wong <djwong@kernel.org> Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Carlos Maiolino <cem@kernel.org>
5 daysxfs: clarify various parts of the bitmap APIDarrick J. Wong
LOLLM pointed out some underspecified parts of the xbitmap{32,64} API. Specifically, the behavior of set/clear/test functions when the length parameter is zero is not well defined, nor is what happens when someone tries to disunion a bitmap with itself. None of these situations are expected, but we'll define zero-length set and clear to be nops, and the rest to be checked by assertions. Cc: stable@vger.kernel.org # v6.8 Fixes: 6ece924b952262 ("xfs: create separate structures and code for u32 bitmaps") Signed-off-by: Darrick J. Wong <djwong@kernel.org> Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Carlos Maiolino <cem@kernel.org>
5 daysxfs: check for buffer overruns when examining local/remote xattr entriesDarrick J. Wong
LOLLM noticed that the xattr scrub and repair code can walk off the end of the buffer if the xattr entry record starts so close to the end of the buffer that there's not even space for the entry structure itself. Strengthen the bounds checking here. Cc: stable@vger.kernel.org # v4.15 Fixes: 13791d3b833428 ("xfs: scrub extended attribute leaf space") Signed-off-by: Darrick J. Wong <djwong@kernel.org> Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Carlos Maiolino <cem@kernel.org>
5 daysxfs: break out xattr entry checks into separate functionsDarrick J. Wong
We're going to add more xattr entry checking code in xchk_xattr_entry so break these out into separate functions so that we don't go crazy indenting. There's a slight behavior change here where we skip updating the usedmap if we've decided the xattr structure is corrupt. Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Carlos Maiolino <cem@kernel.org>
5 daysxfs: reject absurdly large xattr value lengths in xchk_xattr_actorDarrick J. Wong
LOLLM suggests that we shouldn't try to allocate absurdly large buffers for xattr value checks because that will push reclaim very hard, never succeed, and is pointless because nobody can create xattrs that large. Since the xattr repair code ignores values larger than XATTR_SIZE_MAX, we can flag the corruption and return early. Cc: stable@vger.kernel.org # v5.3 Fixes: 6d6ccedd76823c ("xfs: only allocate memory for scrubbing attributes when we need it") Signed-off-by: Darrick J. Wong <djwong@kernel.org> Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Carlos Maiolino <cem@kernel.org>
5 daysxfs: range-check bc_levels array access in scrub tracepointsDarrick J. Wong
LOLLM noticed xchk_btree()'s odd habit of passing cur->bc_nlevels to xchk_btree_ptr_ok when we're checking the pointer to the root block at the start of the btree scan. This enables us to skip checking the pointer for an inode btree's root (since it doesn't have one) but doesn't handle per-AG btrees quite correctly. There isn't a problem for __xfs_btree_check_ptr itself, but the corruption tracepoint naively walks off the end of bc_level[]. Fix that by adding a helper to do an implicit range check. Cc: stable@vger.kernel.org # v5.16 Fixes: 6ca444cfd66354 ("xfs: prepare xfs_btree_cur for dynamic cursor heights") Signed-off-by: Darrick J. Wong <djwong@kernel.org> Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Carlos Maiolino <cem@kernel.org>
5 daysxfs: always report inode repair setup failuresDarrick J. Wong
LOLLM noticed that xchk_setup_inode silently discards errors being returned by xrep_setup_inode. Fix that, and fix the stub macro so that it actually "returns" a value. Cc: stable@vger.kernel.org # v6.8 Fixes: 2d295fe65776d1 ("xfs: repair inode records") Signed-off-by: Darrick J. Wong <djwong@kernel.org> Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Carlos Maiolino <cem@kernel.org>
5 daysxfs: fix correction of unwritten extents in quota file data forkDarrick J. Wong
LOLLM noticed a couple of problems with the code that fixes unwritten mappings in the quota file's data fork: first, we should zero the ondisk contents as part of converting them to "unwritten" just in case we crash shortly after the conversion. Second, and more importantly, it noticed that we fail to resynchronize the iext tree cursor after modifying the iext tree. If the tree shape changes, we could be in a world of hurt. Third, we should force a quotacheck if we reset an ondisk dquot. Fix all issues. Cc: stable@vger.kernel.org # v6.8 Fixes: a5b91555403e3a ("xfs: repair quotas") Signed-off-by: Darrick J. Wong <djwong@kernel.org> Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Carlos Maiolino <cem@kernel.org>
5 daysxfs: never reset the default quota timerDarrick J. Wong
LOLLM notices that xrep_quota_fix_timer doesn't check the dquot id, which means that it can inadvertently reset the default quota timer when we really meant to ensure that a (non-root) quota overage timeout has a sane timestamp. Fix that. Cc: stable@vger.kernel.org # v6.8 Fixes: a5b91555403e3a ("xfs: repair quotas") Signed-off-by: Darrick J. Wong <djwong@kernel.org> Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Carlos Maiolino <cem@kernel.org>
5 daysxfs: reattach dquots after changing inode idsDarrick J. Wong
LOLLM noticed that xrep_inode_ids can change the user, group, or project id of any given file. When this happens, we need to detach any existing incore dquot and attach the correct ones. Cc: stable@vger.kernel.org # v6.8 Fixes: 2d295fe65776d1 ("xfs: repair inode records") Signed-off-by: Darrick J. Wong <djwong@kernel.org> Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Carlos Maiolino <cem@kernel.org>
5 daysxfs: abort directory tree repair whenever dl->aborted is setDarrick J. Wong
LOLLM observed that if the live update hooks for the directory tree repair code ever fail, they'll set dl->aborted, but then the main repair code path won't check it to exit early. This can cause incorrect repairs, so let's check for hook errors and abort the repair. Cc: stable@vger.kernel.org # v6.10 Fixes: 3f31406aef493b ("xfs: fix corruptions in the directory tree") Signed-off-by: Darrick J. Wong <djwong@kernel.org> Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Carlos Maiolino <cem@kernel.org>
5 daysxfs: don't subtract excess usage twice when computing agf_btreeblksDarrick J. Wong
LOLLM noticed that the free space btree repair code calculates agf_btreeblks from the number of blocks we wrote to rebuild the free space btrees (minus the roots). That's correct. However, it observes that we subtract the "excess" reservation, which is not correct. Fix this accounting problem. Cc: stable@vger.kernel.org # v6.8 Fixes: 4bdfd7d15747b1 ("xfs: repair free space btrees") Signed-off-by: Darrick J. Wong <djwong@kernel.org> Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Carlos Maiolino <cem@kernel.org>
5 daysxfs: check for termination during rmap btree walkDarrick J. Wong
LOLLM complains that we should check for a fatal signal *every* time we walk a record in the rmap btree as part of rebuilding the free space btrees. Fix that, and improve responsiveness to ^C of xfs_scrub. Cc: stable@vger.kernel.org # v6.8 Fixes: 4bdfd7d15747b1 ("xfs: repair free space btrees") Signed-off-by: Darrick J. Wong <djwong@kernel.org> Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Carlos Maiolino <cem@kernel.org>
5 daysMerge tag 'qcom-clk-for-7.4-2' of ↵Jerome Brunet
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into clk-qcom Qualcomm clock updates for v7.4 (second attempt) Add new clock support for Eliza, Kuno, MSM8952, Nord, Hawi, Maili, and IPQ5210. Rework common probe and CX power-domain handling. Add generic subsystem-init helpers and clean up the initcall setup. - Add camera, camera BIST, GPU, and video clock controllers for Eliza, and complete the Milos camera and video power-domain bindings. - Add Nord camera and video clocks, video AXI and QUSB2 PHY resets, EMAC interconnect clocks, and the corrected GCC GPLL enable offset. - Add Hawi camera and GPU clock controllers, extend them for Maili, and correct the camera Rivian PLL configuration. - Add global and RPMh clock controllers for Kuno. - Add the MSM8952 global clock controller and RPM clock binding. - Extend the IPQ common PLL driver with all IPQ5210 networking clock outputs, divider flags, and safe bounds handling. - Add IPQ9650 NoC clock management through the interconnect framework, add 24 MHz USB UTMI rates for three IPQ SoCs, and correct IPQ5018 and IPQ5424 clock and reset handling. - Add QCS8300 TSCSS clocks and resets, SM7250 RPMh clocks, and Glymur LNBB clocks. - Model GCC CX power-domain dependencies and runtime PM across the affected application, compute, and modem platforms. - Move always-on clock and GCC initialization into common Qualcomm probe handling across 47 camera, display, GPU, video, audio, and global clock controller drivers. - Add generic subsys_driver and subsys_platform_driver helpers, then convert the Qualcomm and Renesas clock drivers to use them. - Fix shared RCG initialization, status error propagation, and cleanup after failed rate changes. - Correct clock and reset register offsets for SM6115, QCS615, MSM8996, SDM660, and IPQ5424. - Correct APQ8064 PLL15 setup, MSM8939 Venus GDSC flags, SM8450 display clock ops, Glymur clock IDs and UFS mux ops, X1E80100 USB4 polling, and Lucid Ole PLL status handling. - Split out the X1E80100 TCSR binding and use the clk_ref helper, merge SM7150 into the SM6375 GCC binding, sort the Nord Kconfig entries, and migrate the SM8450 display controller to common driver data. - Add Abel Vesa as a reviewer for Qualcomm clock drivers.
5 daysALSA: usb-audio: Use fixed control index for us16x08 mixer elementsTakashi Iwai
The callbacks for us16x08 mixer elements assume that id.index points to the channel to be operated, and the assumption is correct for now. However, since the kctls are added via snd_usb_mixer_add_control() and it looks for the empty slot if the same control name is already present, in theory, the index can become more than the channel numbers (if a conflicting name really happens). Since the mixer code in us16x08 doesn't need the search for an empty slot but requires the fixed index, this patch changes slightly how to assign the kcontrols. Now, a new argument is added to snd_usb_mixer_add_list() in order to disable the empty slot search, and use it in us16x08's add_new_ctl() helper function, instead. Fixes: d2bb390a2081 ("ALSA: usb-audio: Tascam US-16x08 DSP mixer quirk") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://patch.msgid.link/20261014061406.162938-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
5 daysALSA: seq: oss: Prevent duplicate MIDI device teardownCen Zhang
Each OSS MIDI alias and its coder must have one final-release owner. find_slot() pins the alias under register_lock, but snd_seq_oss_midi_check_exit_port() clears its slot in a separate critical section without checking whether another callback already removed it. The use counter protects active users, but draining it does not elect a single remover. This requires overlapping raw kernel-client port controls for the same client. snd_seq_kernel_client_ctl() does not take ioctl_mutex, and snd_seq_delete_port() releases ports_mutex before returning to the DELETE_PORT handler's PORT_EXIT broadcast. If the old deletion is delayed before that broadcast, a new port can reuse the vacant address. Its PORT_START finds and keeps the old alias. Deleting the replacement then produces a second PORT_EXIT for the same address. Non-atomic subscriber delivery holds a read rwsem, so the two receive_announce() callbacks can run concurrently: Old-port deletion Replacement-port controls ----------------- ------------------------- Unlink and drain old port Delay before PORT_EXIT Create port at the same address PORT_START keeps existing alias Delete port; PORT_EXIT pins mdev PORT_EXIT pins the same mdev Clear slot; drop pin Clear slot; drop pin Wait for users to drain Wait for users to drain Free coder; pause before kfree(mdev) Free coder again: read freed coder->buf Both callbacks can select the same alias before either clears its slot. After both drop their pins, both waits can return. The second call to snd_midi_event_free() can then read the freed coder's buffer pointer, as in the report below, and attempt to release the same objects twice. Check that the pinned alias still occupies its slot under register_lock before clearing it. A callback that finds it already removed drops its pin and returns. Only the callback that removes the alias drains users and frees the coder and record. The pin keeps the record alive through this check, and the wait remains outside the spinlock. KASAN report as below: ================================================================== BUG: KASAN: slab-use-after-free in snd_midi_event_free+0x53/0x60 Read of size 8 at addr ffff888107074518 by task alsa-seq-fixtur/492 CPU: 3 UID: 0 PID: 492 Comm: alsa-seq-fixtur Not tainted 7.2.0-rc6-pmb-bt-functional-v1+ #1 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x93/0xd0 print_report+0xce/0x630 ? snd_midi_event_free+0x53/0x60 ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x20d/0x410 ? snd_midi_event_free+0x53/0x60 kasan_report+0xe0/0x110 ? snd_midi_event_free+0x53/0x60 snd_midi_event_free+0x53/0x60 snd_seq_oss_midi_check_exit_port+0x1d8/0x370 receive_announce+0x1b8/0x370 ? __pfx_receive_announce+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __lock_acquire+0x466/0x2260 ? snd_seq_port_use_ptr+0x40/0x170 ? srso_alias_return_thunk+0x5/0xfbef5 ? find_held_lock+0x2b/0x80 ? snd_seq_port_use_ptr+0x10c/0x170 ? srso_alias_return_thunk+0x5/0xfbef5 ? lock_release+0xc8/0x280 ? srso_alias_return_thunk+0x5/0xfbef5 ? __pfx_receive_announce+0x10/0x10 __snd_seq_deliver_single_event+0x105/0x1a0 ? snd_seq_port_use_ptr+0x111/0x170 snd_seq_deliver_single_event+0x2fc/0x770 ? __pfx_snd_seq_deliver_single_event+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __pfx_down_read_nested+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? do_raw_read_unlock+0x49/0xe0 ? srso_alias_return_thunk+0x5/0xfbef5 ? _raw_read_unlock+0x23/0x40 snd_seq_deliver_event+0x351/0x760 ? __pfx_snd_seq_deliver_event+0x10/0x10 ? _raw_spin_unlock_irqrestore+0x44/0x60 ? trace_hardirqs_on+0x18/0x160 ? srso_alias_return_thunk+0x5/0xfbef5 ? _raw_spin_unlock_irqrestore+0x44/0x60 ? srso_alias_return_thunk+0x5/0xfbef5 snd_seq_kernel_client_dispatch+0x13f/0x170 snd_seq_system_broadcast+0x100/0x150 ? __pfx_snd_seq_system_broadcast+0x10/0x10 ? mark_held_locks+0x40/0x70 ? _raw_spin_unlock_irqrestore+0x44/0x60 ? srso_alias_return_thunk+0x5/0xfbef5 ? lockdep_hardirqs_on_prepare+0xea/0x1a0 ? srso_alias_return_thunk+0x5/0xfbef5 snd_seq_ioctl_delete_port+0x179/0x4b0 call_seq_client_ctl+0x90/0x110 snd_seq_kernel_client_ctl+0x8a/0x100 pmbd_case_delete_port+0xa6/0xf0 ? __pfx_pmbd_case_delete_port+0x10/0x10 ? __might_fault+0xdd/0x190 ? srso_alias_return_thunk+0x5/0xfbef5 ? __might_fault+0x14e/0x190 ? srso_alias_return_thunk+0x5/0xfbef5 ? strim+0x19c/0x200 pmbd_case_control_write+0x2c5/0x470 ? __pfx_pmbd_case_control_write+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __debugfs_file_get+0x1bd/0x7f0 ? srso_alias_return_thunk+0x5/0xfbef5 ? lock_acquire+0x17b/0x2f0 ? ksys_write+0x111/0x200 full_proxy_write+0x11f/0x180 vfs_write+0x25a/0x1010 ? __pfx_full_proxy_write+0x10/0x10 ? __pfx___mutex_lock+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? lock_acquire+0x17b/0x2f0 ? __pfx_vfs_write+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? __fget_files+0x1e1/0x370 ksys_write+0x111/0x200 ? __pfx_ksys_write+0x10/0x10 ? rseq_register.isra.0+0x1f3/0x2e0 ? srso_alias_return_thunk+0x5/0xfbef5 ? exit_to_user_mode_loop+0x3a5/0x570 ? srso_alias_return_thunk+0x5/0xfbef5 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f3532e4e9ee Code: 08 0f 85 f5 4b ff ff 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 80 00 00 00 00 48 83 ec 08 RSP: 002b:00007f3532dafe08 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007f3532db06c0 RCX: 00007f3532e4e9ee RDX: 000000000000000a RSI: 000055efbd747156 RDI: 0000000000000003 RBP: 000055efbd747156 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000a R13: 0000000000000000 R14: 00007ffe7894e7f0 R15: 00007f35325b0000 </TASK> Allocated by task 490: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 __kmalloc_cache_noprof+0x251/0x610 snd_midi_event_new+0x74/0x210 snd_seq_oss_midi_check_new_port+0x329/0x610 receive_announce+0x277/0x370 __snd_seq_deliver_single_event+0x105/0x1a0 snd_seq_deliver_single_event+0x2fc/0x770 snd_seq_deliver_event+0x351/0x760 snd_seq_kernel_client_dispatch+0x13f/0x170 snd_seq_system_broadcast+0x100/0x150 snd_seq_ioctl_create_port+0x39a/0x9d0 call_seq_client_ctl+0x90/0x110 snd_seq_kernel_client_ctl+0x8a/0x100 pmbd_case_create_port+0xcc/0x160 pmbd_case_control_write+0x21d/0x470 full_proxy_write+0x11f/0x180 vfs_write+0x25a/0x1010 ksys_write+0x111/0x200 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 493: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 kfree+0x307/0x580 snd_midi_event_free+0x48/0x60 snd_seq_oss_midi_check_exit_port+0x1d8/0x370 receive_announce+0x1b8/0x370 __snd_seq_deliver_single_event+0x105/0x1a0 snd_seq_deliver_single_event+0x2fc/0x770 snd_seq_deliver_event+0x351/0x760 snd_seq_kernel_client_dispatch+0x13f/0x170 snd_seq_system_broadcast+0x100/0x150 snd_seq_ioctl_delete_port+0x179/0x4b0 call_seq_client_ctl+0x90/0x110 snd_seq_kernel_client_ctl+0x8a/0x100 pmbd_case_delete_port+0xa6/0xf0 pmbd_case_control_write+0x398/0x470 full_proxy_write+0x11f/0x180 vfs_write+0x25a/0x1010 ksys_write+0x111/0x200 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f The buggy address belongs to the object at ffff888107074500 which belongs to the cache kmalloc-96 of size 96 The buggy address is located 24 bytes inside of freed 96-byte region [ffff888107074500, ffff888107074560) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x107074 flags: 0x200000000000000(node=0|zone=2) page_type: f5(slab) raw: 0200000000000000 ffff888100042280 dead000000000122 0000000000000000 raw: 0000000000000000 0000000000200020 00000000f5000000 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888107074400: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff888107074480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff888107074500: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888107074580: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ffff888107074600: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ================================================================== Assisted-by: LLM Signed-off-by: Cen Zhang <zzzccc427@gmail.com> Link: https://patch.msgid.link/pm-pmb-7c5128efe2110a87b872-v2-c718183fd693e73d8e95@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
5 dayswifi: nxpwifi: use str_on_off() for carrier stateAryan Sinha
Both carrier prints open code the on/off ternary. Use the helper from string_choices.h instead. No change in output. Signed-off-by: Aryan Sinha <sinha.aryan03@gmail.com> Signed-off-by: Jeff Chen <jeff.chen_1@nxp.com>
5 dayswifi: nxpwifi: return timeout error from nxpwifi_sdio_poll_card_status()Karl Mehltretter
nxpwifi_sdio_poll_card_status() returns the result of the last register read when polling times out. If the final register read succeeds, the timeout is incorrectly reported as success. Return -ETIMEDOUT when polling runs out of retries. Fixes: 73b01e57ed3e ("wifi: nxp: add nxpwifi driver for IW61x") Assisted-by: LLM Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com> Signed-off-by: Jeff Chen <jeff.chen_1@nxp.com>
5 daysALSA: emux: Guard the OSS argument during port initializationCen Zhang
The OSS argument must be non-NULL before reset_port_mode() writes its event_passing field. snd_emux_open_seq_oss() assigns p->oss_arg only after snd_emux_create_port() attaches the writable sequencer port, so this field is still NULL when the callback first becomes reachable. With sequencer OSS and an EMUX provider enabled, another sequencer client can learn the new address from a PORT_START announcement and send a direct SNDRV_SEQ_EVENT_OSS channel-mode command, with marker 0xfe and command byte 0x8a. The following ordering is possible: OSS opener Sequencer writer snd_emux_create_port() snd_seq_event_port_attach() publish port, announce receive PORT_START snd_seq_write() snd_emux_event_oss_input() reset_port_mode() write via NULL oss_arg p->oss_arg = arg The callback's write precedes the opener's assignment. The core's port reference keeps the private data allocated but does not wait for its initialization. The write therefore dereferences NULL and can panic the kernel, as shown by the report below. Take a single READ_ONCE() snapshot of oss_arg and update event_passing only when that snapshot is non-NULL. Pair it with WRITE_ONCE() in the open path, so the check and write use the same pointer despite concurrent initialization. The open path still sets the initial mode after assigning the argument, and subsequent channel-mode events retain their existing handling. KASAN report as below: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] CPU: 2 UID: 0 PID: 495 Comm: fixture Tainted: G O 7.2.0-rc6-pmb-bt-functional-v1+ #1 PREEMPT(lazy) Tainted: [O]=OOT_MODULE Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:snd_emux_event_oss_input+0xa76/0xdd0 Code: fc ff df 48 c1 ea 03 80 3c 02 00 0f 85 e1 02 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b 5d 78 48 8d 7b 18 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 40 03 00 00 c7 43 18 00 00 00 RSP: 0018:ffff88810a937888 EFLAGS: 00010216 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff84f391b2 RDX: 0000000000000003 RSI: 0000000000000000 RDI: 0000000000000018 RBP: ffff8881179fc000 R08: 0000000000000001 R09: 0000000000000001 R10: ffffffff89444257 R11: ffff888107dd3a00 R12: 1ffff11021526f17 R13: 0000000000000000 R14: 0000000000000001 R15: ffff888112cda000 FS: 00007fdd13c9f780(0000) GS:ffff8881fd826000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fdd13e2f943 CR3: 00000001057ba005 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: <TASK> ? __pfx_snd_emux_event_oss_input+0x10/0x10 ? snd_seq_port_use_ptr+0x40/0x170 ? srso_alias_return_thunk+0x5/0xfbef5 ? find_held_lock+0x2b/0x80 ? snd_seq_port_use_ptr+0x10c/0x170 ? srso_alias_return_thunk+0x5/0xfbef5 ? lock_release+0xc8/0x280 ? srso_alias_return_thunk+0x5/0xfbef5 ? __pfx_snd_emux_event_oss_input+0x10/0x10 __snd_seq_deliver_single_event+0x105/0x1a0 ? snd_seq_port_use_ptr+0x111/0x170 snd_seq_deliver_single_event+0x2fc/0x770 ? __pfx_snd_seq_deliver_single_event+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? add_lock_to_list+0x9d/0x1e0 ? srso_alias_return_thunk+0x5/0xfbef5 ? check_prev_add+0x34c/0xe80 snd_seq_deliver_event+0x45a/0x760 ? __pfx_snd_seq_deliver_event+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? lock_acquire+0x17b/0x2f0 snd_seq_client_enqueue_event.constprop.0+0x278/0x430 ? __pfx_snd_seq_client_enqueue_event.constprop.0+0x10/0x10 ? __might_fault+0xdd/0x190 ? srso_alias_return_thunk+0x5/0xfbef5 ? __might_fault+0x14e/0x190 ? _raw_spin_unlock_irq+0x28/0x50 snd_seq_write+0x30a/0x5e0 ? __pfx_snd_seq_write+0x10/0x10 ? selinux_file_permission+0x122/0x570 ? srso_alias_return_thunk+0x5/0xfbef5 ? security_file_permission+0x26/0x80 vfs_write+0x25a/0x1010 ? __pfx_snd_seq_write+0x10/0x10 ? __pfx_vfs_write+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? trace_hardirqs_on+0x18/0x160 ? srso_alias_return_thunk+0x5/0xfbef5 ? __call_rcu_common.constprop.0+0x5c1/0xbd0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __fput+0x5ba/0xa60 ksys_write+0x1b7/0x200 ? __pfx_ksys_write+0x10/0x10 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fdd13d31687 Code: 48 89 fa 4c 89 df e8 58 b3 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff RSP: 002b:00007fff073e9f20 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fdd13c9f780 RCX: 00007fdd13d31687 RDX: 000000000000001c RSI: 00007fff073e9fc0 RDI: 0000000000000003 RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 0000561260c48082 R13: 0000561260c48011 R14: 0000561260c4809d R15: 0000000000000002 </TASK> Modules linked in: snd_emux_validation(O) ---[ end trace 0000000000000000 ]--- RIP: 0010:snd_emux_event_oss_input+0xa76/0xdd0 Code: fc ff df 48 c1 ea 03 80 3c 02 00 0f 85 e1 02 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b 5d 78 48 8d 7b 18 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 40 03 00 00 c7 43 18 00 00 00 RSP: 0018:ffff88810a937888 EFLAGS: 00010216 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff84f391b2 RDX: 0000000000000003 RSI: 0000000000000000 RDI: 0000000000000018 RBP: ffff8881179fc000 R08: 0000000000000001 R09: 0000000000000001 R10: ffffffff89444257 R11: ffff888107dd3a00 R12: 1ffff11021526f17 R13: 0000000000000000 R14: 0000000000000001 R15: ffff888112cda000 FS: 00007fdd13c9f780(0000) GS:ffff8881fd826000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fdd13e2f943 CR3: 00000001057ba005 CR4: 0000000000770ef0 PKRU: 55555554 Kernel panic - not syncing: Fatal exception Kernel Offset: disabled Rebooting in 1 seconds.. Assisted-by: LLM Signed-off-by: Cen Zhang <zzzccc427@gmail.com> Link: https://patch.msgid.link/pm-pmb-f8d6ccb28f196910444f-v2-c253bf022b6e954a7bdc@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
5 daysALSA: vmaster: Serialize hook registration with control callbacksCen Zhang
An HDA virtual-master hook must have its private argument initialized before a control callback can invoke it. snd_hda_add_vmaster_hook() installs the trampoline through snd_ctl_add_vmaster_hook(), which stores master->hook before master->hook_private_data without serialization. When a codec with a vmaster mute hook binds to an already registered card, snd_hda_gen_build_controls() publishes and initializes the Master Playback Switch before installing the hook. A native write that changes the switch can then run in the following order: 1. The codec bind path publishes and initializes the master control in __snd_hda_add_vmaster(), then calls snd_hda_add_vmaster_hook(). 2. The hook setter stores master->hook, but has not yet stored its private argument. 3. SNDRV_CTL_IOCTL_ELEM_WRITE takes controls_rwsem and calls master_put() while the setter remains between those stores. 4. master_put() sees the callback and invokes vmaster_hook() with a NULL argument. The trampoline dereferences it before the setter can complete publication. The write lock held by snd_ctl_elem_write() does not exclude the hook setter, so this can cause a NULL pointer dereference. Take the same controls_rwsem for writing inside snd_ctl_add_vmaster_hook() so the callback and its argument are installed together with respect to native control callbacks. Pass the card into the helper and update the HDA caller, keeping the lock in the ALSA core. Release it when registration returns, before the caller synchronizes the hook. KASAN report as below: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 1 UID: 0 PID: 499 Comm: alsa-vmaster-tr Not tainted 7.2.0-rc6-pmb-bt-functional-v1+ #1 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:vmaster_hook+0x35/0xb0 Code: f5 53 48 89 fb 48 83 ec 08 e8 57 f0 9a fc eb 50 e8 50 f0 9a fc 48 8d 7b 08 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 75 59 48 8d 7b 10 48 8b 43 08 48 ba 00 00 00 00 00 fc RSP: 0018:ffff888117647cd0 EFLAGS: 00010212 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff84e9ff50 RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000000000000008 RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000001 R10: ffffffff89427457 R11: ffff888115ad1d00 R12: ffffffff84e9ff30 R13: ffff888114943ca0 R14: 0000000000000000 R15: 0000000000000001 FS: 00007fe8167b3780(0000) GS:ffff88826b7e3000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000557c8c2842a8 CR3: 000000011579f005 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: <TASK> master_put+0x20e/0x2b0 snd_ctl_elem_write+0x37f/0x5e0 snd_ctl_ioctl+0x997/0xdd0 ? __pfx_snd_ctl_ioctl+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? selinux_file_ioctl+0xaa/0x280 ? __pfx_snd_ctl_ioctl+0x10/0x10 __x64_sys_ioctl+0x163/0x1d0 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fe8168c291b Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1c 48 8b 44 24 18 64 48 2b 04 25 28 00 00 RSP: 002b:00007fffab0cb150 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fe8168c291b RDX: 00007fffab0cb310 RSI: 00000000c4c85513 RDI: 0000000000000003 RBP: 00007fffab0cb310 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 00007fffab0cb1c0 R14: 0000000000000001 R15: 0000557c4f71fd10 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- Fixes: ee52e56e7b12 ("ALSA: hda - Fix mute-LED fixed mode") Signed-off-by: Cen Zhang <zzzccc427@gmail.com> Assisted-by: LLM Link: https://patch.msgid.link/pm-pmb-c2667fb9cc42fbb7943c-v4-b7bc2fe90e950accb3f7@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
5 daysALSA: hda/realtek: keep headset mic on Acer SSID 0x1640Iván Ezequiel Rodriguez
The micmute-LED quirk for the Aspire A315-44P matches PCI SSID 1025:1640 before the Acer ALC256 pin fallback. The Aspire Go 15 AG15-42P shares that SSID and leaves nid 0x19 as 0x411111f0, so selecting the LED-only fixup drops the headset-mic pin remap that the fallback would have applied. Chain ALC2XX_FIXUP_HEADSET_MIC before the GPIO3 micmute LED on that SSID. Leave the Swift SFG16 entry (0x169a) unchanged. Tested on Acer Aspire AG15-42P (Callisto_BCU): PCI pick 1025:1640, Headset Mic=0x19, GPIO3 enabled with no physical micmute LED, speaker and capture paths functional. Fixes: d830631a128b ("ALSA: hda/realtek: Add micmute LED quirk for Acer Aspire A315-44P") Cc: stable@vger.kernel.org Signed-off-by: Iván Ezequiel Rodriguez <ivanrwcm25@gmail.com> Link: https://patch.msgid.link/20261013204219.9649-1-ivanrwcm25@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
5 daysALSA: line6: Use kzalloc() for PCM buffer allocationTakashi Iwai
LINE6 driver allocates the PCM buffer via kmalloc(), and this might leave some bytes uninitialized that are out of the actual ring buffer size, while it's still exposed via mmap. For avoiding the leak of the uninitialized kernel memory, simply replace it with kzalloc(). Fixes: 705ececd1c60 ("Staging: add line6 usb driver") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://patch.msgid.link/20261013120528.52586-5-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
5 daysALSA: pcm: Protect delay DMA sync in forward and rewind, tooTakashi Iwai
Like the previous fix for snd_pcm_delay() (in the commit 50f413b83b31 "ALSA: pcm: Protect delay DMA sync against concurrent HW_FREE"), the snd_pcm_dma_buffer_sync() call in snd_pcm_forward() and snd_pcm_rewind() needs the similar protection against the concurrent hw_free action for avoiding potential UAFs. Fixes: a25684a95646 ("ALSA: memalloc: Support for non-contiguous page allocation") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://patch.msgid.link/20261013120528.52586-4-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
5 daysPCI: ultrarisc: Skip MEM outbound iATU setup on DP1000Xincheng Zhang
DP1000 has 16 outbound iATU windows and each window can map up to 4GB. One window is used for CFG accesses, one for I/O space and one for the 32-bit MEM aperture, leaving only 13 windows for the 64-bit MEM aperture. This limits the 64-bit MEM aperture that can be described with outbound iATU windows. DP1000 routes MEM transactions without using outbound iATU windows, so skip generic DWC MEM outbound iATU setup to allow a larger 64-bit MEM aperture. DP1000 does not use ECAM for this controller. Config space accesses keep using the normal DWC config access path and CFG outbound iATU programming. I/O space is also unchanged and still uses an outbound iATU window. The new flag only skips generic MEM-window programming. The DP1000 integration has SoC wrapper address decode for the PCIe MEM apertures described by the "ranges" property. CPU physical accesses to those MEM apertures are routed directly as PCIe MEM transactions with the corresponding PCIe bus address, without consuming outbound iATU windows. Set 'dw_pcie_rp->bypass_ob_mem_iatu' for this controller. Signed-off-by: Xincheng Zhang <zhangxincheng@ultrarisc.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://patch.msgid.link/20260905025635.211390-3-zhangxincheng@ultrarisc.com
5 daysALSA: jack: Fix kctl free at error in snd_jack_kctl_new()Takashi Iwai
When an error happens in snd_jack_kctl_new(), it tries to free the new kcontrol element via snd_ctl_free_one(). But snd_ctl_free_one() releases only the memories, and the internal linked list and hash entries still remain, which may lead to bogus accesses to user. Replace with the correct destructor, snd_ctl_remove(), for clearing the whole resources of the given kcontrol, instead. Fixes: 9058cbe1eed2 ("ALSA: jack: implement kctl creating for jack devices") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://patch.msgid.link/20261013120528.52586-2-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
5 daysPCI: dwc: Allow drivers to skip MEM outbound iATU setupXincheng Zhang
Some DWC-based controllers do not require outbound iATU windows for MEM transactions. For those platforms, programming outbound iATU windows for host bridge MEM ranges is unnecessary and may constrain the available MEM aperture. The DWC PCIe RP Controller Databook v6.00a, section 3.12.2, describes the default outbound no-match behavior as pass-through. Section 3.12.5.6, "No Address Match Result", says the address is not translated and programmable TLP header fields come from the application transmit interface. This no-match path cannot translate between different parent-bus and PCI addresses, so require skipped MEM ranges to be identity-mapped. Add dw_pcie_rp->bypass_ob_mem_iatu so drivers can skip generic MEM iATU setup while using the common DWC host init path. Existing drivers keep the current behavior because the flag defaults to false. The I/O iATU setup does not use the MEM resource iterator, and the iterator may be uninitialized when MEM setup is skipped. Avoid using it in the I/O iATU error path. Signed-off-by: Xincheng Zhang <zhangxincheng@ultrarisc.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://patch.msgid.link/20260905025635.211390-2-zhangxincheng@ultrarisc.com
5 daysALSA: pcm: Fix driver_tstamp value reportingAmadeusz Sławiński
In some cases (system32 and compat64) due to incorrect assignment wrong value is being reported. Fix it. Fixes: 3ddee7f88aaf ("ALSA: Avoid using timespec for struct snd_pcm_status") Signed-off-by: Amadeusz Sławiński <amade@asmblr.net> Link: https://patch.msgid.link/20261013164256.4949-1-amade@asmblr.net Signed-off-by: Takashi Iwai <tiwai@suse.de>
5 daysALSA: hda/tas2781: Skip invalid TAS2563 UEFI calibration dataGergo Koteles
Some Lenovo 14ARB7 laptops do not have proper calibration data. Skip these zero calibration values and fall back to the calibration data provided by the DSP firmware. Tested-by: Georg Wenzel <g.wenzel@gmail.com> Fixes: c3ca4458cc2f ("ALSA: hda/tas2781: add TAS2563 support for 14ARB7") Cc: stable@vger.kernel.org # 6.18 Signed-off-by: Gergo Koteles <soyer@irl.hu> Tested-by: Philipp Oster <philippdev5396@outlook.de> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/12a1ab265a1dc0e3a062a54287c8ef48682c4efc.1791895478.git.soyer@irl.hu
5 daysALSA: hda/tas2781: Assign total_sz at the end of the functionGergo Koteles
In the tas2563_save_calibration() function, cd->total_sz is assigned in several error paths. Move the assignment to the end of the function. Fixes: b6016332b889 ("ALSA: hda/tas2781: clear cali_data.total_sz when calibration read fails") Cc: stable@vger.kernel.org # 6.18 Signed-off-by: Gergo Koteles <soyer@irl.hu> Tested-by: Philipp Oster <philippdev5396@outlook.de> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/4b357778dce1b70a647e7e47b5ab3f0a6b2fc0cc.1791895478.git.soyer@irl.hu
5 daysRevert "ALSA: hda/tas2781: Enable bass speakers support"Takashi Iwai
This reverts commit 3bc4fc135ec741c5657cba6b2300bf8bf81179d2. The problem will be addressed in a more proper way later. Signed-off-by: Takashi Iwai <tiwai@suse.de>