mailweb.openeuler.org
Manage this list

Keyboard Shortcuts

Thread View

  • j: Next unread message
  • k: Previous unread message
  • j a: Jump to all threads
  • j l: Jump to MailingList overview

Kernel

Threads by month
  • ----- 2025 -----
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2024 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2023 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2022 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2021 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2020 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2019 -----
  • December
kernel@openeuler.org

  • 47 participants
  • 18695 discussions
[PATCH kernel-4.19] bluetooth: eliminate the potential race condition when removing the HCI controller
by Yang Yingliang 22 May '21

22 May '21
From: Lin Ma <linma(a)zju.edu.cn> mainline inclusion from mainline-v5.13-rc1 commit e2cb6b891ad2b8caa9131e3be70f45243df82a80 category: bugfix bugzilla: NA CVE: CVE-2021-32399 -------------------------------- There is a possible race condition vulnerability between issuing a HCI command and removing the cont. Specifically, functions hci_req_sync() and hci_dev_do_close() can race each other like below: thread-A in hci_req_sync() | thread-B in hci_dev_do_close() | hci_req_sync_lock(hdev); test_bit(HCI_UP, &hdev->flags); | ... | test_and_clear_bit(HCI_UP, &hdev->flags) hci_req_sync_lock(hdev); | | In this commit we alter the sequence in function hci_req_sync(). Hence, the thread-A cannot issue th. Signed-off-by: Lin Ma <linma(a)zju.edu.cn> Cc: Marcel Holtmann <marcel(a)holtmann.org> Fixes: 7c6a329e4447 ("[Bluetooth] Fix regression from using default link policy") Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> Reviewed-by: Xiu Jianfeng <xiujianfeng(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- net/bluetooth/hci_request.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c index a8ddd211e94c2..76bd6b1227240 100644 --- a/net/bluetooth/hci_request.c +++ b/net/bluetooth/hci_request.c @@ -271,12 +271,16 @@ int hci_req_sync(struct hci_dev *hdev, int (*req)(struct hci_request *req, { int ret; - if (!test_bit(HCI_UP, &hdev->flags)) - return -ENETDOWN; - /* Serialize all requests */ hci_req_sync_lock(hdev); - ret = __hci_req_sync(hdev, req, opt, timeout, hci_status); + /* check the state after obtaing the lock to protect the HCI_UP + * against any races from hci_dev_do_close when the controller + * gets removed. + */ + if (test_bit(HCI_UP, &hdev->flags)) + ret = __hci_req_sync(hdev, req, opt, timeout, hci_status); + else + ret = -ENETDOWN; hci_req_sync_unlock(hdev); return ret; -- 2.25.1
1 0
0 0
[PATCH openEuler-1.0-LTS v2] mm: enhance variables check and sync for pin mem
by Cheng Jian 21 May '21

21 May '21
From: Jingxian He <hejingxian(a)huawei.com> hulk inclusion category: feature bugzilla: 48159 CVE: N/A ------------------------------ Enhance variables check and sync for pin mem as followings: 1) Remove unused variable in set_fork_pid; 2) Remove unused calling of access_ok, which is called in copy_from_user; 3) Enhance page_map_entry_start check in pin_mem_area; 4) Keep get_page_map_info and create_page_map_info for internal use, and increase get_page_map_info_by_pid and create_page_map_info_by_pid for external use, which is protected by spinlock; 5) Use spin_lock_irqsave instead of spin_lock. Signed-off-by: Jingxian He <hejingxian(a)huawei.com> Reviewed-by: Jing Xiangfeng <jingxiangfeng(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> Signed-off-by: Cheng Jian <cj.chengjian(a)huawei.com> --- drivers/char/pin_memory.c | 7 ------ include/linux/pin_mem.h | 4 +-- mm/pin_mem.c | 51 +++++++++++++++++++++++++++++---------- 3 files changed, 40 insertions(+), 22 deletions(-) diff --git a/drivers/char/pin_memory.c b/drivers/char/pin_memory.c index 12ae7627bdf0..e6ed26c18135 100644 --- a/drivers/char/pin_memory.c +++ b/drivers/char/pin_memory.c @@ -98,8 +98,6 @@ static int set_pin_mem_area(unsigned long arg) struct pin_mem_area_set pmas; void __user *buf = (void __user *)arg; - if (!access_ok(buf, sizeof(pmas))) - return -EFAULT; if (copy_from_user(&pmas, buf, sizeof(pmas))) return -EINVAL; if (pmas.area_num > MAX_PIN_MEM_AREA_NUM) { @@ -119,8 +117,6 @@ static int pin_mem_remap(unsigned long arg) void __user *buf = (void __user *)arg; struct pid *pid_s; - if (!access_ok(buf, sizeof(int))) - return -EINVAL; if (copy_from_user(&pid, buf, sizeof(int))) return -EINVAL; @@ -157,11 +153,8 @@ static int pin_mem_remap(unsigned long arg) static int set_fork_pid(unsigned long arg) { int pid; - struct page_map_info *pmi = NULL; void __user *buf = (void __user *)arg; - if (!access_ok(buf, sizeof(int))) - goto fault; if (copy_from_user(&pid, buf, sizeof(int))) goto fault; current->fork_pid_union.fork_pid = pid; diff --git a/include/linux/pin_mem.h b/include/linux/pin_mem.h index 21422f8b0349..6c54482a42a1 100644 --- a/include/linux/pin_mem.h +++ b/include/linux/pin_mem.h @@ -64,8 +64,8 @@ struct redirect_info { unsigned int redirect_index[0]; }; -extern struct page_map_info *get_page_map_info(int pid); -extern struct page_map_info *create_page_map_info(int pid); +extern struct page_map_info *get_page_map_info_by_pid(int pid); +extern struct page_map_info *create_page_map_info_by_pid(int pid); extern vm_fault_t do_mem_remap(int pid, struct mm_struct *mm); extern vm_fault_t do_anon_page_remap(struct vm_area_struct *vma, unsigned long address, pmd_t *pmd, struct page *page); diff --git a/mm/pin_mem.c b/mm/pin_mem.c index c657ae7f6486..d035934724cd 100644 --- a/mm/pin_mem.c +++ b/mm/pin_mem.c @@ -72,7 +72,7 @@ static int __init setup_redirect_space_size(char *str) } early_param("redirect_space_size", setup_redirect_space_size); -struct page_map_info *create_page_map_info(int pid) +static struct page_map_info *create_page_map_info(int pid) { struct page_map_info *new; @@ -93,9 +93,20 @@ struct page_map_info *create_page_map_info(int pid) pin_pid_num++; return new; } -EXPORT_SYMBOL_GPL(create_page_map_info); -struct page_map_info *get_page_map_info(int pid) +struct page_map_info *create_page_map_info_by_pid(int pid) +{ + unsigned long flags; + struct page_map_info *ret; + + spin_lock_irqsave(&page_map_entry_lock, flags); + ret = create_page_map_info(pid); + spin_unlock_irqrestore(&page_map_entry_lock, flags); + return ret; +} +EXPORT_SYMBOL_GPL(create_page_map_info_by_pid); + +static struct page_map_info *get_page_map_info(int pid) { int i; @@ -108,7 +119,18 @@ struct page_map_info *get_page_map_info(int pid) } return NULL; } -EXPORT_SYMBOL_GPL(get_page_map_info); + +struct page_map_info *get_page_map_info_by_pid(int pid) +{ + unsigned long flags; + struct page_map_info *ret; + + spin_lock_irqsave(&page_map_entry_lock, flags); + ret = get_page_map_info(pid); + spin_unlock_irqrestore(&page_map_entry_lock, flags); + return ret; +} +EXPORT_SYMBOL_GPL(get_page_map_info_by_pid); static struct page *find_head_page(struct page *page) { @@ -380,12 +402,12 @@ static void reserve_user_space_map_pages(void) } } } - spin_unlock(&page_map_entry_lock); + spin_unlock_irqrestore(&page_map_entry_lock, flags); return; free_pages: free_user_map_pages(index, i, j); - spin_unlock(&page_map_entry_lock); + spin_unlock_irqrestore(&page_map_entry_lock, flags); } @@ -672,10 +694,11 @@ int pin_mem_area(struct task_struct *task, struct mm_struct *mm, pid = task->pid; spin_lock_irqsave(&page_map_entry_lock, flags); nr_pages = ((end_addr - start_addr) / PAGE_SIZE); - if ((unsigned long)page_map_entry_start + nr_pages * sizeof(struct page *) >= - page_map_entry_end) { + if ((unsigned long)page_map_entry_start + + nr_pages * sizeof(unsigned long) + + sizeof(struct page_map_entry) >= page_map_entry_end) { pr_warn("Page map entry use up!\n"); - ret = -EFAULT; + ret = -ENOMEM; goto finish; } @@ -965,13 +988,15 @@ vm_fault_t do_mem_remap(int pid, struct mm_struct *mm) if (reserve_user_map_pages_fail || !mm) return -EFAULT; + + spin_lock_irqsave(&page_map_entry_lock, flags); pmi = get_page_map_info(pid); + if (pmi) + pmi->disable_free_page = true; + spin_unlock_irqrestore(&page_map_entry_lock, flags); if (!pmi) return -EFAULT; - spin_lock_irqsave(&page_map_entry_lock, flags); - pmi->disable_free_page = true; - spin_unlock(&page_map_entry_lock); down_write(&mm->mmap_sem); pme = pmi->pme; vma = mm->mmap; @@ -1067,7 +1092,7 @@ void clear_pin_memory_record(void) pin_pid_num = 0; page_map_entry_start = __page_map_entry_start; } - spin_unlock(&page_map_entry_lock); + spin_unlock_irqrestore(&page_map_entry_lock, flags); } EXPORT_SYMBOL_GPL(clear_pin_memory_record); -- 2.25.1
1 0
0 0
[PATCH openEuler-1.0-LTS] mm: enhance variables check and sync for pin mem
by Cheng Jian 21 May '21

