October 2024 - Linux-stable-mirror

[PATCH v3 0/2] drm/nouveau/dmem: Fix Vulnerability and Device Channels configuration

by Yonatan Maman

From: Yonatan Maman <Ymaman(a)Nvidia.com> This patch series addresses two critical issues in the Nouveau driver related to device channels, error handling, and sensitive data leaks. - Vulnerability in migrate_to_ram: The migrate_to_ram function might return a dirty HIGH_USER page when a copy push command (FW channel) fails, potentially exposing sensitive data and posing a security risk. To mitigate this, the patch ensures the allocation of a non-dirty (zero) page for the destination, preventing the return of a dirty page and enhancing driver security in case of failure. - Privileged Error in Copy Engine Channel: An error was observed when the nouveau_dmem_copy_one function is executed, leading to a Host Copy Engine Privileged error on channel 1. The patch resolves this by adjusting the Copy Engine channel configuration to permit privileged push commands, resolving the error. Changes since V2: - Fixed version according to Danilo Krummrich's comments. Yonatan Maman (2): nouveau/dmem: Fix privileged error in copy engine channel nouveau/dmem: Fix vulnerability in migrate_to_ram upon copy error drivers/gpu/drm/nouveau/nouveau_dmem.c | 2 +- drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- 2.34.1

6 months, 3 weeks

3
4
0 0

[PATCH 6.1.y 1/5] erofs: get rid of erofs_inode_datablocks()

by Gao Xiang

commit 4efdec36dc9907628e590a68193d6d8e5e74d032 upstream. erofs_inode_datablocks() has the only one caller, let's just get rid of it entirely. No logic changes. Reviewed-by: Yue Hu <huyue2(a)coolpad.com> Reviewed-by: Jingbo Xu <jefflexu(a)linux.alibaba.com> Reviewed-by: Chao Yu <chao(a)kernel.org> Stable-dep-of: 9ed50b8231e3 ("erofs: fix incorrect symlink detection in fast symlink") Link: https://lore.kernel.org/r/20230204093040.97967-1-hsiangkao@linux.alibaba.com [ Gao Xiang: apply this to 6.6.y to avoid further backport twists due to obsoleted EROFS_BLKSIZ. ] Signed-off-by: Gao Xiang <hsiangkao(a)linux.alibaba.com> --- Obsoleted EROFS_BLKSIZ impedes efforts to backport 9ed50b8231e3 ("erofs: fix incorrect symlink detection in fast symlink") 9e2f9d34dd12 ("erofs: handle overlapped pclusters out of crafted images properly") To avoid further bugfix conflicts due to random EROFS_BLKSIZs around the whole codebase, just backport the dependencies for 6.1.y. fs/erofs/internal.h | 6 ------ fs/erofs/namei.c | 18 +++++------------- 2 files changed, 5 insertions(+), 19 deletions(-) diff --git a/fs/erofs/internal.h b/fs/erofs/internal.h index 79a7a5815ea6..30d464230ae0 100644 --- a/fs/erofs/internal.h +++ b/fs/erofs/internal.h @@ -347,12 +347,6 @@ static inline erofs_off_t erofs_iloc(struct inode *inode) (EROFS_I(inode)->nid << sbi->islotbits); } -static inline unsigned long erofs_inode_datablocks(struct inode *inode) -{ - /* since i_size cannot be changed */ - return DIV_ROUND_UP(inode->i_size, EROFS_BLKSIZ); -} - static inline unsigned int erofs_bitrange(unsigned int value, unsigned int bit, unsigned int bits) { diff --git a/fs/erofs/namei.c b/fs/erofs/namei.c index e8ccaa761bd6..642431350bea 100644 --- a/fs/erofs/namei.c +++ b/fs/erofs/namei.c @@ -5,7 +5,6 @@ * Copyright (C) 2022, Alibaba Cloud */ #include "xattr.h" - #include <trace/events/erofs.h> struct erofs_qstr { @@ -87,19 +86,13 @@ static struct erofs_dirent *find_target_dirent(struct erofs_qstr *name, return ERR_PTR(-ENOENT); } -static void *find_target_block_classic(struct erofs_buf *target, - struct inode *dir, - struct erofs_qstr *name, - int *_ndirents) +static void *erofs_find_target_block(struct erofs_buf *target, + struct inode *dir, struct erofs_qstr *name, int *_ndirents) { - unsigned int startprfx, endprfx; - int head, back; + int head = 0, back = DIV_ROUND_UP(dir->i_size, EROFS_BLKSIZ) - 1; + unsigned int startprfx = 0, endprfx = 0; void *candidate = ERR_PTR(-ENOENT); - startprfx = endprfx = 0; - head = 0; - back = erofs_inode_datablocks(dir) - 1; - while (head <= back) { const int mid = head + (back - head) / 2; struct erofs_buf buf = __EROFS_BUF_INITIALIZER; @@ -180,8 +173,7 @@ int erofs_namei(struct inode *dir, const struct qstr *name, erofs_nid_t *nid, qn.end = name->name + name->len; ndirents = 0; - - de = find_target_block_classic(&buf, dir, &qn, &ndirents); + de = erofs_find_target_block(&buf, dir, &qn, &ndirents); if (IS_ERR(de)) return PTR_ERR(de); -- 2.43.5

