May 2023 - Linux-stable-mirror

[PATCH v2] ext4: fix race condition between buffer write and page_mkwrite

by Baokun Li

Syzbot reported a BUG_ON: ================================================================== EXT4-fs (loop0): mounted filesystem without journal. Quota mode: none. EXT4-fs error (device loop0): ext4_mb_generate_buddy:1098: group 0, block bitmap and bg descriptor inconsistent: 25 vs 150994969 free clusters ------------[ cut here ]------------ kernel BUG at fs/ext4/ext4_jbd2.c:53! invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 494 Comm: syz-executor.0 6.1.0-rc7-syzkaller-ga4412fdd49dc #0 RIP: 0010:__ext4_journal_stop+0x1b3/0x1c0 [...] Call Trace: ext4_write_inline_data_end+0xa39/0xdf0 ext4_da_write_end+0x1e2/0x950 generic_perform_write+0x401/0x5f0 ext4_buffered_write_iter+0x35f/0x640 ext4_file_write_iter+0x198/0x1cd0 vfs_write+0x8b5/0xef0 [...] ================================================================== The above BUG_ON is triggered by the following race: cpu1 cpu2 ________________________|________________________ ksys_write vfs_write new_sync_write ext4_file_write_iter ext4_buffered_write_iter generic_perform_write ext4_da_write_begin do_fault do_page_mkwrite ext4_page_mkwrite ext4_convert_inline_data ext4_convert_inline_data_nolock ext4_destroy_inline_data_nolock //clear EXT4_STATE_MAY_INLINE_DATA ext4_map_blocks --> return error ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA) ext4_block_write_begin ext4_restore_inline_data // set EXT4_STATE_MAY_INLINE_DATA ext4_da_write_end ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA) ext4_write_inline_data_end handle=NULL ext4_journal_stop(handle) __ext4_journal_stop ext4_put_nojournal(handle) ref_cnt = (unsigned long)handle BUG_ON(ref_cnt == 0) ---> BUG_ON The root cause of this problem is that the ext4_convert_inline_data() in ext4_page_mkwrite() does not grab i_rwsem, so it may race with ext4_buffered_write_iter() and cause the write_begin() and write_end() functions to be inconsistent and trigger BUG_ON. To solve the above issue, we can not add inode_lock directly to ext4_page_mkwrite(), which would not only cause performance degradation but also ABBA deadlock (see Link). Hence we move ext4_convert_inline_data() to ext4_file_mmap(), and only when inline_data is enabled and mmap a writeable file in shared mode, we hold the lock to convert, which avoids the above problems. Link: https://lore.kernel.org/r/20230530102804.6t7np7om6tczscuo@quack3/ Reported-by: Jun Nie <jun.nie(a)linaro.org> Closes: https://lore.kernel.org/lkml/63903521.5040307@huawei.com/t/ Reported-by: syzbot+a158d886ca08a3fecca4(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?id=899b37f20ce4072bcdfecfe1647b39602e956e… Fixes: 7b4cc9787fe3 ("ext4: evict inline data when writing to memory map") CC: stable(a)vger.kernel.org # 4.12+ Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- fs/ext4/file.c | 24 +++++++++++++++++++++++- fs/ext4/inode.c | 4 ---- 2 files changed, 23 insertions(+), 5 deletions(-) diff --git a/fs/ext4/file.c b/fs/ext4/file.c index d101b3b0c7da..9df82d72eb90 100644 --- a/fs/ext4/file.c +++ b/fs/ext4/file.c @@ -795,7 +795,8 @@ static const struct vm_operations_struct ext4_file_vm_ops = { static int ext4_file_mmap(struct file *file, struct vm_area_struct *vma) { struct inode *inode = file->f_mapping->host; - struct ext4_sb_info *sbi = EXT4_SB(inode->i_sb); + struct super_block *sb = inode->i_sb; + struct ext4_sb_info *sbi = EXT4_SB(sb); struct dax_device *dax_dev = sbi->s_daxdev; if (unlikely(ext4_forced_shutdown(sbi))) @@ -808,6 +809,27 @@ static int ext4_file_mmap(struct file *file, struct vm_area_struct *vma) if (!daxdev_mapping_supported(vma, dax_dev)) return -EOPNOTSUPP; + /* + * Writing via mmap has no logic to handle inline data, so we + * need to call ext4_convert_inline_data() to convert the inode + * to normal format before doing so, otherwise a BUG_ON will be + * triggered in ext4_writepages() due to the + * EXT4_STATE_MAY_INLINE_DATA flag. Moreover, we need to grab + * i_rwsem during conversion, since clearing and setting the + * inline data flag may race with ext4_buffered_write_iter() + * to trigger a BUG_ON. + */ + if (ext4_has_feature_inline_data(sb) && + vma->vm_flags & VM_SHARED && vma->vm_flags & VM_MAYWRITE) { + int err; + + inode_lock(inode); + err = ext4_convert_inline_data(inode); + inode_unlock(inode); + if (err) + return err; + } + file_accessed(file); if (IS_DAX(file_inode(file))) { vma->vm_ops = &ext4_dax_vm_ops; diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index ce5f21b6c2b3..31844c4ec9fe 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -6043,10 +6043,6 @@ vm_fault_t ext4_page_mkwrite(struct vm_fault *vmf) filemap_invalidate_lock_shared(mapping); - err = ext4_convert_inline_data(inode); - if (err) - goto out_ret; - /* * On data journalling we skip straight to the transaction handle: * there's no delalloc; page truncated will be checked later; the -- 2.31.1

1 year

4
10
0 0

[PATCHv2 2/3] x86/tdx: Fix race between set_memory_encrypted() and load_unaligned_zeropad()

by Kirill A. Shutemov

Touching privately mapped GPA that is not properly converted to private with MapGPA and accepted leads to unrecoverable exit to VMM. load_unaligned_zeropad() can touch memory that is not owned by the caller, but just happened to next after the owned memory. This load_unaligned_zeropad() behaviour makes it important when kernel asks VMM to convert a GPA from shared to private or back. Kernel must never have a page mapped into direct mapping (and aliases) as private when the GPA is already converted to shared or when GPA is not yet converted to private. guest.enc_status_change_prepare() called before adjusting direct mapping and therefore it is responsible for converting the memory to private. guest.enc_status_change_finish() called after adjusting direct mapping and it converts the memory to shared. It is okay to have a shared mapping of memory that is not converted properly. handle_mmio() knows how to deal with load_unaligned_zeropad() stepping on it. Signed-off-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Fixes: 7dbde7631629 ("x86/mm/cpa: Add support for TDX shared memory") Cc: stable(a)vger.kernel.org --- arch/x86/coco/tdx/tdx.c | 56 ++++++++++++++++++++++++++++++++++++++--- 1 file changed, 53 insertions(+), 3 deletions(-) diff --git a/arch/x86/coco/tdx/tdx.c b/arch/x86/coco/tdx/tdx.c index e146b599260f..59cc13e41aa6 100644 --- a/arch/x86/coco/tdx/tdx.c +++ b/arch/x86/coco/tdx/tdx.c @@ -840,6 +840,30 @@ static bool tdx_enc_status_changed(unsigned long vaddr, int numpages, bool enc) return true; } +static bool tdx_enc_status_change_prepare(unsigned long vaddr, int numpages, + bool enc) +{ + /* + * Only handle shared->private conversion here. + * See the comment in tdx_early_init(). + */ + if (enc) + return tdx_enc_status_changed(vaddr, numpages, enc); + return true; +} + +static bool tdx_enc_status_change_finish(unsigned long vaddr, int numpages, + bool enc) +{ + /* + * Only handle private->shared conversion here. + * See the comment in tdx_early_init(). + */ + if (!enc) + return tdx_enc_status_changed(vaddr, numpages, enc); + return true; +} + void __init tdx_early_init(void) { u64 cc_mask; @@ -867,9 +891,35 @@ void __init tdx_early_init(void) */ physical_mask &= cc_mask - 1; - x86_platform.guest.enc_cache_flush_required = tdx_cache_flush_required; - x86_platform.guest.enc_tlb_flush_required = tdx_tlb_flush_required; - x86_platform.guest.enc_status_change_finish = tdx_enc_status_changed; + /* + * Touching privately mapped GPA that is not properly converted to + * private with MapGPA and accepted leads to unrecoverable exit + * to VMM. + * + * load_unaligned_zeropad() can touch memory that is not owned by + * the caller, but just happened to next after the owned memory. + * This load_unaligned_zeropad() behaviour makes it important when + * kernel asks VMM to convert a GPA from shared to private or back. + * Kernel must never have a page mapped into direct mapping (and + * aliases) as private when the GPA is already converted to shared or + * when GPA is not yet converted to private. + * + * guest.enc_status_change_prepare() called before adjusting direct + * mapping and therefore it is responsible for converting the memory + * to private. + * + * guest.enc_status_change_finish() called after adjusting direct + * mapping and it converts the memory to shared. + * + * It is okay to have a shared mapping of memory that is not converted + * properly. handle_mmio() knows how to deal with load_unaligned_zeropad() + * stepping on it. + */ + x86_platform.guest.enc_status_change_prepare = tdx_enc_status_change_prepare; + x86_platform.guest.enc_status_change_finish = tdx_enc_status_change_finish; + + x86_platform.guest.enc_cache_flush_required = tdx_cache_flush_required; + x86_platform.guest.enc_tlb_flush_required = tdx_tlb_flush_required; pr_info("Guest detected\n"); } -- 2.39.3

