- Kernel - mailweb.openeuler.org

[PATCH openEuler-21.03] add return value check for acpi_get_table
by mpiglet 01 Sep '21

01 Sep '21

Signed-off-by: mpiglet <mpiglet(a)outlook.com> --- drivers/acpi/arm64/mpam.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/acpi/arm64/mpam.c b/drivers/acpi/arm64/mpam.c index 6c238f5a5c5a..fe870605f652 100644 --- a/drivers/acpi/arm64/mpam.c +++ b/drivers/acpi/arm64/mpam.c @@ -255,7 +255,7 @@ int __init acpi_mpam_parse(void) return -ENOENT; /* PPTT is optional, there may be no mpam cache controls */ - acpi_get_table(ACPI_SIG_PPTT, 0, &pptt); + status = acpi_get_table(ACPI_SIG_PPTT, 0, &pptt); if (ACPI_FAILURE(status)) pptt = NULL; -- 2.27.0

1 0

[PATCH openEuler-21.03] net: mdiobus: get rid of a BUG_ON()
by mpiglet 01 Sep '21

01 Sep '21

From: Dan Carpenter <dan.carpenter(a)oracle.com> stable inclusion from stable-v5.10.44 commit be23c4af3d8a1b986fe9b43b8966797653a76ca4 bugzilla: https://bugzilla.openeuler.org/show_bug.cgi?id=341 CVE: NA -------------------------------- [ Upstream commit 1dde47a66d4fb181830d6fa000e5ea86907b639e ] We spotted a bug recently during a review where a driver was unregistering a bus that wasn't registered, which would trigger this BUG_ON(). Let's handle that situation more gracefully, and just print a warning and return. Reported-by: Russell King (Oracle) <rmk+kernel(a)armlinux.org.uk> Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> Reviewed-by: Russell King (Oracle) <rmk+kernel(a)armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew(a)lunn.ch> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: wangqing <wangqing(a)uniontech.com> Reviewed-by: Xie XiuQi <xiexiuqi(a)huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai(a)huawei.com> --- drivers/net/phy/mdio_bus.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c index 757e950fb745..b848439fa837 100644 --- a/drivers/net/phy/mdio_bus.c +++ b/drivers/net/phy/mdio_bus.c @@ -608,7 +608,8 @@ void mdiobus_unregister(struct mii_bus *bus) struct mdio_device *mdiodev; int i; - BUG_ON(bus->state != MDIOBUS_REGISTERED); + if (WARN_ON_ONCE(bus->state != MDIOBUS_REGISTERED)) + return; bus->state = MDIOBUS_UNREGISTERED; for (i = 0; i < PHY_MAX_ADDR; i++) { -- 2.27.0

1 0

[PATCH openEuler-1.0-LTS 0/5] Introduce default passthrough
by Cheng Jian 01 Sep '21

01 Sep '21

Extended the SMMU_BYPASS_DEV to support SMMU default bypass for some CPU SoCs which the SMMU is not functional well in address translation mode. This patch set based on openEuler kernel LTS 1.0. Guo Hui (1): arm64: Add MIDR encoding for PHYTIUM CPUs Hanjun Guo (3): arm64: phytium: using MIDR_PHYTIUM_FT2000PLUS instead of ARM_CPU_IMP_PHYTIUM iommu: dev_bypass: cleanup dev bypass code iommu: smmuv2: Using the SMMU_BYPASS_DEV to bypass SMMU for some SoCs Weilong Chen (1): arm64: Add MIDR encoding for HiSilicon Taishan CPUs arch/arm64/include/asm/cputype.h | 7 +++++++ arch/arm64/kernel/topology.c | 6 +++--- drivers/iommu/Kconfig | 14 +++++++++++--- drivers/iommu/arm-smmu-v3.c | 2 +- drivers/iommu/arm-smmu.c | 28 ++++++++++++++++++++++++++++ drivers/iommu/iommu.c | 13 ++++--------- drivers/usb/host/xhci-pci.c | 4 +++- 7 files changed, 57 insertions(+), 17 deletions(-) -- 2.25.1

