- Kernel - mailweb.openeuler.org

[PATCH OLK-6.6] printk: Disable passing console lock owner completely during panic()
by Ye Weihua 30 Apr '24

30 Apr '24

From: Petr Mladek <pmladek(a)suse.com> stable inclusion from stable-v6.6.23 commit a3b17859c818a4a9a861e8ec0b9c01d28c0770d2 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9KZP4 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit d04d5882cd678b898a9d7c5aee6afbe9e6e77fcd ] The commit d51507098ff91 ("printk: disable optimistic spin during panic") added checks to avoid becoming a console waiter if a panic is in progress. However, the transition to panic can occur while there is already a waiter. The current owner should not pass the lock to the waiter because it might get stopped or blocked anytime. Also the panic context might pass the console lock owner to an already stopped waiter by mistake. It might happen when console_flush_on_panic() ignores the current lock owner, for example: CPU0 CPU1 ---- ---- console_lock_spinning_enable() console_trylock_spinning() [CPU1 now console waiter] NMI: panic() panic_other_cpus_shutdown() [stopped as console waiter] console_flush_on_panic() console_lock_spinning_enable() [print 1 record] console_lock_spinning_disable_and_check() [handover to stopped CPU1] This results in panic() not flushing the panic messages. Fix these problems by disabling all spinning operations completely during panic(). Another advantage is that it prevents possible deadlocks caused by "console_owner_lock". The panic() context does not need to take it any longer. The lockless checks are safe because the functions become NOPs when they see the panic in progress. All operations manipulating the state are still synchronized by the lock even when non-panic CPUs would notice the panic synchronously. The current owner might stay spinning. But non-panic() CPUs would get stopped anyway and the panic context will never start spinning. Fixes: dbdda842fe96 ("printk: Add console owner and waiter logic to load balance console writes") Signed-off-by: John Ogness <john.ogness(a)linutronix.de> Link: https://lore.kernel.org/r/20240207134103.1357162-12-john.ogness@linutronix.… Signed-off-by: Petr Mladek <pmladek(a)suse.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Ye Weihua <yeweihua4(a)huawei.com> --- kernel/printk/printk.c | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c index 8bccea05df1b..6ebcf40241fd 100644 --- a/kernel/printk/printk.c +++ b/kernel/printk/printk.c @@ -1850,10 +1850,23 @@ static bool console_waiter; */ static void console_lock_spinning_enable(void) { + /* + * Do not use spinning in panic(). The panic CPU wants to keep the lock. + * Non-panic CPUs abandon the flush anyway. + * + * Just keep the lockdep annotation. The panic-CPU should avoid + * taking console_owner_lock because it might cause a deadlock. + * This looks like the easiest way how to prevent false lockdep + * reports without handling races a lockless way. + */ + if (panic_in_progress()) + goto lockdep; + raw_spin_lock(&console_owner_lock); console_owner = current; raw_spin_unlock(&console_owner_lock); +lockdep: /* The waiter may spin on us after setting console_owner */ spin_acquire(&console_owner_dep_map, 0, 0, _THIS_IP_); } @@ -1878,6 +1891,22 @@ static int console_lock_spinning_disable_and_check(int cookie) { int waiter; + /* + * Ignore spinning waiters during panic() because they might get stopped + * or blocked at any time, + * + * It is safe because nobody is allowed to start spinning during panic + * in the first place. If there has been a waiter then non panic CPUs + * might stay spinning. They would get stopped anyway. The panic context + * will never start spinning and an interrupted spin on panic CPU will + * never continue. + */ + if (panic_in_progress()) { + /* Keep lockdep happy. */ + spin_release(&console_owner_dep_map, _THIS_IP_); + return 0; + } + raw_spin_lock(&console_owner_lock); waiter = READ_ONCE(console_waiter); console_owner = NULL; -- 2.34.1

2 1

[openeuler:OLK-6.6 7192/7643] mm/page_alloc.c:4110:9: error: call to undeclared function 'dynamic_pool_should_alloc'; ISO C99 and later do not support implicit function declarations
by kernel test robot 30 Apr '24

30 Apr '24

tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: 3fd472966bcc21f40dc20bb47c7ad18392fbec05 commit: fd855715f24e3eeadaa56de5fde21c55a14aeea0 [7192/7643] mm/mem_reliable: Fallback to dpool if reliable memory is not enough config: arm64-randconfig-r053-20240430 (https://download.01.org/0day-ci/archive/20240430/202404301532.nTD4ftcZ-lkp@…) compiler: clang version 19.0.0git (https://github.com/llvm/llvm-project 37ae4ad0eef338776c7e2cffb3896153d43dcd90) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240430/202404301532.nTD4ftcZ-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/202404301532.nTD4ftcZ-lkp@intel.com/ All errors (new ones prefixed by >>): In file included from mm/page_alloc.c:19: In file included from include/linux/mm.h:2204: include/linux/vmstat.h:522:36: warning: arithmetic between different enumeration types ('enum node_stat_item' and 'enum lru_list') [-Wenum-enum-conversion] 522 | return node_stat_name(NR_LRU_BASE + lru) + 3; // skip "nr_" | ~~~~~~~~~~~ ^ ~~~ In file included from mm/page_alloc.c:43: include/linux/mm_inline.h:47:41: warning: arithmetic between different enumeration types ('enum node_stat_item' and 'enum lru_list') [-Wenum-enum-conversion] 47 | __mod_lruvec_state(lruvec, NR_LRU_BASE + lru, nr_pages); | ~~~~~~~~~~~ ^ ~~~ include/linux/mm_inline.h:49:22: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum lru_list') [-Wenum-enum-conversion] 49 | NR_ZONE_LRU_BASE + lru, nr_pages); | ~~~~~~~~~~~~~~~~ ^ ~~~ mm/page_alloc.c:2769:2: warning: arithmetic between different enumeration types ('enum vm_event_item' and 'enum zone_type') [-Wenum-enum-conversion] 2769 | __count_zid_vm_events(PGALLOC, page_zonenum(page), 1 << order); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ include/linux/vmstat.h:135:34: note: expanded from macro '__count_zid_vm_events' 135 | __count_vm_events(item##_NORMAL - ZONE_NORMAL + zid, delta) | ~~~~~~~~~~~~~ ^ ~~~~~~~~~~~ mm/page_alloc.c:2886:3: warning: arithmetic between different enumeration types ('enum vm_event_item' and 'enum zone_type') [-Wenum-enum-conversion] 2886 | __count_zid_vm_events(PGALLOC, page_zonenum(page), 1 << order); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ include/linux/vmstat.h:135:34: note: expanded from macro '__count_zid_vm_events' 135 | __count_vm_events(item##_NORMAL - ZONE_NORMAL + zid, delta) | ~~~~~~~~~~~~~ ^ ~~~~~~~~~~~ >> mm/page_alloc.c:4110:9: error: call to undeclared function 'dynamic_pool_should_alloc'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 4110 | return dynamic_pool_should_alloc(gfp_mask & ~GFP_RELIABLE, order); | ^ mm/page_alloc.c:4596:2: warning: arithmetic between different enumeration types ('enum vm_event_item' and 'enum zone_type') [-Wenum-enum-conversion] 4596 | __count_zid_vm_events(PGALLOC, zone_idx(zone), nr_account); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ include/linux/vmstat.h:135:34: note: expanded from macro '__count_zid_vm_events' 135 | __count_vm_events(item##_NORMAL - ZONE_NORMAL + zid, delta) | ~~~~~~~~~~~~~ ^ ~~~~~~~~~~~ 6 warnings and 1 error generated. vim +/dynamic_pool_should_alloc +4110 mm/page_alloc.c 4101 4102 static inline bool mem_reliable_fallback_dpool(gfp_t gfp_mask, unsigned int order) 4103 { 4104 if (!reliable_allow_fb_enabled()) 4105 return false; 4106 4107 if (!(gfp_mask & GFP_RELIABLE)) 4108 return false; 4109 > 4110 return dynamic_pool_should_alloc(gfp_mask & ~GFP_RELIABLE, order); 4111 } 4112 #else 4113 static inline struct zone *mem_reliable_fallback_zone(gfp_t gfp_mask, 4114 struct alloc_context *ac) 4115 { 4116 return NULL; 4117 } 4118 static inline void mem_reliable_fallback_slowpath(gfp_t gfp_mask, 4119 struct alloc_context *ac) {} 4120 static inline bool mem_reliable_fallback_dpool(gfp_t gfp_mask, unsigned int order) 4121 { 4122 return false; 4123 } 4124 #endif 4125 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH openEuler-1.0-LTS] tun: Fix xdp_rxq_info's queue_index when detaching
by Dong Chenchen 30 Apr '24

30 Apr '24

From: Yunjian Wang <wangyunjian(a)huawei.com> stable inclusion from stable-v4.19.309 commit 32793f71f212db99560816a0916ff060e46dfc6f category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9GV9R CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 2a770cdc4382b457ca3d43d03f0f0064f905a0d0 ] When a queue(tfile) is detached, we only update tfile's queue_index, but do not update xdp_rxq_info's queue_index. This patch fixes it. Fixes: 8bf5c4ee1889 ("tun: setup xdp_rxq_info") Signed-off-by: Yunjian Wang <wangyunjian(a)huawei.com> Link: https://lore.kernel.org/r/1708398727-46308-1-git-send-email-wangyunjian@hua… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> --- drivers/net/tun.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/tun.c b/drivers/net/tun.c index e9b8a68b350a..08bfde8280c7 100644 --- a/drivers/net/tun.c +++ b/drivers/net/tun.c @@ -721,6 +721,7 @@ static void __tun_detach(struct tun_file *tfile, bool clean) tun->tfiles[tun->numqueues - 1]); ntfile = rtnl_dereference(tun->tfiles[index]); ntfile->queue_index = index; + ntfile->xdp_rxq.queue_index = index; rcu_assign_pointer(tun->tfiles[tun->numqueues - 1], NULL); -- 2.25.1