6 months, 3 weeks

2
6
0 0

[PATCH 4.19] btrfs: get rid of warning on transaction commit when using flushoncommit

by hsimeliere.opensource＠witekio.com

From: Filipe Manana <fdmanana(a)suse.com> commit a0f0cf8341e34e5d2265bfd3a7ad68342da1e2aa upstream. When using the flushoncommit mount option, during almost every transaction commit we trigger a warning from __writeback_inodes_sb_nr(): $ cat fs/fs-writeback.c: (...) static void __writeback_inodes_sb_nr(struct super_block *sb, ... { (...) WARN_ON(!rwsem_is_locked(&sb->s_umount)); (...) } (...) The trace produced in dmesg looks like the following: [947.473890] WARNING: CPU: 5 PID: 930 at fs/fs-writeback.c:2610 __writeback_inodes_sb_nr+0x7e/0xb3 [947.481623] Modules linked in: nfsd nls_cp437 cifs asn1_decoder cifs_arc4 fscache cifs_md4 ipmi_ssif [947.489571] CPU: 5 PID: 930 Comm: btrfs-transacti Not tainted 95.16.3-srb-asrock-00001-g36437ad63879 #186 [947.497969] RIP: 0010:__writeback_inodes_sb_nr+0x7e/0xb3 [947.502097] Code: 24 10 4c 89 44 24 18 c6 (...) [947.519760] RSP: 0018:ffffc90000777e10 EFLAGS: 00010246 [947.523818] RAX: 0000000000000000 RBX: 0000000000963300 RCX: 0000000000000000 [947.529765] RDX: 0000000000000000 RSI: 000000000000fa51 RDI: ffffc90000777e50 [947.535740] RBP: ffff888101628a90 R08: ffff888100955800 R09: ffff888100956000 [947.541701] R10: 0000000000000002 R11: 0000000000000001 R12: ffff888100963488 [947.547645] R13: ffff888100963000 R14: ffff888112fb7200 R15: ffff888100963460 [947.553621] FS: 0000000000000000(0000) GS:ffff88841fd40000(0000) knlGS:0000000000000000 [947.560537] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [947.565122] CR2: 0000000008be50c4 CR3: 000000000220c000 CR4: 00000000001006e0 [947.571072] Call Trace: [947.572354] <TASK> [947.573266] btrfs_commit_transaction+0x1f1/0x998 [947.576785] ? start_transaction+0x3ab/0x44e [947.579867] ? schedule_timeout+0x8a/0xdd [947.582716] transaction_kthread+0xe9/0x156 [947.585721] ? btrfs_cleanup_transaction.isra.0+0x407/0x407 [947.590104] kthread+0x131/0x139 [947.592168] ? set_kthread_struct+0x32/0x32 [947.595174] ret_from_fork+0x22/0x30 [947.597561] </TASK> [947.598553] ---[ end trace 644721052755541c ]--- This is because we started using writeback_inodes_sb() to flush delalloc when committing a transaction (when using -o flushoncommit), in order to avoid deadlocks with filesystem freeze operations. This change was made by commit ce8ea7cc6eb313 ("btrfs: don't call btrfs_start_delalloc_roots in flushoncommit"). After that change we started producing that warning, and every now and then a user reports this since the warning happens too often, it spams dmesg/syslog, and a user is unsure if this reflects any problem that might compromise the filesystem's reliability. We can not just lock the sb->s_umount semaphore before calling writeback_inodes_sb(), because that would at least deadlock with filesystem freezing, since at fs/super.c:freeze_super() sync_filesystem() is called while we are holding that semaphore in write mode, and that can trigger a transaction commit, resulting in a deadlock. It would also trigger the same type of deadlock in the unmount path. Possibly, it could also introduce some other locking dependencies that lockdep would report. To fix this call try_to_writeback_inodes_sb() instead of writeback_inodes_sb(), because that will try to read lock sb->s_umount and then will only call writeback_inodes_sb() if it was able to lock it. This is fine because the cases where it can't read lock sb->s_umount are during a filesystem unmount or during a filesystem freeze - in those cases sb->s_umount is write locked and sync_filesystem() is called, which calls writeback_inodes_sb(). In other words, in all cases where we can't take a read lock on sb->s_umount, writeback is already being triggered elsewhere. An alternative would be to call btrfs_start_delalloc_roots() with a number of pages different from LONG_MAX, for example matching the number of delalloc bytes we currently have, in which case we would end up starting all delalloc with filemap_fdatawrite_wbc() and not with an async flush via filemap_flush() - that is only possible after the rather recent commit e076ab2a2ca70a ("btrfs: shrink delalloc pages instead of full inodes"). However that creates a whole new can of worms due to new lock dependencies, which lockdep complains, like for example: [ 8948.247280] ====================================================== [ 8948.247823] WARNING: possible circular locking dependency detected [ 8948.248353] 5.17.0-rc1-btrfs-next-111 #1 Not tainted [ 8948.248786] ------------------------------------------------------ [ 8948.249320] kworker/u16:18/933570 is trying to acquire lock: [ 8948.249812] ffff9b3de1591690 (sb_internal#2){.+.+}-{0:0}, at: find_free_extent+0x141e/0x1590 [btrfs] [ 8948.250638] but task is already holding lock: [ 8948.251140] ffff9b3e09c717d8 (&root->delalloc_mutex){+.+.}-{3:3}, at: start_delalloc_inodes+0x78/0x400 [btrfs] [ 8948.252018] which lock already depends on the new lock. [ 8948.252710] the existing dependency chain (in reverse order) is: [ 8948.253343] -> #2 (&root->delalloc_mutex){+.+.}-{3:3}: [ 8948.253950] __mutex_lock+0x90/0x900 [ 8948.254354] start_delalloc_inodes+0x78/0x400 [btrfs] [ 8948.254859] btrfs_start_delalloc_roots+0x194/0x2a0 [btrfs] [ 8948.255408] btrfs_commit_transaction+0x32f/0xc00 [btrfs] [ 8948.255942] btrfs_mksubvol+0x380/0x570 [btrfs] [ 8948.256406] btrfs_mksnapshot+0x81/0xb0 [btrfs] [ 8948.256870] __btrfs_ioctl_snap_create+0x17f/0x190 [btrfs] [ 8948.257413] btrfs_ioctl_snap_create_v2+0xbb/0x140 [btrfs] [ 8948.257961] btrfs_ioctl+0x1196/0x3630 [btrfs] [ 8948.258418] __x64_sys_ioctl+0x83/0xb0 [ 8948.258793] do_syscall_64+0x3b/0xc0 [ 8948.259146] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 8948.259709] -> #1 (&fs_info->delalloc_root_mutex){+.+.}-{3:3}: [ 8948.260330] __mutex_lock+0x90/0x900 [ 8948.260692] btrfs_start_delalloc_roots+0x97/0x2a0 [btrfs] [ 8948.261234] btrfs_commit_transaction+0x32f/0xc00 [btrfs] [ 8948.261766] btrfs_set_free_space_cache_v1_active+0x38/0x60 [btrfs] [ 8948.262379] btrfs_start_pre_rw_mount+0x119/0x180 [btrfs] [ 8948.262909] open_ctree+0x1511/0x171e [btrfs] [ 8948.263359] btrfs_mount_root.cold+0x12/0xde [btrfs] [ 8948.263863] legacy_get_tree+0x30/0x50 [ 8948.264242] vfs_get_tree+0x28/0xc0 [ 8948.264594] vfs_kern_mount.part.0+0x71/0xb0 [ 8948.265017] btrfs_mount+0x11d/0x3a0 [btrfs] [ 8948.265462] legacy_get_tree+0x30/0x50 [ 8948.265851] vfs_get_tree+0x28/0xc0 [ 8948.266203] path_mount+0x2d4/0xbe0 [ 8948.266554] __x64_sys_mount+0x103/0x140 [ 8948.266940] do_syscall_64+0x3b/0xc0 [ 8948.267300] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 8948.267790] -> #0 (sb_internal#2){.+.+}-{0:0}: [ 8948.268322] __lock_acquire+0x12e8/0x2260 [ 8948.268733] lock_acquire+0xd7/0x310 [ 8948.269092] start_transaction+0x44c/0x6e0 [btrfs] [ 8948.269591] find_free_extent+0x141e/0x1590 [btrfs] [ 8948.270087] btrfs_reserve_extent+0x14b/0x280 [btrfs] [ 8948.270588] cow_file_range+0x17e/0x490 [btrfs] [ 8948.271051] btrfs_run_delalloc_range+0x345/0x7a0 [btrfs] [ 8948.271586] writepage_delalloc+0xb5/0x170 [btrfs] [ 8948.272071] __extent_writepage+0x156/0x3c0 [btrfs] [ 8948.272579] extent_write_cache_pages+0x263/0x460 [btrfs] [ 8948.273113] extent_writepages+0x76/0x130 [btrfs] [ 8948.273573] do_writepages+0xd2/0x1c0 [ 8948.273942] filemap_fdatawrite_wbc+0x68/0x90 [ 8948.274371] start_delalloc_inodes+0x17f/0x400 [btrfs] [ 8948.274876] btrfs_start_delalloc_roots+0x194/0x2a0 [btrfs] [ 8948.275417] flush_space+0x1f2/0x630 [btrfs] [ 8948.275863] btrfs_async_reclaim_data_space+0x108/0x1b0 [btrfs] [ 8948.276438] process_one_work+0x252/0x5a0 [ 8948.276829] worker_thread+0x55/0x3b0 [ 8948.277189] kthread+0xf2/0x120 [ 8948.277506] ret_from_fork+0x22/0x30 [ 8948.277868] other info that might help us debug this: [ 8948.278548] Chain exists of: sb_internal#2 --> &fs_info->delalloc_root_mutex --> &root->delalloc_mutex [ 8948.279601] Possible unsafe locking scenario: [ 8948.280102] CPU0 CPU1 [ 8948.280508] ---- ---- [ 8948.280915] lock(&root->delalloc_mutex); [ 8948.281271] lock(&fs_info->delalloc_root_mutex); [ 8948.281915] lock(&root->delalloc_mutex); [ 8948.282487] lock(sb_internal#2); [ 8948.282800] *** DEADLOCK *** [ 8948.283333] 4 locks held by kworker/u16:18/933570: [ 8948.283750] #0: ffff9b3dc00a9d48 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work+0x1d2/0x5a0 [ 8948.284609] #1: ffffa90349dafe70 ((work_completion)(&fs_info->async_data_reclaim_work)){+.+.}-{0:0}, at: process_one_work+0x1d2/0x5a0 [ 8948.285637] #2: ffff9b3e14db5040 (&fs_info->delalloc_root_mutex){+.+.}-{3:3}, at: btrfs_start_delalloc_roots+0x97/0x2a0 [btrfs] [ 8948.286674] #3: ffff9b3e09c717d8 (&root->delalloc_mutex){+.+.}-{3:3}, at: start_delalloc_inodes+0x78/0x400 [btrfs] [ 8948.287596] stack backtrace: [ 8948.287975] CPU: 3 PID: 933570 Comm: kworker/u16:18 Not tainted 5.17.0-rc1-btrfs-next-111 #1 [ 8948.288677] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 8948.289649] Workqueue: events_unbound btrfs_async_reclaim_data_space [btrfs] [ 8948.290298] Call Trace: [ 8948.290517] <TASK> [ 8948.290700] dump_stack_lvl+0x59/0x73 [ 8948.291026] check_noncircular+0xf3/0x110 [ 8948.291375] ? start_transaction+0x228/0x6e0 [btrfs] [ 8948.291826] __lock_acquire+0x12e8/0x2260 [ 8948.292241] lock_acquire+0xd7/0x310 [ 8948.292714] ? find_free_extent+0x141e/0x1590 [btrfs] [ 8948.293241] ? lock_is_held_type+0xea/0x140 [ 8948.293601] start_transaction+0x44c/0x6e0 [btrfs] [ 8948.294055] ? find_free_extent+0x141e/0x1590 [btrfs] [ 8948.294518] find_free_extent+0x141e/0x1590 [btrfs] [ 8948.294957] ? _raw_spin_unlock+0x29/0x40 [ 8948.295312] ? btrfs_get_alloc_profile+0x124/0x290 [btrfs] [ 8948.295813] btrfs_reserve_extent+0x14b/0x280 [btrfs] [ 8948.296270] cow_file_range+0x17e/0x490 [btrfs] [ 8948.296691] btrfs_run_delalloc_range+0x345/0x7a0 [btrfs] [ 8948.297175] ? find_lock_delalloc_range+0x247/0x270 [btrfs] [ 8948.297678] writepage_delalloc+0xb5/0x170 [btrfs] [ 8948.298123] __extent_writepage+0x156/0x3c0 [btrfs] [ 8948.298570] extent_write_cache_pages+0x263/0x460 [btrfs] [ 8948.299061] extent_writepages+0x76/0x130 [btrfs] [ 8948.299495] do_writepages+0xd2/0x1c0 [ 8948.299817] ? sched_clock_cpu+0xd/0x110 [ 8948.300160] ? lock_release+0x155/0x4a0 [ 8948.300494] filemap_fdatawrite_wbc+0x68/0x90 [ 8948.300874] ? do_raw_spin_unlock+0x4b/0xa0 [ 8948.301243] start_delalloc_inodes+0x17f/0x400 [btrfs] [ 8948.301706] ? lock_release+0x155/0x4a0 [ 8948.302055] btrfs_start_delalloc_roots+0x194/0x2a0 [btrfs] [ 8948.302564] flush_space+0x1f2/0x630 [btrfs] [ 8948.302970] btrfs_async_reclaim_data_space+0x108/0x1b0 [btrfs] [ 8948.303510] process_one_work+0x252/0x5a0 [ 8948.303860] ? process_one_work+0x5a0/0x5a0 [ 8948.304221] worker_thread+0x55/0x3b0 [ 8948.304543] ? process_one_work+0x5a0/0x5a0 [ 8948.304904] kthread+0xf2/0x120 [ 8948.305184] ? kthread_complete_and_exit+0x20/0x20 [ 8948.305598] ret_from_fork+0x22/0x30 [ 8948.305921] </TASK> It all comes from the fact that btrfs_start_delalloc_roots() takes the delalloc_root_mutex, in the transaction commit path we are holding a read lock on one of the superblock's freeze semaphores (via sb_start_intwrite()), the async reclaim task can also do a call to btrfs_start_delalloc_roots(), which ends up triggering writeback with calls to filemap_fdatawrite_wbc(), resulting in extent allocation which in turn can call btrfs_start_transaction(), which will result in taking the freeze semaphore via sb_start_intwrite(), forming a nasty dependency on all those locks which can be taken in different orders by different code paths. So just adopt the simple approach of calling try_to_writeback_inodes_sb() at btrfs_start_delalloc_flush(). Link: https://lore.kernel.org/linux-btrfs/20220130005258.GA7465@cuci.nl/ Link: https://lore.kernel.org/linux-btrfs/43acc426-d683-d1b6-729d-c6bc4a2fff4d@gm… Link: https://lore.kernel.org/linux-btrfs/6833930a-08d7-6fbc-0141-eb9cdfd6bb4d@gm… Link: https://lore.kernel.org/linux-btrfs/20190322041731.GF16651@hungrycats.org/ Reviewed-by: Omar Sandoval <osandov(a)fb.com> Signed-off-by: Filipe Manana <fdmanana(a)suse.com> [ add more link reports ] Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Hugo SIMELIERE <hsimeliere.opensource(a)witekio.com> --- fs/btrfs/transaction.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c index df9b209bf1b2..a844e3b2bc2e 100644 --- a/fs/btrfs/transaction.c +++ b/fs/btrfs/transaction.c @@ -1921,16 +1921,24 @@ static void cleanup_transaction(struct btrfs_trans_handle *trans, int err) static inline int btrfs_start_delalloc_flush(struct btrfs_fs_info *fs_info) { /* - * We use writeback_inodes_sb here because if we used + * We use try_to_writeback_inodes_sb() here because if we used * btrfs_start_delalloc_roots we would deadlock with fs freeze. * Currently are holding the fs freeze lock, if we do an async flush * we'll do btrfs_join_transaction() and deadlock because we need to * wait for the fs freeze lock. Using the direct flushing we benefit * from already being in a transaction and our join_transaction doesn't * have to re-take the fs freeze lock. + * + * Note that try_to_writeback_inodes_sb() will only trigger writeback + * if it can read lock sb->s_umount. It will always be able to lock it, + * except when the filesystem is being unmounted or being frozen, but in + * those cases sync_filesystem() is called, which results in calling + * writeback_inodes_sb() while holding a write lock on sb->s_umount. + * Note that we don't call writeback_inodes_sb() directly, because it + * will emit a warning if sb->s_umount is not locked. */ if (btrfs_test_opt(fs_info, FLUSHONCOMMIT)) - writeback_inodes_sb(fs_info->sb, WB_REASON_SYNC); + try_to_writeback_inodes_sb(fs_info->sb, WB_REASON_SYNC); return 0; } -- 2.43.0

6 months, 3 weeks

1
0
0 0

[PATCH] arm64: dts: mediatek: mt8186-corsola-voltorb: Merge speaker codec nodes

by Chen-Yu Tsai

The Voltorb device uses a speaker codec different from the original Corsola device. When the Voltorb device tree was first added, the new codec was added as a separate node when it should have just replaced the existing one. Merge the two nodes. The only differences are the compatible string and the GPIO line property name. This keeps the device node path for the speaker codec the same across the MT8186 Chromebook line. Fixes: 321ad586e607 ("arm64: dts: mediatek: Add MT8186 Voltorb Chromebooks") Cc: <stable(a)vger.kernel.org> Signed-off-by: Chen-Yu Tsai <wenst(a)chromium.org> --- .../dts/mediatek/mt8186-corsola-voltorb.dtsi | 19 ++++--------------- 1 file changed, 4 insertions(+), 15 deletions(-) diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-voltorb.dtsi b/arch/arm64/boot/dts/mediatek/mt8186-corsola-voltorb.dtsi index 52ec58128d56..fbcd97069df9 100644 --- a/arch/arm64/boot/dts/mediatek/mt8186-corsola-voltorb.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-voltorb.dtsi @@ -10,12 +10,6 @@ / { chassis-type = "laptop"; - - max98360a: max98360a { - compatible = "maxim,max98360a"; - sdmode-gpios = <&pio 150 GPIO_ACTIVE_HIGH>; - #sound-dai-cells = <0>; - }; }; &cpu6 { @@ -59,19 +53,14 @@ &cluster1_opp_15 { opp-hz = /bits/ 64 <2200000000>; }; -&rt1019p{ - status = "disabled"; +&rt1019p { + compatible = "maxim,max98360a"; + sdmode-gpios = <&pio 150 GPIO_ACTIVE_HIGH>; + /delete-property/ sdb-gpios; }; &sound { compatible = "mediatek,mt8186-mt6366-rt5682s-max98360-sound"; - status = "okay"; - - spk-hdmi-playback-dai-link { - codec { - sound-dai = <&it6505dptx>, <&max98360a>; - }; - }; }; &spmi { -- 2.47.0.rc0.187.ge670bccf7e-goog

6 months, 3 weeks

2
3
0 0

[PATCH 5.15,6.1 0/3] Fix block integrity violation of kobject rules

by Thadeu Lima de Souza Cascardo

integrity_kobj did not have a release function and with CONFIG_DEBUG_KOBJECT_RELEASE, a use-after-free would be triggered as its holding struct gendisk would be freed without relying on its refcount. Thomas Weißschuh (3): blk-integrity: use sysfs_emit blk-integrity: convert to struct device_attribute blk-integrity: register sysfs attributes on struct device block/blk-integrity.c | 175 ++++++++++++++--------------------------- block/blk.h | 10 +-- block/genhd.c | 12 +-- include/linux/blkdev.h | 3 - 4 files changed, 66 insertions(+), 134 deletions(-) -- 2.34.1

6 months, 3 weeks

3
6
0 0

[PATCH] KVM: arm64: Unregister redistributor for failed vCPU creation

by Oliver Upton

Alex reports that syzkaller has managed to trigger a use-after-free when tearing down a VM: BUG: KASAN: slab-use-after-free in kvm_put_kvm+0x300/0xe68 virt/kvm/kvm_main.c:5769 Read of size 8 at addr ffffff801c6890d0 by task syz.3.2219/10758 CPU: 3 UID: 0 PID: 10758 Comm: syz.3.2219 Not tainted 6.11.0-rc6-dirty #64 Hardware name: linux,dummy-virt (DT) Call trace: dump_backtrace+0x17c/0x1a8 arch/arm64/kernel/stacktrace.c:317 show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:324 __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x94/0xc0 lib/dump_stack.c:119 print_report+0x144/0x7a4 mm/kasan/report.c:377 kasan_report+0xcc/0x128 mm/kasan/report.c:601 __asan_report_load8_noabort+0x20/0x2c mm/kasan/report_generic.c:381 kvm_put_kvm+0x300/0xe68 virt/kvm/kvm_main.c:5769 kvm_vm_release+0x4c/0x60 virt/kvm/kvm_main.c:1409 __fput+0x198/0x71c fs/file_table.c:422 ____fput+0x20/0x30 fs/file_table.c:450 task_work_run+0x1cc/0x23c kernel/task_work.c:228 do_notify_resume+0x144/0x1a0 include/linux/resume_user_mode.h:50 el0_svc+0x64/0x68 arch/arm64/kernel/entry-common.c:169 el0t_64_sync_handler+0x90/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 Upon closer inspection, it appears that we do not properly tear down the MMIO registration for a vCPU that fails creation late in the game, e.g. a vCPU w/ the same ID already exists in the VM. It is important to consider the context of commit that introduced this bug by moving the unregistration out of __kvm_vgic_vcpu_destroy(). That change correctly sought to avoid an srcu v. config_lock inversion by breaking up the vCPU teardown into two parts, one guarded by the config_lock. Fix the use-after-free while avoiding lock inversion by adding a special-cased unregistration to __kvm_vgic_vcpu_destroy(). This is safe because failed vCPUs are torn down outside of the config_lock. Cc: stable(a)vger.kernel.org Fixes: f616506754d3 ("KVM: arm64: vgic: Don't hold config_lock while unregistering redistributors") Reported-by: Alexander Potapenko <glider(a)google.com> Signed-off-by: Oliver Upton <oliver.upton(a)linux.dev> --- arch/arm64/kvm/vgic/vgic-init.c | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/arch/arm64/kvm/vgic/vgic-init.c b/arch/arm64/kvm/vgic/vgic-init.c index e7c53e8af3d1..57aedf7b2b76 100644 --- a/arch/arm64/kvm/vgic/vgic-init.c +++ b/arch/arm64/kvm/vgic/vgic-init.c @@ -417,8 +417,28 @@ static void __kvm_vgic_vcpu_destroy(struct kvm_vcpu *vcpu) kfree(vgic_cpu->private_irqs); vgic_cpu->private_irqs = NULL; - if (vcpu->kvm->arch.vgic.vgic_model == KVM_DEV_TYPE_ARM_VGIC_V3) + if (vcpu->kvm->arch.vgic.vgic_model == KVM_DEV_TYPE_ARM_VGIC_V3) { + /* + * If this vCPU is being destroyed because of a failed creation + * then unregister the redistributor to avoid leaving behind a + * dangling pointer to the vCPU struct. + * + * vCPUs that have been successfully created (i.e. added to + * kvm->vcpu_array) get unregistered in kvm_vgic_destroy(), as + * this function gets called while holding kvm->arch.config_lock + * in the VM teardown path and would otherwise introduce a lock + * inversion w.r.t. kvm->srcu. + * + * vCPUs that failed creation are torn down outside of the + * kvm->arch.config_lock and do not get unregistered in + * kvm_vgic_destroy(), meaning it is both safe and necessary to + * do so here. + */ + if (kvm_get_vcpu_by_id(vcpu->kvm, vcpu->vcpu_id) != vcpu) + vgic_unregister_redist_iodev(vcpu); + vgic_cpu->rd_iodev.base_addr = VGIC_ADDR_UNDEF; + } } void kvm_vgic_vcpu_destroy(struct kvm_vcpu *vcpu) -- 2.47.0.rc0.187.ge670bccf7e-goog

6 months, 3 weeks

2
1
0 0

[PATCH 6.6.y] Revert "drm/amd/display: Skip Recompute DSC Params if no Stream on Link"

by Jonathan Gray

This reverts commit a53841b074cc196c3caaa37e1f15d6bc90943b97. duplicated a change made in 6.6.46 718d83f66fb07b2cab89a1fc984613a00e3db18f Cc: stable(a)vger.kernel.org # 6.6 Signed-off-by: Jonathan Gray <jsg(a)jsg.id.au> --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c index 7fb11445a28f..d390e3d62e56 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c @@ -1266,9 +1266,6 @@ static bool is_dsc_need_re_compute( } } - if (new_stream_on_link_num == 0) - return false; - if (new_stream_on_link_num == 0) return false; -- 2.46.1

6 months, 3 weeks

2
1
0 0

FAILED: patch "[PATCH] drm/xe/vram: fix ccs offset calculation" failed to apply to 6.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.10.y git checkout FETCH_HEAD git cherry-pick -x ee06c09ded3c2f722be4e240ed06287e23596bda # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024100809-goes-diagnosis-d07c@gregkh' --subject-prefix 'PATCH 6.10.y' HEAD^.. Possible dependencies: ee06c09ded3c ("drm/xe/vram: fix ccs offset calculation") 638d1c79cbf1 ("drm/xe: Promote VRAM initialization function to own file") 8c52ca22b15b ("drm/xe: Drop xe_ prefix from static functions in xe_mmio.c") 2d8865b27724 ("drm/xe: Move BAR definitions to dedicated file") 2adfc4e022f3 ("drm/xe: Move XEHP_MTCFG_ADDR register definition to xe_regs.h") c7117419784f ("drm/xe: reset mmio mappings with devm") a0b834c8957a ("drm/xe/mmio: move mmio_fini over to devm") f7e20cfb59c9 ("drm/xe: Cleanup xe_mmio.h") 93dd6ad89c7d ("drm/xe: Don't rely on xe_force_wake.h to be included elsewhere") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From ee06c09ded3c2f722be4e240ed06287e23596bda Mon Sep 17 00:00:00 2001 From: Matthew Auld <matthew.auld(a)intel.com> Date: Mon, 16 Sep 2024 09:49:12 +0100 Subject: [PATCH] drm/xe/vram: fix ccs offset calculation Spec says SW is expected to round up to the nearest 128K, if not already aligned for the CC unit view of CCS. We are seeing the assert sometimes pop on BMG to tell us that there is a hole between GSM and CCS, as well as popping other asserts with having a vram size with strange alignment, which is likely caused by misaligned offset here. v2 (Shuicheng): - Do the round_up() on final SW address. BSpec: 68023 Fixes: b5c2ca0372dc ("drm/xe/xe2hpg: Determine flat ccs offset for vram") Signed-off-by: Matthew Auld <matthew.auld(a)intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray(a)intel.com> Cc: Akshata Jahagirdar <akshata.jahagirdar(a)intel.com> Cc: Lucas De Marchi <lucas.demarchi(a)intel.com> Cc: Shuicheng Lin <shuicheng.lin(a)intel.com> Cc: Matt Roper <matthew.d.roper(a)intel.com> Cc: stable(a)vger.kernel.org # v6.10+ Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray(a)intel.com> Tested-by: Shuicheng Lin <shuicheng.lin(a)intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi(a)intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240916084911.13119-2-matthe… Signed-off-by: Lucas De Marchi <lucas.demarchi(a)intel.com> (cherry picked from commit 37173392741c425191b959acb3adf70c9a4610c0) Signed-off-by: Lucas De Marchi <lucas.demarchi(a)intel.com> diff --git a/drivers/gpu/drm/xe/xe_vram.c b/drivers/gpu/drm/xe/xe_vram.c index 5bcd59190353..80ba2fc78837 100644 --- a/drivers/gpu/drm/xe/xe_vram.c +++ b/drivers/gpu/drm/xe/xe_vram.c @@ -182,6 +182,7 @@ static inline u64 get_flat_ccs_offset(struct xe_gt *gt, u64 tile_size) offset = offset_hi << 32; /* HW view bits 39:32 */ offset |= offset_lo << 6; /* HW view bits 31:6 */ offset *= num_enabled; /* convert to SW view */ + offset = round_up(offset, SZ_128K); /* SW must round up to nearest 128K */ /* We don't expect any holes */ xe_assert_msg(xe, offset == (xe_mmio_read64_2x32(gt, GSMBASE) - ccs_size),

6 months, 3 weeks

1
0
0 0

FAILED: patch "[PATCH] drm/i915/bios: fix printk format width" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x 0289507609dcb7690e45e79fbcc3680d9298ec77 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024100818-doorstop-clone-45d6@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: 0289507609dc ("drm/i915/bios: fix printk format width") 9aec6f76a28c ("drm/i915/bios: convert to struct intel_display") 769b081c18b9 ("drm/i915/opregion: convert to struct intel_display") b7f317e62968 ("drm/i915/opregion: unify intel_encoder/intel_connector naming") f7303ab29d08 ("drm/i915/acpi: convert to struct intel_display") 4c288f56030f ("drm/i915/bios: remove stale and useless comments") 6f4e43a2f771 ("drm/xe: Fix opregion leak") bc3ca4d94369 ("drm/i915: Make I2C terminology more inclusive") fd5a9b950ea8 ("drm/i915/fbc: Convert to intel_display, mostly") bc34d310b578 ("drm/i915/fbc: Extract intel_fbc_has_fences()") d754ed2821fd ("Merge drm/drm-next into drm-intel-next") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 0289507609dcb7690e45e79fbcc3680d9298ec77 Mon Sep 17 00:00:00 2001 From: Jani Nikula <jani.nikula(a)intel.com> Date: Thu, 5 Sep 2024 14:25:19 +0300 Subject: [PATCH] drm/i915/bios: fix printk format width s/0x04%x/0x%04x/ to use 0 prefixed width 4 instead of printing 04 verbatim. Fixes: 51f5748179d4 ("drm/i915/bios: create fake child devices on missing VBT") Cc: stable(a)vger.kernel.org # v5.13+ Reviewed-by: Vandita Kulkarni <vandita.kulkarni(a)intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240905112519.4186408-1-jani… Signed-off-by: Jani Nikula <jani.nikula(a)intel.com> (cherry picked from commit 54df34c5a2439b481f066476e67bfa21a0a640e5) Signed-off-by: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c b/drivers/gpu/drm/i915/display/intel_bios.c index d49435af62c7..bed485374ab0 100644 --- a/drivers/gpu/drm/i915/display/intel_bios.c +++ b/drivers/gpu/drm/i915/display/intel_bios.c @@ -2948,7 +2948,7 @@ init_vbt_missing_defaults(struct intel_display *display) list_add_tail(&devdata->node, &display->vbt.display_devices); drm_dbg_kms(display->drm, - "Generating default VBT child device with type 0x04%x on port %c\n", + "Generating default VBT child device with type 0x%04x on port %c\n", child->device_type, port_name(port)); }

6 months, 3 weeks

1
0
0 0

FAILED: patch "[PATCH] drm/i915/bios: fix printk format width" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x 0289507609dcb7690e45e79fbcc3680d9298ec77 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024100817-erupt-tutor-d82f@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: 0289507609dc ("drm/i915/bios: fix printk format width") 9aec6f76a28c ("drm/i915/bios: convert to struct intel_display") 769b081c18b9 ("drm/i915/opregion: convert to struct intel_display") b7f317e62968 ("drm/i915/opregion: unify intel_encoder/intel_connector naming") f7303ab29d08 ("drm/i915/acpi: convert to struct intel_display") 4c288f56030f ("drm/i915/bios: remove stale and useless comments") 6f4e43a2f771 ("drm/xe: Fix opregion leak") bc3ca4d94369 ("drm/i915: Make I2C terminology more inclusive") fd5a9b950ea8 ("drm/i915/fbc: Convert to intel_display, mostly") bc34d310b578 ("drm/i915/fbc: Extract intel_fbc_has_fences()") d754ed2821fd ("Merge drm/drm-next into drm-intel-next") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 0289507609dcb7690e45e79fbcc3680d9298ec77 Mon Sep 17 00:00:00 2001 From: Jani Nikula <jani.nikula(a)intel.com> Date: Thu, 5 Sep 2024 14:25:19 +0300 Subject: [PATCH] drm/i915/bios: fix printk format width s/0x04%x/0x%04x/ to use 0 prefixed width 4 instead of printing 04 verbatim. Fixes: 51f5748179d4 ("drm/i915/bios: create fake child devices on missing VBT") Cc: stable(a)vger.kernel.org # v5.13+ Reviewed-by: Vandita Kulkarni <vandita.kulkarni(a)intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240905112519.4186408-1-jani… Signed-off-by: Jani Nikula <jani.nikula(a)intel.com> (cherry picked from commit 54df34c5a2439b481f066476e67bfa21a0a640e5) Signed-off-by: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c b/drivers/gpu/drm/i915/display/intel_bios.c index d49435af62c7..bed485374ab0 100644 --- a/drivers/gpu/drm/i915/display/intel_bios.c +++ b/drivers/gpu/drm/i915/display/intel_bios.c @@ -2948,7 +2948,7 @@ init_vbt_missing_defaults(struct intel_display *display) list_add_tail(&devdata->node, &display->vbt.display_devices); drm_dbg_kms(display->drm, - "Generating default VBT child device with type 0x04%x on port %c\n", + "Generating default VBT child device with type 0x%04x on port %c\n", child->device_type, port_name(port)); }

6 months, 3 weeks

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror October 2024