1 5

[PATCH openEuler-21.03] net: mdiobus: get rid of a BUG_ON()
by mpiglet 01 Sep '21

01 Sep '21

From: Dan Carpenter <dan.carpenter(a)oracle.com> stable inclusion from stable-v5.10.44 commit be23c4af3d8a1b986fe9b43b8966797653a76ca4 bugzilla: https://bugzilla.openeuler.org/show_bug.cgi?id=341 CVE: NA -------------------------------- [ Upstream commit 1dde47a66d4fb181830d6fa000e5ea86907b639e ] We spotted a bug recently during a review where a driver was unregistering a bus that wasn't registered, which would trigger this BUG_ON(). Let's handle that situation more gracefully, and just print a warning and return. Reported-by: Russell King (Oracle) <rmk+kernel(a)armlinux.org.uk> Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> Reviewed-by: Russell King (Oracle) <rmk+kernel(a)armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew(a)lunn.ch> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: wangqing <wangqing(a)uniontech.com> Reviewed-by: Xie XiuQi <xiexiuqi(a)huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai(a)huawei.com> --- drivers/net/phy/mdio_bus.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c index 757e950fb745..b848439fa837 100644 --- a/drivers/net/phy/mdio_bus.c +++ b/drivers/net/phy/mdio_bus.c @@ -608,7 +608,8 @@ void mdiobus_unregister(struct mii_bus *bus) struct mdio_device *mdiodev; int i; - BUG_ON(bus->state != MDIOBUS_REGISTERED); + if (WARN_ON_ONCE(bus->state != MDIOBUS_REGISTERED)) + return; bus->state = MDIOBUS_UNREGISTERED; for (i = 0; i < PHY_MAX_ADDR; i++) { -- 2.27.0

1 0

[PATCH kernel-4.19 0/4] Introduce default passthrough mode for
by Cheng Jian 01 Sep '21

01 Sep '21

Extended the SMMU_BYPASS_DEV to support SMMU default bypass for some CPU SoCs which the SMMU is not functional well in address translation mode. This is the version for 4.19 kernel. Guo Hui, if you didn't test patchset based on 1.0 LTS kernel, you can just apply this patch set instead. Guo Hui (1): arm64: Add MIDR encoding for PHYTIUM CPUs Hanjun Guo (3): arm64: phytium: using MIDR_PHYTIUM_FT2000PLUS instead of ARM_CPU_IMP_PHYTIUM iommu: dev_bypass: cleanup dev bypass code iommu: smmuv2: Using the SMMU_BYPASS_DEV to bypass SMMU for some SoCs arch/arm64/include/asm/cputype.h | 5 +++++ arch/arm64/kernel/topology.c | 6 +++--- drivers/iommu/Kconfig | 14 +++++++++++--- drivers/iommu/arm-smmu-v3.c | 2 +- drivers/iommu/arm-smmu.c | 28 ++++++++++++++++++++++++++++ drivers/iommu/iommu.c | 13 ++++--------- drivers/usb/host/xhci-pci.c | 4 +++- 7 files changed, 55 insertions(+), 17 deletions(-) -- 2.25.1

1 4

[PATCH kernel-4.19] sched: Fix sched_fork() access an invalid sched_task_group
by Yang Yingliang 01 Sep '21

01 Sep '21