21 May '21
From: Jingxian He <hejingxian(a)huawei.com> hulk inclusion category: feature bugzilla: 48159 CVE: N/A ------------------------------ Enhance variables check and sync for pin mem as followings: 1) Remove unused variable in set_fork_pid; 2) Remove unused calling of access_ok, which is called in copy_from_user; 3) Enhance page_map_entry_start check in pin_mem_area; 4) Keep get_page_map_info and create_page_map_info for internal use, and increase get_page_map_info_by_pid and create_page_map_info_by_pid for external use, which is protected by spinlock; 5) Use spin_lock_irqsave instead of spin_lock. Signed-off-by: Jingxian He <hejingxian(a)huawei.com> Reviewed-by: Jing Xiangfeng <jingxiangfeng(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> Signed-off-by: Cheng Jian <cj.chengjian(a)huawei.com> --- drivers/char/pin_memory.c | 7 ------ include/linux/pin_mem.h | 4 +-- mm/pin_mem.c | 51 +++++++++++++++++++++++++++++---------- 3 files changed, 40 insertions(+), 22 deletions(-) diff --git a/drivers/char/pin_memory.c b/drivers/char/pin_memory.c index 05fa7cfde03b..4b3a6c8b31de 100644 --- a/drivers/char/pin_memory.c +++ b/drivers/char/pin_memory.c @@ -98,8 +98,6 @@ static int set_pin_mem_area(unsigned long arg) struct pin_mem_area_set pmas; void __user *buf = (void __user *)arg; - if (!access_ok(buf, sizeof(pmas))) - return -EFAULT; if (copy_from_user(&pmas, buf, sizeof(pmas))) return -EINVAL; if (pmas.area_num > MAX_PIN_MEM_AREA_NUM) { @@ -119,8 +117,6 @@ static int pin_mem_remap(unsigned long arg) void __user *buf = (void __user *)arg; struct pid *pid_s; - if (!access_ok(buf, sizeof(int))) - return -EINVAL; if (copy_from_user(&pid, buf, sizeof(int))) return -EINVAL; @@ -157,11 +153,8 @@ static int pin_mem_remap(unsigned long arg) static int set_fork_pid(unsigned long arg) { int pid; - struct page_map_info *pmi = NULL; void __user *buf = (void __user *)arg; - if (!access_ok(buf, sizeof(int))) - goto fault; if (copy_from_user(&pid, buf, sizeof(int))) goto fault; current->fork_pid = pid; diff --git a/include/linux/pin_mem.h b/include/linux/pin_mem.h index 21422f8b0349..6c54482a42a1 100644 --- a/include/linux/pin_mem.h +++ b/include/linux/pin_mem.h @@ -64,8 +64,8 @@ struct redirect_info { unsigned int redirect_index[0]; }; -extern struct page_map_info *get_page_map_info(int pid); -extern struct page_map_info *create_page_map_info(int pid); +extern struct page_map_info *get_page_map_info_by_pid(int pid); +extern struct page_map_info *create_page_map_info_by_pid(int pid); extern vm_fault_t do_mem_remap(int pid, struct mm_struct *mm); extern vm_fault_t do_anon_page_remap(struct vm_area_struct *vma, unsigned long address, pmd_t *pmd, struct page *page); diff --git a/mm/pin_mem.c b/mm/pin_mem.c index c657ae7f6486..d035934724cd 100644 --- a/mm/pin_mem.c +++ b/mm/pin_mem.c @@ -72,7 +72,7 @@ static int __init setup_redirect_space_size(char *str) } early_param("redirect_space_size", setup_redirect_space_size); -struct page_map_info *create_page_map_info(int pid) +static struct page_map_info *create_page_map_info(int pid) { struct page_map_info *new; @@ -93,9 +93,20 @@ struct page_map_info *create_page_map_info(int pid) pin_pid_num++; return new; } -EXPORT_SYMBOL_GPL(create_page_map_info); -struct page_map_info *get_page_map_info(int pid) +struct page_map_info *create_page_map_info_by_pid(int pid) +{ + unsigned long flags; + struct page_map_info *ret; + + spin_lock_irqsave(&page_map_entry_lock, flags); + ret = create_page_map_info(pid); + spin_unlock_irqrestore(&page_map_entry_lock, flags); + return ret; +} +EXPORT_SYMBOL_GPL(create_page_map_info_by_pid); + +static struct page_map_info *get_page_map_info(int pid) { int i; @@ -108,7 +119,18 @@ struct page_map_info *get_page_map_info(int pid) } return NULL; } -EXPORT_SYMBOL_GPL(get_page_map_info); + +struct page_map_info *get_page_map_info_by_pid(int pid) +{ + unsigned long flags; + struct page_map_info *ret; + + spin_lock_irqsave(&page_map_entry_lock, flags); + ret = get_page_map_info(pid); + spin_unlock_irqrestore(&page_map_entry_lock, flags); + return ret; +} +EXPORT_SYMBOL_GPL(get_page_map_info_by_pid); static struct page *find_head_page(struct page *page) { @@ -380,12 +402,12 @@ static void reserve_user_space_map_pages(void) } } } - spin_unlock(&page_map_entry_lock); + spin_unlock_irqrestore(&page_map_entry_lock, flags); return; free_pages: free_user_map_pages(index, i, j); - spin_unlock(&page_map_entry_lock); + spin_unlock_irqrestore(&page_map_entry_lock, flags); } @@ -672,10 +694,11 @@ int pin_mem_area(struct task_struct *task, struct mm_struct *mm, pid = task->pid; spin_lock_irqsave(&page_map_entry_lock, flags); nr_pages = ((end_addr - start_addr) / PAGE_SIZE); - if ((unsigned long)page_map_entry_start + nr_pages * sizeof(struct page *) >= - page_map_entry_end) { + if ((unsigned long)page_map_entry_start + + nr_pages * sizeof(unsigned long) + + sizeof(struct page_map_entry) >= page_map_entry_end) { pr_warn("Page map entry use up!\n"); - ret = -EFAULT; + ret = -ENOMEM; goto finish; } @@ -965,13 +988,15 @@ vm_fault_t do_mem_remap(int pid, struct mm_struct *mm) if (reserve_user_map_pages_fail || !mm) return -EFAULT; + + spin_lock_irqsave(&page_map_entry_lock, flags); pmi = get_page_map_info(pid); + if (pmi) + pmi->disable_free_page = true; + spin_unlock_irqrestore(&page_map_entry_lock, flags); if (!pmi) return -EFAULT; - spin_lock_irqsave(&page_map_entry_lock, flags); - pmi->disable_free_page = true; - spin_unlock(&page_map_entry_lock); down_write(&mm->mmap_sem); pme = pmi->pme; vma = mm->mmap; @@ -1067,7 +1092,7 @@ void clear_pin_memory_record(void) pin_pid_num = 0; page_map_entry_start = __page_map_entry_start; } - spin_unlock(&page_map_entry_lock); + spin_unlock_irqrestore(&page_map_entry_lock, flags); } EXPORT_SYMBOL_GPL(clear_pin_memory_record); -- 2.25.1
1 0
0 0
Re: Fwd: 网迅万兆网卡驱动合入openeuler-4.19内核申请
by Xie XiuQi 19 May '21

19 May '21
Hi, On 2021/3/25 9:43, zhenpengzheng(a)net-swift.com wrote: > > to Leizhen, > >     have these two patches been merged into kernel-4.19 and openEuler-1.0-LTS branches? This patch is in my queue and under testing, which would be merged before April 15. Thanks. > > regards, > zhenpeng > > > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > > **************************************************************** > > 郑振鹏(zheng zhenpeng) > > 北京网迅科技有限公司杭州分公司 软件工程师 > > 浙江省杭州市西湖区文三路478号华星时代广场A座507室 310013 > > Beijing WangXun Technology Co., Ltd. Software Engineer. > > Room A507, HuaXing Times Square, No.478 West Wensan Road. > > West Lake District, Hangzhou City, 310013 ZHEJIANG, P.R.CHINA. > >   > > Office: +86(0571)89807901-8014 > > Mobile: +86-13656681762 > > E-Mail: z <mailto:jianwang@trustnetic.com>henpengzheng(a)net-swift.com > > **************************************************************** > >   > *发件人:* Xie XiuQi <mailto:xiexiuqi@huawei.com> > *发送时间:* 2021-03-12 16:22 > *收件人:* zhenpengzheng(a)net-swift.com <mailto:zhenpengzheng@net-swift.com>; Leizhen (ThunderTown) <mailto:thunder.leizhen@huawei.com> > *抄送:* liuyuan36 <mailto:liuyuan36@huawei.com>; Cheng Jian <mailto:cj.chengjian@huawei.com>; Libin (Huawei) <mailto:huawei.libin@huawei.com>; Yang Yingliang <mailto:yangyingliang@huawei.com>; Dukaitian (Dukaitian, Intelligent Computing R&D) <mailto:dukaitian@huawei.com>; neil.yao(a)huawei.com <mailto:neil.yao@huawei.com>; kernel(a)openeuler.org <mailto:kernel@openeuler.org> > *主题:* Re: Fwd: 网迅万兆网卡驱动合入openeuler-4.19内核申请 > For this series, > Acked-by: Xie XiuQi <xiexiuqi(a)huawei.com> >   > @Leizhen, >   > Please help to apply this two patches to kernel-4.19 & openEuler-1.0-LTS branches. > Thanks. >   > On 2021/3/9 19:13, zhenpengzheng(a)net-swift.com wrote: > > to谢工, > >     已清理所有提交文件中“huawei” “intel” “HiNIC”等字样与本次提交无关的注释。 > > > > toLei工, > >     已删除所有提交文件末尾空行。 > > > > 谢谢大家的意见,附件为改动后最新的patch。 > > > > 振鹏 > > > > > > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > > > > **************************************************************** > > > > 郑振鹏(zheng zhenpeng) > > > > 北京网迅科技有限公司杭州分公司 软件工程师 > > > > 浙江省杭州市西湖区文三路478号华星时代广场A座507室 310013 > > > > Beijing WangXun Technology Co., Ltd. Software Engineer. > > > > Room A507, HuaXing Times Square, No.478 West Wensan Road. > > > > West Lake District, Hangzhou City, 310013 ZHEJIANG, P.R.CHINA. > > > >   > > > > Office: +86(0571)89807901-8014 > > > > Mobile: +86-13656681762 > > > > E-Mail: z <mailto:jianwang@trustnetic.com>henpengzheng(a)net-swift.com > > > > **************************************************************** > > > >       > >     *发件人:* Leizhen (ThunderTown) <mailto:thunder.leizhen@huawei.com> > >     *发送时间:* 2021-03-09 17:59 > >     *收件人:* zhenpengzheng(a)net-swift.com <mailto:zhenpengzheng@net-swift.com>; Xie XiuQi <mailto:xiexiuqi@huawei.com> > >     *抄送:* liuyuan36 <mailto:liuyuan36@huawei.com>; Cheng Jian <mailto:cj.chengjian@huawei.com>; Libin (Huawei) <mailto:huawei.libin@huawei.com>; Yang Yingliang <mailto:yangyingliang@huawei.com>; Dukaitian (Dukaitian, Intelligent Computing R&D) <mailto:dukaitian@huawei.com>; neil.yao(a)huawei.com <mailto:neil.yao@huawei.com> > >     *主题:* Re: Fwd: 网迅万兆网卡驱动合入openeuler-4.19内核申请 > >       > >       > >     On 2021/3/9 16:38, zhenpengzheng(a)net-swift.com wrote: > >     > 谢工,lei工 > >     >     您好,附件是我按照社区要求整改的patch,第一份较大的patch是不包含openeuler_config(x86)文件修改的驱动主代码,第二份patch仅含openeuler_config(x86)文件修改,arm的配置暂未修改,后续我尽快测完再发patch开启arm配置。 > >     > > >     >     针对社区反馈的问题1,我查过patch中确实存在一处告警所说明的违规(即指向patch90行那处),其余违规处对照后未发现异常,我检查过代码本身应无段尾出现空白的情况,不知道如何进一步确认patch是否合规,请在邮件中告知,谢谢。 > >     drivers/net/ethernet/netswift/txgbe/txgbe_bp.h > >     drivers/net/ethernet/netswift/txgbe/txgbe_ethtool.c > >     drivers/net/ethernet/netswift/txgbe/txgbe_hw.c > >     drivers/net/ethernet/netswift/txgbe/txgbe_lib.c > >     drivers/net/ethernet/netswift/txgbe/txgbe_main.c > >     drivers/net/ethernet/netswift/txgbe/txgbe_mtd.c > >     drivers/net/ethernet/netswift/txgbe/txgbe_mtd.h > >       > >     这个告警是文件末尾有空行。每个文件打开一下,shift+G到末尾check下就好了。 > >       > >     > > >     > 振鹏 > >     > > >     > > >     > > >     > > >     > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > >     > > >     > **************************************************************** > >     > > >     > 郑振鹏(zheng zhenpeng) > >     > > >     > 北京网迅科技有限公司杭州分公司 软件工程师 > >     > > >     > 浙江省杭州市西湖区文三路478号华星时代广场A座507室 310013 > >     > > >     > Beijing WangXun Technology Co., Ltd. Software Engineer. > >     > > >     > Room A507, HuaXing Times Square, No.478 West Wensan Road. > >     > > >     > West Lake District, Hangzhou City, 310013 ZHEJIANG, P.R.CHINA. > >     > > >     >   > >     > > >     > Office: +86(0571)89807901-8014 > >     > > >     > Mobile: +86-13656681762 > >     > > >     > E-Mail: z <mailto:jianwang@trustnetic.com>henpengzheng(a)net-swift.com > >     > > >     > **************************************************************** > >     > > >     >       > >     >     *发件人:* Xie XiuQi <mailto:xiexiuqi@huawei.com> > >     >     *发送时间:* 2021-03-08 16:29 > >     >     *收件人:* zhenpengzheng(a)net-swift.com <mailto:zhenpengzheng@net-swift.com>; Leizhen (ThunderTown) <mailto:thunder.leizhen@huawei.com> > >     >     *抄送:* liuyuan36 <mailto:liuyuan36@huawei.com>; Cheng Jian <mailto:cj.chengjian@huawei.com>; Libin (Huawei) <mailto:huawei.libin@huawei.com>; Yang Yingliang <mailto:yangyingliang@huawei.com>; Dukaitian (Dukaitian, Intelligent Computing R&D) <mailto:dukaitian@huawei.com>; neil.yao(a)huawei.com <mailto:neil.yao@huawei.com> > >     >     *主题:* Re: Fwd: 网迅万兆网卡驱动合入openeuler-4.19内核申请 > >     >     Hi, > >     >       > >     >     On 2021/3/8 11:12, zhenpengzheng(a)net-swift.com wrote: > >     >     > 适用arm64,但这份驱动我只在x86指令集的机器上测试过,我先改好,稍后安排ARM的适配测试。 > >     >       > >     >     好的,在 x86 上测试过,就先在 x86 上 enable 吧。 > >     >     ARM64 的测试过之后,可以再 enable。 > >     >       > >     >     > > >     >     > > >     >     > >     > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > >     >     > > >     >     > **************************************************************** > >     >     > > >     >     > 郑振鹏(zheng zhenpeng) > >     >     > > >     >     > 北京网迅科技有限公司杭州分公司 软件工程师 > >     >     > > >     >     > 浙江省杭州市西湖区文三路478号华星时代广场A座507室 310013 > >     >     > > >     >     > Beijing WangXun Technology Co., Ltd. Software Engineer. > >     >     > > >     >     > Room A507, HuaXing Times Square, No.478 West Wensan Road. > >     >     > > >     >     > West Lake District, Hangzhou City, 310013 ZHEJIANG, P.R.CHINA. > >     >     > > >     >     >   > >     >     > > >     >     > Office: +86(0571)89807901-8014 > >     >     > > >     >     > Mobile: +86-13656681762 > >     >     > > >     >     > E-Mail: z <mailto:jianwang@trustnetic.com>henpengzheng(a)net-swift.com > >     >     > > >     >     > **************************************************************** > >     >     > > >     >     >       > >     >     >     *发件人:* Xie XiuQi <mailto:xiexiuqi@huawei.com> > >     >     >     *发送时间:* 2021-03-08 10:30 > >     >     >     *收件人:* zhenpengzheng(a)net-swift.com <mailto:zhenpengzheng@net-swift.com>; Leizhen (ThunderTown) <mailto:thunder.leizhen@huawei.com> > >     >     >     *抄送:* liuyuan36 <mailto:liuyuan36@huawei.com>; Cheng Jian <mailto:cj.chengjian@huawei.com>; Libin (Huawei) <mailto:huawei.libin@huawei.com>; Yang Yingliang <mailto:yangyingliang@huawei.com>; Dukaitian (Dukaitian, Intelligent Computing R&D) <mailto:dukaitian@huawei.com>; neil.yao(a)huawei.com <mailto:neil.yao@huawei.com> > >     >     >     *主题:* Re: Fwd: 网迅万兆网卡驱动合入openeuler-4.19内核申请 > >     >     >     Hi, > >     >     >       > >     >     >     网讯网卡驱动在 arm64 上也是适用的吧? > >     >     >     是的话,arm64 的config,也打开吧。 > >     >     >       > >     >     >     arch/arm64/configs/openeuler_defconfig > >     >     >       > >     >     >       > >     >     >       > >     >     >     On 2021/3/8 9:42, zhenpengzheng(a)net-swift.com wrote: > >     >     >     > 好的,对于问题2,我分割成两个patch再发一次,谢谢。 > >     >     >     > > >     >     >     > > >     >     >     > >     >     > >     > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > >     >     >     > > >     >     >     > **************************************************************** > >     >     >     > > >     >     >     > 郑振鹏(zheng zhenpeng) > >     >     >     > > >     >     >     > 北京网迅科技有限公司杭州分公司 软件工程师 > >     >     >     > > >     >     >     > 浙江省杭州市西湖区文三路478号华星时代广场A座507室 310013 > >     >     >     > > >     >     >     > Beijing WangXun Technology Co., Ltd. Software Engineer. > >     >     >     > > >     >     >     > Room A507, HuaXing Times Square, No.478 West Wensan Road. > >     >     >     > > >     >     >     > West Lake District, Hangzhou City, 310013 ZHEJIANG, P.R.CHINA. > >     >     >     > > >     >     >     >   > >     >     >     > > >     >     >     > Office: +86(0571)89807901-8014 > >     >     >     > > >     >     >     > Mobile: +86-13656681762 > >     >     >     > > >     >     >     > E-Mail: z <mailto:jianwang@trustnetic.com>henpengzheng(a)net-swift.com > >     >     >     > > >     >     >     > **************************************************************** > >     >     >     > > >     >     >     >       > >     >     >     >     *发件人:* Leizhen (ThunderTown) <mailto:thunder.leizhen@huawei.com> > >     >     >     >     *发送时间:* 2021-03-06 15:05 > >     >     >     >     *收件人:* Xie XiuQi <mailto:xiexiuqi@huawei.com>; 郑振鹏 <mailto:zhenpengzheng@net-swift.com> > >     >     >     >     *抄送:* Liuyuan (Compatibility, Cloud Infrastructure Service Product Dept.) <mailto:liuyuan36@huawei.com>; Cheng Jian <mailto:cj.chengjian@huawei.com>; Libin (Huawei) <mailto:huawei.libin@huawei.com>; Yang Yingliang <mailto:yangyingliang@huawei.com>; Dukaitian (Dukaitian, Intelligent Computing R&D) <mailto:dukaitian@huawei.com>; neil.yao(a)huawei.com <mailto:neil.yao@huawei.com> > >     >     >     >     *主题:* Re: Fwd: 网迅万兆网卡驱动合入openeuler-4.19内核申请 > >     >     >     >     Hi 振鹏, > >     >     >     >         我review了一下补丁,有几个地方需要改进下: > >     >     >     >       > >     >     >     >     1. git am补丁的时候会报几个warning,需要消除一下; > >     >     >     >        git am 0001-add-WangXun-XGIG-NIC-driver-for-EulerOS.patch > >     >     >     >     Applying: add WangXun XGIG NIC driver for EulerOS > >     >     >     >     .git/rebase-apply/patch:90: new blank line at EOF. > >     >     >     >     + > >     >     >     >     .git/rebase-apply/patch:2331: new blank line at EOF. > >     >     >     >     + > >     >     >     >     .git/rebase-apply/patch:5755: new blank line at EOF. > >     >     >     >     + > >     >     >     >     .git/rebase-apply/patch:12891: new blank line at EOF. > >     >     >     >     + > >     >     >     >     .git/rebase-apply/patch:14134: new blank line at EOF. > >     >     >     >     + > >     >     >     >     warning: squelched 3 whitespace errors > >     >     >     >     warning: 8 lines add whitespace errors. > >     >     >     >     2. 对arch/x86/configs/openeuler_defconfig文件的修改,最好能拆分到一个独立的补丁中去。 > >     >     >     >     3. txgbe_bp.c没有添加版权声明。 > >     >     >     >     4. 其它#if 0、//注释掉的代码,最好能清掉。 > >     >     >     >       > >     >     >     >       > >     >     >     >       > >     >     >     >     On 2021/3/1 16:32, Xie XiuQi wrote: > >     >     >     >     > Hi 振鹏, > >     >     >     >     > > >     >     >     >     > Thanks for your patch, we'll review this patch, and give a feedback soon. > >     >     >     >     > > >     >     >     >     > --- > >     >     >     >     > Thanks, > >     >     >     >     > Xie XiuQi > >     >     >     >     > > >     >     >     >     > > >     >     >     >     > -------- Forwarded Message -------- > >     >     >     >     > Subject: 网迅万兆网卡驱动合入openeuler-4.19内核申请 > >     >     >     >     > Date: Mon, 1 Mar 2021 15:41:09 +0800 > >     >     >     >     > From: zhenpengzheng(a)net-swift.com <zhenpengzheng(a)net-swift.com> > >     >     >     >     > To: xiexiuqi <xiexiuqi(a)huawei.com>, liuyuan36 <liuyuan36(a)huawei.com> > >     >     >     >     > > >     >     >     >     > > >     >     >     >     > > >     >     >     >     > > >     >     >     >     > 谢工,刘工: > >     >     >     >     > > >     >     >     >     >     您好,我已准备好patch,见附件,patch已按照社区要求做checkpatch,报告的错误已消除,commit信息已更新。 > >     >     >     >     > > >     >     >     >     > 振鹏 > >     >     >     >     > > >     >     >     >     > > >     >     >     >     > >     >     >     > >     >     > >     > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > >     >     >     >     > > >     >     >     >     > **************************************************************** > >     >     >     >     > > >     >     >     >     > 郑振鹏(zheng zhenpeng) > >     >     >     >     > > >     >     >     >     > 北京网迅科技有限公司杭州分公司 软件工程师 > >     >     >     >     > > >     >     >     >     > 浙江省杭州市西湖区文三路478号华星时代广场A座507室 310013 > >     >     >     >     > > >     >     >     >     > Beijing WangXun Technology Co., Ltd. Software Engineer. > >     >     >     >     > > >     >     >     >     > Room A507, HuaXing Times Square, No.478 West Wensan Road. > >     >     >     >     > > >     >     >     >     > West Lake District, Hangzhou City, 310013 ZHEJIANG, P.R.CHINA. > >     >     >     >     > > >     >     >     >     >   > >     >     >     >     > > >     >     >     >     > Office: +86(0571)89807901-8014 > >     >     >     >     > > >     >     >     >     > Mobile: +86-13656681762 > >     >     >     >     > > >     >     >     >     > E-Mail: z <mailto:jianwang@trustnetic.com>henpengzheng(a)net-swift.com > >     >     >     >     > > >     >     >     >     > **************************************************************** > >     >     >     >     > > >     >     >     > > >     >     > > >     > > > >
1 1
0 0
[PATCH kernel-4.19 0/6] Perf: backport JVMTI plugin from mainline 5.7
by Zhichang Yuan 18 May '21

18 May '21
This series is a set of backports to enhance the JVMTI plugin support in Linux perf tool. It allows one to use perf to profile Java applications and attain clearer symbols output. Nick Gasson (6): perf jvmti: Fix jitdump for methods without debug info perf jvmti: Do not report error when missing debug information perf tests: Add test for the java demangler perf jvmti: Fix demangling Java symbols perf jvmti: Remove redundant jitdump line table entries perf jit: Fix inaccurate DWARF line table tools/perf/jvmti/libjvmti.c | 92 ++++++++++++--------------- tools/perf/tests/Build | 1 + tools/perf/tests/builtin-test.c | 4 ++ tools/perf/tests/demangle-java-test.c | 42 ++++++++++++ tools/perf/tests/tests.h | 1 + tools/perf/util/demangle-java.c | 13 ++-- tools/perf/util/genelf_debug.c | 4 +- 7 files changed, 96 insertions(+), 61 deletions(-) create mode 100644 tools/perf/tests/demangle-java-test.c -- 2.23.0
1 6
0 0
[PATCH openEuler-1.0-LTS 1/2] bpf: Fix masking negation logic upon negative dst register
by Yang Yingliang 18 May '21

18 May '21
From: Daniel Borkmann <daniel(a)iogearbox.net> stable inclusion from linux-4.19.190 commit 0e2dfdc74a7f4036127356d42ea59388f153f42c -------------------------------- commit b9b34ddbe2076ade359cd5ce7537d5ed019e9807 upstream. The negation logic for the case where the off_reg is sitting in the dst register is not correct given then we cannot just invert the add to a sub or vice versa. As a fix, perform the final bitwise and-op unconditionally into AX from the off_reg, then move the pointer from the src to dst and finally use AX as the source for the original pointer arithmetic operation such that the inversion yields a correct result. The single non-AX mov in between is possible given constant blinding is retaining it as it's not an immediate based operation. Fixes: 979d63d50c0c ("bpf: prevent out of bounds speculation on pointer arithmetic") Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net> Tested-by: Piotr Krysiuk <piotras(a)gmail.com> Reviewed-by: Piotr Krysiuk <piotras(a)gmail.com> Reviewed-by: John Fastabend <john.fastabend(a)gmail.com> Acked-by: Alexei Starovoitov <ast(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- kernel/bpf/verifier.c | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c index c1df2803033d3..79b50911008a0 100644 --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -6373,14 +6373,10 @@ static int fixup_bpf_calls(struct bpf_verifier_env *env) *patch++ = BPF_ALU64_REG(BPF_OR, BPF_REG_AX, off_reg); *patch++ = BPF_ALU64_IMM(BPF_NEG, BPF_REG_AX, 0); *patch++ = BPF_ALU64_IMM(BPF_ARSH, BPF_REG_AX, 63); - if (issrc) { - *patch++ = BPF_ALU64_REG(BPF_AND, BPF_REG_AX, - off_reg); - insn->src_reg = BPF_REG_AX; - } else { - *patch++ = BPF_ALU64_REG(BPF_AND, off_reg, - BPF_REG_AX); - } + *patch++ = BPF_ALU64_REG(BPF_AND, BPF_REG_AX, off_reg); + if (!issrc) + *patch++ = BPF_MOV64_REG(insn->dst_reg, insn->src_reg); + insn->src_reg = BPF_REG_AX; if (isneg) insn->code = insn->code == code_add ? code_sub : code_add; -- 2.25.1
1 1
0 0
[PATCH kernel-4.19] bpf: Fix leakage of uninitialized bpf stack under speculation
by Yang Yingliang 18 May '21