1 year

6
11
0 0

[PATCH AUTOSEL 6.3] mailbox: mailbox-test: Fix potential double-free in mbox_test_message_write()

by Sasha Levin

From: Lee Jones <lee(a)kernel.org> [ Upstream commit 2d1e952a2b8e5e92d8d55ac88a7cf7ca5ea591ad ] If a user can make copy_from_user() fail, there is a potential for UAF/DF due to a lack of locking around the allocation, use and freeing of the data buffers. This issue is not theoretical. I managed to author a POC for it: BUG: KASAN: double-free in kfree+0x5c/0xac Free of addr ffff29280be5de00 by task poc/356 CPU: 1 PID: 356 Comm: poc Not tainted 6.1.0-00001-g961aa6552c04-dirty #20 Hardware name: linux,dummy-virt (DT) Call trace: dump_backtrace.part.0+0xe0/0xf0 show_stack+0x18/0x40 dump_stack_lvl+0x64/0x80 print_report+0x188/0x48c kasan_report_invalid_free+0xa0/0xc0 ____kasan_slab_free+0x174/0x1b0 __kasan_slab_free+0x18/0x24 __kmem_cache_free+0x130/0x2e0 kfree+0x5c/0xac mbox_test_message_write+0x208/0x29c full_proxy_write+0x90/0xf0 vfs_write+0x154/0x440 ksys_write+0xcc/0x180 __arm64_sys_write+0x44/0x60 invoke_syscall+0x60/0x190 el0_svc_common.constprop.0+0x7c/0x160 do_el0_svc+0x40/0xf0 el0_svc+0x2c/0x6c el0t_64_sync_handler+0xf4/0x120 el0t_64_sync+0x18c/0x190 Allocated by task 356: kasan_save_stack+0x3c/0x70 kasan_set_track+0x2c/0x40 kasan_save_alloc_info+0x24/0x34 __kasan_kmalloc+0xb8/0xc0 kmalloc_trace+0x58/0x70 mbox_test_message_write+0x6c/0x29c full_proxy_write+0x90/0xf0 vfs_write+0x154/0x440 ksys_write+0xcc/0x180 __arm64_sys_write+0x44/0x60 invoke_syscall+0x60/0x190 el0_svc_common.constprop.0+0x7c/0x160 do_el0_svc+0x40/0xf0 el0_svc+0x2c/0x6c el0t_64_sync_handler+0xf4/0x120 el0t_64_sync+0x18c/0x190 Freed by task 357: kasan_save_stack+0x3c/0x70 kasan_set_track+0x2c/0x40 kasan_save_free_info+0x38/0x5c ____kasan_slab_free+0x13c/0x1b0 __kasan_slab_free+0x18/0x24 __kmem_cache_free+0x130/0x2e0 kfree+0x5c/0xac mbox_test_message_write+0x208/0x29c full_proxy_write+0x90/0xf0 vfs_write+0x154/0x440 ksys_write+0xcc/0x180 __arm64_sys_write+0x44/0x60 invoke_syscall+0x60/0x190 el0_svc_common.constprop.0+0x7c/0x160 do_el0_svc+0x40/0xf0 el0_svc+0x2c/0x6c el0t_64_sync_handler+0xf4/0x120 el0t_64_sync+0x18c/0x190 Signed-off-by: Lee Jones <lee(a)kernel.org> Signed-off-by: Jassi Brar <jaswinder.singh(a)linaro.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/mailbox/mailbox-test.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/mailbox/mailbox-test.c b/drivers/mailbox/mailbox-test.c index 4555d678fadda..6dd5b9614452b 100644 --- a/drivers/mailbox/mailbox-test.c +++ b/drivers/mailbox/mailbox-test.c @@ -12,6 +12,7 @@ #include <linux/kernel.h> #include <linux/mailbox_client.h> #include <linux/module.h> +#include <linux/mutex.h> #include <linux/of.h> #include <linux/platform_device.h> #include <linux/poll.h> @@ -38,6 +39,7 @@ struct mbox_test_device { char *signal; char *message; spinlock_t lock; + struct mutex mutex; wait_queue_head_t waitq; struct fasync_struct *async_queue; struct dentry *root_debugfs_dir; @@ -110,6 +112,8 @@ static ssize_t mbox_test_message_write(struct file *filp, return -EINVAL; } + mutex_lock(&tdev->mutex); + tdev->message = kzalloc(MBOX_MAX_MSG_LEN, GFP_KERNEL); if (!tdev->message) return -ENOMEM; @@ -144,6 +148,8 @@ static ssize_t mbox_test_message_write(struct file *filp, kfree(tdev->message); tdev->signal = NULL; + mutex_unlock(&tdev->mutex); + return ret < 0 ? ret : count; } @@ -392,6 +398,7 @@ static int mbox_test_probe(struct platform_device *pdev) platform_set_drvdata(pdev, tdev); spin_lock_init(&tdev->lock); + mutex_init(&tdev->mutex); if (tdev->rx_channel) { tdev->rx_buffer = devm_kzalloc(&pdev->dev, -- 2.39.2

1 year

2
1
0 0

