Skip to content

Linux 6.6.18 eic7 x update#4

Merged
JoeyZheng merged 19 commits into
eswincomputing:linux-6.6.18-EIC7Xfrom
RevySR:linux-6.6.18-EIC7X-update
Jul 24, 2024
Merged

Linux 6.6.18 eic7 x update#4
JoeyZheng merged 19 commits into
eswincomputing:linux-6.6.18-EIC7Xfrom
RevySR:linux-6.6.18-EIC7X-update

Conversation

@RevySR

@RevySR RevySR commented Jul 22, 2024

Copy link
Copy Markdown
Contributor

No description provided.

RevySR and others added 19 commits July 23, 2024 00:55
detected buffer overflow in strcpy

[    1.391721] detected buffer overflow in strcpy
[    1.396122] ------------[ cut here ]------------
[    1.396124] Kernel BUG at fortify_panic+0x1a/0x1c [verbose debug info unavailable]
[    1.396142] Kernel BUG [eswincomputing#1]
[    1.396145] Modules linked in:
[    1.396150] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.6.36 #0
[    1.396155] Hardware name: ESWIN EIC7700 (DT)
[    1.396157] epc : fortify_panic+0x1a/0x1c
[    1.396163]  ra : fortify_panic+0x1a/0x1c
[    1.396168] epc : ffffffff8030b2de ra : ffffffff8030b2de sp : ffffaf80a7177b20
[    1.396171]  gp : ffffffff812e47a8 tp : ffffaf80a714cd00 t0 : 2000000000000000
[    1.396174]  t1 : 0000000000000064 t2 : 2064657463657465 s0 : ffffaf80a7177b30
[    1.396177]  s1 : ffffaf80a8755c40 a0 : 0000000000000022 a1 : ffffffff81283d48
[    1.396180]  a2 : 0000000000000010 a3 : ffffffff81283d48 a4 : ffffffff81283d60
[    1.396183]  a5 : 0000000000000000 a6 : ffffffff81213cf0 a7 : 0000000000000001
[    1.396186]  s2 : ffffaf80a794a000 s3 : ffffaf80a8755c60 s4 : ffff8d7ffec18dae
[    1.396189]  s5 : ffffaf82a6f9fb00 s6 : ffffaf80a794a020 s7 : ffffaf80a8755cd0
[    1.396192]  s8 : 0000000000000000 s9 : 0000000000000000 s10: 0000000000000000
[    1.396194]  s11: 0000000000000000 t3 : ffffffff812f5ad7 t4 : ffffffff812f5ad7
[    1.396197]  t5 : ffffffff812f5ad8 t6 : ffffaf80a7177970
[    1.396199] status: 0000000200000120 badaddr: 0000000000000000 cause: 0000000000000003
[    1.396203] [<ffffffff8030b2de>] fortify_panic+0x1a/0x1c
[    1.396209] [<ffffffff80393d18>] mpq8785_probe+0x3d8/0x462

Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
fix es-fbdev

Co-authored-by: Icenowy Zheng <uwu@icenowy.me>
Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
Signed-off-by: Han Gao <rabenda.cn@gmail.com>
riscv_noncoherent_supported should not be called multiple times
in the sifive_errata_probe function

[   72.659708] Unable to handle kernel paging request at virtual address ffffffff81389380
[   72.667661] Oops [eswincomputing#1]
[   72.669934] Modules linked in: es_iommu_rsv es_dev_dma_buf es_vdec es_rsvmem_heap es_buddy_driver nfnetlink ip_tables x_tables sha1_generic hmac ipv6 pvrsrvkm
[   72.684133] CPU: 0 PID: 696 Comm: modprobe Not tainted 6.6.36-win2030 eswincomputing#10
[   72.690922] Hardware name: ESWIN EIC7700 (DT)
[   72.695277] epc : riscv_noncoherent_supported+0x10/0x3e
[   72.700507]  ra : sifive_errata_patch_func+0x44/0x1e2
[   72.705560] epc : ffffffff8000bff6 ra : ffffffff8000c4da sp : ffff8f8008273ac0
[   72.712781]  gp : ffffffff81948e40 tp : ffffaf80b1115400 t0 : 0000000000000000
[   72.720001]  t1 : 0000000000000000 t2 : 0000000000000002 s0 : ffff8f8008273b30
[   72.727221]  s1 : ffffffff01d5e388 a0 : ffffffff01d5e388 a1 : ffffffff01d5e3c8
[   72.734441]  a2 : 8000000000000008 a3 : 0000000006220425 a4 : ffffffff81388ff2
[   72.741661]  a5 : 0000000000000001 a6 : 0000000000000006 a7 : 0000000000000010
[   72.748881]  s2 : ffffffff01d5e3c8 s3 : 8000000000000008 s4 : 0000000000000001
[   72.756101]  s5 : 0000000006220425 s6 : ffffffff8180f660 s7 : 0000000000000001
[   72.763321]  s8 : ffff8f8008273d58 s9 : ffffffff01dcb8c0 s10: ffffffff01dcb758
[   72.770542]  s11: 0000000000000000 t3 : ffffffffffffffff t4 : ffffffffffffffff
[   72.777761]  t5 : ffffffffffffffff t6 : ffffaf82a5ecc1c8
[   72.783071] status: 0000000200000120 badaddr: ffffffff81389380 cause: 000000000000000f
[   72.790986] [<ffffffff8000bff6>] riscv_noncoherent_supported+0x10/0x3e
[   72.797514] [<ffffffff800027f6>] _apply_alternatives+0x84/0x86
[   72.803348] [<ffffffff800029cc>] apply_module_alternatives+0x10/0x18
[   72.809701] [<ffffffff80007c8c>] module_finalize+0x5e/0x74
[   72.815193] [<ffffffff80083b54>] load_module+0x1110/0x18b4
[   72.820682] [<ffffffff80084496>] init_module_from_file+0x76/0xaa
[   72.826688] [<ffffffff800846e4>] __riscv_sys_finit_module+0x1e2/0x2a8
[   72.833129] [<ffffffff80a9ccbc>] do_trap_ecall_u+0xbe/0x130
[   72.838703] [<ffffffff80aa51f8>] ret_from_exception+0x0/0x64
[   72.844376] Code: 0009 b7ed e797 0193 a783 12e7 c799 4785 d717 0137 (0723) 38f7
[   72.851970] ---[ end trace 0000000000000000 ]---

Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
Signed-off-by: Han Gao <rabenda.cn@gmail.com>
Revert commitid: 6bb2e00

EIC770X is not support it.

Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
Signed-off-by: Han Gao <rabenda.cn@gmail.com>
Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
Signed-off-by: Han Gao <rabenda.cn@gmail.com>
@NingYu00

Copy link
Copy Markdown
Collaborator

@RevySR
Can you provide the reason for removing the "kvm_riscv_vcpu_update_config" function?

@NingYu00 NingYu00 left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review +1

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's ok to move the "riscv_cbom_block_size = 1....". But why?

@JoeyZheng JoeyZheng left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1

@JoeyZheng
JoeyZheng merged commit 5bdcbf5 into eswincomputing:linux-6.6.18-EIC7X Jul 24, 2024
super2279 pushed a commit that referenced this pull request Sep 4, 2024
…ng/linux-stable:linux-6.6.18-EIC7X into linux-6.6.18-EIC7X

Reviewed-by: ningyu <ningyu@eswincomputing.com>
Reviewed-by: Joey Zheng <zhengyu@eswincomputing.com>
super2279 pushed a commit that referenced this pull request Nov 6, 2024
…ng/linux-stable:linux-6.6.18-EIC7X into linux-6.6.18-EIC7X

Reviewed-on: http://10.100.130.109:3000/Upstream/linux-stable/pulls/4
Reviewed-by: Joey Zheng <zhengyu@eswincomputing.com>
Reviewed-by: Ning Yu <ningyu@eswincomputing.com>
super2279 pushed a commit that referenced this pull request Jul 14, 2026
[ Upstream commit 77603ab10429fe713a03345553ca8dbbfb1d91c6 ]

Shin'ichiro reported sporadic hangs when running generic/013 in our CI
system. When enabling lockdep, there is a lockdep splat when calling
btrfs_get_dev_zone_info_all_devices() in the mount path that can be
triggered by i.e. generic/013:

  ======================================================
  WARNING: possible circular locking dependency detected
  7.0.0-rc1+ #355 Not tainted
  ------------------------------------------------------
  mount/1043 is trying to acquire lock:
  ffff8881020b5470 (&vblk->vdev_mutex){+.+.}-{4:4}, at: virtblk_report_zones+0xda/0x430

  but task is already holding lock:
  ffff888102a738e0 (&fs_devs->device_list_mutex){+.+.}-{4:4}, at: btrfs_get_dev_zone_info_all_devices+0x45/0x90

  which lock already depends on the new lock.

  the existing dependency chain (in reverse order) is:

  -> #4 (&fs_devs->device_list_mutex){+.+.}-{4:4}:
	 __mutex_lock+0xa3/0x1360
	 btrfs_create_pending_block_groups+0x1f4/0x9d0
	 __btrfs_end_transaction+0x3e/0x2e0
	 btrfs_zoned_reserve_data_reloc_bg+0x2f8/0x390
	 open_ctree+0x1934/0x23db
	 btrfs_get_tree.cold+0x105/0x26c
	 vfs_get_tree+0x28/0xb0
	 __do_sys_fsconfig+0x324/0x680
	 do_syscall_64+0x92/0x4f0
	 entry_SYSCALL_64_after_hwframe+0x76/0x7e

  -> #3 (btrfs_trans_num_extwriters){++++}-{0:0}:
	 join_transaction+0xc2/0x5c0
	 start_transaction+0x17c/0xbc0
	 btrfs_zoned_reserve_data_reloc_bg+0x2b4/0x390
	 open_ctree+0x1934/0x23db
	 btrfs_get_tree.cold+0x105/0x26c
	 vfs_get_tree+0x28/0xb0
	 __do_sys_fsconfig+0x324/0x680
	 do_syscall_64+0x92/0x4f0
	 entry_SYSCALL_64_after_hwframe+0x76/0x7e

  -> #2 (btrfs_trans_num_writers){++++}-{0:0}:
	 lock_release+0x163/0x4b0
	 __btrfs_end_transaction+0x1c7/0x2e0
	 btrfs_dirty_inode+0x6f/0xd0
	 touch_atime+0xe5/0x2c0
	 btrfs_file_mmap_prepare+0x65/0x90
	 __mmap_region+0x4b9/0xf00
	 mmap_region+0xf7/0x120
	 do_mmap+0x43d/0x610
	 vm_mmap_pgoff+0xd6/0x190
	 ksys_mmap_pgoff+0x7e/0xc0
	 do_syscall_64+0x92/0x4f0
	 entry_SYSCALL_64_after_hwframe+0x76/0x7e

  -> #1 (&mm->mmap_lock){++++}-{4:4}:
	 __might_fault+0x68/0xa0
	 _copy_to_user+0x22/0x70
	 blkdev_copy_zone_to_user+0x22/0x40
	 virtblk_report_zones+0x282/0x430
	 blkdev_report_zones_ioctl+0xfd/0x130
	 blkdev_ioctl+0x20f/0x2c0
	 __x64_sys_ioctl+0x86/0xd0
	 do_syscall_64+0x92/0x4f0
	 entry_SYSCALL_64_after_hwframe+0x76/0x7e

  -> #0 (&vblk->vdev_mutex){+.+.}-{4:4}:
	 __lock_acquire+0x1522/0x2680
	 lock_acquire+0xd5/0x2f0
	 __mutex_lock+0xa3/0x1360
	 virtblk_report_zones+0xda/0x430
	 blkdev_report_zones_cached+0x162/0x190
	 btrfs_get_dev_zones+0xdc/0x2e0
	 btrfs_get_dev_zone_info+0x219/0xe80
	 btrfs_get_dev_zone_info_all_devices+0x62/0x90
	 open_ctree+0x1200/0x23db
	 btrfs_get_tree.cold+0x105/0x26c
	 vfs_get_tree+0x28/0xb0
	 __do_sys_fsconfig+0x324/0x680
	 do_syscall_64+0x92/0x4f0
	 entry_SYSCALL_64_after_hwframe+0x76/0x7e

  other info that might help us debug this:

  Chain exists of:
    &vblk->vdev_mutex --> btrfs_trans_num_extwriters --> &fs_devs->device_list_mutex

   Possible unsafe locking scenario:

	 CPU0                    CPU1
	 ----                    ----
    lock(&fs_devs->device_list_mutex);
				 lock(btrfs_trans_num_extwriters);
				 lock(&fs_devs->device_list_mutex);
    lock(&vblk->vdev_mutex);

   *** DEADLOCK ***

  3 locks held by mount/1043:
   #0: ffff88811063e878 (&fc->uapi_mutex){+.+.}-{4:4}, at: __do_sys_fsconfig+0x2ae/0x680
   #1: ffff88810cb9f0e8 (&type->s_umount_key#31/1){+.+.}-{4:4}, at: alloc_super+0xc0/0x3e0
   #2: ffff888102a738e0 (&fs_devs->device_list_mutex){+.+.}-{4:4}, at: btrfs_get_dev_zone_info_all_devices+0x45/0x90

  stack backtrace:
  CPU: 2 UID: 0 PID: 1043 Comm: mount Not tainted 7.0.0-rc1+ #355 PREEMPT(full)
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-9.fc43 06/10/2025
  Call Trace:
   <TASK>
   dump_stack_lvl+0x5b/0x80
   print_circular_bug.cold+0x18d/0x1d8
   check_noncircular+0x10d/0x130
   __lock_acquire+0x1522/0x2680
   ? vmap_small_pages_range_noflush+0x3ef/0x820
   lock_acquire+0xd5/0x2f0
   ? virtblk_report_zones+0xda/0x430
   ? lock_is_held_type+0xcd/0x130
   __mutex_lock+0xa3/0x1360
   ? virtblk_report_zones+0xda/0x430
   ? virtblk_report_zones+0xda/0x430
   ? __pfx_copy_zone_info_cb+0x10/0x10
   ? virtblk_report_zones+0xda/0x430
   virtblk_report_zones+0xda/0x430
   ? __pfx_copy_zone_info_cb+0x10/0x10
   blkdev_report_zones_cached+0x162/0x190
   ? __pfx_copy_zone_info_cb+0x10/0x10
   btrfs_get_dev_zones+0xdc/0x2e0
   btrfs_get_dev_zone_info+0x219/0xe80
   btrfs_get_dev_zone_info_all_devices+0x62/0x90
   open_ctree+0x1200/0x23db
   btrfs_get_tree.cold+0x105/0x26c
   ? rcu_is_watching+0x18/0x50
   vfs_get_tree+0x28/0xb0
   __do_sys_fsconfig+0x324/0x680
   do_syscall_64+0x92/0x4f0
   entry_SYSCALL_64_after_hwframe+0x76/0x7e
  RIP: 0033:0x7f615e27a40e
  RSP: 002b:00007fff11b18fb8 EFLAGS: 00000246 ORIG_RAX: 00000000000001af
  RAX: ffffffffffffffda RBX: 000055572e92ab10 RCX: 00007f615e27a40e
  RDX: 0000000000000000 RSI: 0000000000000006 RDI: 0000000000000003
  RBP: 00007fff11b19100 R08: 0000000000000000 R09: 0000000000000000
  R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
  R13: 000055572e92bc40 R14: 00007f615e3faa60 R15: 000055572e92bd08
   </TASK>

Don't hold the device_list_mutex while calling into
btrfs_get_dev_zone_info() in btrfs_get_dev_zone_info_all_devices() to
mitigate the issue. This is safe, as no other thread can touch the device
list at the moment of execution.

Reported-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
super2279 pushed a commit that referenced this pull request Jul 14, 2026
[ Upstream commit 317e49358ebbf6390fa439ef3c142f9239dd25fb ]

The devm_free_irq() and devm_request_irq() functions should not be
executed in an atomic context.

During device suspend, all userspace processes and most kernel threads
are frozen. Additionally, we flush all tx/rx status, disable all macb
interrupts, and halt rx operations. Therefore, it is safe to split the
region protected by bp->lock into two independent sections, allowing
devm_free_irq() and devm_request_irq() to run in a non-atomic context.
This modification resolves the following lockdep warning:
  BUG: sleeping function called from invalid context at kernel/locking/mutex.c:591
  in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 501, name: rtcwake
  preempt_count: 1, expected: 0
  RCU nest depth: 1, expected: 0
  7 locks held by rtcwake/501:
   #0: ffff0008038c3408 (sb_writers#5){.+.+}-{0:0}, at: vfs_write+0xf8/0x368
   #1: ffff0008049a5e88 (&of->mutex#2){+.+.}-{4:4}, at: kernfs_fop_write_iter+0xbc/0x1c8
   #2: ffff00080098d588 (kn->active#70){.+.+}-{0:0}, at: kernfs_fop_write_iter+0xcc/0x1c8
   #3: ffff800081c84888 (system_transition_mutex){+.+.}-{4:4}, at: pm_suspend+0x1ec/0x290
   #4: ffff0008009ba0f8 (&dev->mutex){....}-{4:4}, at: device_suspend+0x118/0x4f0
   #5: ffff800081d00458 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire+0x4/0x48
   #6: ffff0008031fb9e0 (&bp->lock){-.-.}-{3:3}, at: macb_suspend+0x144/0x558
  irq event stamp: 8682
  hardirqs last  enabled at (8681): [<ffff8000813c7d7c>] _raw_spin_unlock_irqrestore+0x44/0x88
  hardirqs last disabled at (8682): [<ffff8000813c7b58>] _raw_spin_lock_irqsave+0x38/0x98
  softirqs last  enabled at (7322): [<ffff8000800f1b4c>] handle_softirqs+0x52c/0x588
  softirqs last disabled at (7317): [<ffff800080010310>] __do_softirq+0x20/0x2c
  CPU: 1 UID: 0 PID: 501 Comm: rtcwake Not tainted 7.0.0-rc3-next-20260310-yocto-standard+ #125 PREEMPT
  Hardware name: ZynqMP ZCU102 Rev1.1 (DT)
  Call trace:
   show_stack+0x24/0x38 (C)
   __dump_stack+0x28/0x38
   dump_stack_lvl+0x64/0x88
   dump_stack+0x18/0x24
   __might_resched+0x200/0x218
   __might_sleep+0x38/0x98
   __mutex_lock_common+0x7c/0x1378
   mutex_lock_nested+0x38/0x50
   free_irq+0x68/0x2b0
   devm_irq_release+0x24/0x38
   devres_release+0x40/0x80
   devm_free_irq+0x48/0x88
   macb_suspend+0x298/0x558
   device_suspend+0x218/0x4f0
   dpm_suspend+0x244/0x3a0
   dpm_suspend_start+0x50/0x78
   suspend_devices_and_enter+0xec/0x560
   pm_suspend+0x194/0x290
   state_store+0x110/0x158
   kobj_attr_store+0x1c/0x30
   sysfs_kf_write+0xa8/0xd0
   kernfs_fop_write_iter+0x11c/0x1c8
   vfs_write+0x248/0x368
   ksys_write+0x7c/0xf8
   __arm64_sys_write+0x28/0x40
   invoke_syscall+0x4c/0xe8
   el0_svc_common+0x98/0xf0
   do_el0_svc+0x28/0x40
   el0_svc+0x54/0x1e0
   el0t_64_sync_handler+0x84/0x130
   el0t_64_sync+0x198/0x1a0

Fixes: 558e35c ("net: macb: WoL support for GEM type of Ethernet controller")
Cc: stable@vger.kernel.org
Reviewed-by: Théo Lebrun <theo.lebrun@bootlin.com>
Signed-off-by: Kevin Hao <haokexin@gmail.com>
Link: https://patch.msgid.link/20260318-macb-irq-v2-1-f1179768ab24@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
[ replaced `tmp` variable with direct `MACB_BIT(MAG)` ]
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants