December 2024 - Kernel - mailweb.openeuler.org

[PATCH OLK-6.6 00/16] net:yt6801: Add Motorcomm yt6801 PCIe driver
by Frank Sae 26 Dec '24

26 Dec '24

This series includes adding Motorcomm YT6801 Gigabit ethernet driver and adding yt6801 ethernet driver entry in MAINTAINERS file. YT6801 integrates a YT8531S phy. Frank Sae (16): motorcomm:yt6801: Add support for a pci table in this module motorcomm:yt6801: Implement pci_driver shutdown motorcomm:yt6801: Implement the fxgmac_drv_probe function motorcomm:yt6801: Implement the .ndo_open function motorcomm:yt6801: Implement the fxgmac_start function motorcomm:yt6801: Implement the poll functions motorcomm:yt6801: Implement the fxgmac_init function motorcomm:yt6801: Implement the fxgmac_read_mac_addr function motorcomm:yt6801: Implement some hw_ops function motorcomm:yt6801: Implement .ndo_start_xmit function motorcomm:yt6801: Implement some net_device_ops function motorcomm:yt6801: Implement .ndo_tx_timeout and .ndo_change_mtu functions motorcomm:yt6801: Implement some ethtool_ops function motorcomm:yt6801: Implement the WOL function of ethtool_ops motorcomm:yt6801: Implement pci_driver suspend and resume motorcomm:yt6801: Update the Makefile, Kconfig and maintainer for yt6801 MAINTAINERS | 8 + drivers/net/ethernet/Kconfig | 1 + drivers/net/ethernet/Makefile | 1 + drivers/net/ethernet/motorcomm/Kconfig | 27 + drivers/net/ethernet/motorcomm/Makefile | 6 + .../net/ethernet/motorcomm/yt6801/Makefile | 9 + .../net/ethernet/motorcomm/yt6801/yt6801.h | 617 +++ .../ethernet/motorcomm/yt6801/yt6801_desc.c | 638 ++++ .../ethernet/motorcomm/yt6801/yt6801_desc.h | 39 + .../motorcomm/yt6801/yt6801_ethtool.c | 838 ++++ .../net/ethernet/motorcomm/yt6801/yt6801_hw.c | 3383 +++++++++++++++++ .../ethernet/motorcomm/yt6801/yt6801_net.c | 2908 ++++++++++++++ .../ethernet/motorcomm/yt6801/yt6801_net.h | 32 + .../ethernet/motorcomm/yt6801/yt6801_pci.c | 191 + .../ethernet/motorcomm/yt6801/yt6801_type.h | 1398 +++++++ 15 files changed, 10096 insertions(+) create mode 100644 drivers/net/ethernet/motorcomm/Kconfig create mode 100644 drivers/net/ethernet/motorcomm/Makefile create mode 100644 drivers/net/ethernet/motorcomm/yt6801/Makefile create mode 100644 drivers/net/ethernet/motorcomm/yt6801/yt6801.h create mode 100644 drivers/net/ethernet/motorcomm/yt6801/yt6801_desc.c create mode 100644 drivers/net/ethernet/motorcomm/yt6801/yt6801_desc.h create mode 100644 drivers/net/ethernet/motorcomm/yt6801/yt6801_ethtool.c create mode 100644 drivers/net/ethernet/motorcomm/yt6801/yt6801_hw.c create mode 100644 drivers/net/ethernet/motorcomm/yt6801/yt6801_net.c create mode 100644 drivers/net/ethernet/motorcomm/yt6801/yt6801_net.h create mode 100644 drivers/net/ethernet/motorcomm/yt6801/yt6801_pci.c create mode 100644 drivers/net/ethernet/motorcomm/yt6801/yt6801_type.h -- 2.34.1

2 17

[openeuler:OLK-6.6 1662/1662] drivers/net/ethernet/nebula-matrix/nbl/nbl_core.o: warning: objtool: .text.nbl_dev_start_user_dev: unexpected end of section
by kernel test robot 26 Dec '24