FAILED: patch "[PATCH] net: cdc_ncm: Deal with too low values of dwNtbOutMaxSize" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-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-4.14.y git checkout FETCH_HEAD git cherry-pick -x 7e01c7f7046efc2c7c192c3619db43292b98e997 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023052625-mutual-punch-5c0b@gregkh' --subject-prefix 'PATCH 4.14.y' HEAD^.. Possible dependencies: 7e01c7f7046e ("net: cdc_ncm: Deal with too low values of dwNtbOutMaxSize") 2be6d4d16a08 ("net: cdc_ncm: Allow for dwNtbOutMaxSize to be unset or zero") 0fa81b304a79 ("cdc_ncm: Implement the 32-bit version of NCM Transfer Block") 49c2c3f246e2 ("cdc_ncm: avoid padding beyond end of skb") 6314dab4b8fb ("net: cdc_ncm: GetNtbFormat endian fix") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 7e01c7f7046efc2c7c192c3619db43292b98e997 Mon Sep 17 00:00:00 2001 From: Tudor Ambarus <tudor.ambarus(a)linaro.org> Date: Wed, 17 May 2023 13:38:08 +0000 Subject: [PATCH] net: cdc_ncm: Deal with too low values of dwNtbOutMaxSize Currently in cdc_ncm_check_tx_max(), if dwNtbOutMaxSize is lower than the calculated "min" value, but greater than zero, the logic sets tx_max to dwNtbOutMaxSize. This is then used to allocate a new SKB in cdc_ncm_fill_tx_frame() where all the data is handled. For small values of dwNtbOutMaxSize the memory allocated during alloc_skb(dwNtbOutMaxSize, GFP_ATOMIC) will have the same size, due to how size is aligned at alloc time: size = SKB_DATA_ALIGN(size); size += SKB_DATA_ALIGN(sizeof(struct skb_shared_info)); Thus we hit the same bug that we tried to squash with commit 2be6d4d16a084 ("net: cdc_ncm: Allow for dwNtbOutMaxSize to be unset or zero") Low values of dwNtbOutMaxSize do not cause an issue presently because at alloc_skb() time more memory (512b) is allocated than required for the SKB headers alone (320b), leaving some space (512b - 320b = 192b) for CDC data (172b). However, if more elements (for example 3 x u64 = [24b]) were added to one of the SKB header structs, say 'struct skb_shared_info', increasing its original size (320b [320b aligned]) to something larger (344b [384b aligned]), then suddenly the CDC data (172b) no longer fits in the spare SKB data area (512b - 384b = 128b). Consequently the SKB bounds checking semantics fails and panics: skbuff: skb_over_panic: text:ffffffff831f755b len:184 put:172 head:ffff88811f1c6c00 data:ffff88811f1c6c00 tail:0xb8 end:0x80 dev:<NULL> ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:113! invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 0 PID: 57 Comm: kworker/0:2 Not tainted 5.15.106-syzkaller-00249-g19c0ed55a470 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/14/2023 Workqueue: mld mld_ifc_work RIP: 0010:skb_panic net/core/skbuff.c:113 [inline] RIP: 0010:skb_over_panic+0x14c/0x150 net/core/skbuff.c:118 [snip] Call Trace: <TASK> skb_put+0x151/0x210 net/core/skbuff.c:2047 skb_put_zero include/linux/skbuff.h:2422 [inline] cdc_ncm_ndp16 drivers/net/usb/cdc_ncm.c:1131 [inline] cdc_ncm_fill_tx_frame+0x11ab/0x3da0 drivers/net/usb/cdc_ncm.c:1308 cdc_ncm_tx_fixup+0xa3/0x100 Deal with too low values of dwNtbOutMaxSize, clamp it in the range [USB_CDC_NCM_NTB_MIN_OUT_SIZE, CDC_NCM_NTB_MAX_SIZE_TX]. We ensure enough data space is allocated to handle CDC data by making sure dwNtbOutMaxSize is not smaller than USB_CDC_NCM_NTB_MIN_OUT_SIZE. Fixes: 289507d3364f ("net: cdc_ncm: use sysfs for rx/tx aggregation tuning") Cc: stable(a)vger.kernel.org Reported-by: syzbot+9f575a1f15fc0c01ed69(a)syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=b982f1059506db48409d Link: https://lore.kernel.org/all/20211202143437.1411410-1-lee.jones@linaro.org/ Signed-off-by: Tudor Ambarus <tudor.ambarus(a)linaro.org> Reviewed-by: Simon Horman <simon.horman(a)corigine.com> Link: https://lore.kernel.org/r/20230517133808.1873695-2-tudor.ambarus@linaro.org Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c index 6ce8f4f0c70e..db05622f1f70 100644 --- a/drivers/net/usb/cdc_ncm.c +++ b/drivers/net/usb/cdc_ncm.c @@ -181,9 +181,12 @@ static u32 cdc_ncm_check_tx_max(struct usbnet *dev, u32 new_tx) else min = ctx->max_datagram_size + ctx->max_ndp_size + sizeof(struct usb_cdc_ncm_nth32); - max = min_t(u32, CDC_NCM_NTB_MAX_SIZE_TX, le32_to_cpu(ctx->ncm_parm.dwNtbOutMaxSize)); - if (max == 0) + if (le32_to_cpu(ctx->ncm_parm.dwNtbOutMaxSize) == 0) max = CDC_NCM_NTB_MAX_SIZE_TX; /* dwNtbOutMaxSize not set */ + else + max = clamp_t(u32, le32_to_cpu(ctx->ncm_parm.dwNtbOutMaxSize), + USB_CDC_NCM_NTB_MIN_OUT_SIZE, + CDC_NCM_NTB_MAX_SIZE_TX); /* some devices set dwNtbOutMaxSize too low for the above default */ min = min(min, max); @@ -1244,6 +1247,9 @@ cdc_ncm_fill_tx_frame(struct usbnet *dev, struct sk_buff *skb, __le32 sign) * further. */ if (skb_out == NULL) { + /* If even the smallest allocation fails, abort. */ + if (ctx->tx_curr_size == USB_CDC_NCM_NTB_MIN_OUT_SIZE) + goto alloc_failed; ctx->tx_low_mem_max_cnt = min(ctx->tx_low_mem_max_cnt + 1, (unsigned)CDC_NCM_LOW_MEM_MAX_CNT); ctx->tx_low_mem_val = ctx->tx_low_mem_max_cnt; @@ -1262,13 +1268,8 @@ cdc_ncm_fill_tx_frame(struct usbnet *dev, struct sk_buff *skb, __le32 sign) skb_out = alloc_skb(ctx->tx_curr_size, GFP_ATOMIC); /* No allocation possible so we will abort */ - if (skb_out == NULL) { - if (skb != NULL) { - dev_kfree_skb_any(skb); - dev->net->stats.tx_dropped++; - } - goto exit_no_skb; - } + if (!skb_out) + goto alloc_failed; ctx->tx_low_mem_val--; } if (ctx->is_ndp16) { @@ -1461,6 +1462,11 @@ cdc_ncm_fill_tx_frame(struct usbnet *dev, struct sk_buff *skb, __le32 sign) return skb_out; +alloc_failed: + if (skb) { + dev_kfree_skb_any(skb); + dev->net->stats.tx_dropped++; + } exit_no_skb: /* Start timer, if there is a remaining non-empty skb */ if (ctx->tx_curr_skb != NULL && n > 0)

1 year

3
3
0 0

kernel error at led trigger "phy0tpt"

by Tobias Dahms

Hello, since some kernel versions I get a kernel errror while setting led trigger to phy0tpt. command to reproduce: echo phy0tpt > /sys/class/leds/bpi-r2\:isink\:blue/trigger same trigger, other led location => no error: echo phy0tpt > /sys/class/leds/bpi-r2\:pio\:blue/trigger other trigger, same led location => no error: echo phy0tx > /sys/class/leds/bpi-r2\:isink\:blue/trigger last good kernel: bpi-r2 5.19.17-bpi-r2 error at kernel versions: bpi-r2 6.0.19-bpi-r2 up to bpi-r2 6.3.0-rc1-bpi-r2+ wireless lan card: 01:00.0 Network controller: MEDIATEK Corp. MT7612E 802.11acbgn PCI Express Wireless Network Adapter distribution: Arch-Linux-ARM (with vanilla kernel instead of original distribution kernel) board: BananaPi-R2 log messages: Mär 12 12:54:55 bpi-r2 kernel: BUG: scheduling while atomic: swapper/0/0/0x00000100 Mär 12 12:54:55 bpi-r2 kernel: Modules linked in: aes_arm_bs crypto_simd cryptd nft_masq nft_ct nf_log_syslog nft_log nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink mt76x2e mt76x2_common mt76x02_lib mt76 spi_mt65xx pwm_mediatek mt6577_auxadc sch_fq_codel fuse configfs ip_tables x_tables Mär 12 12:54:55 bpi-r2 kernel: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.3.0-rc1-bpi-r2+ #1 Mär 12 12:54:55 bpi-r2 kernel: Hardware name: Mediatek Cortex-A7 (Device Tree) Mär 12 12:54:55 bpi-r2 kernel: Backtrace: Mär 12 12:54:55 bpi-r2 kernel: dump_backtrace from show_stack+0x20/0x24 Mär 12 12:54:55 bpi-r2 kernel: r7:c14ab340 r6:00000000 r5:c12507fc r4:600f0113 Mär 12 12:54:55 bpi-r2 kernel: show_stack from dump_stack_lvl+0x48/0x54 Mär 12 12:54:55 bpi-r2 kernel: dump_stack_lvl from dump_stack+0x18/0x1c Mär 12 12:54:55 bpi-r2 kernel: r5:c1508fc0 r4:00000000 Mär 12 12:54:55 bpi-r2 kernel: dump_stack from __schedule_bug+0x60/0x70 Mär 12 12:54:55 bpi-r2 kernel: __schedule_bug from __schedule+0x6b0/0x904 Mär 12 12:54:55 bpi-r2 kernel: r5:c1508fc0 r4:eed9d340 Mär 12 12:54:55 bpi-r2 kernel: __schedule from schedule+0x6c/0xe8 Mär 12 12:54:55 bpi-r2 kernel: r10:c1501ba0 r9:00000000 r8:00001b58 r7:c1508fc0 r6:00001b58 r5:0000004a Mär 12 12:54:55 bpi-r2 kernel: r4:c1508fc0 Mär 12 12:54:55 bpi-r2 kernel: schedule from schedule_hrtimeout_range_clock+0xec/0x14c Mär 12 12:54:55 bpi-r2 kernel: r5:0000004a r4:47ac1837 Mär 12 12:54:55 bpi-r2 kernel: schedule_hrtimeout_range_clock from schedule_hrtimeout_range+0x28/0x30 Mär 12 12:54:55 bpi-r2 kernel: r10:c1501c50 r9:c1508fc0 r8:00000002 r7:00000000 r6:c1501ba0 r5:00000000 Mär 12 12:54:55 bpi-r2 kernel: r4:00001b58 Mär 12 12:54:55 bpi-r2 kernel: schedule_hrtimeout_range from usleep_range_state+0x6c/0x90 Mär 12 12:54:55 bpi-r2 kernel: usleep_range_state from pwrap_read16+0xfc/0x2a0 Mär 12 12:54:55 bpi-r2 kernel: r9:0000004a r8:4844840c r7:0000004a r6:48447f8a r5:01980000 r4:c2703940 Mär 12 12:54:55 bpi-r2 kernel: pwrap_read16 from pwrap_regmap_read+0x24/0x28 Mär 12 12:54:55 bpi-r2 kernel: r10:00001f00 r9:00000000 r8:00000f00 r7:c2703940 r6:c1501c50 r5:00000330 Mär 12 12:54:55 bpi-r2 kernel: r4:c196e000 r3:c06f3fbc Mär 12 12:54:55 bpi-r2 kernel: pwrap_regmap_read from _regmap_read+0x70/0x160 Mär 12 12:54:55 bpi-r2 kernel: _regmap_read from _regmap_update_bits+0xc8/0x108 Mär 12 12:54:55 bpi-r2 kernel: r10:00001f00 r9:00000000 r8:00000f00 r7:c1508fc0 r6:00000330 r5:00000000 Mär 12 12:54:55 bpi-r2 kernel: r4:c196e000 r3:00000000 Mär 12 12:54:55 bpi-r2 kernel: _regmap_update_bits from regmap_update_bits_base+0x60/0x84 Mär 12 12:54:55 bpi-r2 kernel: r10:00000000 r9:00000f00 r8:00000000 r7:00001f00 r6:00000000 r5:00000330 Mär 12 12:54:55 bpi-r2 kernel: r4:c196e000 Mär 12 12:54:55 bpi-r2 kernel: regmap_update_bits_base from mt6323_led_set_blink+0xf0/0x148 Mär 12 12:54:55 bpi-r2 kernel: r10:eed94800 r9:c16998c0 r8:c196e000 r7:c31f0c48 r6:c2456f48 r5:00000000 Mär 12 12:54:55 bpi-r2 kernel: r4:0000014e Mär 12 12:54:55 bpi-r2 kernel: mt6323_led_set_blink from led_blink_setup+0x3c/0x110 Mär 12 12:54:55 bpi-r2 kernel: r9:c16998c0 r8:00000770 r7:c1501d60 r6:c1501d5c r5:c1501d60 r4:c31f0c48 Mär 12 12:54:55 bpi-r2 kernel: led_blink_setup from led_blink_set+0x60/0x64 Mär 12 12:54:55 bpi-r2 kernel: r7:c1501d60 r6:c1501d5c r5:c31f0c58 r4:c31f0c48 Mär 12 12:54:55 bpi-r2 kernel: led_blink_set from led_trigger_blink+0x44/0x58 Mär 12 12:54:55 bpi-r2 kernel: r7:c1501d60 r6:c1501d5c r5:c5b69740 r4:c31f0c48 Mär 12 12:54:55 bpi-r2 kernel: led_trigger_blink from tpt_trig_timer+0x10c/0x130 Mär 12 12:54:55 bpi-r2 kernel: r7:c0df71f0 r6:c1508fc0 r5:c5b685a0 r4:c597b628 Mär 12 12:54:55 bpi-r2 kernel: tpt_trig_timer from call_timer_fn+0x48/0x168 Mär 12 12:54:55 bpi-r2 kernel: r6:c597b628 r5:00000100 r4:c16998c0 Mär 12 12:54:55 bpi-r2 kernel: call_timer_fn from run_timer_softirq+0x600/0x6c8 Mär 12 12:54:55 bpi-r2 kernel: r9:c16998c0 r8:00000000 r7:00000770 r6:00000000 r5:c1501de4 r4:c597b628 Mär 12 12:54:55 bpi-r2 kernel: run_timer_softirq from __do_softirq+0x140/0x34c Mär 12 12:54:55 bpi-r2 kernel: r10:00000082 r9:00000100 r8:c1698481 r7:c1698f60 r6:00000001 r5:00000002 Mär 12 12:54:55 bpi-r2 kernel: r4:c1503084 Mär 12 12:54:55 bpi-r2 kernel: __do_softirq from irq_exit+0xb8/0xe8 Mär 12 12:54:55 bpi-r2 kernel: r10:10c5387d r9:c1508fc0 r8:c1698481 r7:c1501f0c r6:00000000 r5:c1501ed8 Mär 12 12:54:55 bpi-r2 kernel: r4:c14aaf58 Mär 12 12:54:55 bpi-r2 kernel: irq_exit from generic_handle_arch_irq+0x48/0x4c Mär 12 12:54:55 bpi-r2 kernel: r5:c1501ed8 r4:c14aaf58 Mär 12 12:54:55 bpi-r2 kernel: generic_handle_arch_irq from __irq_svc+0x88/0xb0 Mär 12 12:54:55 bpi-r2 kernel: Exception stack(0xc1501ed8 to 0xc1501f20) Mär 12 12:54:55 bpi-r2 kernel: 1ec0: 000862f4 2d8f2000 Mär 12 12:54:55 bpi-r2 kernel: 1ee0: c1508fc0 00000000 c1699cc0 c1504f10 c1504f70 00000001 c1698481 c123a9b4 Mär 12 12:54:55 bpi-r2 kernel: 1f00: 10c5387d c1501f3c 00000001 c1501f28 c0e36fa0 c0e3767c 600f0013 ffffffff Mär 12 12:54:55 bpi-r2 kernel: r7:c1501f0c r6:ffffffff r5:600f0013 r4:c0e3767c Mär 12 12:54:55 bpi-r2 kernel: default_idle_call from do_idle+0xc4/0x124 Mär 12 12:54:55 bpi-r2 kernel: r5:c1504f10 r4:00000001 Mär 12 12:54:55 bpi-r2 kernel: do_idle from cpu_startup_entry+0x28/0x2c Mär 12 12:54:55 bpi-r2 kernel: r9:efffcd40 r8:00000000 r7:00000045 r6:c1326068 r5:c16fb9b8 r4:000000ec Mär 12 12:54:55 bpi-r2 kernel: cpu_startup_entry from rest_init+0xc0/0xc4 Mär 12 12:54:55 bpi-r2 kernel: rest_init from arch_post_acpi_subsys_init+0x0/0x30 Mär 12 12:54:55 bpi-r2 kernel: r5:c16fb9b8 r4:c16cc038 Mär 12 12:54:55 bpi-r2 kernel: arch_call_rest_init from start_kernel+0x6c0/0x704 Mär 12 12:54:55 bpi-r2 kernel: start_kernel from 0x0 Mär 12 12:54:55 bpi-r2 kernel: bad: scheduling from the idle thread! Mär 12 12:54:55 bpi-r2 kernel: CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 6.3.0-rc1-bpi-r2+ #1 Mär 12 12:54:55 bpi-r2 kernel: Hardware name: Mediatek Cortex-A7 (Device Tree) Mär 12 12:54:55 bpi-r2 kernel: Backtrace: Mär 12 12:54:55 bpi-r2 kernel: dump_backtrace from show_stack+0x20/0x24 Mär 12 12:54:55 bpi-r2 kernel: r7:c14ab340 r6:00000001 r5:c12507fc r4:60070013 Mär 12 12:54:55 bpi-r2 kernel: show_stack from dump_stack_lvl+0x48/0x54 Mär 12 12:54:55 bpi-r2 kernel: dump_stack_lvl from dump_stack+0x18/0x1c Mär 12 12:54:55 bpi-r2 kernel: r5:c1508fc0 r4:eed9d340 Mär 12 12:54:55 bpi-r2 kernel: dump_stack from dequeue_task_idle+0x30/0x44 Mär 12 12:54:55 bpi-r2 kernel: dequeue_task_idle from __schedule+0x4bc/0x904 Mär 12 12:54:55 bpi-r2 kernel: r5:c1508fc0 r4:eed9d340 Mär 12 12:54:55 bpi-r2 kernel: __schedule from schedule+0x6c/0xe8 Mär 12 12:54:55 bpi-r2 kernel: r10:c1501ba0 r9:00000000 r8:00001b58 r7:c1508fc0 r6:00001b58 r5:0000004a Mär 12 12:54:55 bpi-r2 kernel: r4:c1508fc0 Mär 12 12:54:55 bpi-r2 kernel: schedule from schedule_hrtimeout_range_clock+0xec/0x14c Mär 12 12:54:55 bpi-r2 kernel: r5:0000004a r4:492d8817 Mär 12 12:54:55 bpi-r2 kernel: schedule_hrtimeout_range_clock from schedule_hrtimeout_range+0x28/0x30 Mär 12 12:54:55 bpi-r2 kernel: r10:c1501c50 r9:c1508fc0 r8:00000002 r7:00000000 r6:c1501ba0 r5:00000000 Mär 12 12:54:55 bpi-r2 kernel: r4:00001b58 Mär 12 12:54:55 bpi-r2 kernel: schedule_hrtimeout_range from usleep_range_state+0x6c/0x90 Mär 12 12:54:55 bpi-r2 kernel: usleep_range_state from pwrap_read16+0xfc/0x2a0 Mär 12 12:54:55 bpi-r2 kernel: r9:0000004a r8:49c5f439 r7:0000004a r6:49c5f0eb r5:01990000 r4:c2703940 Mär 12 12:54:55 bpi-r2 kernel: pwrap_read16 from pwrap_regmap_read+0x24/0x28 Mär 12 12:54:55 bpi-r2 kernel: r10:0000ffff r9:00000000 r8:0000014d r7:c2703940 r6:c1501c50 r5:00000332 Mär 12 12:54:55 bpi-r2 kernel: r4:c196e000 r3:c06f3fbc Mär 12 12:54:55 bpi-r2 kernel: pwrap_regmap_read from _regmap_read+0x70/0x160 Mär 12 12:54:55 bpi-r2 kernel: _regmap_read from _regmap_update_bits+0xc8/0x108 Mär 12 12:54:55 bpi-r2 kernel: r10:0000ffff r9:00000000 r8:0000014d r7:c1508fc0 r6:00000332 r5:00000000 Mär 12 12:54:55 bpi-r2 kernel: r4:c196e000 r3:00000000 Mär 12 12:54:55 bpi-r2 kernel: _regmap_update_bits from regmap_update_bits_base+0x60/0x84 Mär 12 12:54:55 bpi-r2 kernel: r10:00000000 r9:0000014d r8:00000000 r7:0000ffff r6:00000000 r5:00000332 Mär 12 12:54:55 bpi-r2 kernel: r4:c196e000 Mär 12 12:54:55 bpi-r2 kernel: regmap_update_bits_base from mt6323_led_set_blink+0x138/0x148 Mär 12 12:54:55 bpi-r2 kernel: r10:eed94800 r9:00000000 r8:c196e000 r7:c31f0c48 r6:c2456f48 r5:00000000 Mär 12 12:54:55 bpi-r2 kernel: r4:0000014e Mär 12 12:54:55 bpi-r2 kernel: mt6323_led_set_blink from led_blink_setup+0x3c/0x110 Mär 12 12:54:55 bpi-r2 kernel: r9:c16998c0 r8:00000770 r7:c1501d60 r6:c1501d5c r5:c1501d60 r4:c31f0c48 Mär 12 12:54:55 bpi-r2 kernel: led_blink_setup from led_blink_set+0x60/0x64 Mär 12 12:54:55 bpi-r2 kernel: r7:c1501d60 r6:c1501d5c r5:c31f0c58 r4:c31f0c48 Mär 12 12:54:55 bpi-r2 kernel: led_blink_set from led_trigger_blink+0x44/0x58 Mär 12 12:54:55 bpi-r2 kernel: r7:c1501d60 r6:c1501d5c r5:c5b69740 r4:c31f0c48 Mär 12 12:54:55 bpi-r2 kernel: led_trigger_blink from tpt_trig_timer+0x10c/0x130 Mär 12 12:54:55 bpi-r2 kernel: r7:c0df71f0 r6:c1508fc0 r5:c5b685a0 r4:c597b628 Mär 12 12:54:55 bpi-r2 kernel: tpt_trig_timer from call_timer_fn+0x48/0x168 Mär 12 12:54:55 bpi-r2 kernel: r6:c597b628 r5:00000100 r4:c16998c0 Mär 12 12:54:55 bpi-r2 kernel: call_timer_fn from run_timer_softirq+0x600/0x6c8 Mär 12 12:54:55 bpi-r2 kernel: r9:c16998c0 r8:00000000 r7:00000770 r6:00000000 r5:c1501de4 r4:c597b628 Mär 12 12:54:55 bpi-r2 kernel: run_timer_softirq from __do_softirq+0x140/0x34c Mär 12 12:54:55 bpi-r2 kernel: r10:00000082 r9:00000100 r8:c1698481 r7:c1698f60 r6:00000001 r5:00000002 Mär 12 12:54:55 bpi-r2 kernel: r4:c1503084 Mär 12 12:54:55 bpi-r2 kernel: __do_softirq from irq_exit+0xb8/0xe8 Mär 12 12:54:55 bpi-r2 kernel: r10:10c5387d r9:c1508fc0 r8:c1698481 r7:c1501f0c r6:00000000 r5:c1501ed8 Mär 12 12:54:55 bpi-r2 kernel: r4:c14aaf58 Mär 12 12:54:55 bpi-r2 kernel: irq_exit from generic_handle_arch_irq+0x48/0x4c Mär 12 12:54:55 bpi-r2 kernel: r5:c1501ed8 r4:c14aaf58 Mär 12 12:54:55 bpi-r2 kernel: generic_handle_arch_irq from __irq_svc+0x88/0xb0 Mär 12 12:54:55 bpi-r2 kernel: Exception stack(0xc1501ed8 to 0xc1501f20) Mär 12 12:54:55 bpi-r2 kernel: 1ec0: 000862f4 2d8f2000 Mär 12 12:54:55 bpi-r2 kernel: 1ee0: c1508fc0 00000000 c1699cc0 c1504f10 c1504f70 00000001 c1698481 c123a9b4 Mär 12 12:54:55 bpi-r2 kernel: 1f00: 10c5387d c1501f3c 00000001 c1501f28 c0e36fa0 c0e3767c 600f0013 ffffffff Mär 12 12:54:55 bpi-r2 kernel: r7:c1501f0c r6:ffffffff r5:600f0013 r4:c0e3767c Mär 12 12:54:55 bpi-r2 kernel: default_idle_call from do_idle+0xc4/0x124 Mär 12 12:54:55 bpi-r2 kernel: r5:c1504f10 r4:00000001 Mär 12 12:54:55 bpi-r2 kernel: do_idle from cpu_startup_entry+0x28/0x2c Mär 12 12:54:55 bpi-r2 kernel: r9:efffcd40 r8:00000000 r7:00000045 r6:c1326068 r5:c16fb9b8 r4:000000ec Mär 12 12:54:55 bpi-r2 kernel: cpu_startup_entry from rest_init+0xc0/0xc4 Mär 12 12:54:55 bpi-r2 kernel: rest_init from arch_post_acpi_subsys_init+0x0/0x30 Mär 12 12:54:55 bpi-r2 kernel: r5:c16fb9b8 r4:c16cc038 Mär 12 12:54:55 bpi-r2 kernel: arch_call_rest_init from start_kernel+0x6c0/0x704 Mär 12 12:54:55 bpi-r2 kernel: start_kernel from 0x0 Mär 12 12:54:55 bpi-r2 kernel: ------------[ cut here ]------------ best regards Tobias Dahms