From: Zhang Qiao <zhangqiao22(a)huawei.com> hulk inclusion category: bugfix bugzilla: 177205, https://gitee.com/openeuler/kernel/issues/I484Y1 CVE: NA -------------------------------- There is a small race between copy_process() and sched_fork() where child->sched_task_group point to an already freed pointer. parent doing fork() | someone moving the parent to another cgroup -------------------------------+------------------------------- copy_process() + dup_task_struct()<1> parent move to another cgroup, and free the old cgroup. <2> + sched_fork() + __set_task_cpu()<3> + task_fork_fair() + sched_slice()<4> In the worst case, this bug can lead to "use-after-free" and cause panic as shown above, (1)parent copy its sched_task_group to child at <1>; (2)someone move the parent to another cgroup and free the old cgroup at <2>; (3)the sched_task_group and cfs_rq that belong to the old cgroup will be accessed at <3> and <4>, which cause a panic: [89249.732198] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 [89249.732701] PGD 8000001fa0a86067 P4D 8000001fa0a86067 PUD 2029955067 PMD 0 [89249.733005] Oops: 0000 [#1] SMP PTI [89249.733288] CPU: 7 PID: 648398 Comm: ebizzy Kdump: loaded Tainted: G OE --------- - - 4.18.0.x86_64+ #1 [89249.734318] RIP: 0010:sched_slice+0x84/0xc0 .... [89249.737910] Call Trace: [89249.738181] task_fork_fair+0x81/0x120 [89249.738457] sched_fork+0x132/0x240 [89249.738732] copy_process.part.5+0x675/0x20e0 [89249.739010] ? __handle_mm_fault+0x63f/0x690 [89249.739286] _do_fork+0xcd/0x3b0 [89249.739558] do_syscall_64+0x5d/0x1d0 [89249.739830] entry_SYSCALL_64_after_hwframe+0x65/0xca [89249.740107] RIP: 0033:0x7f04418cd7e1 When a new process is forked, cgroup_post_fork() associates it with the cgroup of its parent. Therefore this commit move the __set_task_cpu() and task_fork() that access some cgroup-related fields(sched_task_group and cfs_rq) to sched_post_fork() and call sched_post_fork() after cgroup_post_fork(). Fixes: 8323f26ce342 ("sched: Fix race in task_group") Signed-off-by: Zhang Qiao <zhangqiao22(a)huawei.com> Reviewed-by: Chen Hui <judy.chenhui(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- include/linux/sched/task.h | 1 + kernel/fork.c | 1 + kernel/sched/core.c | 36 ++++++++++++++++++++---------------- 3 files changed, 22 insertions(+), 16 deletions(-) diff --git a/include/linux/sched/task.h b/include/linux/sched/task.h index 44c6f15800ff5..5046980ecb0f8 100644 --- a/include/linux/sched/task.h +++ b/include/linux/sched/task.h @@ -33,6 +33,7 @@ extern asmlinkage void schedule_tail(struct task_struct *prev); extern void init_idle(struct task_struct *idle, int cpu); extern int sched_fork(unsigned long clone_flags, struct task_struct *p); +extern void sched_post_fork(struct task_struct *p); extern void sched_dead(struct task_struct *p); void __noreturn do_task_dead(void); diff --git a/kernel/fork.c b/kernel/fork.c index e306f8925008b..403b8a3315979 100644 --- a/kernel/fork.c +++ b/kernel/fork.c @@ -2158,6 +2158,7 @@ static __latent_entropy struct task_struct *copy_process( proc_fork_connector(p); cgroup_post_fork(p); + sched_post_fork(p); cgroup_threadgroup_change_end(current); perf_event_fork(p); diff --git a/kernel/sched/core.c b/kernel/sched/core.c index e362fe5c84b66..d0d6153df7357 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -2348,8 +2348,6 @@ static inline void init_schedstats(void) {} */ int sched_fork(unsigned long clone_flags, struct task_struct *p) { - unsigned long flags; - __sched_fork(clone_flags, p); /* * We mark the process as NEW here. This guarantees that @@ -2393,6 +2391,26 @@ int sched_fork(unsigned long clone_flags, struct task_struct *p) init_entity_runnable_average(&p->se); +#ifdef CONFIG_SCHED_INFO + if (likely(sched_info_on())) + memset(&p->sched_info, 0, sizeof(p->sched_info)); +#endif +#if defined(CONFIG_SMP) + p->on_cpu = 0; +#endif + init_task_preempt_count(p); +#ifdef CONFIG_SMP + plist_node_init(&p->pushable_tasks, MAX_PRIO); + RB_CLEAR_NODE(&p->pushable_dl_tasks); +#endif + + return 0; +} + +void sched_post_fork(struct task_struct *p) +{ + unsigned long flags; + /* * The child is not yet in the pid-hash so no cgroup attach races, * and the cgroup is pinned to this child due to cgroup_fork() @@ -2410,20 +2428,6 @@ int sched_fork(unsigned long clone_flags, struct task_struct *p) if (p->sched_class->task_fork) p->sched_class->task_fork(p); raw_spin_unlock_irqrestore(&p->pi_lock, flags); - -#ifdef CONFIG_SCHED_INFO - if (likely(sched_info_on())) - memset(&p->sched_info, 0, sizeof(p->sched_info)); -#endif -#if defined(CONFIG_SMP) - p->on_cpu = 0; -#endif - init_task_preempt_count(p); -#ifdef CONFIG_SMP - plist_node_init(&p->pushable_tasks, MAX_PRIO); - RB_CLEAR_NODE(&p->pushable_dl_tasks); -#endif - return 0; } unsigned long to_ratio(u64 period, u64 runtime) -- 2.25.1