2 1

[PATCH OLK-5.10] scsi: lpfc: Fix possible memory leak in lpfc_rcv_padisc()
by Baogen Shang 30 Apr '24

30 Apr '24

From: Justin Tee <justin.tee(a)broadcom.com> stable inclusion from stable-v5.10.215 commit c473288f27d15014447de5a891bdf22a0695847a category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9J6AL CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=… ------------------------- [ Upstream commit 2ae917d4bcab80ab304b774d492e2fcd6c52c06b ] The call to lpfc_sli4_resume_rpi() in lpfc_rcv_padisc() may return an unsuccessful status. In such cases, the elsiocb is not issued, the completion is not called, and thus the elsiocb resource is leaked. Check return value after calling lpfc_sli4_resume_rpi() and conditionally release the elsiocb resource. Signed-off-by: Justin Tee <justin.tee(a)broadcom.com> Link: https://lore.kernel.org/r/20240131185112.149731-3-justintee8345@gmail.com Reviewed-by: Himanshu Madhani <himanshu.madhani(a)oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Baogen Shang <baogen.shang(a)windriver.com> --- drivers/scsi/lpfc/lpfc_nportdisc.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/lpfc/lpfc_nportdisc.c b/drivers/scsi/lpfc/lpfc_nportdisc.c index 1e22364a31fc..d6287c58d504 100644 --- a/drivers/scsi/lpfc/lpfc_nportdisc.c +++ b/drivers/scsi/lpfc/lpfc_nportdisc.c @@ -784,8 +784,10 @@ lpfc_rcv_padisc(struct lpfc_vport *vport, struct lpfc_nodelist *ndlp, /* Save the ELS cmd */ elsiocb->drvrTimeout = cmd; - lpfc_sli4_resume_rpi(ndlp, - lpfc_mbx_cmpl_resume_rpi, elsiocb); + if (lpfc_sli4_resume_rpi(ndlp, + lpfc_mbx_cmpl_resume_rpi, + elsiocb)) + kfree(elsiocb); goto out; } } -- 2.33.0

1 0

[PATCH OLK-5.10] scsi: lpfc: Fix possible file string name overflow when updating firmware
by Baogen Shang 30 Apr '24

30 Apr '24