1 year

5
9
0 0

FAILED: patch "[PATCH] net: cdc_ncm: Deal with too low values of dwNtbOutMaxSize" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-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-4.19.y git checkout FETCH_HEAD git cherry-pick -x 7e01c7f7046efc2c7c192c3619db43292b98e997 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023052623-tricky-machinist-46c5@gregkh' --subject-prefix 'PATCH 4.19.y' HEAD^.. Possible dependencies: 7e01c7f7046e ("net: cdc_ncm: Deal with too low values of dwNtbOutMaxSize") 2be6d4d16a08 ("net: cdc_ncm: Allow for dwNtbOutMaxSize to be unset or zero") 0fa81b304a79 ("cdc_ncm: Implement the 32-bit version of NCM Transfer Block") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 7e01c7f7046efc2c7c192c3619db43292b98e997 Mon Sep 17 00:00:00 2001 From: Tudor Ambarus <tudor.ambarus(a)linaro.org> Date: Wed, 17 May 2023 13:38:08 +0000 Subject: [PATCH] net: cdc_ncm: Deal with too low values of dwNtbOutMaxSize Currently in cdc_ncm_check_tx_max(), if dwNtbOutMaxSize is lower than the calculated "min" value, but greater than zero, the logic sets tx_max to dwNtbOutMaxSize. This is then used to allocate a new SKB in cdc_ncm_fill_tx_frame() where all the data is handled. For small values of dwNtbOutMaxSize the memory allocated during alloc_skb(dwNtbOutMaxSize, GFP_ATOMIC) will have the same size, due to how size is aligned at alloc time: size = SKB_DATA_ALIGN(size); size += SKB_DATA_ALIGN(sizeof(struct skb_shared_info)); Thus we hit the same bug that we tried to squash with commit 2be6d4d16a084 ("net: cdc_ncm: Allow for dwNtbOutMaxSize to be unset or zero") Low values of dwNtbOutMaxSize do not cause an issue presently because at alloc_skb() time more memory (512b) is allocated than required for the SKB headers alone (320b), leaving some space (512b - 320b = 192b) for CDC data (172b). However, if more elements (for example 3 x u64 = [24b]) were added to one of the SKB header structs, say 'struct skb_shared_info', increasing its original size (320b [320b aligned]) to something larger (344b [384b aligned]), then suddenly the CDC data (172b) no longer fits in the spare SKB data area (512b - 384b = 128b). Consequently the SKB bounds checking semantics fails and panics: skbuff: skb_over_panic: text:ffffffff831f755b len:184 put:172 head:ffff88811f1c6c00 data:ffff88811f1c6c00 tail:0xb8 end:0x80 dev:<NULL> ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:113! invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 0 PID: 57 Comm: kworker/0:2 Not tainted 5.15.106-syzkaller-00249-g19c0ed55a470 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/14/2023 Workqueue: mld mld_ifc_work RIP: 0010:skb_panic net/core/skbuff.c:113 [inline] RIP: 0010:skb_over_panic+0x14c/0x150 net/core/skbuff.c:118 [snip] Call Trace: <TASK> skb_put+0x151/0x210 net/core/skbuff.c:2047 skb_put_zero include/linux/skbuff.h:2422 [inline] cdc_ncm_ndp16 drivers/net/usb/cdc_ncm.c:1131 [inline] cdc_ncm_fill_tx_frame+0x11ab/0x3da0 drivers/net/usb/cdc_ncm.c:1308 cdc_ncm_tx_fixup+0xa3/0x100 Deal with too low values of dwNtbOutMaxSize, clamp it in the range [USB_CDC_NCM_NTB_MIN_OUT_SIZE, CDC_NCM_NTB_MAX_SIZE_TX]. We ensure enough data space is allocated to handle CDC data by making sure dwNtbOutMaxSize is not smaller than USB_CDC_NCM_NTB_MIN_OUT_SIZE. Fixes: 289507d3364f ("net: cdc_ncm: use sysfs for rx/tx aggregation tuning") Cc: stable(a)vger.kernel.org Reported-by: syzbot+9f575a1f15fc0c01ed69(a)syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=b982f1059506db48409d Link: https://lore.kernel.org/all/20211202143437.1411410-1-lee.jones@linaro.org/ Signed-off-by: Tudor Ambarus <tudor.ambarus(a)linaro.org> Reviewed-by: Simon Horman <simon.horman(a)corigine.com> Link: https://lore.kernel.org/r/20230517133808.1873695-2-tudor.ambarus@linaro.org Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c index 6ce8f4f0c70e..db05622f1f70 100644 --- a/drivers/net/usb/cdc_ncm.c +++ b/drivers/net/usb/cdc_ncm.c @@ -181,9 +181,12 @@ static u32 cdc_ncm_check_tx_max(struct usbnet *dev, u32 new_tx) else min = ctx->max_datagram_size + ctx->max_ndp_size + sizeof(struct usb_cdc_ncm_nth32); - max = min_t(u32, CDC_NCM_NTB_MAX_SIZE_TX, le32_to_cpu(ctx->ncm_parm.dwNtbOutMaxSize)); - if (max == 0) + if (le32_to_cpu(ctx->ncm_parm.dwNtbOutMaxSize) == 0) max = CDC_NCM_NTB_MAX_SIZE_TX; /* dwNtbOutMaxSize not set */ + else + max = clamp_t(u32, le32_to_cpu(ctx->ncm_parm.dwNtbOutMaxSize), + USB_CDC_NCM_NTB_MIN_OUT_SIZE, + CDC_NCM_NTB_MAX_SIZE_TX); /* some devices set dwNtbOutMaxSize too low for the above default */ min = min(min, max); @@ -1244,6 +1247,9 @@ cdc_ncm_fill_tx_frame(struct usbnet *dev, struct sk_buff *skb, __le32 sign) * further. */ if (skb_out == NULL) { + /* If even the smallest allocation fails, abort. */ + if (ctx->tx_curr_size == USB_CDC_NCM_NTB_MIN_OUT_SIZE) + goto alloc_failed; ctx->tx_low_mem_max_cnt = min(ctx->tx_low_mem_max_cnt + 1, (unsigned)CDC_NCM_LOW_MEM_MAX_CNT); ctx->tx_low_mem_val = ctx->tx_low_mem_max_cnt; @@ -1262,13 +1268,8 @@ cdc_ncm_fill_tx_frame(struct usbnet *dev, struct sk_buff *skb, __le32 sign) skb_out = alloc_skb(ctx->tx_curr_size, GFP_ATOMIC); /* No allocation possible so we will abort */ - if (skb_out == NULL) { - if (skb != NULL) { - dev_kfree_skb_any(skb); - dev->net->stats.tx_dropped++; - } - goto exit_no_skb; - } + if (!skb_out) + goto alloc_failed; ctx->tx_low_mem_val--; } if (ctx->is_ndp16) { @@ -1461,6 +1462,11 @@ cdc_ncm_fill_tx_frame(struct usbnet *dev, struct sk_buff *skb, __le32 sign) return skb_out; +alloc_failed: + if (skb) { + dev_kfree_skb_any(skb); + dev->net->stats.tx_dropped++; + } exit_no_skb: /* Start timer, if there is a remaining non-empty skb */ if (ctx->tx_curr_skb != NULL && n > 0)

