- Kernel - mailweb.openeuler.org

[PATCH OLK-5.10] media: v4l2-tpg: prevent the risk of a division by zero
by Zhao Yipeng 26 Dec '24

26 Dec '24

From: Mauro Carvalho Chehab <mchehab+huawei(a)kernel.org> stable inclusion from stable-v5.10.230 commit 054931ca3cfcb8e8fa036e887d6f379942b02565 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IB5ATB CVE: CVE-2024-50287 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=… -------------------------------- media: v4l2-tpg: prevent the risk of a division by zero commit e6a3ea83fbe15d4818d01804e904cbb0e64e543b upstream. As reported by Coverity, the logic at tpg_precalculate_line() blindly rescales the buffer even when scaled_witdh is equal to zero. If this ever happens, this will cause a division by zero. Instead, add a WARN_ON_ONCE() to trigger such cases and return without doing any precalculation. Fixes: 63881df94d3e ("[media] vivid: add the Test Pattern Generator") Cc: stable(a)vger.kernel.org Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zhao Yipeng <zhaoyipeng5(a)huawei.com> --- drivers/media/common/v4l2-tpg/v4l2-tpg-core.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c index 7607b516a7c4..e1128b819192 100644 --- a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c +++ b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c @@ -1757,6 +1757,9 @@ static void tpg_precalculate_line(struct tpg_data *tpg) unsigned p; unsigned x; + if (WARN_ON_ONCE(!tpg->src_width || !tpg->scaled_width)) + return; + switch (tpg->pattern) { case TPG_PAT_GREEN: contrast = TPG_COLOR_100_RED; -- 2.34.1

2 1

[PATCH OLK-5.10] x86/sgx: Fix deadlock in SGX NUMA node search
by Zhao Yipeng 26 Dec '24

26 Dec '24

From: Aaron Lu <aaron.lu(a)intel.com> mainline inclusion from mainline-v6.12-rc1 commit 9c936844010466535bd46ea4ce4656ef17653644 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAYQRL CVE: CVE-2024-49856 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- x86/sgx: Fix deadlock in SGX NUMA node search When the current node doesn't have an EPC section configured by firmware and all other EPC sections are used up, CPU can get stuck inside the while loop that looks for an available EPC page from remote nodes indefinitely, leading to a soft lockup. Note how nid_of_current will never be equal to nid in that while loop because nid_of_current is not set in sgx_numa_mask. Also worth mentioning is that it's perfectly fine for the firmware not to setup an EPC section on a node. While setting up an EPC section on each node can enhance performance, it is not a requirement for functionality. Rework the loop to start and end on *a* node that has SGX memory. This avoids the deadlock looking for the current SGX-lacking node to show up in the loop when it never will. Fixes: 901ddbb9ecf5 ("x86/sgx: Add a basic NUMA allocation scheme to sgx_alloc_epc_page()") Reported-by: "Molina Sabido, Gerardo" <gerardo.molina.sabido(a)intel.com> Signed-off-by: Aaron Lu <aaron.lu(a)intel.com> Signed-off-by: Dave Hansen <dave.hansen(a)linux.intel.com> Reviewed-by: Kai Huang <kai.huang(a)intel.com> Reviewed-by: Jarkko Sakkinen <jarkko(a)kernel.org> Acked-by: Dave Hansen <dave.hansen(a)linux.intel.com> Tested-by: Zhimin Luo <zhimin.luo(a)intel.com> Link: https://lore.kernel.org/all/20240905080855.1699814-2-aaron.lu%40intel.com Signed-off-by: Zhao Yipeng <zhaoyipeng5(a)huawei.com> --- arch/x86/kernel/cpu/sgx/main.c | 27 ++++++++++++++------------- 1 file changed, 14 insertions(+), 13 deletions(-) diff --git a/arch/x86/kernel/cpu/sgx/main.c b/arch/x86/kernel/cpu/sgx/main.c index 58f57fcff166..04884515cdae 100644 --- a/arch/x86/kernel/cpu/sgx/main.c +++ b/arch/x86/kernel/cpu/sgx/main.c @@ -474,24 +474,25 @@ struct sgx_epc_page *__sgx_alloc_epc_page(void) { struct sgx_epc_page *page; int nid_of_current = numa_node_id(); - int nid = nid_of_current; + int nid_start, nid; - if (node_isset(nid_of_current, sgx_numa_mask)) { - page = __sgx_alloc_epc_page_from_node(nid_of_current); - if (page) - return page; - } - - /* Fall back to the non-local NUMA nodes: */ - while (true) { - nid = next_node_in(nid, sgx_numa_mask); - if (nid == nid_of_current) - break; + /* + * Try local node first. If it doesn't have an EPC section, + * fall back to the non-local NUMA nodes. + */ + if (node_isset(nid_of_current, sgx_numa_mask)) + nid_start = nid_of_current; + else + nid_start = next_node_in(nid_of_current, sgx_numa_mask); + nid = nid_start; + do { page = __sgx_alloc_epc_page_from_node(nid); if (page) return page; - } + + nid = next_node_in(nid, sgx_numa_mask); + } while (nid != nid_start); return ERR_PTR(-ENOMEM); } -- 2.34.1

2 1

[openeuler:OLK-6.6 1662/1662] arch/x86/kernel/zhaoxin_kh40000.c:155:26: sparse: sparse: symbol 'kh40000_dma_direct_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: 9e7f01f21883b8c1e74302dbac8030cf2771b5ae commit: 11557c1ae4529f133483879b7ee00b7d8c653be7 [1662/1662] x86/cpu/zhaoxin: Encapsulate access to kh40000_dma_direct_ops within function config: x86_64-randconfig-123-20241226 (https://download.01.org/0day-ci/archive/20241226/202412261949.sqULJFrV-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/202412261949.sqULJFrV-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/202412261949.sqULJFrV-lkp@intel.com/ sparse warnings: (new ones prefixed by >>) arch/x86/kernel/zhaoxin_kh40000.c:33:15: sparse: sparse: symbol 'zhaoxin_patch_code' was not declared. Should it be static? >> arch/x86/kernel/zhaoxin_kh40000.c:155:26: sparse: sparse: symbol 'kh40000_dma_direct_ops' was not declared. Should it be static? arch/x86/kernel/zhaoxin_kh40000.c:325:26: sparse: sparse: symbol 'kh40000_dma_iommu_ops' was not declared. Should it be static? vim +/kh40000_dma_direct_ops +155 arch/x86/kernel/zhaoxin_kh40000.c 4332dbb0718135 leoliu-oc 2024-05-13 32 4332dbb0718135 leoliu-oc 2024-05-13 @33 unsigned long zhaoxin_patch_code = ZHAOXIN_PATCH_CODE_DEFAULT; 4332dbb0718135 leoliu-oc 2024-05-13 34 4332dbb0718135 leoliu-oc 2024-05-13 35 static int __init zhaoxin_patch_code_setup(char *str) 4332dbb0718135 leoliu-oc 2024-05-13 36 { 4332dbb0718135 leoliu-oc 2024-05-13 37 int err = kstrtoul(str, 0, &zhaoxin_patch_code); 4332dbb0718135 leoliu-oc 2024-05-13 38 4332dbb0718135 leoliu-oc 2024-05-13 39 if (err || (zhaoxin_patch_code > ZHAOXIN_PATCH_CODE_MAX)) { 4332dbb0718135 leoliu-oc 2024-05-13 40 pr_err("cmdline 'zhaoxin_patch_bitmask=%s' inappropriate\n", str); 4332dbb0718135 leoliu-oc 2024-05-13 41 zhaoxin_patch_code = ZHAOXIN_PATCH_CODE_DEFAULT; 4332dbb0718135 leoliu-oc 2024-05-13 42 return err; 4332dbb0718135 leoliu-oc 2024-05-13 43 } 4332dbb0718135 leoliu-oc 2024-05-13 44 a4738ea3785a75 leoliu-oc 2024-05-23 45 if (ZHAOXIN_P2CW_NODE_CHECK & zhaoxin_patch_code) 4332dbb0718135 leoliu-oc 2024-05-13 46 pr_info("zhaoxin dma patch node check is enabled\n"); 4332dbb0718135 leoliu-oc 2024-05-13 47 4332dbb0718135 leoliu-oc 2024-05-13 48 return 0; 4332dbb0718135 leoliu-oc 2024-05-13 49 } 4332dbb0718135 leoliu-oc 2024-05-13 50 __setup("zhaoxin_patch_bitmask=", zhaoxin_patch_code_setup); 4332dbb0718135 leoliu-oc 2024-05-13 51 4332dbb0718135 leoliu-oc 2024-05-13 52 static struct pci_dev *kh40000_get_pci_dev(struct device *dev) 4332dbb0718135 leoliu-oc 2024-05-13 53 { 4332dbb0718135 leoliu-oc 2024-05-13 54 if (dev_is_pci(dev)) 4332dbb0718135 leoliu-oc 2024-05-13 55 return to_pci_dev(dev); 4332dbb0718135 leoliu-oc 2024-05-13 56 4332dbb0718135 leoliu-oc 2024-05-13 57 if (dev->parent) 4332dbb0718135 leoliu-oc 2024-05-13 58 return kh40000_get_pci_dev(dev->parent); 4332dbb0718135 leoliu-oc 2024-05-13 59 4332dbb0718135 leoliu-oc 2024-05-13 60 return NULL; 4332dbb0718135 leoliu-oc 2024-05-13 61 } 4332dbb0718135 leoliu-oc 2024-05-13 62 4332dbb0718135 leoliu-oc 2024-05-13 63 static void kh40000_sync_single_dma_for_cpu(struct device *dev, dma_addr_t paddr, 4332dbb0718135 leoliu-oc 2024-05-13 64 enum dma_data_direction dir, bool is_iommu) 4332dbb0718135 leoliu-oc 2024-05-13 65 { 4332dbb0718135 leoliu-oc 2024-05-13 66 u8 vid; 4332dbb0718135 leoliu-oc 2024-05-13 67 struct pci_dev *pci; 4332dbb0718135 leoliu-oc 2024-05-13 68 u64 dma_mask = *dev->dma_mask; 4332dbb0718135 leoliu-oc 2024-05-13 69 4332dbb0718135 leoliu-oc 2024-05-13 70 /* check direction */ 4332dbb0718135 leoliu-oc 2024-05-13 71 if ((dir != DMA_FROM_DEVICE) && (dir != DMA_BIDIRECTIONAL)) 4332dbb0718135 leoliu-oc 2024-05-13 72 return; 4332dbb0718135 leoliu-oc 2024-05-13 73 4332dbb0718135 leoliu-oc 2024-05-13 74 /* check dma capability */ 4332dbb0718135 leoliu-oc 2024-05-13 75 if (dma_mask <= DMA_BIT_MASK(32)) 4332dbb0718135 leoliu-oc 2024-05-13 76 return; 4332dbb0718135 leoliu-oc 2024-05-13 77 4332dbb0718135 leoliu-oc 2024-05-13 78 /* check device type */ 4332dbb0718135 leoliu-oc 2024-05-13 79 pci = kh40000_get_pci_dev(dev); 4332dbb0718135 leoliu-oc 2024-05-13 80 if (pci == NULL) 4332dbb0718135 leoliu-oc 2024-05-13 81 return; 4332dbb0718135 leoliu-oc 2024-05-13 82 4332dbb0718135 leoliu-oc 2024-05-13 83 /* get real physical address */ 4332dbb0718135 leoliu-oc 2024-05-13 84 if (is_iommu) { 4332dbb0718135 leoliu-oc 2024-05-13 85 struct iommu_domain *domain = iommu_get_dma_domain(dev); 4332dbb0718135 leoliu-oc 2024-05-13 86 4332dbb0718135 leoliu-oc 2024-05-13 87 paddr = iommu_iova_to_phys(domain, paddr); 4332dbb0718135 leoliu-oc 2024-05-13 88 if (!paddr) 4332dbb0718135 leoliu-oc 2024-05-13 89 return; 4332dbb0718135 leoliu-oc 2024-05-13 90 } 4332dbb0718135 leoliu-oc 2024-05-13 91 4332dbb0718135 leoliu-oc 2024-05-13 92 /* check node or not */ 4332dbb0718135 leoliu-oc 2024-05-13 93 if ((zhaoxin_patch_code & ZHAOXIN_P2CW_NODE_CHECK) 4332dbb0718135 leoliu-oc 2024-05-13 94 && pfn_to_nid(PFN_DOWN(paddr)) == dev_to_node(dev)) 4332dbb0718135 leoliu-oc 2024-05-13 95 return; 4332dbb0718135 leoliu-oc 2024-05-13 96 4332dbb0718135 leoliu-oc 2024-05-13 97 /* flush data by one pci read cycle */ 4332dbb0718135 leoliu-oc 2024-05-13 98 pci_read_config_byte(pci, PCI_VENDOR_ID, &vid); 4332dbb0718135 leoliu-oc 2024-05-13 99 } 4332dbb0718135 leoliu-oc 2024-05-13 100 4332dbb0718135 leoliu-oc 2024-05-13 101 /* zhaoxin kh-40000 direct dma ops */ 4332dbb0718135 leoliu-oc 2024-05-13 102 static void *kh40000_dma_direct_alloc(struct device *dev, size_t size, 4332dbb0718135 leoliu-oc 2024-05-13 103 dma_addr_t *addr, gfp_t gfp, unsigned long attrs) 4332dbb0718135 leoliu-oc 2024-05-13 104 { 4332dbb0718135 leoliu-oc 2024-05-13 105 if (dev->coherent_dma_mask > DMA_BIT_MASK(32)) 4332dbb0718135 leoliu-oc 2024-05-13 106 gfp |= __GFP_THISNODE; 4332dbb0718135 leoliu-oc 2024-05-13 107 4332dbb0718135 leoliu-oc 2024-05-13 108 return dma_direct_alloc(dev, size, addr, gfp, attrs); 4332dbb0718135 leoliu-oc 2024-05-13 109 } 4332dbb0718135 leoliu-oc 2024-05-13 110 4332dbb0718135 leoliu-oc 2024-05-13 111 static void kh40000_dma_direct_unmap_page(struct device *dev, dma_addr_t addr, 4332dbb0718135 leoliu-oc 2024-05-13 112 size_t size, enum dma_data_direction dir, unsigned long attrs) 4332dbb0718135 leoliu-oc 2024-05-13 113 { 4332dbb0718135 leoliu-oc 2024-05-13 114 kh40000_sync_single_dma_for_cpu(dev, addr, dir, 0); 4332dbb0718135 leoliu-oc 2024-05-13 115 dma_direct_unmap_page(dev, addr, size, dir, attrs); 4332dbb0718135 leoliu-oc 2024-05-13 116 } 4332dbb0718135 leoliu-oc 2024-05-13 117 4332dbb0718135 leoliu-oc 2024-05-13 118 static void kh40000_dma_direct_sync_sg_for_cpu(struct device *dev, 4332dbb0718135 leoliu-oc 2024-05-13 119 struct scatterlist *sgl, int nents, enum dma_data_direction dir) 4332dbb0718135 leoliu-oc 2024-05-13 120 { 4332dbb0718135 leoliu-oc 2024-05-13 121 struct scatterlist *sg; 4332dbb0718135 leoliu-oc 2024-05-13 122 int i; 4332dbb0718135 leoliu-oc 2024-05-13 123 4332dbb0718135 leoliu-oc 2024-05-13 124 for_each_sg(sgl, sg, nents, i) 4332dbb0718135 leoliu-oc 2024-05-13 125 kh40000_sync_single_dma_for_cpu(dev, sg_dma_address(sg), dir, 0); 4332dbb0718135 leoliu-oc 2024-05-13 126 4332dbb0718135 leoliu-oc 2024-05-13 127 dma_direct_sync_sg_for_cpu(dev, sgl, nents, dir); 4332dbb0718135 leoliu-oc 2024-05-13 128 } 4332dbb0718135 leoliu-oc 2024-05-13 129 4332dbb0718135 leoliu-oc 2024-05-13 130 static void kh40000_dma_direct_sync_single_for_cpu(struct device *dev, 4332dbb0718135 leoliu-oc 2024-05-13 131 dma_addr_t addr, size_t size, enum dma_data_direction dir) 4332dbb0718135 leoliu-oc 2024-05-13 132 { 4332dbb0718135 leoliu-oc 2024-05-13 133 kh40000_sync_single_dma_for_cpu(dev, addr, dir, 0); 4332dbb0718135 leoliu-oc 2024-05-13 134 dma_direct_sync_single_for_cpu(dev, addr, size, dir); 4332dbb0718135 leoliu-oc 2024-05-13 135 } 4332dbb0718135 leoliu-oc 2024-05-13 136 4332dbb0718135 leoliu-oc 2024-05-13 137 static void kh40000_dma_direct_unmap_sg(struct device *dev, struct scatterlist *sgl, 4332dbb0718135 leoliu-oc 2024-05-13 138 int nents, enum dma_data_direction dir, unsigned long attrs) 4332dbb0718135 leoliu-oc 2024-05-13 139 { 4332dbb0718135 leoliu-oc 2024-05-13 140 struct scatterlist *sg; 4332dbb0718135 leoliu-oc 2024-05-13 141 int i; 4332dbb0718135 leoliu-oc 2024-05-13 142 4332dbb0718135 leoliu-oc 2024-05-13 143 for_each_sg(sgl, sg, nents, i) 4332dbb0718135 leoliu-oc 2024-05-13 144 kh40000_sync_single_dma_for_cpu(dev, sg_dma_address(sg), dir, 0); 4332dbb0718135 leoliu-oc 2024-05-13 145 4332dbb0718135 leoliu-oc 2024-05-13 146 dma_direct_unmap_sg(dev, sgl, nents, dir, attrs); 4332dbb0718135 leoliu-oc 2024-05-13 147 } 4332dbb0718135 leoliu-oc 2024-05-13 148 4332dbb0718135 leoliu-oc 2024-05-13 149 static void kh40000_dma_direct_unmap_resource(struct device *dev, dma_addr_t addr, 4332dbb0718135 leoliu-oc 2024-05-13 150 size_t size, enum dma_data_direction dir, unsigned long attrs) 4332dbb0718135 leoliu-oc 2024-05-13 151 { 4332dbb0718135 leoliu-oc 2024-05-13 152 kh40000_sync_single_dma_for_cpu(dev, addr, dir, 0); 4332dbb0718135 leoliu-oc 2024-05-13 153 } 4332dbb0718135 leoliu-oc 2024-05-13 154 4332dbb0718135 leoliu-oc 2024-05-13 @155 const struct dma_map_ops kh40000_dma_direct_ops = { 4332dbb0718135 leoliu-oc 2024-05-13 156 .flags = DMA_F_PCI_P2PDMA_SUPPORTED, 4332dbb0718135 leoliu-oc 2024-05-13 157 .alloc = kh40000_dma_direct_alloc, 4332dbb0718135 leoliu-oc 2024-05-13 158 .sync_sg_for_cpu = kh40000_dma_direct_sync_sg_for_cpu, 4332dbb0718135 leoliu-oc 2024-05-13 159 .unmap_page = kh40000_dma_direct_unmap_page, 4332dbb0718135 leoliu-oc 2024-05-13 160 .sync_single_for_cpu = kh40000_dma_direct_sync_single_for_cpu, 4332dbb0718135 leoliu-oc 2024-05-13 161 .unmap_sg = kh40000_dma_direct_unmap_sg, 4332dbb0718135 leoliu-oc 2024-05-13 162 .unmap_resource = kh40000_dma_direct_unmap_resource, 4332dbb0718135 leoliu-oc 2024-05-13 163 .dma_supported = dma_direct_supported, 4332dbb0718135 leoliu-oc 2024-05-13 164 .free = dma_direct_free, 4332dbb0718135 leoliu-oc 2024-05-13 165 .alloc_pages = dma_direct_alloc_pages, 4332dbb0718135 leoliu-oc 2024-05-13 166 .free_pages = dma_direct_free_pages, 4332dbb0718135 leoliu-oc 2024-05-13 167 .sync_single_for_device = dma_direct_sync_single_for_device, 4332dbb0718135 leoliu-oc 2024-05-13 168 .sync_sg_for_device = dma_direct_sync_sg_for_device, 4332dbb0718135 leoliu-oc 2024-05-13 169 .get_required_mask = dma_direct_get_required_mask, 4332dbb0718135 leoliu-oc 2024-05-13 170 .max_mapping_size = dma_direct_max_mapping_size, 4332dbb0718135 leoliu-oc 2024-05-13 171 .mmap = dma_direct_mmap, 4332dbb0718135 leoliu-oc 2024-05-13 172 .get_sgtable = dma_direct_get_sgtable, 4332dbb0718135 leoliu-oc 2024-05-13 173 .map_page = dma_direct_map_page, 4332dbb0718135 leoliu-oc 2024-05-13 174 .map_sg = dma_direct_map_sg, 4332dbb0718135 leoliu-oc 2024-05-13 175 .map_resource = dma_direct_map_resource, 4332dbb0718135 leoliu-oc 2024-05-13 176 }; ef20808db09987 leoliu-oc 2024-03-22 177 :::::: The code at line 155 was first introduced by commit :::::: 4332dbb07181359cccca3ba757ef54e434fb1296 Add kh40000_direct_dma_ops for KH-40000 platform :::::: TO: leoliu-oc <leoliu-oc(a)zhaoxin.com> :::::: CC: leoliu-oc <leoliu-oc(a)zhaoxin.com> -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[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

2025

2024

2023

2022

2021

2020

2019

Kernel