1 0

【Meeting Notice】openEuler kernel 技术分享第十一期 & 双周例会 Time: 2021-09-03 14:00-17:00
by Meeting Book 31 Aug '21

31 Aug '21

1 0

[PATCH openEuler-1.0-LTS 1/2] KVM: nSVM: always intercept VMLOAD/VMSAVE when nested (CVE-2021-3656)
by Yang Yingliang 31 Aug '21

31 Aug '21

From: Maxim Levitsky <mlevitsk(a)redhat.com> stable inclusion from linux-4.19.205 commit 119d547cbf7c055ba8100309ad71910478092f24 CVE: CVE-2021-3656 -------------------------------- [ upstream commit c7dfa4009965a9b2d7b329ee970eb8da0d32f0bc ] If L1 disables VMLOAD/VMSAVE intercepts, and doesn't enable Virtual VMLOAD/VMSAVE (currently not supported for the nested hypervisor), then VMLOAD/VMSAVE must operate on the L1 physical memory, which is only possible by making L0 intercept these instructions. Failure to do so allowed the nested guest to run VMLOAD/VMSAVE unintercepted, and thus read/write portions of the host physical memory. Fixes: 89c8a4984fc9 ("KVM: SVM: Enable Virtual VMLOAD VMSAVE feature") Suggested-by: Paolo Bonzini <pbonzini(a)redhat.com> Signed-off-by: Maxim Levitsky <mlevitsk(a)redhat.com> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> 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> --- arch/x86/kvm/svm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c index 464e271dc354d..1076dc1bd92ae 100644 --- a/arch/x86/kvm/svm.c +++ b/arch/x86/kvm/svm.c @@ -513,6 +513,9 @@ static void recalc_intercepts(struct vcpu_svm *svm) c->intercept_dr = h->intercept_dr | g->intercept_dr; c->intercept_exceptions = h->intercept_exceptions | g->intercept_exceptions; c->intercept = h->intercept | g->intercept; + + c->intercept |= (1ULL << INTERCEPT_VMLOAD); + c->intercept |= (1ULL << INTERCEPT_VMSAVE); } static inline struct vmcb *get_host_vmcb(struct vcpu_svm *svm) -- 2.25.1

1 1

转发: 转发: 请教一下，想提交一个内核的补丁，怎么操作，谢谢。（补丁内容见内）
by 徐力群 31 Aug '21

31 Aug '21

