Select Git revision
Search by author
- Any Author
- authors
-
Alexander Arndt
aarndt
-
Andreas Findeklee afindeklee
-
Annette Kobou akobou
-
Armin Mück amueck
-
**** project_143_bot_c8bbc40375b18788e4765d3c396612d5
-
Daniel Ehrler dehrler
-
Devran Ölcer doelcer
-
Dieter Scheufele dscheufele
-
Dietmar Kolbus dkolbus
-
Dominik Wurster Wurster
-
Eberhard Stoll estoll
-
Florian Mayer fmayer
-
Frieder Schrempf
fschrempf
-
Julian Bauknecht jbauknecht
-
Jó Bitsch jbitsch
-
Jürgen Kling
jgkling
-
Klemenz Christof kchristof
-
Lukas Loosli lloosli
-
Marc Gonser mgonser
-
Markus Abegg mabegg
- Dec 05, 2024
-
-
Adrian Hunter authored
commit 5b590160d2cf776b304eb054afafea2bd55e3620 upstream. If the trace data buffer becomes full, a truncated flag [T] is reported in PERF_RECORD_AUX. In some cases, the size reported is 0, even though data must have been added to make the buffer full. That happens when the buffer fills up from empty to full before the Intel PT driver has updated the buffer position. Then the driver calculates the new buffer position before calculating the data size. If the old and new positions are the same, the data size is reported as 0, even though it is really the whole buffer size. Fix by detecting when the buffer position is wrapped, and adjust the data size calculation accordingly. Example Use a very small buffer size (8K) and observe the size of truncated [T] data. Before the fix, it is possible to see records of 0 size. Before: $ perf record -m,8K -e intel_pt// uname Linux [ perf record: Woken up 2 times to write data ] [ perf record: Captured and wrote 0.105 MB perf.data ] $ perf script -D --no-itrace | grep AUX | grep -F '[T]' Warning: AUX data lost 2 times out of 3! 5 19462712368111 0x19710 [0x40]: PERF_RECORD_AUX offset: 0 size: 0 flags: 0x1 [T] 5 19462712700046 0x19ba8 [0x40]: PERF_RECORD_AUX offset: 0x170 size: 0xe90 flags: 0x1 [T] After: $ perf record -m,8K -e intel_pt// uname Linux [ perf record: Woken up 3 times to write data ] [ perf record: Captured and wrote 0.040 MB perf.data ] $ perf script -D --no-itrace | grep AUX | grep -F '[T]' Warning: AUX data lost 2 times out of 3! 1 113720802995 0x4948 [0x40]: PERF_RECORD_AUX offset: 0 size: 0x2000 flags: 0x1 [T] 1 113720979812 0x6b10 [0x40]: PERF_RECORD_AUX offset: 0x2000 size: 0x2000 flags: 0x1 [T] Fixes: 52ca9ced ("perf/x86/intel/pt: Add Intel PT PMU driver") Signed-off-by:Adrian Hunter <adrian.hunter@intel.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20241022155920.17511-2-adrian.hunter@intel.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Claudiu Beznea authored
commit 9d4f9f6a7bb1afbde57d08c98f2db4ff019ee19d upstream. On the Renesas RZ/G3S SMARC Carrier II board having a DA7212 codec (using da7213 driver) connected to one SSIF-2 available on the Renesas RZ/G3S SoC it has been discovered that using the runtime PM API for suspend/resume (as will be proposed in the following commits) leads to the codec not being propertly initialized after resume. This is because w/o max_register populated to regmap_config the regcache_rbtree_sync() breaks on base_reg > max condition and the regcache_sync_block() call is skipped. Fixes: ef5c2eba ("ASoC: codecs: Add da7213 codec") Cc: stable@vger.kernel.org Signed-off-by:
Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Link: https://patch.msgid.link/20241106081826.1211088-23-claudiu.beznea.uj@bp.renesas.com Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Qiu-ji Chen authored
commit 1157733344651ca505e259d6554591ff156922fa upstream. An atomicity violation occurs when the validity of the variables da7219->clk_src and da7219->mclk_rate is being assessed. Since the entire assessment is not protected by a lock, the da7219 variable might still be in flux during the assessment, rendering this check invalid. To fix this issue, we recommend adding a lock before the block if ((da7219->clk_src == clk_id) && (da7219->mclk_rate == freq)) so that the legitimacy check for da7219->clk_src and da7219->mclk_rate is protected by the lock, ensuring the validity of the check. This possible bug is found by an experimental static analysis tool developed by our team. This tool analyzes the locking APIs to extract function pairs that can be concurrently executed, and then analyzes the instructions in the paired functions to identify possible concurrency bugs including data races and atomicity violations. Fixes: 6d817c0e ("ASoC: codecs: Add da7219 codec driver") Cc: stable@vger.kernel.org Signed-off-by:
Qiu-ji Chen <chenqiuji666@gmail.com> Link: https://patch.msgid.link/20240930101216.23723-1-chenqiuji666@gmail.com Signed-off-by:
-
Ilya Zverev authored
commit b682aa788e5f9f1ddacdfbb453e49fd3f4e83721 upstream. New ThinkPads need new quirk entries. Ilya has tested this one. Laptop product id is 21MES00B00, though the shorthand 21ME works. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219533 Cc: stable@vger.kernel.org Signed-off-by:
Ilya Zverev <ilya@zverev.info> Link: https://patch.msgid.link/20241127134420.14471-1-ilya@zverev.info Signed-off-by:
-
Artem Sadovnikov authored
commit d9f9d96136cba8fedd647d2c024342ce090133c2 upstream. Commit 7c55b788 ("jfs: xattr: fix buffer overflow for invalid xattr") also addresses this issue but it only fixes it for positive values, while ea_size is an integer type and can take negative values, e.g. in case of a corrupted filesystem. This still breaks validation and would overflow because of implicit conversion from int to size_t in print_hex_dump(). Fix this issue by clamping the ea_size value instead. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Cc: stable@vger.kernel.org Signed-off-by:
Artem Sadovnikov <ancowi69@gmail.com> Signed-off-by:
Dave Kleikamp <dave.kleikamp@oracle.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
commit 72ad4ff638047bbbdf3232178fea4bec1f429319 upstream. Due to recent changes on the way we're maintaining media, the location of the main tree was updated. Change docs accordingly. Cc: stable@vger.kernel.org Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Reviewed-by:
Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by:
-
Mauro Carvalho Chehab authored
commit dc51b3cc9d4d2a04bdbfe34f7746fc9122cc3f49 upstream. There were some recent changes on the way we're handling media patches. Now, the official tree is located at: https://git.linuxtv.org/media.git/ Update it at MAINTAINERS file. Cc: stable@vger.kernel.org Signed-off-by:
-
Theodore Ts'o authored
commit 4a622e4d477bb12ad5ed4abbc7ad1365de1fa347 upstream. The original implementation ext4's FS_IOC_GETFSMAP handling only worked when the range of queried blocks included at least one free (unallocated) block range. This is because how the metadata blocks were emitted was as a side effect of ext4_mballoc_query_range() calling ext4_getfsmap_datadev_helper(), and that function was only called when a free block range was identified. As a result, this caused generic/365 to fail. Fix this by creating a new function ext4_getfsmap_meta_helper() which gets called so that blocks before the first free block range in a block group can get properly reported. Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Cc: stable@vger.kernel.org Signed-off-by:
-
Jeongjun Park authored
commit 902cc179c931a033cd7f4242353aa2733bf8524c upstream. find_group_other() and find_group_orlov() read *_lo, *_hi with ext4_free_inodes_count without additional locking. This can cause data-race warning, but since the lock is held for most writes and free inodes value is generally not a problem even if it is incorrect, it is more appropriate to use READ_ONCE()/WRITE_ONCE() than to add locking. ================================================================== BUG: KCSAN: data-race in ext4_free_inodes_count / ext4_free_inodes_set write to 0xffff88810404300e of 2 bytes by task 6254 on cpu 1: ext4_free_inodes_set+0x1f/0x80 fs/ext4/super.c:405 __ext4_new_inode+0x15ca/0x2200 fs/ext4/ialloc.c:1216 ext4_symlink+0x242/0x5a0 fs/ext4/namei.c:3391 vfs_symlink+0xca/0x1d0 fs/namei.c:4615 do_symlinkat+0xe3/0x340 fs/namei.c:4641 __do_sys_symlinkat fs/namei.c:4657 [inline] __se_sys_symlinkat fs/namei.c:4654 [inline] __x64_sys_symlinkat+0x5e/0x70 fs/namei.c:4654 x64_sys_call+0x1dda/0x2d60 arch/x86/include/generated/asm/syscalls_64.h:267 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x54/0x120 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x76/0x7e read to 0xffff88810404300e of 2 bytes by task 6257 on cpu 0: ext4_free_inodes_count+0x1c/0x80 fs/ext4/super.c:349 find_group_other fs/ext4/ialloc.c:594 [inline] __ext4_new_inode+0x6ec/0x2200 fs/ext4/ialloc.c:1017 ext4_symlink+0x242/0x5a0 fs/ext4/namei.c:3391 vfs_symlink+0xca/0x1d0 fs/namei.c:4615 do_symlinkat+0xe3/0x340 fs/namei.c:4641 __do_sys_symlinkat fs/namei.c:4657 [inline] __se_sys_symlinkat fs/namei.c:4654 [inline] __x64_sys_symlinkat+0x5e/0x70 fs/namei.c:4654 x64_sys_call+0x1dda/0x2d60 arch/x86/include/generated/asm/syscalls_64.h:267 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x54/0x120 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x76/0x7e Cc: stable@vger.kernel.org Signed-off-by:
Jeongjun Park <aha310510@gmail.com> Reviewed-by:
Andreas Dilger <adilger@dilger.ca> Link: https://patch.msgid.link/20241003125337.47283-1-aha310510@gmail.com Signed-off-by:
-
Darrick J. Wong authored
commit 62027820eb4486f075b89ec31c1548c6cb1bb13f upstream. In commit 11f4c3a5, we tried to simplify the extent lookup in xfs_can_free_eofblocks so that it doesn't incur the overhead of all the extra stuff that xfs_bmapi_read does around the iext lookup. Unfortunately, this causes regressions on generic/603, xfs/108, generic/219, xfs/173, generic/694, xfs/052, generic/230, and xfs/441 when always_cow is turned on. In all cases, the regressions take the form of alwayscow files consuming rather more space than the golden output is expecting. I observed that in all these cases, the cause of the excess space usage was due to CoW fork delalloc reservations that go beyond EOF. For alwayscow files we allow posteof delalloc CoW reservations because all writes go through the CoW fork. Recall that all extents in the CoW fork are accounted for via i_delayed_blks, which means that prior to this patch, we'd invoke xfs_free_eofblocks on first close if anything was in the CoW fork. Now we don't do that. Fix the problem by reverting the removal of the i_delayed_blks check. Cc: <stable@vger.kernel.org> # v6.12-rc1 Fixes: 11f4c3a5 ("xfs: simplify extent lookup in xfs_can_free_eofblocks") Signed-off-by:
Darrick J. Wong <djwong@kernel.org> Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Dmitry Baryshkov authored
commit 4a22918810980897393fa1776ea3877e4baf8cca upstream. UCSI connector's indices start from 1 up to 3, PMIC_GLINK_MAX_PORTS. Correct the condition in the pmic_glink_ucsi_connector_status() callback, fixing Type-C orientation reporting for the third USB-C connector. Fixes: 76716fd5 ("usb: typec: ucsi: glink: move GPIO reading into connector_status callback") Cc: stable@vger.kernel.org Reported-by:
Abel Vesa <abel.vesa@linaro.org> Reviewed-by:
Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by:
Johan Hovold <johan+linaro@kernel.org> Tested-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20241109-ucsi-glue-fixes-v2-1-8b21ff4f9fbe@linaro.org Signed-off-by:
-
Vitalii Mordan authored
commit 40c974826734836402abfd44efbf04f63a2cc1c1 upstream. If the clock sehci->clk was not enabled in spear_ehci_hcd_drv_probe, it should not be disabled in any path. Conversely, if it was enabled in spear_ehci_hcd_drv_probe, it must be disabled in all error paths to ensure proper cleanup. Found by Linux Verification Center (linuxtesting.org) with Klever. Fixes: 7675d6ba ("USB: EHCI: make ehci-spear a separate driver") Cc: stable@vger.kernel.org Signed-off-by:
Vitalii Mordan <mordan@ispras.ru> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20241114230310.432213-1-mordan@ispras.ru Signed-off-by:
-
Takashi Iwai authored
commit a3dd4d63eeb452cfb064a13862fb376ab108f6a6 upstream. The current USB-audio driver code doesn't check bLength of each descriptor at traversing for clock descriptors. That is, when a device provides a bogus descriptor with a shorter bLength, the driver might hit out-of-bounds reads. For addressing it, this patch adds sanity checks to the validator functions for the clock descriptor traversal. When the descriptor length is shorter than expected, it's skipped in the loop. For the clock source and clock multiplier descriptors, we can just check bLength against the sizeof() of each descriptor type. OTOH, the clock selector descriptor of UAC2 and UAC3 has an array of bNrInPins elements and two more fields at its tail, hence those have to be checked in addition to the sizeof() check. Reported-by:
Benoît Sevens <bsevens@google.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/20241121140613.3651-1-bsevens@google.com Link: https://patch.msgid.link/20241125144629.20757-1-tiwai@suse.de Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Benoît Sevens authored
commit b909df18ce2a998afef81d58bbd1a05dc0788c40 upstream. A bogus device can provide a bNumConfigurations value that exceeds the initial value used in usb_get_configuration for allocating dev->config. This can lead to out-of-bounds accesses later, e.g. in usb_destroy_configuration. Signed-off-by:
-
Qiu-ji Chen authored
commit afc545da381ba0c651b2658966ac737032676f01 upstream. This patch fixes an issue in the function xenbus_dev_probe(). In the xenbus_dev_probe() function, within the if (err) branch at line 313, the program incorrectly returns err directly without releasing the resources allocated by err = drv->probe(dev, id). As the return value is non-zero, the upper layers assume the processing logic has failed. However, the probe operation was performed earlier without a corresponding remove operation. Since the probe actually allocates resources, failing to perform the remove operation could lead to problems. To fix this issue, we followed the resource release logic of the xenbus_dev_remove() function by adding a new block fail_remove before the fail_put block. After entering the branch if (err) at line 313, the function will use a goto statement to jump to the fail_remove block, ensuring that the previously acquired resources are correctly released, thus preventing the reference count leak. This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and detecting potential issues where resources are not properly managed. In this case, the tool flagged the missing release operation as a potential problem, which led to the development of this patch. Fixes: 4bac07c9 ("xen: add the Xenbus sysfs and virtual device hotplug driver") Cc: stable@vger.kernel.org Signed-off-by:
Juergen Gross <jgross@suse.com> Message-ID: <20241105130919.4621-1-chenqiuji666@gmail.com> Signed-off-by:
-
Jakub Kicinski authored
commit 122aba8c80618eca904490b1733af27fb8f07528 upstream. Recent kernels cause a lot of TCP retransmissions [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 2.24 GBytes 19.2 Gbits/sec 2767 442 KBytes [ 5] 1.00-2.00 sec 2.23 GBytes 19.1 Gbits/sec 2312 350 KBytes ^^^^ Replacing the qdisc with pfifo makes retransmissions go away. It appears that a flow may have a delayed packet with a very near Tx time. Later, we may get busy processing Rx and the target Tx time will pass, but we won't service Tx since the CPU is busy with Rx. If Rx sees an ACK and we try to push more data for the delayed flow we may fastpath the skb, not realizing that there are already "ready to send" packets for this flow sitting in the qdisc. Don't trust the fastpath if we are "behind" according to the projected Tx time for next flow waiting in the Qdisc. Because we consider anything within the offload window to be okay for fastpath we must consider the entire offload window as "now". Qdisc config: qdisc fq 8001: dev eth0 parent 1234:1 limit 10000p flow_limit 100p \ buckets 32768 orphan_mask 1023 bands 3 \ priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 \ weights 589824 196608 65536 quantum 3028b initial_quantum 15140b \ low_rate_threshold 550Kbit \ refill_delay 40ms timer_slack 10us horizon 10s horizon_drop For iperf this change seems to do fine, the reordering is gone. The fastpath still gets used most of the time: gc 0 highprio 0 fastpath 142614 throttled 418309 latency 19.1us xx_behind 2731 where "xx_behind" counts how many times we hit the new "return false". CC: stable@vger.kernel.org Fixes: 076433bd ("net_sched: sch_fq: add fast path for mostly idle qdisc") Signed-off-by:Jakub Kicinski <kuba@kernel.org> Reviewed-by:
Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20241124022148.3126719-1-kuba@kernel.org Signed-off-by:
Paolo Abeni <pabeni@redhat.com> [stable: drop the offload horizon, it's not supported / 0] Signed-off-by:
-
Xiuhong Wang authored
commit a7a7c1d423a6351a6541e95c797da5358e5ad1ea upstream. After enable 16K page size, an infinite loop may occur in fiemap (fm_length=UINT64_MAX) on a file, such as the 16KB scratch.img during the remount operation in Android. The condition for whether fiemap continues to map is to check whether the number of bytes corresponding to the next map.m_lblk exceeds blks_to_bytes(inode,max_inode_blocks(inode)) if there are HOLE. The latter does not take into account the maximum size of a file with 16KB page size, so the loop cannot be jumped out. The following is the fail trace: When f2fs_map_blocks reaches map.m_lblk=3936, it needs to go to the first direct node block, so the map is 3936 + 4090 = 8026, The next map is the second direct node block, that is, 8026 + 4090 = 12116, The next map is the first indirect node block, that is, 12116 + 4090 * 4090 = 16740216, The next map is the second indirect node block, that is, 16740216 + 4090 * 4090 = 33468316, The next map is the first double indirect node block, that is, 33468316 + 4090 * 4090 * 4090 = 68451397316 Since map.m_lblk represents the address of a block, which is 32 bits, truncation will occur, that is, 68451397316 becomes 4026887876, and the number of bytes corresponding to the block number does not exceed blks_to_bytes(inode,max_inode_blocks(inode)), so the loop will not be jumped out. The next time, it will be considered that it should still be a double indirect node block, that is, 4026887876 + 4090 * 4090 * 4090 = 72444816876, which will be truncated to 3725340140, and the loop will not be jumped out. 156.374871: f2fs_map_blocks: dev = (254,57), ino = 7449, file offset = 0, start blkaddr = 0x8e00, len = 0x200, flags = 2,seg_type = 8, may_create = 0, multidevice = 0, flag = 1, err = 0 156.374916: f2fs_map_blocks: dev = (254,57), ino = 7449, file offset = 512, start blkaddr = 0x0, len = 0x0, flags = 0 , seg_type = 8, may_create = 0, multidevice = 0, flag = 1, err = 0 156.374920: f2fs_map_blocks: dev = (254,57), ino = 7449, file offset = 513, start blkaddr = 0x0, len = 0x0, flags = 0, seg_type = 8, may_create = 0, multidevice = 0, flag = 1, err = 0 ...... 156.385747: f2fs_map_blocks: dev = (254,57), ino = 7449, file offset = 3935, start blkaddr = 0x0, len = 0x0, flags = 0, seg_type = 8, may_create = 0, multidevice = 0, flag = 1, err = 0 156.385752: f2fs_map_blocks: dev = (254,57), ino = 7449, file offset = 3936, start blkaddr = 0x0, len = 0x0, flags = 0, seg_type = 8, may_create = 0, multidevice = 0, flag = 1, err = 0 156.385755: f2fs_map_blocks: dev = (254,57), ino = 7449, file offset = 8026, start blkaddr = 0x0, len = 0x0, flags = 0, seg_type = 8, may_create = 0, multidevice = 0, flag = 1, err = 0 156.385758: f2fs_map_blocks: dev = (254,57), ino = 7449, file offset = 12116, start blkaddr = 0x0, len = 0x0, flags = 0, seg_type = 8, may_create = 0, multidevice = 0, flag = 1, err = 0 156.385761: f2fs_map_blocks: dev = (254,57), ino = 7449, file offset = 16740216, start blkaddr = 0x0, len = 0x0, flags = 0, seg_type = 8, may_create = 0, multidevice = 0, flag = 1, err = 0 156.385764: f2fs_map_blocks: dev = (254,57), ino = 7449, file offset = 33468316, start blkaddr = 0x0, len = 0x0, flags = 0, seg_type = 8, may_create = 0, multidevice = 0, flag = 1, err = 0 156.385767: f2fs_map_blocks: dev = (254,57), ino = 7449, file offset = 4026887876, start blkaddr = 0x0, len = 0x0, flags = 0, seg_type = 8, may_create = 0, multidevice = 0, flag = 1, err = 0 156.385770: f2fs_map_blocks: dev = (254,57), ino = 7449, file offset = 3725340140, start blkaddr = 0x0, len = 0x0, flags = 0, seg_type = 8, may_create = 0, multidevice = 0, flag = 1, err = 0 156.385772: f2fs_map_blocks: dev = (254,57), ino = 7449, file offset = 4026887876, start blkaddr = 0x0, len = 0x0, flags = 0, seg_type = 8, may_create = 0, multidevice = 0, flag = 1, err = 0 156.385775: f2fs_map_blocks: dev = (254,57), ino = 7449, file offset = 3725340140, start blkaddr = 0x0, len = 0x0, flags = 0, seg_type = 8, may_create = 0, multidevice = 0, flag = 1, err = 0 Commit a6a010f5 ("f2fs: Restrict max filesize for 16K f2fs") has set the maximum allowed file size to (U32_MAX + 1) * F2FS_BLKSIZE, so max_file_blocks should be used here to limit it, that is, maxbytes defined above. And the max_inode_blocks function is not called by other functions except here, so cleanup it. Signed-off-by:
Xiuhong Wang <xiuhong.wang@unisoc.com> Signed-off-by:
Zhiguo Niu <zhiguo.niu@unisoc.com> Reviewed-by:
Chao Yu <chao@kernel.org> Signed-off-by:
Jaegeuk Kim <jaegeuk@kernel.org> Cc: Daniel Rosenberg <drosen@google.com> Signed-off-by:
-
Niklas Schnelle authored
[ Upstream commit c4a585e952ca403a370586d3f16e8331a7564901 ] In commit 6ee600bf ("s390/pci: remove hotplug slot when releasing the device") the zpci_exit_slot() was moved from zpci_device_reserved() to zpci_release_device() with the intention of keeping the hotplug slot around until the device is actually removed. Now zpci_release_device() is only called once all references are dropped. Since the zPCI subsystem only drops its reference once the device is in the reserved state it follows that zpci_release_device() must only deal with devices in the reserved state. Despite that it contains code to tear down from both configured and standby state. For the standby case this already includes the removal of the hotplug slot so would cause a double removal if a device was ever removed in either configured or standby state. Instead of causing a potential double removal in a case that should never happen explicitly WARN_ON() if a device in non-reserved state is released and get rid of the dead code cases. Fixes: 6ee600bf ("s390/pci: remove hotplug slot when releasing the device") Reviewed-by:
Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by:
Gerd Bayer <gbayer@linux.ibm.com> Tested-by:
Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by:
Heiko Carstens <hca@linux.ibm.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Nícolas F. R. A. Prado authored
[ Upstream commit 2f2020327cc8561d7c520d2f2d9acea84fa7b3a3 ] Following commit 13f58267 ("ASoC: soc.h: don't create dummy Component via COMP_DUMMY()"), COMP_DUMMY() became an array with zero length, and only gets populated with the dummy struct after the card is registered. Since the sound card driver's probe happens before the card registration, accessing any of the members of a dummy component during probe will result in undefined behavior. This can be observed in the mt8188 and mt8195 machine sound drivers. By omitting a dai link subnode in the sound card's node in the Devicetree, the default uninitialized dummy codec is used, and when its dai_name pointer gets passed to strcmp() it results in a null pointer dereference and a kernel panic. In addition to that, set_card_codec_info() in the generic helpers file, mtk-soundcard-driver.c, will populate a dai link with a dummy codec when a dai link node is present in DT but with no codec property. The result is that at probe time, a dummy codec can either be uninitialized with num_codecs = 0, or be an initialized dummy codec, with num_codecs = 1 and dai_name = "snd-soc-dummy-dai". In order to accommodate for both situations, check that num_codecs is not zero before accessing the codecs' fields but still check for the codec's dai name against "snd-soc-dummy-dai" as needed. While at it, also drop the check that dai_name is not null in the mt8192 driver, introduced in commit 4d4e1b63 ("ASoC: mediatek: mt8192: Check existence of dai_name before dereferencing"), as it is actually redundant given the preceding num_codecs != 0 check. Fixes: 13f58267 ("ASoC: soc.h: don't create dummy Component via COMP_DUMMY()") Signed-off-by:
Nícolas F. R. A. Prado <nfraprado@collabora.com> Reviewed-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Acked-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by:
Fei Shao <fshao@chromium.org> Acked-by:
Trevor Wu <trevor.wu@mediatek.com> Link: https://patch.msgid.link/20241126-asoc-mtk-dummy-panic-v1-1-42d53e168d2e@collabora.com Signed-off-by:
-
Venkata Prasad Potturu authored
[ Upstream commit 4095cf872084ecfdfdb0e681f3e9ff9745acfa75 ] Add condition check to register ACP PDM sound card by reading _WOV acpi entry. Fixes: 5426f506 ("ASoC: amd: Add support for enabling DMIC on acp6x via _DSD") Signed-off-by:
Venkata Prasad Potturu <venkataprasad.potturu@amd.com> Link: https://patch.msgid.link/20241127112227.227106-1-venkataprasad.potturu@amd.com Signed-off-by:
-
Zichen Xie authored
[ Upstream commit 9ad467a2b2716d4ed12f003b041aa6c776a13ff5 ] kunit_kzalloc() may return a NULL pointer, dereferencing it without NULL check may lead to NULL dereference. Add NULL checks for all the kunit_kzalloc() in sound_kunit.c Fixes: 3e39acf5 ("ALSA: core: Add sound core KUnit test") Signed-off-by:
Zichen Xie <zichenxie0106@gmail.com> Link: https://patch.msgid.link/20241126192448.12645-1-zichenxie0106@gmail.com Signed-off-by:
-
chao liu authored
[ Upstream commit 9b897132424fe76bf6c61f22f9cf12af7f1d1e6a ] Multiple profiles shared 'ent->caps', so some logs missed. Fixes: 0ed3b28a ("AppArmor: mediation of non file objects") Signed-off-by:
chao liu <liuzgyid@outlook.com> Signed-off-by:
John Johansen <john.johansen@canonical.com> Signed-off-by:
-
Nirmoy Das authored
[ Upstream commit 37a1cf288e4538eb39b38dbc745fe0da7ae53d94 ] If a previous ufence is not signalled, vm_bind will return -EBUSY. Delaying the modification of ufence->signalled can cause issues if the UMD reuses the same ufence so update ufence->signalled before waking up waiters. Cc: Matthew Brost <matthew.brost@intel.com> Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/3233 Fixes: 977e5b82 ("drm/xe: Expose user fence from xe_sync_entry") Reviewed-by:
Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241114150537.4161573-1-nirmoy.das@intel.com Signed-off-by:
Nirmoy Das <nirmoy.das@intel.com> (cherry picked from commit 553a5d14fcd927194c409b10faced6a6dbc678d1) Signed-off-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by:
-
Charles Han authored
[ Upstream commit e038f43edaf0083f6aa7c9415d86cf28dfd152f9 ] devm_kasprintf() can return a NULL pointer on failure,but this returned value in imx_audmix_probe() is not checked. Add NULL check in imx_audmix_probe(), to handle kernel NULL pointer dereference error. Fixes: 05d996e1 ("ASoC: imx-audmix: Split capture device for audmix") Signed-off-by:
Charles Han <hanchunchao@inspur.com> Link: https://patch.msgid.link/20241118084553.4195-1-hanchunchao@inspur.com Signed-off-by:
-
Zicheng Qu authored
[ Upstream commit 2bc96c95070571c6c824e0d4c7783bee25a37876 ] This commit addresses a null pointer dereference issue in hwss_setup_dpp(). The issue could occur when pipe_ctx->plane_state is null. The fix adds a check to ensure `pipe_ctx->plane_state` is not null before accessing. This prevents a null pointer dereference. Fixes: 0baae624 ("drm/amd/display: Refactor fast update to use new HWSS build sequence") Reviewed-by:
Tom Chung <chiahsuan.chung@amd.com> Signed-off-by:
Zicheng Qu <quzicheng@huawei.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Zicheng Qu authored
[ Upstream commit 6a057072ddd127255350357dd880903e8fa23f36 ] This commit addresses a null pointer dereference issue in dcn20_program_pipe(). Previously, commit 8e4ed3cf ("drm/amd/display: Add null check for pipe_ctx->plane_state in dcn20_program_pipe") partially fixed the null pointer dereference issue. However, in dcn20_update_dchubp_dpp(), the variable pipe_ctx is passed in, and plane_state is accessed again through pipe_ctx. Multiple if statements directly call attributes of plane_state, leading to potential null pointer dereference issues. This patch adds necessary null checks to ensure stability. Fixes: 8e4ed3cf ("drm/amd/display: Add null check for pipe_ctx->plane_state in dcn20_program_pipe") Reviewed-by:
-
Steven 'Steve' Kendall authored
[ Upstream commit 7037bb04265ef05c6ffad56d884b0df76f57b095 ] On several HP models (tested on HP 3125 and HP Probook 455 G2), spurious unplug events are emitted upon login on Chrome OS. This is likely due to the way Chrome OS restarts graphics upon login, so it's possible it's an issue on other distributions but not as common, though I haven't reproduced the issue elsewhere. Use logic from an earlier version of the merged change (see link below) which iterates over connectors and finds matching encoders, rather than the other way around. Also fixes an issue with screen mirroring on Chrome OS. I've deployed this patch on Fedora and did not observe any regression on these devices. Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1569#note_1603002 Link: https://gitlab.freedesktop.org/drm/amd/-/issues/3771 Fixes: 20ea3471 ("drm/radeon: Add HD-audio component notifier support (v6)") Signed-off-by:
Steven 'Steve' Kendall <skend@chromium.org> Signed-off-by:
-
Kailang Yang authored
[ Upstream commit cc3d0b5dd989d3238d456f9fd385946379a9c13d ] Old procedure has a chance to meet Headphone no output. Fixes: 4a219ef8 ("ALSA: hda/realtek - Add ALC256 HP depop function") Signed-off-by:
Kailang Yang <kailang@realtek.com> Link: https://lore.kernel.org/463c5f93715d4714967041a0a8cec28e@realtek.com Signed-off-by:
-
Gaosheng Cui authored
[ Upstream commit 369a9c046c2fdfe037f05b43b84c386bdbccc103 ] The alg instance should be released under the exception path, otherwise there may be resource leak here. To mitigate this, free the alg instance with crypto_free_shash when kmalloc fails. Fixes: 02fe26f2 ("firmware_loader: Add debug message with checksum for FW file") Signed-off-by:
Gaosheng Cui <cuigaosheng1@huawei.com> Reviewed-by:
Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Reviewed-by:
Russ Weight <russ.weight@linux.dev> Link: https://lore.kernel.org/r/20241016110335.3677924-1-cuigaosheng1@huawei.com Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit e56aac6e5a25630645607b6856d4b2a17b2311a5 ] The "command" variable can be controlled by the user via debugfs. The worry is that if con_index is zero then "&uc->ucsi->connector[con_index - 1]" would be an array underflow. Fixes: 170a6726 ("usb: typec: ucsi: add support for separate DP altmode devices") Signed-off-by:
Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/c69ef0b3-61b0-4dde-98dd-97b97f81d912@stanley.mountain Signed-off-by:
-
Carl Vanderlip authored
[ Upstream commit 23388a1b305e8aac714fafd5fdc72a580586bd0c ] Each of the __field() macros were triggering sparse warnings similar to: trace.h:87:1: sparse: sparse: cast to restricted __le64 trace.h:87:1: sparse: sparse: restricted __le64 degrades to integer trace.h:87:1: sparse: sparse: restricted __le64 degrades to integer Change each little endian type to its similarly sized native integer. Convert inputs into native endian. Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202402071859.8qMhgJEQ-lkp@intel.com/ Fixes: ceeb64f4 ("bus: mhi: host: Add tracing support") Signed-off-by:
Carl Vanderlip <quic_carlv@quicinc.com> Reviewed-by:
Jeffrey Hugo <quic_jhugo@quicinc.com> Reviewed-by:
Mayank Rana <quic_mrana@quicinc.com> Reviewed-by:
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/20241004170321.4047492-1-quic_carlv@quicinc.com Signed-off-by:
-
Jiasheng Jiang authored
[ Upstream commit 1437d9f1c56fce9c24e566508bce1d218dd5497a ] Add check for the return value of clk_enable() in order to catch the potential exception. Fixes: 4e2f42aa ("counter: ti-ecap-capture: capture driver support for ECAP") Reviewed-by:
Julien Panis <jpanis@baylibre.com> Signed-off-by:
Jiasheng Jiang <jiashengjiangcool@gmail.com> Link: https://lore.kernel.org/r/20241104194059.47924-1-jiashengjiangcool@gmail.com Signed-off-by:
William Breathitt Gray <wbg@kernel.org> Signed-off-by:
-
Jiasheng Jiang authored
[ Upstream commit 842c3755a6bfbfcafa4a1438078d2485a9eb1d87 ] Add check for the return value of clk_enable() in order to catch the potential exception. Fixes: c5b84255 ("counter: stm32-timer-cnt: add power management support") Fixes: ad29937e ("counter: Add STM32 Timer quadrature encoder") Signed-off-by:
-
Charles Han authored
[ Upstream commit bf373d2919d98f3d1fe1b19a0304f72fe74386d9 ] In rtk_usb3phy_probe() devm_kzalloc() may return NULL but this returned value is not checked. Fixes: adda6e82 ("phy: realtek: usb: Add driver for the Realtek SoC USB 3.0 PHY") Signed-off-by:
-
Charles Han authored
[ Upstream commit 04e3e9188291a183b27306ddb833722c0d083d6a ] In rtk_usb2phy_probe() devm_kzalloc() may return NULL but this returned value is not checked. Fixes: 134e6d25 ("phy: realtek: usb: Add driver for the Realtek SoC USB 2.0 PHY") Signed-off-by:
-
Antoniu Miclaus authored
[ Upstream commit bfa335f18d91c52fa0f8ba3e4d49afebbd9ee792 ] The adxl380_read_chn function returns either a negative value in case an error occurs or the actual sample. Check only for negative values after a channel is read. Fixes: df36de13 ("iio: accel: add ADXL380 driver") Signed-off-by:
Antoniu Miclaus <antoniu.miclaus@analog.com> Link: https://patch.msgid.link/20241101095202.20121-1-antoniu.miclaus@analog.com Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
-
Andy Shevchenko authored
[ Upstream commit 869aa5e847696bcda8966be9d03de2560226bcc3 ] Even if it's not critical, the avoidance of checking the error code from devm_mutex_init() call today diminishes the point of using devm variant of it. Tomorrow it may even leak something. Add the missed check. Fixes: 371f778b ("iio: adc: add support for pac1921") Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by:
Matteo Martelli <matteomartelli3@gmail.com> Link: https://patch.msgid.link/20241030162013.2100253-3-andriy.shevchenko@linux.intel.com Signed-off-by:
-
Andy Shevchenko authored
[ Upstream commit 8ebfd09255219ae55f8a101f6aeb0f64dd780d88 ] Even if it's not critical, the avoidance of checking the error code from devm_mutex_init() call today diminishes the point of using devm variant of it. Tomorrow it may even leak something. Add the missed check. Fixes: 938fd562 ("iio: adc: Add support for AD4000") Signed-off-by:
-
David Lechner authored
[ Upstream commit 62dd96ac9cdf2814f41cfc55ecaf22a28aad6ccb ] Fix reading unsigned data from the AD4000 ADC via the _raw sysfs attribute by ensuring that *val is set before returning from ad4000_single_conversion(). This was not being set in any code path and was causing the attribute to return a random value. Fixes: 938fd562 ("iio: adc: Add support for AD4000") Signed-off-by:
David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20241030-iio-adc-ad4000-fix-reading-unsigned-data-v1-1-2e28dd75fe29@baylibre.com Signed-off-by:
-
Yang Yingliang authored
[ Upstream commit fa4076314480bcb2bb32051027735b1cde07eea2 ] It should be fwnode_back passed to IS_ERR(). Fixes: c464cc61 ("iio: add child nodes support in iio backend framework") Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Link: https://patch.msgid.link/20241028135215.1549-1-yangyingliang@huaweicloud.com Signed-off-by:
-