26 Dec '24

Hi Bennie, First bad commit (maybe != root cause): tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: 589aaab51b2a3b112b232f89fd29a5302222d946 commit: 69181c3c9413ccaa4dab458057d13efda520cb60 [1662/1662] Net: nebula_matrix: fix ci build warning config: x86_64-randconfig-123-20241226 (https://download.01.org/0day-ci/archive/20241226/202412261702.O5HnEzsC-lkp@…) compiler: clang version 19.1.3 (https://github.com/llvm/llvm-project ab51eccf88f5321e7c60591c5546b254b6afab99) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241226/202412261702.O5HnEzsC-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202412261702.O5HnEzsC-lkp@intel.com/ All warnings (new ones prefixed by >>): >> drivers/net/ethernet/nebula-matrix/nbl/nbl_core.o: warning: objtool: .text.nbl_dev_start_user_dev: unexpected end of section -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-6.6 0/5] OLK-6.6: Some patches of RDMA/hns from Linux to olk-6.6
by Chengchang Tang 26 Dec '24

26 Dec '24

From: Xinghai Cen <cenxinghai(a)h-partners.com> OLK-6.6: Some patches of RDMA/hns from Linux to olk-6.6 Chengchang Tang (3): RDMA/hns: Fix accessing invalid dip_ctx during destroying QP RDMA/hns: Fix warning storm caused by invalid input in IO path RDMA/hns: Fix missing flush CQE for DWQE Xinghai Cen (1): Revert "RDMA/hns: Fix accessing invalid dip_ctx during destroying QP" wenglianfa (1): RDMA/hns: Fix mapping error of zero-hop WQE buffer drivers/infiniband/hw/hns/hns_roce_hem.c | 43 +++++++++++++++------- drivers/infiniband/hw/hns/hns_roce_hw_v2.c | 8 +++- drivers/infiniband/hw/hns/hns_roce_mr.c | 5 --- 3 files changed, 35 insertions(+), 21 deletions(-) -- 2.33.0

2 6

[PATCH openEuler-1.0-LTS] signal: Replace BUG_ON()s
by He Yujie 26 Dec '24

26 Dec '24

From: Thomas Gleixner <tglx(a)linutronix.de> stable inclusion from stable-v4.19.323 commit 0f9c27fbb8a52c50ff7d2659386f1f43e7fbddee category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IBDY6Z CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 7f8af7bac5380f2d95a63a6f19964e22437166e1 ] These really can be handled gracefully without killing the machine. Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Signed-off-by: Frederic Weisbecker <frederic(a)kernel.org> Reviewed-by: Oleg Nesterov <oleg(a)redhat.com> Acked-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zheng Zucheng <zhengzucheng(a)huawei.com> Signed-off-by: He Yujie <coka.heyujie(a)huawei.com> --- kernel/signal.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/kernel/signal.c b/kernel/signal.c index 4166d22645f8..9e8474dfd251 100644 --- a/kernel/signal.c +++ b/kernel/signal.c @@ -1744,10 +1744,11 @@ struct sigqueue *sigqueue_alloc(void) void sigqueue_free(struct sigqueue *q) { - unsigned long flags; spinlock_t *lock = &current->sighand->siglock; + unsigned long flags; - BUG_ON(!(q->flags & SIGQUEUE_PREALLOC)); + if (WARN_ON_ONCE(!(q->flags & SIGQUEUE_PREALLOC))) + return; /* * We must hold ->siglock while testing q->list * to serialize with collect_signal() or with @@ -1775,7 +1776,10 @@ int send_sigqueue(struct sigqueue *q, struct pid *pid, enum pid_type type) unsigned long flags; int ret, result; - BUG_ON(!(q->flags & SIGQUEUE_PREALLOC)); + if (WARN_ON_ONCE(!(q->flags & SIGQUEUE_PREALLOC))) + return 0; + if (WARN_ON_ONCE(q->info.si_code != SI_TIMER)) + return 0; ret = -1; rcu_read_lock(); @@ -1794,7 +1798,6 @@ int send_sigqueue(struct sigqueue *q, struct pid *pid, enum pid_type type) * If an SI_TIMER entry is already queue just increment * the overrun count. */ - BUG_ON(q->info.si_code != SI_TIMER); q->info.si_overrun++; result = TRACE_SIGNAL_ALREADY_PENDING; goto out; -- 2.34.1

2 1

[PATCH OLK-5.10] printk: Fix the qspinlock deadloop caused by zap_locks()
by Li Huafei 26 Dec '24

26 Dec '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IBC1RM CVE: NA -------------------------------- printk calls zap_locks() to bypass logbuf_lock during panic. If the current system uses qspinlock, it may cause a deadloop in queued_spin_lock_slowpath(). Consider the following locking sequence: cpu1: (0, 0, 1) cpu2: (0, 1, 1) cpu3: (3, 1, 1) If zap_locks() is called at this time, cpu2 may acquire the lock first, and then cpu3 acquires the lock. When cpu3 releases the lock, it checks if the tail is itself. Originally, it should be, but after zap_locks(), the tail is modified to 0. At this point, cpu3 thinks there are other contenders, it will first set the locked bit and then wait for the contender to set its next pointer. However, in reality, there are no other contenders, so cpu3 will hold the lock (locked bit is 1) and loop here, causing other CPUs that want to acquire the lock to be stuck. To fix this problem, the lock initialization in zap_locks() can be degraded to clear locked_pending and retain the tail, avoiding misjudgment. Fixes: 0cc12581b3db ("printk/panic: Avoid deadlock in printk()") Signed-off-by: Li Huafei <lihuafei1(a)huawei.com> --- kernel/printk/printk.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c index d6727b71599b..fd53eebd5637 100644 --- a/kernel/printk/printk.c +++ b/kernel/printk/printk.c @@ -1762,11 +1762,21 @@ void zap_locks(void) { if (raw_spin_is_locked(&logbuf_lock)) { debug_locks_off(); +#ifdef CONFIG_QUEUED_SPINLOCKS + /* Do not clear the tail to avoid infinite loops in qspinlock. */ + WRITE_ONCE(logbuf_lock.raw_lock.locked_pending, 0); +#else raw_spin_lock_init(&logbuf_lock); +#endif } if (raw_spin_is_locked(&console_owner_lock)) { +#ifdef CONFIG_QUEUED_SPINLOCKS + /* Do not clear the tail to avoid infinite loops in qspinlock. */ + WRITE_ONCE(console_owner_lock.raw_lock.locked_pending, 0); +#else raw_spin_lock_init(&console_owner_lock); +#endif } console_owner = NULL; -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] printk: Fix the qspinlock deadloop caused by zap_locks()
by Li Huafei 26 Dec '24

26 Dec '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IBC1RM CVE: NA -------------------------------- printk calls zap_locks() to bypass logbuf_lock during panic. If the current system uses qspinlock, it may cause a deadloop in queued_spin_lock_slowpath(). Consider the following locking sequence: cpu1: (0, 0, 1) cpu2: (0, 1, 1) cpu3: (3, 1, 1) If zap_locks() is called at this time, cpu2 may acquire the lock first, and then cpu3 acquires the lock. When cpu3 releases the lock, it checks if the tail is itself. Originally, it should be, but after zap_locks(), the tail is modified to 0. At this point, cpu3 thinks there are other contenders, it will first set the locked bit and then wait for the contender to set its next pointer. However, in reality, there are no other contenders, so cpu3 will hold the lock (locked bit is 1) and loop here, causing other CPUs that want to acquire the lock to be stuck. To fix this problem, the lock initialization in zap_locks() can be degraded to clear locked_pending and retain the tail, avoiding misjudgment. Fixes: 0cc12581b3db ("printk/panic: Avoid deadlock in printk()") Signed-off-by: Li Huafei <lihuafei1(a)huawei.com> --- kernel/printk/printk.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c index ecd28d4fa20e..f38190a092f6 100644 --- a/kernel/printk/printk.c +++ b/kernel/printk/printk.c @@ -1751,11 +1751,21 @@ void zap_locks(void) { if (raw_spin_is_locked(&logbuf_lock)) { debug_locks_off(); +#ifdef CONFIG_QUEUED_SPINLOCKS + /* Do not clear the tail to avoid infinite loops in qspinlock. */ + WRITE_ONCE(logbuf_lock.raw_lock.locked_pending, 0); +#else raw_spin_lock_init(&logbuf_lock); +#endif } if (raw_spin_is_locked(&console_owner_lock)) { +#ifdef CONFIG_QUEUED_SPINLOCKS + /* Do not clear the tail to avoid infinite loops in qspinlock. */ + WRITE_ONCE(console_owner_lock.raw_lock.locked_pending, 0); +#else raw_spin_lock_init(&console_owner_lock); +#endif } console_owner = NULL; -- 2.25.1

2 1

[PATCH OLK-5.10] printk: Fix the qspinlock deadloop caused by zap_locks()
by Li Huafei 26 Dec '24

26 Dec '24

Offering: HULK hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IBC1RM -------------------------------- printk calls zap_locks() to bypass logbuf_lock during panic. If the current system uses qspinlock, it may cause a deadloop in queued_spin_lock_slowpath(). Consider the following locking sequence: cpu1: (0, 0, 1) cpu2: (0, 1, 1) cpu3: (3, 1, 1) If zap_locks() is called at this time, cpu2 may acquire the lock first, and then cpu3 acquires the lock. When cpu3 releases the lock, it checks if the tail is itself. Originally, it should be, but after zap_locks(), the tail is modified to 0. At this point, cpu3 thinks there are other contenders, it will first set the locked bit and then wait for the contender to set its next pointer. However, in reality, there are no other contenders, so cpu3 will hold the lock (locked bit is 1) and loop here, causing other CPUs that want to acquire the lock to be stuck. To fix this problem, the lock initialization in zap_locks() can be degraded to clear locked_pending and retain the tail, avoiding misjudgment. Fixes: 0cc12581b3db ("printk/panic: Avoid deadlock in printk()") Signed-off-by: Li Huafei <lihuafei1(a)huawei.com> --- kernel/printk/printk.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c index d6727b71599b..fd53eebd5637 100644 --- a/kernel/printk/printk.c +++ b/kernel/printk/printk.c @@ -1762,11 +1762,21 @@ void zap_locks(void) { if (raw_spin_is_locked(&logbuf_lock)) { debug_locks_off(); +#ifdef CONFIG_QUEUED_SPINLOCKS + /* Do not clear the tail to avoid infinite loops in qspinlock. */ + WRITE_ONCE(logbuf_lock.raw_lock.locked_pending, 0); +#else raw_spin_lock_init(&logbuf_lock); +#endif } if (raw_spin_is_locked(&console_owner_lock)) { +#ifdef CONFIG_QUEUED_SPINLOCKS + /* Do not clear the tail to avoid infinite loops in qspinlock. */ + WRITE_ONCE(console_owner_lock.raw_lock.locked_pending, 0); +#else raw_spin_lock_init(&console_owner_lock); +#endif } console_owner = NULL; -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] printk: Fix the qspinlock deadloop caused by zap_locks()
by Li Huafei 26 Dec '24

26 Dec '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IBC1RM CVE: NA -------------------------------- printk calls zap_locks() to bypass logbuf_lock during panic. If the current system uses qspinlock, it may cause a deadloop in queued_spin_lock_slowpath(). Consider the following locking sequence: cpu1: (0, 0, 1) cpu2: (0, 1, 1) cpu3: (3, 1, 1) If zap_locks() is called at this time, cpu2 may acquire the lock first, and then cpu3 acquires the lock. When cpu3 releases the lock, it checks if the tail is itself. Originally, it should be, but after zap_locks(), the tail is modified to 0. At this point, cpu3 thinks there are other contenders, it will first set the locked bit and then wait for the contender to set its next pointer. However, in reality, there are no other contenders, so cpu3 will hold the lock (locked bit is 1) and loop here, causing other CPUs that want to acquire the lock to be stuck. To fix this problem, the lock initialization in zap_locks() can be degraded to clear locked_pending and retain the tail, avoiding misjudgment. Fixes: be926ed0f034 ("printk/panic: Avoid deadlock in printk()") Signed-off-by: Li Huafei <lihuafei1(a)huawei.com> --- kernel/printk/printk.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c index 11ebe66c473a..532d1f9a194f 100644 --- a/kernel/printk/printk.c +++ b/kernel/printk/printk.c @@ -1634,11 +1634,21 @@ void zap_locks(void) { if (raw_spin_is_locked(&logbuf_lock)) { debug_locks_off(); +#ifdef CONFIG_QUEUED_SPINLOCKS + /* Do not clear the tail to avoid infinite loop in qspinlock. */ + WRITE_ONCE(logbuf_lock.raw_lock.locked_pending, 0); +#else raw_spin_lock_init(&logbuf_lock); +#endif } if (raw_spin_is_locked(&console_owner_lock)) { +#ifdef CONFIG_QUEUED_SPINLOCKS + /* Do not clear the tail to avoid infinite loop in qspinlock. */ + WRITE_ONCE(console_owner_lock.raw_lock.locked_pending, 0); +#else raw_spin_lock_init(&console_owner_lock); +#endif console_owner = NULL; console_waiter = false; } -- 2.25.1

2 1

[PATCH OLK-5.10 0/3] RDMA/hns: Some patches are integrated into OLK-5.10
by Chengchang Tang 26 Dec '24

26 Dec '24

From: Xinghai Cen <cenxinghai(a)h-partners.com> RDMA/hns: Some patches are integrated into OLK-5.10 Junxian Huang (2): RDMA/hns: Fix bonding failure due to wrong reset_state RDMA/hns: Don't query *except on hip10* wenglianfa (1): RDMA/hns: Fix creating GSI QP in non-extended SGE QP bank drivers/infiniband/hw/hns/hns_roce_bond.c | 9 ++++++--- drivers/infiniband/hw/hns/hns_roce_device.h | 2 +- drivers/infiniband/hw/hns/hns_roce_hw_v2.c | 16 ++++++---------- 3 files changed, 13 insertions(+), 14 deletions(-) -- 2.33.0

2 4

[openeuler:OLK-6.6 1662/1662] drivers/iommu/amd/iommu.c:69:30: sparse: sparse: symbol 'amd_dirty_ops' was not declared. Should it be static?
by kernel test robot 26 Dec '24

26 Dec '24

tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: 589aaab51b2a3b112b232f89fd29a5302222d946 commit: ebb4f9309c67ec7e9a872dbd5e7cacaaf78f4bf2 [1662/1662] iommu/amd: Access/Dirty bit support in IOPTEs config: x86_64-randconfig-123-20241226 (https://download.01.org/0day-ci/archive/20241226/202412261534.t0pLjUDz-lkp@…) compiler: clang version 19.1.3 (https://github.com/llvm/llvm-project ab51eccf88f5321e7c60591c5546b254b6afab99) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241226/202412261534.t0pLjUDz-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202412261534.t0pLjUDz-lkp@intel.com/ sparse warnings: (new ones prefixed by >>) >> drivers/iommu/amd/iommu.c:69:30: sparse: sparse: symbol 'amd_dirty_ops' was not declared. Should it be static? vim +/amd_dirty_ops +69 drivers/iommu/amd/iommu.c 67 68 const struct iommu_ops amd_iommu_ops; > 69 const struct iommu_dirty_ops amd_dirty_ops; 70 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

2025

2024

2023

2022

2021

2020

2019

Kernel December 2024