18 May '21
From: Daniel Borkmann <daniel(a)iogearbox.net> mainline inclusion from mainline-v5.13-rc1 commit 801c6058d14a82179a7ee17a4b532cac6fad067f category: bugfix bugzilla: NA CVE: CVE-2021-31829 -------------------------------- The current implemented mechanisms to mitigate data disclosure under speculation mainly address stack and map value oob access from the speculative domain. However, Piotr discovered that uninitialized BPF stack is not protected yet, and thus old data from the kernel stack, potentially including addresses of kernel structures, could still be extracted from that 512 bytes large window. The BPF stack is special compared to map values since it's not zero initialized for every program invocation, whereas map values /are/ zero initialized upon their initial allocation and thus cannot leak any prior data in either domain. In the non-speculative domain, the verifier ensures that every stack slot read must have a prior stack slot write by the BPF program to avoid such data leaking issue. However, this is not enough: for example, when the pointer arithmetic operation moves the stack pointer from the last valid stack offset to the first valid offset, the sanitation logic allows for any intermediate offsets during speculative execution, which could then be used to extract any restricted stack content via side-channel. Given for unprivileged stack pointer arithmetic the use of unknown but bounded scalars is generally forbidden, we can simply turn the register-based arithmetic operation into an immediate-based arithmetic operation without the need for masking. This also gives the benefit of reducing the needed instructions for the operation. Given after the work in 7fedb63a8307 ("bpf: Tighten speculative pointer arithmetic mask"), the aux->alu_limit already holds the final immediate value for the offset register with the known scalar. Thus, a simple mov of the immediate to AX register with using AX as the source for the original instruction is sufficient and possible now in this case. Reported-by: Piotr Krysiuk <piotras(a)gmail.com> Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net> Tested-by: Piotr Krysiuk <piotras(a)gmail.com> Reviewed-by: Piotr Krysiuk <piotras(a)gmail.com> Reviewed-by: John Fastabend <john.fastabend(a)gmail.com> Acked-by: Alexei Starovoitov <ast(a)kernel.org> Conflicts: kernel/bpf/verifier.c Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> Reviewed-by: Xiu Jianfeng <xiujianfeng(a)huawei.com> Reviewed-by: Kuohai Xu <xukuohai(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- include/linux/bpf_verifier.h | 5 +++-- kernel/bpf/verifier.c | 27 +++++++++++++++++---------- 2 files changed, 20 insertions(+), 12 deletions(-) diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h index 42dc8c2146f4d..daab0960c0544 100644 --- a/include/linux/bpf_verifier.h +++ b/include/linux/bpf_verifier.h @@ -142,10 +142,11 @@ struct bpf_verifier_state_list { }; /* Possible states for alu_state member. */ -#define BPF_ALU_SANITIZE_SRC 1U -#define BPF_ALU_SANITIZE_DST 2U +#define BPF_ALU_SANITIZE_SRC (1U << 0) +#define BPF_ALU_SANITIZE_DST (1U << 1) #define BPF_ALU_NEG_VALUE (1U << 2) #define BPF_ALU_NON_POINTER (1U << 3) +#define BPF_ALU_IMMEDIATE (1U << 4) #define BPF_ALU_SANITIZE (BPF_ALU_SANITIZE_SRC | \ BPF_ALU_SANITIZE_DST) diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c index 46e21bdb79c4c..c49aa17839875 100644 --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -2745,6 +2745,7 @@ static int sanitize_ptr_alu(struct bpf_verifier_env *env, { struct bpf_insn_aux_data *aux = commit_window ? cur_aux(env) : tmp_aux; struct bpf_verifier_state *vstate = env->cur_state; + bool off_is_imm = tnum_is_const(off_reg->var_off); bool off_is_neg = off_reg->smin_value < 0; bool ptr_is_dst_reg = ptr_reg == dst_reg; u8 opcode = BPF_OP(insn->code); @@ -2775,6 +2776,7 @@ static int sanitize_ptr_alu(struct bpf_verifier_env *env, alu_limit = abs(tmp_aux->alu_limit - alu_limit); } else { alu_state = off_is_neg ? BPF_ALU_NEG_VALUE : 0; + alu_state |= off_is_imm ? BPF_ALU_IMMEDIATE : 0; alu_state |= ptr_is_dst_reg ? BPF_ALU_SANITIZE_SRC : BPF_ALU_SANITIZE_DST; } @@ -6301,7 +6303,7 @@ static int fixup_bpf_calls(struct bpf_verifier_env *env) const u8 code_sub = BPF_ALU64 | BPF_SUB | BPF_X; struct bpf_insn insn_buf[16]; struct bpf_insn *patch = &insn_buf[0]; - bool issrc, isneg; + bool issrc, isneg, isimm; u32 off_reg; aux = &env->insn_aux_data[i + delta]; @@ -6312,16 +6314,21 @@ static int fixup_bpf_calls(struct bpf_verifier_env *env) isneg = aux->alu_state & BPF_ALU_NEG_VALUE; issrc = (aux->alu_state & BPF_ALU_SANITIZE) == BPF_ALU_SANITIZE_SRC; + isimm = aux->alu_state & BPF_ALU_IMMEDIATE; off_reg = issrc ? insn->src_reg : insn->dst_reg; - if (isneg) - *patch++ = BPF_ALU64_IMM(BPF_MUL, off_reg, -1); - *patch++ = BPF_MOV32_IMM(BPF_REG_AX, aux->alu_limit); - *patch++ = BPF_ALU64_REG(BPF_SUB, BPF_REG_AX, off_reg); - *patch++ = BPF_ALU64_REG(BPF_OR, BPF_REG_AX, off_reg); - *patch++ = BPF_ALU64_IMM(BPF_NEG, BPF_REG_AX, 0); - *patch++ = BPF_ALU64_IMM(BPF_ARSH, BPF_REG_AX, 63); - *patch++ = BPF_ALU64_REG(BPF_AND, BPF_REG_AX, off_reg); + if (isimm) { + *patch++ = BPF_MOV32_IMM(BPF_REG_AX, aux->alu_limit); + } else { + if (isneg) + *patch++ = BPF_ALU64_IMM(BPF_MUL, off_reg, -1); + *patch++ = BPF_MOV32_IMM(BPF_REG_AX, aux->alu_limit); + *patch++ = BPF_ALU64_REG(BPF_SUB, BPF_REG_AX, off_reg); + *patch++ = BPF_ALU64_REG(BPF_OR, BPF_REG_AX, off_reg); + *patch++ = BPF_ALU64_IMM(BPF_NEG, BPF_REG_AX, 0); + *patch++ = BPF_ALU64_IMM(BPF_ARSH, BPF_REG_AX, 63); + *patch++ = BPF_ALU64_REG(BPF_AND, BPF_REG_AX, off_reg); + } if (!issrc) *patch++ = BPF_MOV64_REG(insn->dst_reg, insn->src_reg); insn->src_reg = BPF_REG_AX; @@ -6329,7 +6336,7 @@ static int fixup_bpf_calls(struct bpf_verifier_env *env) insn->code = insn->code == code_add ? code_sub : code_add; *patch++ = *insn; - if (issrc && isneg) + if (issrc && isneg && !isimm) *patch++ = BPF_ALU64_IMM(BPF_MUL, off_reg, -1); cnt = patch - insn_buf; -- 2.25.1
1 0
0 0
[PATCH openEuler-20.03-LTS-SP1] mm/page_alloc: fix managed_pages of zone is incorrect and out of bounds
by Guo Hui 18 May '21

