- Kernel - mailweb.openeuler.org

[PATCH openEuler-1.0-LTS] net/sched: sch_qfq: account for stab overhead in qfq_enqueue
by Zhengchao Shao 25 Jul '23

25 Jul '23

From: Pedro Tammela <pctammela(a)mojatatu.com> mainline inclusion from mainline-v6.5-rc2 commit 3e337087c3b5805fe0b8a46ba622a962880b5d64 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7N3MX CVE: CVE-2023-3611 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- Lion says: ------- In the QFQ scheduler a similar issue to CVE-2023-31436 persists. Consider the following code in net/sched/sch_qfq.c: static int qfq_enqueue(struct sk_buff *skb, struct Qdisc *sch, struct sk_buff **to_free) { unsigned int len = qdisc_pkt_len(skb), gso_segs; // ... if (unlikely(cl->agg->lmax < len)) { pr_debug("qfq: increasing maxpkt from %u to %u for class %u", cl->agg->lmax, len, cl->common.classid); err = qfq_change_agg(sch, cl, cl->agg->class_weight, len); if (err) { cl->qstats.drops++; return qdisc_drop(skb, sch, to_free); } // ... } Similarly to CVE-2023-31436, "lmax" is increased without any bounds checks according to the packet length "len". Usually this would not impose a problem because packet sizes are naturally limited. This is however not the actual packet length, rather the "qdisc_pkt_len(skb)" which might apply size transformations according to "struct qdisc_size_table" as created by "qdisc_get_stab()" in net/sched/sch_api.c if the TCA_STAB option was set when modifying the qdisc. A user may choose virtually any size using such a table. As a result the same issue as in CVE-2023-31436 can occur, allowing heap out-of-bounds read / writes in the kmalloc-8192 cache. ------- We can create the issue with the following commands: tc qdisc add dev $DEV root handle 1: stab mtu 2048 tsize 512 mpu 0 \ overhead 999999999 linklayer ethernet qfq tc class add dev $DEV parent 1: classid 1:1 htb rate 6mbit burst 15k tc filter add dev $DEV parent 1: matchall classid 1:1 ping -I $DEV 1.1.1.2 This is caused by incorrectly assuming that qdisc_pkt_len() returns a length within the QFQ_MIN_LMAX < len < QFQ_MAX_LMAX. Fixes: 462dbc9101ac ("pkt_sched: QFQ Plus: fair-queueing service at DRR cost") Reported-by: Lion <nnamrec(a)gmail.com> Reviewed-by: Eric Dumazet <edumazet(a)google.com> Signed-off-by: Jamal Hadi Salim <jhs(a)mojatatu.com> Signed-off-by: Pedro Tammela <pctammela(a)mojatatu.com> Reviewed-by: Simon Horman <simon.horman(a)corigine.com> Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Conflicts: net/sched/sch_qfq.c Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- net/sched/sch_qfq.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/net/sched/sch_qfq.c b/net/sched/sch_qfq.c index 0326793b700b..a08579a5f75e 100644 --- a/net/sched/sch_qfq.c +++ b/net/sched/sch_qfq.c @@ -116,6 +116,7 @@ #define QFQ_MTU_SHIFT 16 /* to support TSO/GSO */ #define QFQ_MIN_LMAX 512 /* see qfq_slot_insert */ +#define QFQ_MAX_LMAX (1UL << QFQ_MTU_SHIFT) #define QFQ_MAX_AGG_CLASSES 8 /* max num classes per aggregate allowed */ @@ -387,8 +388,13 @@ static int qfq_change_agg(struct Qdisc *sch, struct qfq_class *cl, u32 weight, u32 lmax) { struct qfq_sched *q = qdisc_priv(sch); - struct qfq_aggregate *new_agg = qfq_find_agg(q, lmax, weight); + struct qfq_aggregate *new_agg; + /* 'lmax' can range from [QFQ_MIN_LMAX, pktlen + stab overhead] */ + if (lmax > QFQ_MAX_LMAX) + return -EINVAL; + + new_agg = qfq_find_agg(q, lmax, weight); if (new_agg == NULL) { /* create new aggregate */ new_agg = kzalloc(sizeof(*new_agg), GFP_ATOMIC); if (new_agg == NULL) -- 2.34.1

2 1

[PATCH OLK-5.10] arm64/mpam: fix missing kfree domain's ctrl_val arrray
by Jialin Zhang 25 Jul '23

25 Jul '23

From: Wang ShaoBo <bobo.shaobowang(a)huawei.com> hulk inclusion category: bugfix bugzilla: 187154, https://gitee.com/openeuler/kernel/issues/I7M52S CVE: NA -------------------------------- Fix mpam memleak issue found by kmemleak: unreferenced object 0xffff204000d1d000 (size 128): comm "cpuhp/24", pid 132, jiffies 4294896121 (age 146328.256s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000dd76fed3>] __kmalloc+0x478/0x664 [<00000000e2fa4b32>] mpam_resctrl_setup_domain+0x290/0x5d0 [<0000000088adc589>] mpam_resctrl_cpu_online+0x14c/0x1d0 [<00000000b223bfaa>] mpam_cpu_online+0x1c8/0x2e4 [<000000004438534a>] cpuhp_invoke_callback+0x1f4/0x11b0 [<0000000049ede841>] cpuhp_thread_fun+0x2b8/0x510 [<000000000d731c73>] smpboot_thread_fn+0x260/0x5a0 [<0000000093c61bad>] kthread+0x27c/0x350 [<00000000379f0572>] ret_from_fork+0x10/0x18 There are two cases causing memleak: 1. When offline all cpus of a domain in mpam_resctrl_cpu_offline(), we only free domain's space but not the space of ctrl_val array. 2. When allocating ctrl_val array failed in mpam_resctrl_setup_domain(), the space of ctrl_val array may not be freed. Fixes: e1ff5fac8ffc ("arm64/mpam: resctrl: Handle cpuhp and resctrl_dom allocation") Signed-off-by: Wang ShaoBo <bobo.shaobowang(a)huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11(a)huawei.com> --- arch/arm64/kernel/mpam/mpam_setup.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/arch/arm64/kernel/mpam/mpam_setup.c b/arch/arm64/kernel/mpam/mpam_setup.c index cef66a5e6f2f..4d0ec0052133 100644 --- a/arch/arm64/kernel/mpam/mpam_setup.c +++ b/arch/arm64/kernel/mpam/mpam_setup.c @@ -65,7 +65,7 @@ static int mpam_resctrl_setup_domain(unsigned int cpu, struct mpam_component *comp_iter, *comp; u32 num_partid; u32 **ctrlval_ptr; - enum resctrl_ctrl_type type; + enum resctrl_ctrl_type type, type_free; struct list_head *tmp; num_partid = mpam_sysprops_num_partid(); @@ -96,6 +96,12 @@ static int mpam_resctrl_setup_domain(unsigned int cpu, *ctrlval_ptr = kmalloc_array(num_partid, sizeof(**ctrlval_ptr), GFP_KERNEL); if (!*ctrlval_ptr) { + for_each_ctrl_type(type_free) { + if (type_free == type) + break; + ctrlval_ptr = &dom->resctrl_dom.ctrl_val[type_free]; + kfree(*ctrlval_ptr); + } kfree(dom); return -ENOMEM; } @@ -156,6 +162,8 @@ int mpam_resctrl_cpu_offline(unsigned int cpu) struct rdt_domain *d; struct mpam_resctrl_res *res; struct mpam_resctrl_dom *dom; + u32 **ctrlval_ptr; + enum resctrl_ctrl_type type; for_each_supported_resctrl_exports(res) { d = resctrl_get_domain_from_cpu(cpu, &res->resctrl_res); @@ -171,6 +179,11 @@ int mpam_resctrl_cpu_offline(unsigned int cpu) list_del(&d->list); dom = container_of(d, struct mpam_resctrl_dom, resctrl_dom); + for_each_ctrl_type(type) { + ctrlval_ptr = &dom->resctrl_dom.ctrl_val[type]; + kfree(*ctrlval_ptr); + } + kfree(dom); res->resctrl_res.dom_num--; -- 2.25.1

2 1

Re: [RFC 1/1] Optimizing the rand function on arm64 platforms
by tiantao (H) 24 Jul '23

24 Jul '23

在 2023/7/24 12:49, Xi Ruoyao 写道: > On Mon, 2023-07-24 at 04:01 +0000, tiantao (H) wrote: >> Thanks for the reply. >> >> Using FEAT_RNG can be a very big performance boost > Hmm, I think this may be untrue. I've attempted using inline asm to > invoke x86 rdrand instead of rand() for some competitive programming > code, but the result is *slower*. Thanks for the reply, I tested the performance on an ARM64 server very well, especially in multithreaded scenarios > The spec of this instruction [1] even says: > > If the instruction cannot return a genuine random number in a reasonable > period of time, PSTATE.NZCV is set to 0b0100 and the data value returned > is 0. > > So at least for some implementations the "reasonable period of time" may > be long. And we need to check PSTATE.NZCV and loop (or fallback to a > software-based PRNG), then it will be even slower... > > [1]:https://developer.arm.com/documentation/ddi0601/2023-06/AArch64-Register… > > Generally a hardware RNG is for cryptography use, so the design of HWRNG > is often focused on security, instead of speed. Maybe it is fast on > *your* implementation, and it may never fail on *your* implementation, > but other implementations may do things differently. > >> any suggestions for applying the FEAT_RNG feature to glibc? > The suggestion is "don't do that". > > A feature is not necessarily useful for Glibc only because it exists. >

1 0

[PATCH OLK-5.10 v3 0/8] enable bonding XDP
by Zhengchao Shao 24 Jul '23

24 Jul '23

Currently, the 10G 82599 network adapter is used for the test on the Intel(R) Xeon(R) Gold 6138 CPU @ 2.00 GHz platform. The peer end uses the pktgen of the dpdk to send 64 bytes packets. The test performance is as follows: -----------------------| CPU |--| rxpck/s |--| txpck/s |---- without patch (1 dev): XDP_DROP: 1.00% 14.69Mpps XDP_TX: 2.20% 10.70Mpps 10.70Mpps XDP_DROP (RSS): 1.90% 10.13Mpps XDP_TX (RSS): 6.20% 10.09Mpps 10.09Mpps ----------------------- with patch, bond (1 dev): XDP_DROP: 1.00% 14.69Mpps XDP_TX: 2.10% 6.84Mpps 6.84Mpps XDP_DROP (RSS): 2.00% 10.20pps XDP_TX (RSS): 8.40% 10.17Mpps 10.17Mpps ----------------------- with patch, bond (2 devs): XDP_DROP: 1.90% 29.3Mpps XDP_TX: 4.20% 11.31Mpps 11.31Mpps XDP_DROP (RSS): 3.90% 20.40Mpps XDP_TX (RSS): 16.80% 18.55Mpps 18.55Mpps -------------------------------------------------------------- Jonathan Toppins (1): bonding: fix NULL deref in bond_rr_gen_slave_id Jussi Maki (5): net, bonding: Refactor bond_xmit_hash for use with xdp_buff net, core: Add support for XDP redirection to slave device net, bonding: Add XDP support to the bonding driver bonding: Fix negative jump label count on nested bonding net: bonding: Use per-cpu rr_tx_counter Moshe Tal (1): bonding: Fix extraction of ports from the packet headers Zhengchao Shao (1): net: fix kabi change in struct net_device_ops drivers/net/bonding/bond_main.c | 457 ++++++++++++++++++++++++++++---- include/linux/filter.h | 13 +- include/linux/netdevice.h | 7 +- include/net/bonding.h | 3 +- net/core/dev.c | 13 +- net/core/filter.c | 25 ++ 6 files changed, 456 insertions(+), 62 deletions(-) -- 2.34.1

2 9

[PATCH OLK-5.10 0/5] enable bonding XDP
by Zhengchao Shao 24 Jul '23

24 Jul '23

Currently, the 10G 82599 network adapter is used for the test on the Intel(R) Xeon(R) Gold 6138 CPU @ 2.00 GHz platform. The peer end uses the pktgen of the dpdk to send 64 bytes packets. The test performance is as follows: -----------------------| CPU |--| rxpck/s |--| txpck/s |---- without patch (1 dev): XDP_DROP: 1.00% 14.69Mpps XDP_TX: 2.20% 10.70Mpps 10.70Mpps XDP_DROP (RSS): 1.90% 10.13Mpps XDP_TX (RSS): 6.20% 10.09Mpps 10.09Mpps ----------------------- with patch, bond (1 dev): XDP_DROP: 1.00% 14.69Mpps XDP_TX: 2.10% 6.84Mpps 6.84Mpps XDP_DROP (RSS): 2.00% 10.20pps XDP_TX (RSS): 8.40% 10.17Mpps 10.17Mpps ----------------------- with patch, bond (2 devs): XDP_DROP: 1.90% 29.3Mpps XDP_TX: 4.20% 11.31Mpps 11.31Mpps XDP_DROP (RSS): 3.90% 20.40Mpps XDP_TX (RSS): 16.80% 18.55Mpps 18.55Mpps -------------------------------------------------------------- Jussi Maki (5): net, bonding: Refactor bond_xmit_hash for use with xdp_buff net, core: Add support for XDP redirection to slave device net, bonding: Add XDP support to the bonding driver bonding: Fix negative jump label count on nested bonding net: bonding: Use per-cpu rr_tx_counter drivers/net/bonding/bond_main.c | 460 ++++++++++++++++++++++++++++---- include/linux/filter.h | 13 +- include/linux/netdevice.h | 6 + include/net/bonding.h | 3 +- net/core/dev.c | 13 +- net/core/filter.c | 25 ++ 6 files changed, 459 insertions(+), 61 deletions(-) -- 2.34.1

1 6

[PATCH OLK-5.10 v2 0/6] enable bonding XDP
by Zhengchao Shao 24 Jul '23

24 Jul '23

Currently, the 10G 82599 network adapter is used for the test on the Intel(R) Xeon(R) Gold 6138 CPU @ 2.00 GHz platform. The peer end uses the pktgen of the dpdk to send 64 bytes packets. The test performance is as follows: -----------------------| CPU |--| rxpck/s |--| txpck/s |---- without patch (1 dev): XDP_DROP: 1.00% 14.69Mpps XDP_TX: 2.20% 10.70Mpps 10.70Mpps XDP_DROP (RSS): 1.90% 10.13Mpps XDP_TX (RSS): 6.20% 10.09Mpps 10.09Mpps ----------------------- with patch, bond (1 dev): XDP_DROP: 1.00% 14.69Mpps XDP_TX: 2.10% 6.84Mpps 6.84Mpps XDP_DROP (RSS): 2.00% 10.20pps XDP_TX (RSS): 8.40% 10.17Mpps 10.17Mpps ----------------------- with patch, bond (2 devs): XDP_DROP: 1.90% 29.3Mpps XDP_TX: 4.20% 11.31Mpps 11.31Mpps XDP_DROP (RSS): 3.90% 20.40Mpps XDP_TX (RSS): 16.80% 18.55Mpps 18.55Mpps -------------------------------------------------------------- Jussi Maki (5): net, bonding: Refactor bond_xmit_hash for use with xdp_buff net, core: Add support for XDP redirection to slave device net, bonding: Add XDP support to the bonding driver bonding: Fix negative jump label count on nested bonding net: bonding: Use per-cpu rr_tx_counter Zhengchao Shao (1): net: fix kabi change in struct net_device_ops drivers/net/bonding/bond_main.c | 460 ++++++++++++++++++++++++++++---- include/linux/filter.h | 13 +- include/linux/netdevice.h | 7 +- include/net/bonding.h | 3 +- net/core/dev.c | 13 +- net/core/filter.c | 25 ++ 6 files changed, 459 insertions(+), 62 deletions(-) -- 2.34.1

2 7

[PATCH OLK-5.10 0/5] enable bonding XDP
by Zhengchao Shao 24 Jul '23

24 Jul '23

Currently, the 10G 82599 network adapter is used for the test on the Intel(R) Xeon(R) Gold 6138 CPU @ 2.00 GHz platform. The peer end uses the pktgen of the dpdk to send 64 bytes packets. The test performance is as follows: -----------------------| CPU |--| rxpck/s |--| txpck/s |---- without patch (1 dev): XDP_DROP: 1.00% 14.69Mpps XDP_TX: 2.20% 10.70Mpps 10.70Mpps XDP_DROP (RSS): 1.90% 10.13Mpps XDP_TX (RSS): 6.20% 10.09Mpps 10.09Mpps ----------------------- with patch, bond (1 dev): XDP_DROP: 1.00% 14.69Mpps XDP_TX: 2.10% 6.84Mpps 6.84Mpps XDP_DROP (RSS): 2.00% 10.20pps XDP_TX (RSS): 8.40% 10.17Mpps 10.17Mpps ----------------------- with patch, bond (2 devs): XDP_DROP: 1.90% 29.3Mpps XDP_TX: 4.20% 11.31Mpps 11.31Mpps XDP_DROP (RSS): 3.90% 20.40Mpps XDP_TX (RSS): 16.80% 18.55Mpps 18.55Mpps -------------------------------------------------------------- Jussi Maki (5): net, bonding: Refactor bond_xmit_hash for use with xdp_buff net, core: Add support for XDP redirection to slave device net, bonding: Add XDP support to the bonding driver bonding: Fix negative jump label count on nested bonding net: bonding: Use per-cpu rr_tx_counter drivers/net/bonding/bond_main.c | 460 ++++++++++++++++++++++++++++---- include/linux/filter.h | 13 +- include/linux/netdevice.h | 6 + include/net/bonding.h | 3 +- net/core/dev.c | 13 +- net/core/filter.c | 25 ++ 6 files changed, 459 insertions(+), 61 deletions(-) -- 2.34.1

2 6

[PATCH openEuler-22.03-LTS 0/2] Fix CDM node problems
by Zhang Zekun 24 Jul '23

24 Jul '23

Fix problem introduced by feature CDM node, which might alloc memory from other no cdm nodes. Zhou Guanghui (2): mm: fix ignore cpuset enforcement mm: fix alloc CDM node memory for MPOL_BIND mm/page_alloc.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) -- 2.17.1