1 year

2
1
0 0

FAILED: patch "[PATCH] drm/amdgpu/gfx10: Disable gfxoff before disabling" 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 8173cab3368a13cdc3cad0bd5cf14e9399b0f501 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023052257-kiwi-level-12a2@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: 8173cab3368a ("drm/amdgpu/gfx10: Disable gfxoff before disabling powergating.") fabe1753851c ("drm/amdgpu: enable gfx power gating for GC 10.3.7") 874bfdfa4735 ("drm/amdgpu: add gc 10.3.6 support") a65dbf7cded7 ("drm/amdgpu/gfx10: Add GC 10.3.7 Support") 35c27d957835 ("drm/amdgpu: update vcn/jpeg PG flags for VCN 3.1.1") b67f00e06f36 ("drm/amdgpu: set new revision id for 10.3.7 GC") dfcc3e8c24cc ("drm/amdgpu: make cyan skillfish support code more consistent") 212021297eaf ("drm/amdgpu: set APU flag based on IP discovery table") e8a423c589a0 ("drm/amdgpu: update RLC_PG_DELAY_3 Value to 200us for yellow carp") a61794bd2f65 ("drm/amdgpu: remove grbm cam index/data operations for gfx v10") b05b9c591f9e ("drm/amdgpu: clean up set IP function") 1d789535a036 ("drm/amdgpu: convert IP version array to include instances") 5c3720be7d46 ("drm/amdgpu: get VCN and SDMA instances from IP discovery table") 2cbc6f4259f6 ("drm/amd/display: fix error case handling") 75a07bcd1d30 ("drm/amdgpu/soc15: convert to IP version checking") 0b64a5a85229 ("drm/amdgpu/vcn2.5: convert to IP version checking") 96b8dd4423e7 ("drm/amdgpu/amdgpu_vcn: convert to IP version checking") 50638f7dbd0b ("drm/amdgpu/pm/amdgpu_smu: convert more IP version checking") 61b396b91196 ("drm/amdgpu/pm/smu_v13.0: convert IP version checking") 6b726a0a52cc ("drm/amdgpu/pm/smu_v11.0: update IP version checking") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 8173cab3368a13cdc3cad0bd5cf14e9399b0f501 Mon Sep 17 00:00:00 2001 From: Bas Nieuwenhuizen <bas(a)basnieuwenhuizen.nl> Date: Tue, 9 May 2023 18:49:46 +0200 Subject: [PATCH] drm/amdgpu/gfx10: Disable gfxoff before disabling powergating. Otherwise we get a full system lock (looks like a FW mess). Copied the order from the GFX9 powergating code. Fixes: 366468ff6c34 ("drm/amdgpu: Allow GfxOff on Vangogh as default") Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2545 Signed-off-by: Bas Nieuwenhuizen <bas(a)basnieuwenhuizen.nl> Tested-by: Guilherme G. Piccoli <gpiccoli(a)igalia.com> Cc: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Cc: stable(a)vger.kernel.org diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c index f5b5ce1051a2..1ec076517c96 100644 --- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c @@ -8152,8 +8152,14 @@ static int gfx_v10_0_set_powergating_state(void *handle, case IP_VERSION(10, 3, 3): case IP_VERSION(10, 3, 6): case IP_VERSION(10, 3, 7): + if (!enable) + amdgpu_gfx_off_ctrl(adev, false); + gfx_v10_cntl_pg(adev, enable); - amdgpu_gfx_off_ctrl(adev, enable); + + if (enable) + amdgpu_gfx_off_ctrl(adev, true); + break; default: break;

1 year

2
1
0 0

Regression on drm/i915, with bisected commit

by Éric Brunet

Hello all, I have a HP Elite x360 1049 G9 2-in-1 notebook running fedora 38 with an Adler Lake intel video card. After upgrading to kernel 6.2.13 (as packaged by fedora), I started seeing severe video glitches made of random pixels in a vertical band occupying about 20% of my screen, on the right. The glitches would happen both with X.org and wayland. I checked that vanilla 6.2.12 does not have the bug and that both vanilla 6.2.13 and vanilla 6.3.2 do have the bug. I bisected the problem to commit e2b789bc3dc34edc87ffb85634967d24ed351acb (it is a one-liner reproduced at the end of this message). I checked that vanilla 6.3.2 with this commit reverted does not have the bug. I am CC-ing every e-mail appearing in this commit , I hope this is ok, and I apologize if it is not. I have filled a fedora bug report about this, see https://bugzilla.redhat.com/ show_bug.cgi?id=2203549 . You will find there a small video (made with fedora kernel 2.6.14) demonstrating the issue. Some more details: % sudo lspci -vk -s 00:02.0 00:02.0 VGA compatible controller: Intel Corporation Alder Lake-UP3 GT2 [Iris Xe Graphics] (rev 0c) (prog-if 00 [VGA controller]) DeviceName: Onboard IGD Subsystem: Hewlett-Packard Company Device 896d Flags: bus master, fast devsel, latency 0, IRQ 143 Memory at 603c000000 (64-bit, non-prefetchable) [size=16M] Memory at 4000000000 (64-bit, prefetchable) [size=256M] I/O ports at 3000 [size=64] Expansion ROM at 000c0000 [virtual] [disabled] [size=128K] Capabilities: [40] Vendor Specific Information: Len=0c <?> Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00 Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable+ 64bit- Capabilities: [d0] Power Management version 2 Capabilities: [100] Process Address Space ID (PASID) Capabilities: [200] Address Translation Service (ATS) Capabilities: [300] Page Request Interface (PRI) Capabilities: [320] Single Root I/O Virtualization (SR-IOV) Kernel driver in use: i915 Kernel modules: i915 Relevant kernel boot messages: (appart from timestamps, these lines are identical for 6.2.12 and 6.2.14): [ 2.790043] i915 0000:00:02.0: vgaarb: deactivate vga console [ 2.790089] i915 0000:00:02.0: [drm] Using Transparent Hugepages [ 2.790497] i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem [ 2.793812] i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/ adlp_dmc_ver2_16.bin (v2.16) [ 2.825058] i915 0000:00:02.0: [drm] GuC firmware i915/adlp_guc_70.bin version 70.5.1 [ 2.825061] i915 0000:00:02.0: [drm] HuC firmware i915/tgl_huc.bin version 7.9.3 [ 2.842906] i915 0000:00:02.0: [drm] HuC authenticated [ 2.843778] i915 0000:00:02.0: [drm] GuC submission enabled [ 2.843779] i915 0000:00:02.0: [drm] GuC SLPC enabled [ 2.844200] i915 0000:00:02.0: [drm] GuC RC: enabled [ 2.845010] i915 0000:00:02.0: [drm] Protected Xe Path (PXP) protected content support initialized [ 3.964766] [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on minor 1 [ 3.968403] ACPI: video: Video Device [GFX0] (multi-head: yes rom: no post: no) [ 3.968981] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/ PNP0A08:00/LNXVIDEO:00/input/input18 [ 3.977892] fbcon: i915drmfb (fb0) is primary device [ 3.977899] fbcon: Deferring console take-over [ 3.977904] i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device [ 4.026120] i915 0000:00:02.0: [drm] Selective fetch area calculation failed in pipe A Is there anything else I should provide? I am willing to run some tests, of course. Thanks for your help, Éric Brunet ================================================= commit e2b789bc3dc34edc87ffb85634967d24ed351acb (HEAD) Author: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Date: Wed Mar 29 20:24:33 2023 +0300 drm/i915: Fix fast wake AUX sync len commit e1c71f8f918047ce822dc19b42ab1261ed259fd1 upstream. Fast wake should use 8 SYNC pulses for the preamble and 10-16 SYNC pulses for the precharge. Reduce our fast wake SYNC count to match the maximum value. We also use the maximum precharge length for normal AUX transactions. Cc: stable(a)vger.kernel.org Cc: Jouni Högander <jouni.hogander(a)intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ 20230329172434.18744-1-ville.syrjala(a)linux.intel.com Reviewed-by: Jouni Högander <jouni.hogander(a)intel.com> (cherry picked from commit 605f7c73133341d4b762cbd9a22174cc22d4c38b) Signed-off-by: Jani Nikula <jani.nikula(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c b/drivers/gpu/drm/ i915/display/intel_dp_aux.c index 664bebdecea7..d5fed2eb66d2 100644 --- a/drivers/gpu/drm/i915/display/intel_dp_aux.c +++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c @@ -166,7 +166,7 @@ static u32 skl_get_aux_send_ctl(struct intel_dp *intel_dp, DP_AUX_CH_CTL_TIME_OUT_MAX | DP_AUX_CH_CTL_RECEIVE_ERROR | (send_bytes << DP_AUX_CH_CTL_MESSAGE_SIZE_SHIFT) | - DP_AUX_CH_CTL_FW_SYNC_PULSE_SKL(32) | + DP_AUX_CH_CTL_FW_SYNC_PULSE_SKL(24) | DP_AUX_CH_CTL_SYNC_PULSE_SKL(32); if (intel_tc_port_in_tbt_alt_mode(dig_port))

1 year

5
7
0 0

[PATCH v1] i2c: designware: Handle invalid SMBus block data response length

by Tam Nguyen

In I2C_FUNC_SMBUS_BLOCK_DATA case, the I2C Designware driver does not handle correctly when it receives the length of SMBus block data response from SMBus slave device, which is outside the range 1-32 bytes. Consequently, the I2C Designware bus is stuck and cannot recover. Because if IC_EMPTYFIFO_HOLD_MASTER_EN is set, which cannot be detected from the registers, the controller can be disabled if the STOP bit is set. But it is only set after receiving block data response length. Hence, to prevent the bus from stuck condition, after receiving the invalid block data response length, the driver will read another byte with STOP bit set. Cc: stable(a)vger.kernel.org Signed-off-by: Tam Nguyen <tamnguyenchi(a)os.amperecomputing.com> --- drivers/i2c/busses/i2c-designware-master.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/drivers/i2c/busses/i2c-designware-master.c b/drivers/i2c/busses/i2c-designware-master.c index 55ea91a63382..94dadd785ed0 100644 --- a/drivers/i2c/busses/i2c-designware-master.c +++ b/drivers/i2c/busses/i2c-designware-master.c @@ -527,8 +527,19 @@ i2c_dw_read(struct dw_i2c_dev *dev) regmap_read(dev->map, DW_IC_DATA_CMD, &tmp); /* Ensure length byte is a valid value */ - if (flags & I2C_M_RECV_LEN && - (tmp & DW_IC_DATA_CMD_DAT) <= I2C_SMBUS_BLOCK_MAX && tmp > 0) { + if (flags & I2C_M_RECV_LEN) { + /* + * if IC_EMPTYFIFO_HOLD_MASTER_EN is set, which cannot be + * detected from the registers, the controller can be + * disabled if the STOP bit is set. But it is only set + * after receiving block data response length in + * I2C_FUNC_SMBUS_BLOCK_DATA case. That needs to read + * another byte with STOP bit set when the block data + * response length is invalid to complete the transaction. + */ + if ((tmp & DW_IC_DATA_CMD_DAT) > I2C_SMBUS_BLOCK_MAX || tmp == 0) + tmp = 1; + len = i2c_dw_recv_len(dev, tmp); } *buf++ = tmp; -- 2.25.1

1 year

3
4
0 0

[PATCH v6 2/2] ceph: fix blindly expanding the readahead windows

by xiubli＠redhat.com

From: Xiubo Li <xiubli(a)redhat.com> Blindly expanding the readahead windows will cause unneccessary pagecache thrashing and also will introdue the network workload. We should disable expanding the windows if the readahead is disabled and also shouldn't expand the windows too much. Expanding forward firstly instead of expanding backward for possible sequential reads. Bound `rreq->len` to the actual file size to restore the previous page cache usage. The posix_fadvise may change the maximum size of a file readahead. Cc: stable(a)vger.kernel.org Fixes: 49870056005c ("ceph: convert ceph_readpages to ceph_readahead") URL: https://lore.kernel.org/ceph-devel/20230504082510.247-1-sehuww@mail.scut.ed… URL: https://www.spinics.net/lists/ceph-users/msg76183.html Cc: Hu Weiwen <sehuww(a)mail.scut.edu.cn> Signed-off-by: Xiubo Li <xiubli(a)redhat.com> --- fs/ceph/addr.c | 40 +++++++++++++++++++++++++++++++++------- 1 file changed, 33 insertions(+), 7 deletions(-) diff --git a/fs/ceph/addr.c b/fs/ceph/addr.c index 93fff1a7373f..4b29777c01d7 100644 --- a/fs/ceph/addr.c +++ b/fs/ceph/addr.c @@ -188,16 +188,42 @@ static void ceph_netfs_expand_readahead(struct netfs_io_request *rreq) struct inode *inode = rreq->inode; struct ceph_inode_info *ci = ceph_inode(inode); struct ceph_file_layout *lo = &ci->i_layout; + unsigned long max_pages = inode->i_sb->s_bdi->ra_pages; + loff_t end = rreq->start + rreq->len, new_end; + struct ceph_netfs_request_data *priv = rreq->netfs_priv; + unsigned long max_len; u32 blockoff; - u64 blockno; - /* Expand the start downward */ - blockno = div_u64_rem(rreq->start, lo->stripe_unit, &blockoff); - rreq->start = blockno * lo->stripe_unit; - rreq->len += blockoff; + if (priv) { + /* Readahead is disabled by posix_fadvise POSIX_FADV_RANDOM */ + if (priv->file_ra_disabled) + max_pages = 0; + else + max_pages = priv->file_ra_pages; + + } + + /* Readahead is disabled */ + if (!max_pages) + return; - /* Now, round up the length to the next block */ - rreq->len = roundup(rreq->len, lo->stripe_unit); + max_len = max_pages << PAGE_SHIFT; + + /* + * Try to expand the length forward by rounding up it to the next + * block, but do not exceed the file size, unless the original + * request already exceeds it. + */ + new_end = min(round_up(end, lo->stripe_unit), rreq->i_size); + if (new_end > end && new_end <= rreq->start + max_len) + rreq->len = new_end - rreq->start; + + /* Try to expand the start downward */ + div_u64_rem(rreq->start, lo->stripe_unit, &blockoff); + if (rreq->len + blockoff <= max_len) { + rreq->start -= blockoff; + rreq->len += blockoff; + } } static bool ceph_netfs_clamp_length(struct netfs_io_subrequest *subreq) -- 2.40.1

1 year

3
2
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror May 2023