18 May '21
uniontech inclusion category: bugfix bugzilla: NA CVE: NA Commit eb761d6521c3 ("mm: parallelize deferred struct page initialization within each node") the code "++zone" in follow code: /* Sanity check that the next zone really is unpopulated */ WARN_ON(++zid < MAX_NR_ZONES && populated_zone(++zone)); VM_BUG_ON(nr_init != nr_free); zone->managed_pages += nr_free; makes the managed_pages statistics of the current zone incorrect and the zone may have out-of-bounds memory when CONFIG_DEFERRED_STRUCT_PAGE_INIT=y, causing the Virtual machine system startup to fail when the Virtual machine system current allocated memory is set to half of the Virtual machine maximum memory using virt-manager tool Fix it by putting the code “zone->managed_pages += nr_free;” before “++zone” code Fixes: eb761d6521c3 ("mm: parallelize deferred struct page initialization within each node") Reported-by: Peng Yuanbo <pengyuanbo(a)uniontech.com> Signed-off-by: Guo Hui <guohui(a)uniontech.com> --- mm/page_alloc.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 0888870e3458..6bf3d4461430 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -1688,12 +1688,13 @@ static int __init deferred_init_memmap(void *data) nr_free += atomic64_read(&args.nr_pages); } - /* Sanity check that the next zone really is unpopulated */ - WARN_ON(++zid < MAX_NR_ZONES && populated_zone(++zone)); VM_BUG_ON(nr_init != nr_free); zone->managed_pages += nr_free; + /* Sanity check that the next zone really is unpopulated */ + WARN_ON(++zid < MAX_NR_ZONES && populated_zone(++zone)); + pr_info("node %d initialised, %lu pages in %ums\n", nid, nr_free, jiffies_to_msecs(jiffies - start)); -- 2.20.1
2 1
0 0
[PATCH kernel-4.19 0/6] Perf: backport JVMTI plugin from mainline 5.7
by Zhichang Yuan 18 May '21