2 3

答复: [RFC 1/1] Optimizing the rand function on arm64 platforms
by tiantao (H) 24 Jul '23

24 Jul '23

Thanks for the reply. Using FEAT_RNG can be a very big performance boost, any suggestions for applying the FEAT_RNG feature to glibc? -----邮件原件----- 发件人: Xi Ruoyao <xry111(a)xry111.site> 发送时间: 2023年7月24日 11:50 收件人: tiantao (H) <tiantao6(a)hisilicon.com>; libc-alpha(a)sourceware.org 抄送: kernel(a)openeuler.org 主题: Re: [RFC 1/1] Optimizing the rand function on arm64 platforms On Mon, 2023-07-24 at 10:32 +0800, Tian Tao via Libc-alpha wrote: > Armv8.5 adds the FEAT_RNG feature so that true random numbers can be > obtained from the cpu. This optimization is therefore proposed for the > arm64 platform. NAK. Glibc documentation explicitly says: You can obtain repeatable sequences of numbers on a particular machine type by specifying the same initial seed value for the random number generator. This rand() implementation obviously does not satisfy this requirement. > > Signed-off-by: Tian Tao <tiantao6(a)hisilicon.com> > --- > stdlib/rand.c | 32 ++++++++++++++++++++++++++++++++ > 1 file changed, 32 insertions(+) > > diff --git a/stdlib/rand.c b/stdlib/rand.c index > c250c065e4..f199dbd65f 100644 > --- a/stdlib/rand.c > +++ b/stdlib/rand.c > @@ -19,10 +19,42 @@ > > #undef rand > > +#ifdef __aarch64__ > +// A global variable to indicate whether rndr instruction is > supported > +static int rndr_supported = 0; > +// A function prototype to check rndr support static void > +check_rndr_support (void) __attribute__ ((constructor)); #endif > > /* Return a random integer between 0 and RAND_MAX. */ > int > rand (void) > { > + // Use armv8.5 rndr instruction if supported #ifdef __aarch64__ > + if (rndr_supported) { > + unsigned int r; > + asm volatile("mrs %0, s3_3_c2_c4_0" : "=r" (r)); > + // Discard the least random bit > + r >>=1; > + return (int) r; > + } > +#endif > return (int) __random (); > } > + > +#ifdef __aarch64__ > +// A function to check rndr support and set the global variable > accordingly > +static void > +check_rndr_support (void) > +{ > + unsigned long isar0; > + // Read the ID_AA64ISAR0_EL1 register to check the rndr feature > + asm volatile("mrs %0, id_aa64isar0_el1" : "=r" (isar0)); > + // Check the bits [63:60] for the rndr feature > + if ((isar0 >> 60) & 0xf) { > + // Set the global variable to indicate rndr support > + rndr_supported = 1; > + } > +} > +#endif -- Xi Ruoyao <xry111(a)xry111.site> School of Aerospace Science and Technology, Xidian University

