Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 18 7月, 2023 3 次提交
  3. 17 7月, 2023 6 次提交
  5. 14 7月, 2023 8 次提交
  7. 13 7月, 2023 5 次提交
  9. 12 7月, 2023 3 次提交
    • P
      bpf: cpumap: Fix memory leak in cpu_map_update_elem · 28eb4213
      由 Pu Lehui 提交于 
      maillist inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7KNGM
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=4369016497319a9635702da010d02af1ebb1849d

----------------------------------------

Syzkaller reported a memory leak as follows:

BUG: memory leak
unreferenced object 0xff110001198ef748 (size 192):
  comm "syz-executor.3", pid 17672, jiffies 4298118891 (age 9.906s)
  hex dump (first 32 bytes):
    00 00 00 00 4a 19 00 00 80 ad e3 e4 fe ff c0 00  ....J...........
    00 b2 d3 0c 01 00 11 ff 28 f5 8e 19 01 00 11 ff  ........(.......
  backtrace:
    [<ffffffffadd28087>] __cpu_map_entry_alloc+0xf7/0xb00
    [<ffffffffadd28d8e>] cpu_map_update_elem+0x2fe/0x3d0
    [<ffffffffadc6d0fd>] bpf_map_update_value.isra.0+0x2bd/0x520
    [<ffffffffadc7349b>] map_update_elem+0x4cb/0x720
    [<ffffffffadc7d983>] __se_sys_bpf+0x8c3/0xb90
    [<ffffffffb029cc80>] do_syscall_64+0x30/0x40
    [<ffffffffb0400099>] entry_SYSCALL_64_after_hwframe+0x61/0xc6

BUG: memory leak
unreferenced object 0xff110001198ef528 (size 192):
  comm "syz-executor.3", pid 17672, jiffies 4298118891 (age 9.906s)
  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:
    [<ffffffffadd281f0>] __cpu_map_entry_alloc+0x260/0xb00
    [<ffffffffadd28d8e>] cpu_map_update_elem+0x2fe/0x3d0
    [<ffffffffadc6d0fd>] bpf_map_update_value.isra.0+0x2bd/0x520
    [<ffffffffadc7349b>] map_update_elem+0x4cb/0x720
    [<ffffffffadc7d983>] __se_sys_bpf+0x8c3/0xb90
    [<ffffffffb029cc80>] do_syscall_64+0x30/0x40
    [<ffffffffb0400099>] entry_SYSCALL_64_after_hwframe+0x61/0xc6

BUG: memory leak
unreferenced object 0xff1100010fd93d68 (size 8):
  comm "syz-executor.3", pid 17672, jiffies 4298118891 (age 9.906s)
  hex dump (first 8 bytes):
    00 00 00 00 00 00 00 00                          ........
  backtrace:
    [<ffffffffade5db3e>] kvmalloc_node+0x11e/0x170
    [<ffffffffadd28280>] __cpu_map_entry_alloc+0x2f0/0xb00
    [<ffffffffadd28d8e>] cpu_map_update_elem+0x2fe/0x3d0
    [<ffffffffadc6d0fd>] bpf_map_update_value.isra.0+0x2bd/0x520
    [<ffffffffadc7349b>] map_update_elem+0x4cb/0x720
    [<ffffffffadc7d983>] __se_sys_bpf+0x8c3/0xb90
    [<ffffffffb029cc80>] do_syscall_64+0x30/0x40
    [<ffffffffb0400099>] entry_SYSCALL_64_after_hwframe+0x61/0xc6

In the cpu_map_update_elem flow, when kthread_stop is called before
calling the threadfn of rcpu->kthread, since the KTHREAD_SHOULD_STOP bit
of kthread has been set by kthread_stop, the threadfn of rcpu->kthread
will never be executed, and rcpu->refcnt will never be 0, which will
lead to the allocated rcpu, rcpu->queue and rcpu->queue->queue cannot be
released.

Calling kthread_stop before executing kthread's threadfn will return
-EINTR. We can complete the release of memory resources in this state.

Fixes: 6710e112 ("bpf: introduce new bpf cpu map type BPF_MAP_TYPE_CPUMAP")
Signed-off-by: NPu Lehui <pulehui@huawei.com>
Acked-by: NJesper Dangaard Brouer <hawk@kernel.org>
Acked-by: NHou Tao <houtao1@huawei.com>
Link: https://lore.kernel.org/r/20230711115848.2701559-1-pulehui@huaweicloud.comSigned-off-by: NAlexei Starovoitov <ast@kernel.org>
      28eb4213
    • O
      !1355 etmem: fix the div 0 problem in swapcache reclaim process · cd0c6a73
      由 openeuler-ci-bot 提交于 
      Merge Pull Request from: @ci-robot 
 
PR sync from: liubo <liubo254@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/U5CT23M5QJUQGMVYUGL6TDAA75CMGKLX/ 
 
 
Link:https://gitee.com/openeuler/kernel/pulls/1355 

Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
      cd0c6a73
    • O
      !1345 dm: requeue IO if mapping table not yet · 0aa0ca11
      由 openeuler-ci-bot 提交于 
      Merge Pull Request from: @ci-robot 
 
PR sync from: Li Lingfeng <lilingfeng3@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/2PV7QOUKZR3DCG46HYA5N3UC6X6ZZ3EU/ 
It's not proper to just abort IO when the map is not ready.
So revert this and requeue IO to keep consistent with the community.
And fix the deadlock introduced by the patch.

v1->v2:
  add patch 38d11da5 "dm: don't lock fs when the map is NULL in
process of resume"

Li Lingfeng (3):
  Revert "dm: make sure dm_table is binded before queue request"
  dm: don't lock fs when the map is NULL in process of resume
  dm: don't lock fs when the map is NULL during suspend or resume

Mike Snitzer (1):
  dm: requeue IO if mapping table not yet available


-- 
2.31.1
 
 
Link:https://gitee.com/openeuler/kernel/pulls/1345 

Reviewed-by: Yu Kuai <yukuai3@huawei.com> 
Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
      0aa0ca11
  11. 11 7月, 2023 12 次提交
  13. 10 7月, 2023 2 次提交
  15. 09 7月, 2023 1 次提交
    • B
      bpf, sockops: Enhance the return capability of sockops · f2b0b6a6
      由 bitcoffee 提交于 
      hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I71USM

----------------------------------------------------

Since commit 2585cd62 ("bpf: Only reply field should be writeable"),
sockops is not allowd to modify the replylong field except replylong[0].
The reason is that the replylong[1] to replylong[3] field is not used
at that time.

But in actual use, we can call `BPF_CGROUP_RUN_PROG_SOCK_OPS` in the
kernel modules and expect sockops to return some useful data.

The design comment about bpf_sock_ops::replylong in
include/uapi/linux/bpf.h is described as follows:

```
  struct bpf_sock_ops {
        __u32 op;
        union {
                __u32 args[4];          /* Optionally passed to bpf program */
                __u32 reply;            /* Returned by bpf program          */
                __u32 replylong[4];     /* Optioznally returned by bpf prog  */
        };
  ...
```

It seems to contradict the purpose for which the field was originally
designed. Let's remove this restriction.

Fixes: 2585cd62 ("bpf: Only reply field should be writeable")
Signed-off-by: Nbitcoffee <liuxin350@huawei.com>
      f2b0b6a6