18 May '21
This series is a set of backports to enhance the JVMTI plugin support in Linux perf tool. It allows one to use perf to profile Java applications and attain clearer symbols output. Nick Gasson (6): perf jvmti: Fix jitdump for methods without debug info perf jvmti: Do not report error when missing debug information perf tests: Add test for the java demangler perf jvmti: Fix demangling Java symbols perf jvmti: Remove redundant jitdump line table entries perf jit: Fix inaccurate DWARF line table tools/perf/jvmti/libjvmti.c | 92 ++++++++++++--------------- tools/perf/tests/Build | 1 + tools/perf/tests/builtin-test.c | 4 ++ tools/perf/tests/demangle-java-test.c | 42 ++++++++++++ tools/perf/tests/tests.h | 1 + tools/perf/util/demangle-java.c | 13 ++-- tools/perf/util/genelf_debug.c | 4 +- 7 files changed, 96 insertions(+), 61 deletions(-) create mode 100644 tools/perf/tests/demangle-java-test.c -- 2.23.0 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
1 6
0 0
[PATCH kernel-4.19 1/4] itrace: Add interrupts trace support
by Yang Yingliang 18 May '21

18 May '21
From: Bixuan Cui <cuibixuan(a)huawei.com> ascend inclusion category: feature bugzilla: NA CVE: NA --------------------------------------------- Itrace (Interrupt Tracing) is a lightweight interrupt tracing tool. It supports the following functions: * Ihandler(Interrupt Handler) tracer can trace and calculate the time consumed of the hardware irq function and list the name, number and duration of the interrupt. * Ihandler supports dynamic disable and threshold setting. Signed-off-by: Bixuan Cui <cuibixuan(a)huawei.com> Reviewed-by: Ding Tianhong <dingtianhong(a)huawei.com> Reviewed-by: Hanjun Guo <guohanjun(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- include/linux/itrace.h | 47 ++++++++++ kernel/irq/handle.c | 3 + kernel/irq/proc.c | 100 +++++++++++++++++++++ kernel/trace/Kconfig | 22 +++++ kernel/trace/Makefile | 2 + kernel/trace/itrace_ihandler.c | 154 +++++++++++++++++++++++++++++++++ 6 files changed, 328 insertions(+) create mode 100644 include/linux/itrace.h create mode 100644 kernel/trace/itrace_ihandler.c diff --git a/include/linux/itrace.h b/include/linux/itrace.h new file mode 100644 index 0000000000000..d7916581e03f2 --- /dev/null +++ b/include/linux/itrace.h @@ -0,0 +1,47 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Copyright(c) 2021 Huawei Technologies Co., Ltd + * Author: Bixuan Cui <cuibixuan(a)huawei.com> + */ + +#ifndef __LINUX_ITRACE_H +#define __LINUX_ITRACE_H + +#define IRQ_NAME_LEN 20 +#define IHANDLER_INFO_NUM_MIN 1 +#define IHANDLER_INFO_NUM_MAX 30 +#define IHANDLER_INFO_CT_MAX 99999 +#define IHANDLER_THRESHOLD_MAX 10000000 +#define IHANDLER_OFF 0 +#define IHANDLER_ON 1 + +struct irq_handler_info { + int irq; + char name[IRQ_NAME_LEN]; + u64 t_max; + unsigned int ct; +}; + +struct Ihandler { + int front; + int num; + struct irq_handler_info info[IHANDLER_INFO_NUM_MAX]; +}; + +#ifdef CONFIG_ITRACE_IHANDLER +extern void itrace_ihandler_entry(void); +extern void itrace_ihandler_exit(int irq, const char *name); +extern void itrace_ihandler_set(u64 set); +extern void itrace_ihandler_get(struct Ihandler *ih, int cpu); +extern void itrace_ihandler_num_set(int set); +extern int itrace_ihandler_num_get(void); +#else +static inline void __maybe_unused itrace_ihandler_entry(void) +{ +}; +static inline void __maybe_unused itrace_ihandler_exit(int irq, const char *name) +{ +}; +#endif /* CONFIG_ITRACE_IHANDLER */ + +#endif /* __LINUX_ITRACE_H */ diff --git a/kernel/irq/handle.c b/kernel/irq/handle.c index 38554bc353755..95caa394df603 100644 --- a/kernel/irq/handle.c +++ b/kernel/irq/handle.c @@ -13,6 +13,7 @@ #include <linux/sched.h> #include <linux/interrupt.h> #include <linux/kernel_stat.h> +#include <linux/itrace.h> #include <trace/events/irq.h> @@ -146,7 +147,9 @@ irqreturn_t __handle_irq_event_percpu(struct irq_desc *desc, unsigned int *flags irqreturn_t res; trace_irq_handler_entry(irq, action); + itrace_ihandler_entry(); res = action->handler(irq, action->dev_id); + itrace_ihandler_exit(irq, action->name); trace_irq_handler_exit(irq, action, res); if (WARN_ONCE(!irqs_disabled(),"irq %u handler %pF enabled interrupts\n", diff --git a/kernel/irq/proc.c b/kernel/irq/proc.c index e8c655b7a4308..1d5b4b0154720 100644 --- a/kernel/irq/proc.c +++ b/kernel/irq/proc.c @@ -12,6 +12,7 @@ #include <linux/interrupt.h> #include <linux/kernel_stat.h> #include <linux/mutex.h> +#include <linux/itrace.h> #include "internals.h" @@ -299,6 +300,99 @@ static int irq_node_proc_show(struct seq_file *m, void *v) } #endif +#ifdef CONFIG_ITRACE_IHANDLER +static int itrace_ihandler_num_show(struct seq_file *m, void *v) +{ + seq_printf(m, "%d\n", itrace_ihandler_num_get()); + + return 0; +} + +static ssize_t itrace_ihandler_num_write(struct file *file, + const char __user *buffer, size_t count, loff_t *ppos) +{ + int ret; + int num; + + ret = kstrtoint_from_user(buffer, count, 10, &num); + if (ret) + return ret; + + if (num > IHANDLER_INFO_NUM_MAX || num < IHANDLER_INFO_NUM_MIN) + return -EINVAL; + + itrace_ihandler_num_set(num); + + return count; +} + +static int itrace_ihandler_num_open(struct inode *inode, struct file *file) +{ + return single_open(file, itrace_ihandler_num_show, PDE_DATA(inode)); +} + +static const struct file_operations itrace_ihandler_num_proc_fops = { + .open = itrace_ihandler_num_open, + .read = seq_read, + .release = single_release, + .write = itrace_ihandler_num_write, +}; + +static int itrace_ihandler_show(struct seq_file *m, void *v) +{ + unsigned int i, j; + struct Ihandler ihandler; + int online_cpus = num_online_cpus(); + + for (i = 0; i < online_cpus; i++) { + itrace_ihandler_get(&ihandler, i); + + /* print nothing while num is 0 */ + if (ihandler.num == 0) + return 0; + + seq_printf(m, "[irq_handler CPU%d]:\n", i); + for (j = 0; j < ihandler.num; j++) + seq_printf(m, " irq:%d name:%s max_time:%llu(us) count:%u\n", + ihandler.info[j].irq, ihandler.info[j].name, + ihandler.info[j].t_max / NSEC_PER_USEC, + ihandler.info[j].ct); + } + + return 0; +} + +static ssize_t itrace_ihandler_write(struct file *file, + const char __user *buffer, size_t count, loff_t *ppos) +{ + int ret; + u64 val; + + ret = kstrtoull_from_user(buffer, count, 10, &val); + if (ret) + return ret; + + if (val > IHANDLER_THRESHOLD_MAX) + return -EINVAL; + + itrace_ihandler_set(val); + + return count; +} + +static int itrace_ihandler_open(struct inode *inode, struct file *file) +{ + return single_open(file, itrace_ihandler_show, PDE_DATA(inode)); +} + +static const struct file_operations itrace_ihandler_proc_fops = { + .open = itrace_ihandler_open, + .read = seq_read, + .release = single_release, + .write = itrace_ihandler_write, +}; +#endif + static int irq_spurious_proc_show(struct seq_file *m, void *v) { struct irq_desc *desc = irq_to_desc((long) m->private); @@ -458,6 +552,12 @@ void init_irq_proc(void) */ for_each_irq_desc(irq, desc) register_irq_proc(irq, desc); +#ifdef CONFIG_ITRACE_IHANDLER + proc_create("irq/itrace_ihandler", 0644, NULL, + &itrace_ihandler_proc_fops); + proc_create("irq/itrace_ihandler_num", 0644, NULL, + &itrace_ihandler_num_proc_fops); +#endif } #ifdef CONFIG_GENERIC_IRQ_SHOW diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig index e656d1e232da4..5dd2e37f1aae0 100644 --- a/kernel/trace/Kconfig +++ b/kernel/trace/Kconfig @@ -788,5 +788,27 @@ config GCOV_PROFILE_FTRACE endif # FTRACE +menuconfig ITRACE + bool "Itrace Support" + help + Itrace(Interrupt Tracing) is a lightweight interrupt tracing + tool. + It can trace the areas that interrupt handler function and + disable interrupts. + +if ITRACE + +config ITRACE_IHANDLER + bool "Support for tracing the interrupt handler function" + default n + help + Ihandler(Interrupt Handler) tracer can trace and calculate + the time consumed of the hardware irq function and list the + name, number and duration of the interrupt. + + Support dynamic disable and threshold setting. + +endif #ITRACE + endif # TRACING_SUPPORT diff --git a/kernel/trace/Makefile b/kernel/trace/Makefile index f81dadbc7c4ac..231ce3c22ea4e 100644 --- a/kernel/trace/Makefile +++ b/kernel/trace/Makefile @@ -84,3 +84,5 @@ obj-$(CONFIG_UPROBE_EVENTS) += trace_uprobe.o obj-$(CONFIG_TRACEPOINT_BENCHMARK) += trace_benchmark.o libftrace-y := ftrace.o + +obj-$(CONFIG_ITRACE_IHANDLER) += itrace_ihandler.o diff --git a/kernel/trace/itrace_ihandler.c b/kernel/trace/itrace_ihandler.c new file mode 100644 index 0000000000000..906e2e0b1a0f8 --- /dev/null +++ b/kernel/trace/itrace_ihandler.c @@ -0,0 +1,154 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright(c) 2021 Huawei Technologies Co., Ltd + * Author: Bixuan Cui <cuibixuan(a)huawei.com> + */ + +#include <linux/init.h> +#include <linux/module.h> +#include <linux/kernel.h> +#include <linux/timer.h> +#include <linux/jiffies.h> +#include <linux/sched/clock.h> +#include <linux/itrace.h> +#include <linux/time64.h> + +static u64 threshold_value; +static int ihandler_info_num = 5; +static int ihandler_enable; + +static DEFINE_PER_CPU(struct Ihandler, ihandler); +static DEFINE_PER_CPU(u64, ihandler_entry); + +/* Per-cpu variable to prevent redundant calls when already entry handler */ +static DEFINE_PER_CPU(int, ihandle_flag); + +void itrace_ihandler_entry(void) +{ + if (ihandler_enable == IHANDLER_OFF) + return; + + if (!this_cpu_read(ihandle_flag)) { + this_cpu_write(ihandle_flag, 1); + + this_cpu_write(ihandler_entry, sched_clock()); + } +} + +static void itrace_insert_diff(int cpu, u64 diff, int irq, const char *name) +{ + int j, index, find = 0; + char *ihandler_name; + unsigned int ct; + u64 t_max; + int front = per_cpu(ihandler, cpu).front; + int num = per_cpu(ihandler, cpu).num; + + for (j = 0; j < num; j++) { + index = (front + j) % num; + if (per_cpu(ihandler, cpu).info[index].irq == irq) { + find = 1; + break; + } + } + + if (find != 0) { + t_max = per_cpu(ihandler, cpu).info[index].t_max; + ct = per_cpu(ihandler, cpu).info[index].ct + 1; + + per_cpu(ihandler, cpu).info[index].t_max = diff > t_max ? + diff : t_max; + per_cpu(ihandler, cpu).info[index].ct = ct > + IHANDLER_INFO_CT_MAX ? IHANDLER_INFO_CT_MAX : ct; + } else { + num = num + 1; + ihandler_name = per_cpu(ihandler, cpu).info[front].name; + + per_cpu(ihandler, cpu).info[front].irq = irq; + strncpy(ihandler_name, name, IRQ_NAME_LEN - 1); + ihandler_name[IRQ_NAME_LEN - 1] = '\0'; + per_cpu(ihandler, cpu).info[front].t_max = diff; + per_cpu(ihandler, cpu).front = (front + 1) % + ihandler_info_num; + per_cpu(ihandler, cpu).num = num > ihandler_info_num ? + ihandler_info_num : num; + per_cpu(ihandler, cpu).info[front].ct += 1; + + } +} + +void itrace_ihandler_exit(int irq, const char *name) +{ + u64 diff; + int cpu; + + if (ihandler_enable == IHANDLER_OFF) + return; + + if (this_cpu_read(ihandle_flag)) { + cpu = smp_processor_id(); + diff = sched_clock() - per_cpu(ihandler_entry, cpu); + + if (diff > threshold_value) + itrace_insert_diff(cpu, diff, irq, name); + + this_cpu_write(ihandle_flag, 0); + } +} + +void itrace_ihandler_set(u64 set) +{ + unsigned int i, j; + int online_cpus = num_online_cpus(); + + /* disable tracer and update threshold_value first */ + ihandler_enable = IHANDLER_OFF; + threshold_value = set * NSEC_PER_USEC; + + for (i = 0; i < online_cpus; i++) { + + per_cpu(ihandler, i).front = 0; + per_cpu(ihandler, i).num = 0; + for (j = 0; j < IHANDLER_INFO_NUM_MAX; j++) { + per_cpu(ihandler, i).info[j].irq = 0; + per_cpu(ihandler, i).info[j].name[0] = '\0'; + per_cpu(ihandler, i).info[j].t_max = 0; + per_cpu(ihandler, i).info[j].ct = 0; + } + + /* enable tracer */ + if (set != 0) { + per_cpu(ihandle_flag, i) = 0; + ihandler_enable = IHANDLER_ON; + } + } +} + +void itrace_ihandler_get(struct Ihandler *ih, int cpu) +{ + unsigned int j; + char *ihandler_name; + + for (j = 0; j < ihandler_info_num; j++) { + ihandler_name = per_cpu(ihandler, cpu).info[j].name; + + ih->num = per_cpu(ihandler, cpu).num; + ih->info[j].irq = per_cpu(ihandler, cpu).info[j].irq; + strncpy(ih->info[j].name, ihandler_name, IRQ_NAME_LEN); + ih->info[j].t_max = per_cpu(ihandler, cpu).info[j].t_max; + ih->info[j].ct = per_cpu(ihandler, cpu).info[j].ct; + } +} + +void itrace_ihandler_num_set(int set) +{ + ihandler_info_num = set; + + /* clear ihandler of per cpu while reset info_num */ + itrace_ihandler_set(threshold_value / NSEC_PER_USEC); +} + +int itrace_ihandler_num_get(void) +{ + return ihandler_info_num; +} -- 2.25.1
1 3
0 0
  • ← Newer
  • 1
  • ...
  • 1784
  • 1785
  • 1786
  • 1787
  • 1788
  • 1789
  • 1790
  • ...
  • 1870
  • Older →

HyperKitty Powered by HyperKitty