kernel@openeuler.org邮件已经订阅成功了（华为汪少博帮忙后台处理了一下），我现在重新发一下邮件。谢谢。请帮忙审阅补丁。发件人: 徐力群发送时间: 2021年8月30日 9:13 收件人: Xie XiuQi <xiexiuqi(a)huawei.com>; kernel(a)openeuler.org 抄送: Cheng Jian <cj.chengjian(a)huawei.com>; 曲维杰 <quweijie(a)huayun.com> 主题: 回复: 转发: 请教一下，想提交一个内核的补丁，怎么操作，谢谢。（补丁内容见内）这个是增加了bugzilla链接地址的补丁，之前可能重复发了几次（一直以为发送失败了）。谢谢。附件包括补丁合入后的测试方法和结果。 https://gitee.com/openeuler/kernel/issues/I47ITN 【标题描述】guest OS内删除文件，从host角度看guest的磁盘文件没有变小发件人: Xie XiuQi <xiexiuqi(a)huawei.com<mailto:xiexiuqi@huawei.com>> 发送时间: 2021年8月27日 22:32 收件人: 徐力群 <xuliqun(a)huayun.com<mailto:xuliqun@huayun.com>>; kernel(a)openeuler.org<mailto:kernel@openeuler.org> 抄送: Cheng Jian <cj.chengjian(a)huawei.com<mailto:cj.chengjian@huawei.com>> 主题: Re: 转发: 请教一下，想提交一个内核的补丁，怎么操作，谢谢。（补丁内容见内）你好，非常欢迎参与 openEuler kernel 开发。首先在这里提交 issue，描述下要解决什么问题。 https://gitee.com/openeuler/kernel/issues 补丁的 Commit Message 中附上对应的 issue 链接，如在bugzila 行添加： bugzilla: https://gitee.com/openeuler/kernel/issues/I3DJ83 然后将适配之后的补丁发往 kernel(a)openeuler.org<mailto:kernel@openeuler.org>, 有问题可以联系我或 Cheng Jian. --- Xie XiuQi On 2021/8/27 14:18, 徐力群 wrote: 发件人: 徐力群发送时间: 2021年8月27日 14:18 收件人: kernel-owner(a)openeuler.org<mailto:kernel-owner@openeuler.org>； <kernel-owner(a)openeuler.org;><mailto:kernel-owner@openeuler.org;>; kernel(a)openeuler.org<mailto:kernel@openeuler.org> 主题: 请教一下，想提交一个内核的补丁，怎么操作，谢谢。（补丁内容见内）该补丁打上之后，guest如果删除了磁盘的文件，那么从host上看磁盘文件会变小。 virtio_blk: add discard and write zeroes support mainline inclusion from mainline-5.14-rc7 commit 1f23816b8eb8fdc39990abe166c10a18c16f6b21、af822aa68fbdf0a480a17462ed70232998127453 category: bugfix bugzilla: NA CVE: NA ------------------------------------------------- from： https://github.com/torvalds/linux/commit/1f23816b8eb8fdc39990abe166c10a18c1… https://github.com/torvalds/linux/commit/af822aa68fbdf0a480a17462ed70232998… In commit 88c85538, "virtio-blk: add discard and write zeroes features to specification" (https://github.com/oasis-tcs/virtio-spec) the virtio block specification has been extended to add VIRTIO_BLK_T_DISCARD and VIRTIO_BLK_T_WRITE_ZEROES commands. This patch enables support for discard and write zeroes in the virtio-blk driver when the device advertises the corresponding features, VIRTIO_BLK_F_DISCARD and VIRTIO_BLK_F_WRITE_ZEROES.

2 3

Re: 转发: 转发: 请教一下，想提交一个内核的补丁，怎么操作，谢谢。（补丁内容见内）
by Xie XiuQi 31 Aug '21

31 Aug '21

