| Age | Commit message (Collapse) | Author |
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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
|
|
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
|
|
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>
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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.
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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
|
|
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>
|
|
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
|
|
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>
|
|
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
|
|
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
|
|
This reverts commit 3bc4fc135ec741c5657cba6b2300bf8bf81179d2.
The problem will be addressed in a more proper way later.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|