From: Justin Tee <justin.tee(a)broadcom.com> stable inclusion from stable-v5.10.215 commit 9bc7617a0d46f5c9e070cb93b08f8036c86aaaa1 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9J6AL CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=… ------------------------- [ Upstream commit f5779b529240b715f0e358489ad0ed933bf77c97 ] Because file_name and phba->ModelName are both declared a size 80 bytes, the extra ".grp" file extension could cause an overflow into file_name. Define a ELX_FW_NAME_SIZE macro with value 84. 84 incorporates the 4 extra characters from ".grp". file_name is changed to be declared as a char and initialized to zeros i.e. null chars. Signed-off-by: Justin Tee <justin.tee(a)broadcom.com> Link: https://lore.kernel.org/r/20231031191224.150862-3-justintee8345@gmail.com Reviewed-by: Himanshu Madhani <himanshu.madhani(a)oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Baogen Shang <baogen.shang(a)windriver.com> --- drivers/scsi/lpfc/lpfc.h | 1 + drivers/scsi/lpfc/lpfc_init.c | 4 ++-- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/lpfc/lpfc.h b/drivers/scsi/lpfc/lpfc.h index 03bc472f302a..cf69f831a725 100644 --- a/drivers/scsi/lpfc/lpfc.h +++ b/drivers/scsi/lpfc/lpfc.h @@ -32,6 +32,7 @@ struct lpfc_sli2_slim; #define ELX_MODEL_NAME_SIZE 80 +#define ELX_FW_NAME_SIZE 84 #define LPFC_PCI_DEV_LP 0x1 #define LPFC_PCI_DEV_OC 0x2 diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c index 1bb3c96a04bd..5f2009327a59 100644 --- a/drivers/scsi/lpfc/lpfc_init.c +++ b/drivers/scsi/lpfc/lpfc_init.c @@ -13026,7 +13026,7 @@ lpfc_write_firmware(const struct firmware *fw, void *context) int lpfc_sli4_request_firmware_update(struct lpfc_hba *phba, uint8_t fw_upgrade) { - uint8_t file_name[ELX_MODEL_NAME_SIZE]; + char file_name[ELX_FW_NAME_SIZE] = {0}; int ret; const struct firmware *fw; @@ -13035,7 +13035,7 @@ lpfc_sli4_request_firmware_update(struct lpfc_hba *phba, uint8_t fw_upgrade) LPFC_SLI_INTF_IF_TYPE_2) return -EPERM; - snprintf(file_name, ELX_MODEL_NAME_SIZE, "%s.grp", phba->ModelName); + scnprintf(file_name, sizeof(file_name), "%s.grp", phba->ModelName); if (fw_upgrade == INT_FW_UPGRADE) { ret = request_firmware_nowait(THIS_MODULE, FW_ACTION_HOTPLUG, -- 2.33.0

1 0

[openeuler:OLK-6.6 6858/7643] drivers/char/ipmi/ipmi_bt_sm.c:194:11: error: call to undeclared function 'acpi_evaluate_integer'; ISO C99 and later do not support implicit function declarations
by kernel test robot 30 Apr '24

30 Apr '24

tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: 3fd472966bcc21f40dc20bb47c7ad18392fbec05 commit: 6449ff7a5a2b148bc0a60efb3f0d723aaeceaae6 [6858/7643] ipmi: Errata workaround to prevent SMS message processing timeout config: arm64-randconfig-r053-20240430 (https://download.01.org/0day-ci/archive/20240430/202404301314.Y3h2lmDN-lkp@…) compiler: clang version 19.0.0git (https://github.com/llvm/llvm-project 37ae4ad0eef338776c7e2cffb3896153d43dcd90) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240430/202404301314.Y3h2lmDN-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/202404301314.Y3h2lmDN-lkp@intel.com/ All errors (new ones prefixed by >>): >> drivers/char/ipmi/ipmi_bt_sm.c:194:11: error: call to undeclared function 'acpi_evaluate_integer'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 194 | status = acpi_evaluate_integer(handle, "SATN", NULL, &tmp); | ^ drivers/char/ipmi/ipmi_bt_sm.c:194:11: note: did you mean 'acpi_evaluate_object'? include/acpi/acpixf.h:550:8: note: 'acpi_evaluate_object' declared here 550 | acpi_evaluate_object(acpi_handle object, | ^ include/acpi/platform/aclinux.h:93:21: note: expanded from macro 'ACPI_EXTERNAL_RETURN_STATUS' 93 | static ACPI_INLINE prototype {return(AE_NOT_CONFIGURED);} | ^ 1 error generated. vim +/acpi_evaluate_integer +194 drivers/char/ipmi/ipmi_bt_sm.c 177 178 #ifdef CONFIG_HISILICON_ERRATUM_162102203 179 /* 180 * To confirm whether the SMS_ATN flag needs to be stored and get 181 * quirk through the method reported by the BIOS. Because in special 182 * cases SMS_ATN flag bits may be lost before being processed. 183 */ 184 static bool get_sms_atn_quirk(struct si_sm_io *io) 185 { 186 acpi_handle handle; 187 acpi_status status; 188 unsigned long long tmp; 189 190 handle = ACPI_HANDLE(io->dev); 191 if (!handle) 192 return false; 193 > 194 status = acpi_evaluate_integer(handle, "SATN", NULL, &tmp); 195 if (ACPI_FAILURE(status)) 196 return false; 197 else if (tmp != 1) 198 return false; 199 200 return true; 201 } 202 #endif 203 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:openEuler-1.0-LTS 21355/22260] drivers/gpio/gpio-phytium-platform.c:111:2-3: Unneeded semicolon
by kernel test robot 30 Apr '24

30 Apr '24

tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: 534530510857129d59e723e50cc93349b4a59fb2 commit: 00711bad7e372a30c4975ba43811ffa666aff0e1 [21355/22260] gpio: add phytium gpio driver config: arm64-randconfig-r054-20240430 (https://download.01.org/0day-ci/archive/20240430/202404301203.LIsGwT62-lkp@…) compiler: aarch64-linux-gcc (GCC) 13.2.0 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/202404301203.LIsGwT62-lkp@intel.com/ cocci warnings: (new ones prefixed by >>) >> drivers/gpio/gpio-phytium-platform.c:111:2-3: Unneeded semicolon vim +111 drivers/gpio/gpio-phytium-platform.c 35 36 static int phytium_gpio_probe(struct platform_device *pdev) 37 { 38 struct device *dev = &pdev->dev; 39 struct resource *res; 40 struct phytium_gpio *gpio; 41 struct gpio_irq_chip *girq; 42 struct fwnode_handle *fwnode; 43 int err, irq_count; 44 45 gpio = devm_kzalloc(&pdev->dev, sizeof(*gpio), GFP_KERNEL); 46 if (!gpio) 47 return -ENOMEM; 48 49 res = platform_get_resource(pdev, IORESOURCE_MEM, 0); 50 gpio->regs = devm_ioremap_resource(&pdev->dev, res); 51 if (IS_ERR(gpio->regs)) 52 return PTR_ERR(gpio->regs); 53 54 if (!device_get_child_node_count(dev)) 55 return -ENODEV; 56 57 device_for_each_child_node(dev, fwnode) { 58 int idx; 59 60 if (fwnode_property_read_u32(fwnode, "reg", &idx) || 61 idx >= MAX_NPORTS) { 62 dev_err(dev, "missing/invalid port index\n"); 63 fwnode_handle_put(fwnode); 64 return -EINVAL; 65 } 66 67 if (fwnode_property_read_u32(fwnode, "nr-gpios", 68 &gpio->ngpio[idx])) { 69 dev_info(dev, 70 "failed to get number of gpios for Port%c\n", 71 idx ? 'B' : 'A'); 72 gpio->ngpio[idx] = NGPIO_DEFAULT; 73 } 74 } 75 76 /* irq_chip support */ 77 gpio->irq_chip.name = dev_name(dev); 78 gpio->irq_chip.irq_ack = phytium_gpio_irq_ack; 79 gpio->irq_chip.irq_mask = phytium_gpio_irq_mask; 80 gpio->irq_chip.irq_unmask = phytium_gpio_irq_unmask; 81 gpio->irq_chip.irq_set_type = phytium_gpio_irq_set_type; 82 gpio->irq_chip.irq_enable = phytium_gpio_irq_enable; 83 gpio->irq_chip.irq_disable = phytium_gpio_irq_disable; 84 #ifdef CONFIG_SMP 85 gpio->irq_chip.irq_set_affinity = phytium_gpio_irq_set_affinity; 86 #endif 87 raw_spin_lock_init(&gpio->lock); 88 89 gpio->gc.base = -1; 90 gpio->gc.get_direction = phytium_gpio_get_direction; 91 gpio->gc.direction_input = phytium_gpio_direction_input; 92 gpio->gc.direction_output = phytium_gpio_direction_output; 93 gpio->gc.get = phytium_gpio_get; 94 gpio->gc.set = phytium_gpio_set; 95 gpio->gc.ngpio = gpio->ngpio[0] + gpio->ngpio[1]; 96 gpio->gc.label = dev_name(dev); 97 gpio->gc.parent = dev; 98 gpio->gc.owner = THIS_MODULE; 99 100 girq = &gpio->gc.irq; 101 girq->handler = handle_bad_irq; 102 girq->default_type = IRQ_TYPE_NONE; 103 104 for (irq_count = 0; irq_count < gpio->ngpio[0]; irq_count++) { 105 gpio->irq[irq_count] = -ENXIO; 106 gpio->irq[irq_count] = platform_get_irq(pdev, irq_count); 107 if (gpio->irq[irq_count] < 0) { 108 dev_warn(dev, "no irq is found.\n"); 109 break; 110 } > 111 }; 112 113 girq->num_parents = irq_count; 114 girq->parents = gpio->irq; 115 girq->parent_handler = phytium_gpio_irq_handler; 116 117 girq->chip = &gpio->irq_chip; 118 119 err = devm_gpiochip_add_data(dev, &gpio->gc, gpio); 120 if (err) 121 return err; 122 123 platform_set_drvdata(pdev, gpio); 124 dev_info(dev, "Phytium GPIO controller @%pa registered\n", 125 &res->start); 126 127 return 0; 128 } 129 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-5.10] [Huawei] ima: Fix suspicious RCU usage
by GUO Zihua 30 Apr '24

30 Apr '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9KUX7 -------------------------------- Fixed "WARNING: suspicious RCU usage" warning on ima_update_policy_flag. Fixes: bccda6c35b52 ("ima: fix deadlock when traversing \"ima_default_rules\".") Signed-off-by: GUO Zihua <guozihua(a)huawei.com> --- security/integrity/ima/ima_policy.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/security/integrity/ima/ima_policy.c b/security/integrity/ima/ima_policy.c index a9dbfc7143b3..43a5c4754a66 100644 --- a/security/integrity/ima/ima_policy.c +++ b/security/integrity/ima/ima_policy.c @@ -759,11 +759,13 @@ void ima_update_policy_flag(void) struct ima_rule_entry *entry; struct list_head *ima_rules_tmp; + rcu_read_lock(); ima_rules_tmp = rcu_dereference(ima_rules); list_for_each_entry_rcu(entry, ima_rules_tmp, list) { if (entry->action & IMA_DO_MASK) ima_policy_flag |= entry->action; } + rcu_read_unlock(); ima_appraise |= (build_ima_appraise | temp_ima_appraise); if (!ima_appraise) -- 2.34.1

2 1

[PATCH OLK-5.10] [Huawei] ima: Fix suspicious RCU usage
by GUO Zihua 30 Apr '24

30 Apr '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9KUX7 -------------------------------- Fixed "WARNING: suspicious RCU usage" warning on ima_update_policy_flag. Fixes: bccda6c35b52 ("ima: fix deadlock when traversing \"ima_default_rules\".") Signed-off-by: GUO Zihua <guozihua(a)huawei.com> --- security/integrity/ima/ima_policy.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/security/integrity/ima/ima_policy.c b/security/integrity/ima/ima_policy.c index a9dbfc7143b3..43a5c4754a66 100644 --- a/security/integrity/ima/ima_policy.c +++ b/security/integrity/ima/ima_policy.c @@ -759,11 +759,13 @@ void ima_update_policy_flag(void) struct ima_rule_entry *entry; struct list_head *ima_rules_tmp; + rcu_read_lock(); ima_rules_tmp = rcu_dereference(ima_rules); list_for_each_entry_rcu(entry, ima_rules_tmp, list) { if (entry->action & IMA_DO_MASK) ima_policy_flag |= entry->action; } + rcu_read_unlock(); ima_appraise |= (build_ima_appraise | temp_ima_appraise); if (!ima_appraise) -- 2.34.1

2 1

[PATCH OLK-6.6] media: dvb-usb: Fix unexpected infinite loop in dvb_usb_read_remote_control()
by Zheng Yejian 30 Apr '24

30 Apr '24

maillist inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9KUFO Reference: https://lore.kernel.org/all/20240412135256.1546051-1-zhengyejian1@huawei.co… -------------------------------- Infinite log printing occurs during fuzz test: rc rc1: DViCO FusionHDTV DVB-T USB (LGZ201) as ... ... dvb-usb: schedule remote query interval to 100 msecs. dvb-usb: DViCO FusionHDTV DVB-T USB (LGZ201) successfully initialized ... dvb-usb: bulk message failed: -22 (1/0) dvb-usb: bulk message failed: -22 (1/0) dvb-usb: bulk message failed: -22 (1/0) ... dvb-usb: bulk message failed: -22 (1/0) Looking into the codes, there is a loop in dvb_usb_read_remote_control(), that is in rc_core_dvb_usb_remote_init() create a work that will call dvb_usb_read_remote_control(), and this work will reschedule itself at 'rc_interval' intervals to recursively call dvb_usb_read_remote_control(), see following code snippet: rc_core_dvb_usb_remote_init() { ... INIT_DELAYED_WORK(&d->rc_query_work, dvb_usb_read_remote_control); schedule_delayed_work(&d->rc_query_work, msecs_to_jiffies(rc_interval)); ... } dvb_usb_read_remote_control() { ... err = d->props.rc.core.rc_query(d); if (err) err(...) // Did not return even if query failed schedule_delayed_work(&d->rc_query_work, msecs_to_jiffies(rc_interval)); } When the infinite log printing occurs, the query callback 'd->props.rc.core.rc_query' is cxusb_rc_query(). And the log is due to the failure of finding a valid 'generic_bulk_ctrl_endpoint' in usb_bulk_msg(), see following code snippet: cxusb_rc_query() { cxusb_ctrl_msg() { dvb_usb_generic_rw() { ret = usb_bulk_msg(d->udev, usb_sndbulkpipe(d->udev, d->props.generic_bulk_ctrl_endpoint),...); if (ret) err("bulk message failed: %d (%d/%d)",ret,wlen,actlen); ... } ... } By analyzing the corresponding USB descriptor, it shows that the bNumEndpoints is 0 in its interface descriptor, but the 'generic_bulk_ctrl_endpoint' is 1, that means user don't configure a valid endpoint for 'generic_bulk_ctrl_endpoint', therefore this 'invalid' USB device should be rejected before it calls into dvb_usb_read_remote_control(). To fix it, iiuc, we can add endpoint check in dvb_usb_adapter_init(). Fixes: 786baecfe78f ("[media] dvb-usb: move it to drivers/media/usb/dvb-usb") Signed-off-by: Zheng Yejian <zhengyejian1(a)huawei.com> --- drivers/media/usb/dvb-usb/dvb-usb-init.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/media/usb/dvb-usb/dvb-usb-init.c b/drivers/media/usb/dvb-usb/dvb-usb-init.c index fbf58012becd..48e7b9fb93dd 100644 --- a/drivers/media/usb/dvb-usb/dvb-usb-init.c +++ b/drivers/media/usb/dvb-usb/dvb-usb-init.c @@ -104,6 +104,14 @@ static int dvb_usb_adapter_init(struct dvb_usb_device *d, short *adapter_nrs) * sometimes a timeout occurs, this helps */ if (d->props.generic_bulk_ctrl_endpoint != 0) { + ret = usb_pipe_type_check(d->udev, usb_sndbulkpipe(d->udev, + d->props.generic_bulk_ctrl_endpoint)); + if (ret) + goto frontend_init_err; + ret = usb_pipe_type_check(d->udev, usb_rcvbulkpipe(d->udev, + d->props.generic_bulk_ctrl_endpoint)); + if (ret) + goto frontend_init_err; usb_clear_halt(d->udev, usb_sndbulkpipe(d->udev, d->props.generic_bulk_ctrl_endpoint)); usb_clear_halt(d->udev, usb_rcvbulkpipe(d->udev, d->props.generic_bulk_ctrl_endpoint)); } -- 2.25.1

2 1

2024

2023

2022

2021

2020

2019

Kernel