On 2021/8/31 9:58, 仇大玉 wrote: > @Xie XiuQi 请问是不是遵循kernel社区的发送方式，使用git send-email的方式参与OpenEuler的kernel提交是的，发到 kernel(a)openeuler.org 即可。发送前，先订阅一下邮件列表。 > > -----Original Message----- > From: 徐力群 <xuliqun(a)huayun.com> > Sent: 2021年8月31日 9:49 > To: chengjian (D) <cj.chengjian(a)huawei.com>; kernel(a)openeuler.org; Xie XiuQi <xiexiuqi(a)huawei.com> > Cc: 曲维杰 <quweijie(a)huayun.com>; 仇大玉 <qiudayu(a)huayun.com> > Subject: 回复: 转发: 转发: 请教一下，想提交一个内核的补丁，怎么操作，谢谢。（补丁内容见内） > > 请看附件，是这个吗？ > 我是收到这个邮件之后再次转发的。 > 难道还需要等待一段时间才能彻底激活？ > > > -----邮件原件----- > 发件人: chengjian (D) <cj.chengjian(a)huawei.com> > 发送时间: 2021年8月30日 20:38 > 收件人: 徐力群 <xuliqun(a)huayun.com>; kernel(a)openeuler.org; Xie XiuQi <xiexiuqi(a)huawei.com> > 抄送: 曲维杰 <quweijie(a)huayun.com>; 仇大玉 <qiudayu(a)huayun.com>; chengjian (D) <cj.chengjian(a)huawei.com> > 主题: Re: 转发: 转发: 请教一下，想提交一个内核的补丁，怎么操作，谢谢。（补丁内容见内） > > > On 2021/8/30 11:10, 徐力群 wrote: >> kernel@openeuler.org邮件已经订阅成功了（华为汪少博帮忙后台处理了一下）， >> >> 我现在重新发一下邮件。谢谢。请帮忙审阅补丁。 >> > 您好，冒昧打扰。 > > > 我这边以及邮件列表仍然没有您那边发送的邮件(PATCH)。 > > 请问您邮件已经发送了么。 > > 如果您发送了，请确认下邮件列表是否订阅成功，以及邮件是否发送成功。（一般来说，邮件被邮件列表墙掉会有一封提醒邮件的）。 > > 谢谢 > > ---- 成坚 > > >> On 2021/8/27 14:18, 徐力群wrote: >> >> *发件人:*徐力群 >> *发送时间:*2021年8月27日14:18 >> *收件人:*kernel-owner@openeuler.org； <kernel-owner(a)openeuler.org;> >> <mailto:kernel-owner@openeuler.org;>; kernel(a)openeuler.org >> *主题:*请教一下，想提交一个内核的补丁，怎么操作，谢谢。（补丁内容见内） >> >> 该补丁打上之后，guest如果删除了磁盘的文件，那么从host上看磁盘文件会变小。 >> >> virtio_blk: add discard and write zeroes support >> >> mainline inclusion >> >> from mainline-5.14-rc7 >> >> commit >> 1f23816b8eb8fdc39990abe166c10a18c16f6b21、af822aa68fbdf0a480a17462ed70232998127453 >> >> category: bugfix >> >> bugzilla: NA >> >> CVE: NA >> >> ------------------------------------------------- >> >> from： >> >> https://github.com/torvalds/linux/commit/1f23816b8eb8fdc39990abe166c10a18c1… >> >> https://github.com/torvalds/linux/commit/af822aa68fbdf0a480a17462ed70232998… >> >> In commit 88c85538, "virtio-blk: add discard and write zeroes features >> >> to specification" (https://github.com/oasis-tcs/virtio-spec) the >> virtio >> >> block specification has been extended to add VIRTIO_BLK_T_DISCARD and >> >> VIRTIO_BLK_T_WRITE_ZEROES commands. This patch enables support for >> >> discard and write zeroes in the virtio-blk driver when the device >> >> advertises the corresponding features, VIRTIO_BLK_F_DISCARD and >> >> VIRTIO_BLK_F_WRITE_ZEROES. >>

1 0