1 0

Re: EAS适配大数据环境验证
by Ruan Jinjie 24 Jul '23

24 Jul '23

关键线程demo 大数据测试 On 2023/7/20 10:51, Ruan Jinjie wrote: > bpftrace测调度延迟脚本 > > On 2023/7/18 12:06, Ruan Jinjie wrote: >> >> >> On 2023/7/17 10:47, Ruan Jinjie wrote: >>> >>> >>> On 2023/7/15 18:18, Ruan Jinjie wrote: >>>> >>>> >>>> On 2023/7/15 10:36, Ruan Jinjie wrote: >>>>> >>>>> >>>>> On 2023/7/14 13:18, Ruan Jinjie wrote: >>>>>> >>>>>> >>>>>> On 2023/7/13 13:03, Ruan Jinjie wrote: >>>>>>> 潮汐适配SP2 >>>>>>> >>>>>>> On 2023/7/13 10:58, Ruan Jinjie wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 2023/7/12 17:23, Ruan Jinjie wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2023/7/5 17:24, Ruan Jinjie wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2023/7/5 17:19, Ruan Jinjie wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2023/7/4 20:34, Ruan Jinjie wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 2023/7/4 13:04, Ruan Jinjie wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 2023/6/3 10:52, Ruan Jinjie wrote:

1 0