- Kernel - mailweb.openeuler.org

[PATCH openEuler-1.0-LTS] netdevsim: Zero-initialize memory for new map's value in function nsim_bpf_map_alloc
by Yang Yingliang 30 Dec '21

30 Dec '21

From: Haimin Zhang <tcs.kernel(a)gmail.com> mainline inclusion from mainline-5.16-rc6 commit 481221775d53d6215a6e5e9ce1cce6d2b4ab9a46 category: bugfix CVE: CVE-2021-4135 -------------------------------- Zero-initialize memory for new map's value in function nsim_bpf_map_alloc since it may cause a potential kernel information leak issue, as follows: 1. nsim_bpf_map_alloc calls nsim_map_alloc_elem to allocate elements for a new map. 2. nsim_map_alloc_elem uses kmalloc to allocate map's value, but doesn't zero it. 3. A user application can use IOCTL BPF_MAP_LOOKUP_ELEM to get specific element's information in the map. 4. The kernel function map_lookup_elem will call bpf_map_copy_value to get the information allocated at step-2, then use copy_to_user to copy to the user buffer. This can only leak information for an array map. Fixes: 395cacb5f1a0 ("netdevsim: bpf: support fake map offload") Suggested-by: Jakub Kicinski <kuba(a)kernel.org> Acked-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Haimin Zhang <tcs.kernel(a)gmail.com> Link: https://lore.kernel.org/r/20211215111530.72103-1-tcs.kernel@gmail.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> Reviewed-by: Wei Yongjun <weiyongjun1(a)huawei.com> Reviewed-by: Yue Haibing <yuehaibing(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- drivers/net/netdevsim/bpf.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/netdevsim/bpf.c b/drivers/net/netdevsim/bpf.c index 81444208b2162..12f100392ed11 100644 --- a/drivers/net/netdevsim/bpf.c +++ b/drivers/net/netdevsim/bpf.c @@ -493,6 +493,7 @@ nsim_bpf_map_alloc(struct netdevsim *ns, struct bpf_offloaded_map *offmap) goto err_free; key = nmap->entry[i].key; *key = i; + memset(nmap->entry[i].value, 0, offmap->map.value_size); } } -- 2.25.1

1 0

[PATCH openEuler-1.0-LTS 1/7] bpf: Fix up register-based shifts in interpreter to silence KUBSAN
by Yang Yingliang 30 Dec '21

30 Dec '21

From: Daniel Borkmann <daniel(a)iogearbox.net> mainline inclusion from mainline-v5.12 commit 28131e9d933339a92f78e7ab6429f4aaaa07061c category: bugfix bugzilla: NA CVE: NA ----------------------------------------------------------------------- syzbot reported a shift-out-of-bounds that KUBSAN observed in the interpreter: [...] UBSAN: shift-out-of-bounds in kernel/bpf/core.c:1420:2 shift exponent 255 is too large for 64-bit type 'long long unsigned int' CPU: 1 PID: 11097 Comm: syz-executor.4 Not tainted 5.12.0-rc2-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x141/0x1d7 lib/dump_stack.c:120 ubsan_epilogue+0xb/0x5a lib/ubsan.c:148 __ubsan_handle_shift_out_of_bounds.cold+0xb1/0x181 lib/ubsan.c:327 ___bpf_prog_run.cold+0x19/0x56c kernel/bpf/core.c:1420 __bpf_prog_run32+0x8f/0xd0 kernel/bpf/core.c:1735 bpf_dispatcher_nop_func include/linux/bpf.h:644 [inline] bpf_prog_run_pin_on_cpu include/linux/filter.h:624 [inline] bpf_prog_run_clear_cb include/linux/filter.h:755 [inline] run_filter+0x1a1/0x470 net/packet/af_packet.c:2031 packet_rcv+0x313/0x13e0 net/packet/af_packet.c:2104 dev_queue_xmit_nit+0x7c2/0xa90 net/core/dev.c:2387 xmit_one net/core/dev.c:3588 [inline] dev_hard_start_xmit+0xad/0x920 net/core/dev.c:3609 __dev_queue_xmit+0x2121/0x2e00 net/core/dev.c:4182 __bpf_tx_skb net/core/filter.c:2116 [inline] __bpf_redirect_no_mac net/core/filter.c:2141 [inline] __bpf_redirect+0x548/0xc80 net/core/filter.c:2164 ____bpf_clone_redirect net/core/filter.c:2448 [inline] bpf_clone_redirect+0x2ae/0x420 net/core/filter.c:2420 ___bpf_prog_run+0x34e1/0x77d0 kernel/bpf/core.c:1523 __bpf_prog_run512+0x99/0xe0 kernel/bpf/core.c:1737 bpf_dispatcher_nop_func include/linux/bpf.h:644 [inline] bpf_test_run+0x3ed/0xc50 net/bpf/test_run.c:50 bpf_prog_test_run_skb+0xabc/0x1c50 net/bpf/test_run.c:582 bpf_prog_test_run kernel/bpf/syscall.c:3127 [inline] __do_sys_bpf+0x1ea9/0x4f00 kernel/bpf/syscall.c:4406 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae [...] Generally speaking, KUBSAN reports from the kernel should be fixed. However, in case of BPF, this particular report caused concerns since the large shift is not wrong from BPF point of view, just undefined. In the verifier, K-based shifts that are >= {64,32} (depending on the bitwidth of the instruction) are already rejected. The register-based cases were not given their content might not be known at verification time. Ideas such as verifier instruction rewrite with an additional AND instruction for the source register were brought up, but regularly rejected due to the additional runtime overhead they incur. As Edward Cree rightly put it: Shifts by more than insn bitness are legal in the BPF ISA; they are implementation-defined behaviour [of the underlying architecture], rather than UB, and have been made legal for performance reasons. Each of the JIT backends compiles the BPF shift operations to machine instructions which produce implementation-defined results in such a case; the resulting contents of the register may be arbitrary but program behaviour as a whole remains defined. Guard checks in the fast path (i.e. affecting JITted code) will thus not be accepted. The case of division by zero is not truly analogous here, as division instructions on many of the JIT-targeted architectures will raise a machine exception / fault on division by zero, whereas (to the best of my knowledge) none will do so on an out-of-bounds shift. Given the KUBSAN report only affects the BPF interpreter, but not JITs, one solution is to add the ANDs with 63 or 31 into ___bpf_prog_run(). That would make the shifts defined, and thus shuts up KUBSAN, and the compiler would optimize out the AND on any CPU that interprets the shift amounts modulo the width anyway (e.g., confirmed from disassembly that on x86-64 and arm64 the generated interpreter code is the same before and after this fix). The BPF interpreter is slow path, and most likely compiled out anyway as distros select BPF_JIT_ALWAYS_ON to avoid speculative execution of BPF instructions by the interpreter. Given the main argument was to avoid sacrificing performance, the fact that the AND is optimized away from compiler for mainstream archs helps as well as a solution moving forward. Also add a comment on LSH/RSH/ARSH translation for JIT authors to provide guidance when they see the ___bpf_prog_run() interpreter code and use it as a model for a new JIT backend. Reported-by: syzbot+bed360704c521841c85d(a)syzkaller.appspotmail.com Reported-by: Kurt Manucredo <fuzzybritches0(a)gmail.com> Signed-off-by: Eric Biggers <ebiggers(a)kernel.org> Co-developed-by: Eric Biggers <ebiggers(a)kernel.org> Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net> Acked-by: Alexei Starovoitov <ast(a)kernel.org> Acked-by: Andrii Nakryiko <andrii(a)kernel.org> Tested-by: syzbot+bed360704c521841c85d(a)syzkaller.appspotmail.com Cc: Edward Cree <ecree.xilinx(a)gmail.com> Link: https://lore.kernel.org/bpf/0000000000008f912605bd30d5d7@google.com Link: https://lore.kernel.org/bpf/bac16d8d-c174-bdc4-91bd-bfa62b410190@gmail.com conflicts: kernel/bpf/core.c Signed-off-by: He Fengqing <hefengqing(a)huawei.com> Reviewed-by: Kuohai Xu <xukuohai(a)huawei.com> Reviewed-by: Xiu Jianfeng <xiujianfeng(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- kernel/bpf/core.c | 59 +++++++++++++++++++++++++++++++++-------------- 1 file changed, 42 insertions(+), 17 deletions(-) diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c index 641622b65de44..625edbc8360de 100644 --- a/kernel/bpf/core.c +++ b/kernel/bpf/core.c @@ -1100,29 +1100,54 @@ static u64 ___bpf_prog_run(u64 *regs, const struct bpf_insn *insn, u64 *stack) select_insn: goto *jumptable[insn->code]; - /* ALU */ -#define ALU(OPCODE, OP) \ - ALU64_##OPCODE##_X: \ - DST = DST OP SRC; \ - CONT; \ - ALU_##OPCODE##_X: \ - DST = (u32) DST OP (u32) SRC; \ - CONT; \ - ALU64_##OPCODE##_K: \ - DST = DST OP IMM; \ - CONT; \ - ALU_##OPCODE##_K: \ - DST = (u32) DST OP (u32) IMM; \ + /* Explicitly mask the register-based shift amounts with 63 or 31 + * to avoid undefined behavior. Normally this won't affect the + * generated code, for example, in case of native 64 bit archs such + * as x86-64 or arm64, the compiler is optimizing the AND away for + * the interpreter. In case of JITs, each of the JIT backends compiles + * the BPF shift operations to machine instructions which produce + * implementation-defined results in such a case; the resulting + * contents of the register may be arbitrary, but program behaviour + * as a whole remains defined. In other words, in case of JIT backends, + * the AND must /not/ be added to the emitted LSH/RSH/ARSH translation. + */ + /* ALU (shifts) */ +#define SHT(OPCODE, OP) \ + ALU64_##OPCODE##_X: \ + DST = DST OP (SRC & 63); \ + CONT; \ + ALU_##OPCODE##_X: \ + DST = (u32) DST OP ((u32) SRC & 31); \ + CONT; \ + ALU64_##OPCODE##_K: \ + DST = DST OP IMM; \ + CONT; \ + ALU_##OPCODE##_K: \ + DST = (u32) DST OP (u32) IMM; \ + CONT; + /* ALU (rest) */ +#define ALU(OPCODE, OP) \ + ALU64_##OPCODE##_X: \ + DST = DST OP SRC; \ + CONT; \ + ALU_##OPCODE##_X: \ + DST = (u32) DST OP (u32) SRC; \ + CONT; \ + ALU64_##OPCODE##_K: \ + DST = DST OP IMM; \ + CONT; \ + ALU_##OPCODE##_K: \ + DST = (u32) DST OP (u32) IMM; \ CONT; - ALU(ADD, +) ALU(SUB, -) ALU(AND, &) ALU(OR, |) - ALU(LSH, <<) - ALU(RSH, >>) ALU(XOR, ^) ALU(MUL, *) + SHT(LSH, <<) + SHT(RSH, >>) +#undef SHT #undef ALU ALU_NEG: DST = (u32) -DST; @@ -1147,7 +1172,7 @@ static u64 ___bpf_prog_run(u64 *regs, const struct bpf_insn *insn, u64 *stack) insn++; CONT; ALU64_ARSH_X: - (*(s64 *) &DST) >>= SRC; + (*(s64 *) &DST) >>= (SRC & 63); CONT; ALU64_ARSH_K: (*(s64 *) &DST) >>= IMM; -- 2.25.1

1 6

[PATCH openEuler-1.0-LTS 00/14] fixes CVEs for xen
by Yang Yingliang 30 Dec '21

30 Dec '21

patch #1 ~ #9 prepare for fix CVEs patch #10 ~ #14 fixes: CVE-2021-28711 CVE-2021-28712 CVE-2021-28713 CVE-2021-28714 CVE-2021-28715 Juergen Gross (14): xen/netback: avoid race in xenvif_rx_ring_slots_available() xen: sync include/xen/interface/io/ring.h with Xen's newest version xen/blkfront: read response from backend only once xen/blkfront: don't take local copy of a request from the ring page xen/blkfront: don't trust the backend response data blindly xen/netfront: read response from backend only once xen/netfront: don't read data from request on the ring page xen/netfront: disentangle tx_skb_freelist xen/netfront: don't trust the backend response data blindly xen/blkfront: harden blkfront against event channel storms xen/netfront: harden netfront against event channel storms xen/console: harden hvc_xen against event channel storms xen/netback: fix rx queue stall detection xen/netback: don't queue unlimited number of packages drivers/block/xen-blkfront.c | 141 ++++++++---- drivers/net/xen-netback/common.h | 1 + drivers/net/xen-netback/rx.c | 70 ++++-- drivers/net/xen-netfront.c | 372 ++++++++++++++++++++----------- drivers/tty/hvc/hvc_xen.c | 30 ++- include/xen/interface/io/ring.h | 293 +++++++++++++----------- 6 files changed, 575 insertions(+), 332 deletions(-) -- 2.25.1

1 14

[PATCH 1.0-LTS ] Add new module parameters:time out
by Yanling Song 29 Dec '21

29 Dec '21

Ramaxel inclusion category: features bugzilla: https://gitee.com/openeuler/kernel/issues/I4ON8F CVE: NA Changes: 1. Split scmd_tmout_nonpt into two parameters: scmd_tmout_vd/scmd_tmout_rawdisk 2. Return -ETIME instead of -EINVAL when command is timeout. 3. Add one module parameters: max_io_force. Signed-off-by: Yanling Song <songyl(a)ramaxel.com> Reviewed-by: Jiang Yu<yujiang(a)ramaxel.com> --- drivers/scsi/spraid/spraid_main.c | 55 ++++++++++++++----------------- 1 file changed, 24 insertions(+), 31 deletions(-) diff --git a/drivers/scsi/spraid/spraid_main.c b/drivers/scsi/spraid/spraid_main.c index 519b39f44e91..df15b1cea426 100644 --- a/drivers/scsi/spraid/spraid_main.c +++ b/drivers/scsi/spraid/spraid_main.c @@ -42,10 +42,17 @@ static u32 admin_tmout = 60; module_param(admin_tmout, uint, 0644); MODULE_PARM_DESC(admin_tmout, "admin commands timeout (seconds)"); -static u32 scmd_tmout_nonpt = 180; -module_param(scmd_tmout_nonpt, uint, 0644); -MODULE_PARM_DESC(scmd_tmout_nonpt, - "scsi commands timeout for rawdisk&raid(seconds)"); +static u32 scmd_tmout_rawdisk = 180; +module_param(scmd_tmout_rawdisk, uint, 0644); +MODULE_PARM_DESC(scmd_tmout_rawdisk, "scsi commands timeout for rawdisk(seconds)"); + +static u32 scmd_tmout_vd = 180; +module_param(scmd_tmout_vd, uint, 0644); +MODULE_PARM_DESC(scmd_tmout_vd, "scsi commands timeout for vd(seconds)"); + +static bool max_io_force; +module_param(max_io_force, bool, 0644); +MODULE_PARM_DESC(max_io_force, "force max_hw_sectors_kb = 1024, default false(performance first)"); static int ioq_depth_set(const char *val, const struct kernel_param *kp); static const struct kernel_param_ops ioq_depth_ops = { @@ -78,7 +85,7 @@ static unsigned char log_debug_switch; module_param_cb(log_debug_switch, &log_debug_switch_ops, &log_debug_switch, 0644); MODULE_PARM_DESC(log_debug_switch, - "set log state, default non-zero for switch on"); + "set log state, default zero for switch off"); static int small_pool_num_set(const char *val, const struct kernel_param *kp) { @@ -981,32 +988,17 @@ static void spraid_slave_destroy(struct scsi_device *sdev) static int spraid_slave_configure(struct scsi_device *sdev) { - u16 idx; - unsigned int timeout = scmd_tmout_nonpt * HZ; + unsigned int timeout = scmd_tmout_rawdisk * HZ; struct spraid_dev *hdev = shost_priv(sdev->host); struct spraid_sdev_hostdata *hostdata = sdev->hostdata; u32 max_sec = sdev->host->max_sectors; if (hostdata) { - idx = hostdata->hdid - 1; - if (sdev->channel == hdev->devices[idx].channel && - sdev->id == le16_to_cpu(hdev->devices[idx].target) && - sdev->lun < hdev->devices[idx].lun) { - if (SPRAID_DEV_INFO_ATTR_PT(hdev->devices[idx].attr)) - timeout = 30 * HZ; - else - timeout = scmd_tmout_nonpt * HZ; - max_sec = le16_to_cpu(hdev->devices[idx].max_io_kb) - << 1; - } else { - dev_err(hdev->dev, - "[%s] err, sdev->channel:id:lun[%d:%d:%lld];" - "devices[%d], channel:target:lun[%d:%d:%d]\n", - __func__, sdev->channel, sdev->id, sdev->lun, - idx, hdev->devices[idx].channel, - hdev->devices[idx].target, - hdev->devices[idx].lun); - } + if (SPRAID_DEV_INFO_ATTR_VD(hostdata->attr)) + timeout = scmd_tmout_vd * HZ; + else if (SPRAID_DEV_INFO_ATTR_RAWDISK(hostdata->attr)) + timeout = scmd_tmout_rawdisk * HZ; + max_sec = hostdata->max_io_kb << 1; } else { dev_err(hdev->dev, "[%s] err, sdev->hostdata is null\n", __func__); @@ -1018,11 +1010,12 @@ static int spraid_slave_configure(struct scsi_device *sdev) if ((max_sec == 0) || (max_sec > sdev->host->max_sectors)) max_sec = sdev->host->max_sectors; - dev_info(hdev->dev, - "[%s] sdev->channel:id:lun[%d:%d:%lld];" - " scmd_timeout[%d]s, maxsec[%d]\n", - __func__, sdev->channel, sdev->id, - sdev->lun, timeout / HZ, max_sec); + if (!max_io_force) + blk_queue_max_hw_sectors(sdev->request_queue, max_sec); + + dev_info(hdev->dev, "[%s] sdev->channel:id:lun[%d:%d:%lld];" + "scmd_timeout[%d]s, maxsec[%d]\n", __func__, sdev->channel, + sdev->id, sdev->lun, timeout / HZ, max_sec); return 0; } -- 2.27.0

1 0

[PATCH openEuler-1.0-LTS 1/2] sctp: account stream padding length for reconf chunk
by Yang Yingliang 29 Dec '21

29 Dec '21

From: Eiichi Tsukata <eiichi.tsukata(a)nutanix.com> stable inclusion from linux-4.19.213 commit c57fdeff69b152185fafabd37e6bfecfce51efda category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4OJ3D CVE: NA -------------------------------- commit a2d859e3fc97e79d907761550dbc03ff1b36479c upstream. sctp_make_strreset_req() makes repeated calls to sctp_addto_chunk() which will automatically account for padding on each call. inreq and outreq are already 4 bytes aligned, but the payload is not and doing SCTP_PAD4(a + b) (which _sctp_make_chunk() did implicitly here) is different from SCTP_PAD4(a) + SCTP_PAD4(b) and not enough. It led to possible attempt to use more buffer than it was allocated and triggered a BUG_ON. Cc: Vlad Yasevich <vyasevich(a)gmail.com> Cc: Neil Horman <nhorman(a)tuxdriver.com> Cc: Greg KH <gregkh(a)linuxfoundation.org> Fixes: cc16f00f6529 ("sctp: add support for generating stream reconf ssn reset request chunk") Reported-by: Eiichi Tsukata <eiichi.tsukata(a)nutanix.com> Signed-off-by: Eiichi Tsukata <eiichi.tsukata(a)nutanix.com> Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com> Signed-off-by: Marcelo Ricardo Leitner <mleitner(a)redhat.com> Reviewed-by: Xin Long <lucien.xin(a)gmail.com> Link: https://lore.kernel.org/r/b97c1f8b0c7ff79ac4ed206fc2c49d3612e0850c.16341568… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Wang Hai <wanghai38(a)huawei.com> Reviewed-by: Wei Yongjun <weiyongjun1(a)huawei.com> Reviewed-by: Yue Haibing <yuehaibing(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- net/sctp/sm_make_chunk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c index 0789109c2d093..35e1fb708f4a7 100644 --- a/net/sctp/sm_make_chunk.c +++ b/net/sctp/sm_make_chunk.c @@ -3673,7 +3673,7 @@ struct sctp_chunk *sctp_make_strreset_req( outlen = (sizeof(outreq) + stream_len) * out; inlen = (sizeof(inreq) + stream_len) * in; - retval = sctp_make_reconf(asoc, outlen + inlen); + retval = sctp_make_reconf(asoc, SCTP_PAD4(outlen) + SCTP_PAD4(inlen)); if (!retval) return NULL; -- 2.25.1

1 1

[PATCH openEuler-5.10 01/64] arm64: Revert feature: Add memmap parameter and register pmem
by Zheng Zengkai 29 Dec '21

29 Dec '21

From: Zhuling <zhuling8(a)huawei.com> euleros inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4O31I?from=project-issue CVE: NA -------------------------------- The reserve memory of PMEM conflicts with "add memmap interface to reserved memory for mremap syscall usage", need to rollback, resubmit after adaptation. Feature related commit： 1.PMEM function commit: 94dc364f5eda10f49449ba573dc3322e1ea92280 2.PMEM feature config commit: 36d7a831e15ceb84e937122c87d01c14242dc377 Signed-off-by: Zhuling <zhuling8(a)huawei.com> Reviewed-by: Sang Yan <sangyan(a)huawei.com> Reviewed-by: Kefeng Wang <wangkefeng.wang(a)huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai(a)huawei.com> --- arch/arm64/Kconfig | 21 ------ arch/arm64/configs/openeuler_defconfig | 3 - arch/arm64/kernel/Makefile | 1 - arch/arm64/kernel/pmem.c | 35 ---------- arch/arm64/kernel/setup.c | 10 --- arch/arm64/mm/init.c | 94 -------------------------- drivers/nvdimm/Kconfig | 5 -- drivers/nvdimm/Makefile | 1 - 8 files changed, 170 deletions(-) delete mode 100644 arch/arm64/kernel/pmem.c diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index df90a6e05ad2..2df4b310eb23 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -1321,27 +1321,6 @@ config RODATA_FULL_DEFAULT_ENABLED This requires the linear region to be mapped down to pages, which may adversely affect performance in some cases. -config ARM64_PMEM_RESERVE - bool "Reserve memory for persistent storage" - default n - help - Use memmap=nn[KMG]!ss[KMG](memmap=100K!0x1a0000000) reserve - memory for persistent storage. - - Say y here to enable this feature. - -config ARM64_PMEM_LEGACY_DEVICE - bool "Create persistent storage" - depends on BLK_DEV - depends on LIBNVDIMM - select ARM64_PMEM_RESERVE - help - Use reserved memory for persistent storage when the kernel - restart or update. the data in PMEM will not be lost and - can be loaded faster. - - Say y if unsure. - config ARM64_SW_TTBR0_PAN bool "Emulate Privileged Access Never using TTBR0_EL1 switching" help diff --git a/arch/arm64/configs/openeuler_defconfig b/arch/arm64/configs/openeuler_defconfig index 17bc8750bba7..b5fc851f1949 100644 --- a/arch/arm64/configs/openeuler_defconfig +++ b/arch/arm64/configs/openeuler_defconfig @@ -416,8 +416,6 @@ CONFIG_ARM64_CPU_PARK=y CONFIG_FORCE_MAX_ZONEORDER=11 CONFIG_UNMAP_KERNEL_AT_EL0=y CONFIG_RODATA_FULL_DEFAULT_ENABLED=y -CONFIG_ARM64_PMEM_RESERVE=y -CONFIG_ARM64_PMEM_LEGACY_DEVICE=y # CONFIG_ARM64_SW_TTBR0_PAN is not set CONFIG_ARM64_TAGGED_ADDR_ABI=y CONFIG_ARM64_ILP32=y @@ -6026,7 +6024,6 @@ CONFIG_ND_BTT=m CONFIG_BTT=y CONFIG_OF_PMEM=m CONFIG_NVDIMM_KEYS=y -CONFIG_PMEM_LEGACY=m CONFIG_DAX_DRIVER=y CONFIG_DAX=y CONFIG_DEV_DAX=m diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile index f6153250b631..169d90f11cf5 100644 --- a/arch/arm64/kernel/Makefile +++ b/arch/arm64/kernel/Makefile @@ -68,7 +68,6 @@ obj-$(CONFIG_ARM64_PTR_AUTH) += pointer_auth.o obj-$(CONFIG_SHADOW_CALL_STACK) += scs.o obj-$(CONFIG_ARM64_MTE) += mte.o obj-$(CONFIG_MPAM) += mpam/ -obj-$(CONFIG_ARM64_PMEM_LEGACY_DEVICE) += pmem.o obj-y += vdso/ probes/ obj-$(CONFIG_COMPAT_VDSO) += vdso32/ diff --git a/arch/arm64/kernel/pmem.c b/arch/arm64/kernel/pmem.c deleted file mode 100644 index 16eaf706f671..000000000000 --- a/arch/arm64/kernel/pmem.c +++ /dev/null @@ -1,35 +0,0 @@ -// SPDX-License-Identifier: GPL-2.0 -/* - * Copyright(c) 2021 Huawei Technologies Co., Ltd - * - * Derived from x86 and arm64 implement PMEM. - */ -#include <linux/platform_device.h> -#include <linux/init.h> -#include <linux/ioport.h> -#include <linux/module.h> - -static int found(struct resource *res, void *data) -{ - return 1; -} - -static int __init register_e820_pmem(void) -{ - struct platform_device *pdev; - int rc; - - rc = walk_iomem_res_desc(IORES_DESC_PERSISTENT_MEMORY_LEGACY, - IORESOURCE_MEM, 0, -1, NULL, found); - if (rc <= 0) - return 0; - - /* - * See drivers/nvdimm/e820.c for the implementation, this is - * simply here to trigger the module to load on demand. - */ - pdev = platform_device_alloc("e820_pmem", -1); - - return platform_device_add(pdev); -} -device_initcall(register_e820_pmem); diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c index 88ec49504001..7cd042536d3b 100644 --- a/arch/arm64/kernel/setup.c +++ b/arch/arm64/kernel/setup.c @@ -70,10 +70,6 @@ static int __init arm64_enable_cpu0_hotplug(char *str) __setup("arm64_cpu0_hotplug", arm64_enable_cpu0_hotplug); #endif -#ifdef CONFIG_ARM64_PMEM_RESERVE -extern struct resource pmem_res; -#endif - phys_addr_t __fdt_pointer __initdata; /* @@ -288,12 +284,6 @@ static void __init request_standard_resources(void) request_resource(res, &pin_memory_resource); #endif } - -#ifdef CONFIG_ARM64_PMEM_RESERVE - if (pmem_res.end && pmem_res.start) - request_resource(&iomem_resource, &pmem_res); -#endif - } static int __init reserve_memblock_reserved_regions(void) diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c index 3b9401ee9c58..e8d446164c76 100644 --- a/arch/arm64/mm/init.c +++ b/arch/arm64/mm/init.c @@ -55,7 +55,6 @@ */ s64 memstart_addr __ro_after_init = -1; EXPORT_SYMBOL(memstart_addr); -phys_addr_t start_at, mem_size; #ifdef CONFIG_PIN_MEMORY struct resource pin_memory_resource = { @@ -112,18 +111,6 @@ static void __init reserve_pin_memory_res(void) */ phys_addr_t arm64_dma_phys_limit __ro_after_init; -static unsigned long long pmem_size, pmem_start; - -#ifdef CONFIG_ARM64_PMEM_RESERVE -struct resource pmem_res = { - .name = "Persistent Memory (legacy)", - .start = 0, - .end = 0, - .flags = IORESOURCE_MEM, - .desc = IORES_DESC_PERSISTENT_MEMORY_LEGACY -}; -#endif - #ifndef CONFIG_KEXEC_CORE static void __init reserve_crashkernel(void) { @@ -417,83 +404,6 @@ static int __init reserve_park_mem(void) } #endif -static bool __init is_mem_valid(unsigned long long mem_size, unsigned long long mem_start) -{ - if (!memblock_is_region_memory(mem_start, mem_size)) { - pr_warn("cannot reserve mem: region is not memory!\n"); - return false; - } - - if (memblock_is_region_reserved(mem_start, mem_size)) { - pr_warn("cannot reserve mem: region overlaps reserved memory!\n"); - return false; - } - - if (!IS_ALIGNED(mem_start, SZ_2M)) { - pr_warn("cannot reserve mem: base address is not 2MB aligned!\n"); - return false; - } - - return true; -} - -static int __init parse_memmap_one(char *p) -{ - char *oldp; - - if (!p) - return -EINVAL; - - oldp = p; - mem_size = memparse(p, &p); - if (p == oldp) - return -EINVAL; - - if (!mem_size) - return -EINVAL; - - mem_size = PAGE_ALIGN(mem_size); - - if (*p == '!') { - start_at = memparse(p+1, &p); - - pmem_start = start_at; - pmem_size = mem_size; - } else - pr_info("Unrecognized memmap option, please check the parameter.\n"); - - return *p == '\0' ? 0 : -EINVAL; -} - -static int __init parse_memmap_opt(char *str) -{ - while (str) { - char *k = strchr(str, ','); - - if (k) - *k++ = 0; - parse_memmap_one(str); - str = k; - } - - return 0; -} -early_param("memmap", parse_memmap_opt); - -#ifdef CONFIG_ARM64_PMEM_RESERVE -static void __init reserve_pmem(void) -{ - if (!is_mem_valid(mem_size, start_at)) - return; - - memblock_remove(pmem_start, pmem_size); - pr_info("pmem reserved: 0x%016llx - 0x%016llx (%lld MB)\n", - pmem_start, pmem_start + pmem_size, pmem_size >> 20); - pmem_res.start = pmem_start; - pmem_res.end = pmem_start + pmem_size - 1; -} -#endif - void __init arm64_memblock_init(void) { const s64 linear_region_size = BIT(vabits_actual - 1); @@ -668,10 +578,6 @@ void __init bootmem_init(void) reserve_quick_kexec(); #endif -#ifdef CONFIG_ARM64_PMEM_RESERVE - reserve_pmem(); -#endif - reserve_pin_memory_res(); memblock_dump_all(); diff --git a/drivers/nvdimm/Kconfig b/drivers/nvdimm/Kconfig index ce4de75262b9..b7d1eb38b27d 100644 --- a/drivers/nvdimm/Kconfig +++ b/drivers/nvdimm/Kconfig @@ -132,8 +132,3 @@ config NVDIMM_TEST_BUILD infrastructure. endif - -config PMEM_LEGACY - tristate "Pmem_legacy" - select X86_PMEM_LEGACY if X86 - select ARM64_PMEM_LEGACY_DEVICE if ARM64 diff --git a/drivers/nvdimm/Makefile b/drivers/nvdimm/Makefile index 6f8dc9242a81..04077532f7ed 100644 --- a/drivers/nvdimm/Makefile +++ b/drivers/nvdimm/Makefile @@ -3,7 +3,6 @@ obj-$(CONFIG_LIBNVDIMM) += libnvdimm.o obj-$(CONFIG_BLK_DEV_PMEM) += nd_pmem.o obj-$(CONFIG_ND_BTT) += nd_btt.o obj-$(CONFIG_ND_BLK) += nd_blk.o -obj-$(CONFIG_PMEM_LEGACY) += nd_e820.o obj-$(CONFIG_OF_PMEM) += of_pmem.o obj-$(CONFIG_VIRTIO_PMEM) += virtio_pmem.o nd_virtio.o -- 2.20.1

1 63

[PATCH openEuler-1.0-LTS 00/93] Enabling AMD Milan series processor support
by Laibin Qiu 28 Dec '21

28 Dec '21

bugzilla: https://gitee.com/openeuler/kernel/issues/I4MKP4 Babu Moger (1): KVM: SVM: Clear the CR4 register on reset David Edmondson (1): KVM: x86: clflushopt should be treated as a no-op by emulation Fenghua Yu (2): x86/cpufeatures: Enumerate MOVDIRI instruction x86/cpufeatures: Enumerate MOVDIR64B instruction Haiyan Song (2): perf vendor events intel: Add Icelake V1.00 event file perf vendor events intel: Add Tremontx event file v1.02 Isaac Vaughn (1): EDAC/amd64: Add PCI device IDs for family 17h, model 70h Jan H. Schönherr (1): x86/mce: Fix use of uninitialized MCE message string Jim Mattson (1): kvm: x86: Expose RDPID in KVM_GET_SUPPORTED_CPUID John Allen (2): kvm/svm: PKU not currently supported x86/microcode/AMD: Increase microcode PATCH_MAX_SIZE John Garry (4): perf jevents: Add support for Hisi hip08 DDRC PMU aliasing perf jevents: Add support for Hisi hip08 HHA PMU aliasing perf jevents: Add support for Hisi hip08 L3C PMU aliasing perf vendor events arm64: Fix Hisi hip08 DDRC PMU eventname Kai Huang (3): kvm: x86: Move kvm_set_mmio_spte_mask() from x86.c to mmu.c kvm: x86: Fix reserved bits related calculation errors caused by MKTME kvm: x86: Fix L1TF mitigation for shadow MMU Kan Liang (1): perf vendor events intel: Add uncore_upi JSON support Kim Phillips (17): perf/amd/uncore: Prepare L3 thread mask code for Family 19h perf/amd/uncore: Make L3 thread mask code more readable perf/amd/uncore: Add support for Family 19h L3 PMU arch/x86/amd/ibs: Fix re-arming IBS Fetch perf/x86/amd/ibs: Fix raw sample data accumulation perf/amd/uncore: Set all slices and threads to restore perf stat -a behaviour perf/x86/amd/ibs: Don't include randomized bits in get_ibs_op_count() perf/amd/uncore: Prepare to scale for more attributes that vary per family perf/amd/uncore: Allow F17h user threadmask and slicemask specification perf/amd/uncore: Allow F19h user coreid, threadmask, and sliceid specification perf vendor events amd: Add L3 cache events for Family 17h perf vendor events amd: Remove redundant '[' perf vendor events amd: Enable Family 19h users by matching Zen2 events x86/cpu/amd: Call init_amd_zn() om Family 19h processors too perf/x86/amd/ibs: Support 27-bit extended Op/cycle counter tools/power turbostat: Support AMD Family 19h perf vendor events amd: Add L2 Prefetch events for zen1 Krish Sadhukhan (1): KVM: SVM: Replace hard-coded value with #define Like Xu (1): perf/x86/amd: Don't touch the AMD64_EVENTSEL_HOSTONLY bit inside the guest Liu Jingqi (2): KVM: x86: expose MOVDIRI CPU feature into VM. KVM: x86: expose MOVDIR64B CPU feature into VM. Maciej S. Szmigiero (1): KVM: mmu: Fix SPTE encoding of MMIO generation upper half Marcel Bocu (1): x86/amd_nb: Add PCI device IDs for family 17h, model 70h Martin Liška (1): perf vendor events amd: perf PMU events for AMD Family 17h Nathan Chancellor (2): crypto: ccp - Remove forward declaration perf/amd/uncore: Fix sysfs type mismatch Paolo Bonzini (3): KVM: x86: only do L1TF workaround on affected processors KVM: x86: assign two bits to track SPTE kinds KVM: x86: fix overlap between SPTE_MMIO_MASK and generation Rasmus Villemoes (1): build_bug.h: add wrapper for _Static_assert Sean Christopherson (13): KVM: nVMX: Allocate and configure VM{READ,WRITE} bitmaps iff enable_shadow_vmcs KVM: x86: Add requisite includes to kvm_cache_regs.h KVM: x86: Add requisite includes to hyperv.h KVM: x86: Use a u64 when passing the MMIO gen around KVM: Explicitly define the "memslot update in-progress" bit KVM: x86: Refactor the MMIO SPTE generation handling KVM: x86: Rename access permissions cache member in struct kvm_vcpu_arch KVM: x86/mmu: Add explicit access mask for MMIO SPTEs KVM: x86/mmu: Consolidate "is MMIO SPTE" code KVM: x86/mmu: Apply max PA check for MMIO sptes to 32-bit KVM KVM: x86/mmu: Set mmio_value to '0' if reserved #PF can't be generated KVM: Remove the hack to trigger memslot generation wraparound KVM: Move the memslot update in-progress flag to bit 63 Sebastian Andrzej Siewior (1): x86/pkeys: Don't check if PKRU is zero before writing it Tom Lendacky (1): KVM: SVM: Override default MMIO mask if memory encryption is enabled Vijay Thakkar (3): perf vendor events amd: Restrict model detection for zen1 based processors perf vendor events amd: Add Zen2 events perf vendor events amd: Update Zen1 events to V2 Woods, Brian (2): hwmon/k10temp, x86/amd_nb: Consolidate shared device IDs x86/amd_nb: Add PCI device IDs for family 17h, model 30h Yazen Ghannam (24): EDAC/amd64: Drop some family checks for newer systems x86/amd_nb: Add Family 19h PCI IDs EDAC/mce_amd: Always load on SMCA systems x86/MCE/AMD, EDAC/mce_amd: Add new MP5, NBIO, and PCIE SMCA bank types x86/MCE/AMD, EDAC/mce_amd: Add new McaTypes for CS, PSP, and SMU units x86/MCE/AMD, EDAC/mce_amd: Add new error descriptions for some SMCA bank types x86/MCE/AMD, EDAC/mce_amd: Add new Load Store unit McaType EDAC/amd64: Use a macro for iterating over Unified Memory Controllers EDAC/amd64: Support more than two controllers for chip selects handling EDAC/amd64: Initialize DIMM info for systems with more than two channels EDAC/amd64: Add Family 17h Model 30h PCI IDs EDAC/amd64: Support more than two Unified Memory Controllers EDAC/amd64: Set maximum channel layer size depending on family EDAC/amd64: Recognize x16 symbol size EDAC/amd64: Adjust printed chip select sizes when interleaved EDAC/amd64: Find Chip Select memory size using Address Mask EDAC/amd64: Cache secondary Chip Select registers EDAC/amd64: Support asymmetric dual-rank DIMMs EDAC/amd64: Set grain per DIMM EDAC/amd64: Make struct amd64_family_type global EDAC/amd64: Gather hardware information early EDAC/amd64: Save max number of controllers to family type EDAC/amd64: Add family ops for Family 19h Models 00h-0Fh EDAC/amd64: Handle three rank interleaving mode Documentation/virtual/kvm/mmu.txt | 13 +- arch/x86/events/amd/ibs.c | 93 +- arch/x86/events/amd/uncore.c | 179 ++-- arch/x86/events/perf_event.h | 3 +- arch/x86/include/asm/cpufeatures.h | 4 +- arch/x86/include/asm/kvm_host.h | 10 +- arch/x86/include/asm/mce.h | 7 + arch/x86/include/asm/microcode_amd.h | 2 +- arch/x86/include/asm/msr-index.h | 1 + arch/x86/include/asm/perf_event.h | 16 +- arch/x86/kernel/amd_nb.c | 15 +- arch/x86/kernel/cpu/amd.c | 3 +- arch/x86/kernel/cpu/mce/amd.c | 28 +- arch/x86/kernel/cpu/mce/core.c | 4 +- arch/x86/kvm/cpuid.c | 6 +- arch/x86/kvm/emulate.c | 8 +- arch/x86/kvm/hyperv.h | 2 + arch/x86/kvm/kvm_cache_regs.h | 2 + arch/x86/kvm/mmu.c | 215 +++-- arch/x86/kvm/mmu.h | 2 +- arch/x86/kvm/svm.c | 53 +- arch/x86/kvm/vmx.c | 51 +- arch/x86/kvm/x86.c | 33 +- arch/x86/kvm/x86.h | 4 +- arch/x86/mm/pkeys.c | 7 - drivers/crypto/ccp/sp-platform.c | 53 +- drivers/edac/amd64_edac.c | 609 ++++++++---- drivers/edac/amd64_edac.h | 31 +- drivers/edac/mce_amd.c | 134 ++- drivers/hwmon/k10temp.c | 9 +- include/linux/build_bug.h | 19 + include/linux/kvm_host.h | 21 + include/linux/pci_ids.h | 5 + .../arm64/hisilicon/hip08/uncore-ddrc.json | 44 + .../arm64/hisilicon/hip08/uncore-hha.json | 51 + .../arm64/hisilicon/hip08/uncore-l3c.json | 37 + .../pmu-events/arch/x86/amdzen1/branch.json | 23 + .../pmu-events/arch/x86/amdzen1/cache.json | 312 ++++++ .../pmu-events/arch/x86/amdzen1/core.json | 125 +++ .../arch/x86/amdzen1/floating-point.json | 224 +++++ .../pmu-events/arch/x86/amdzen1/memory.json | 184 ++++ .../pmu-events/arch/x86/amdzen1/other.json | 56 ++ .../pmu-events/arch/x86/amdzen2/branch.json | 52 + .../pmu-events/arch/x86/amdzen2/cache.json | 338 +++++++ .../pmu-events/arch/x86/amdzen2/core.json | 130 +++ .../arch/x86/amdzen2/floating-point.json | 140 +++ .../pmu-events/arch/x86/amdzen2/memory.json | 341 +++++++ .../pmu-events/arch/x86/amdzen2/other.json | 115 +++ .../pmu-events/arch/x86/icelake/cache.json | 552 +++++++++++ .../arch/x86/icelake/floating-point.json | 102 ++ .../pmu-events/arch/x86/icelake/frontend.json | 424 +++++++++ .../pmu-events/arch/x86/icelake/memory.json | 410 ++++++++ .../pmu-events/arch/x86/icelake/other.json | 121 +++ .../pmu-events/arch/x86/icelake/pipeline.json | 892 ++++++++++++++++++ .../arch/x86/icelake/virtual-memory.json | 236 +++++ tools/perf/pmu-events/arch/x86/mapfile.csv | 6 + .../pmu-events/arch/x86/tremontx/cache.json | 111 +++ .../arch/x86/tremontx/frontend.json | 26 + .../pmu-events/arch/x86/tremontx/memory.json | 26 + .../pmu-events/arch/x86/tremontx/other.json | 26 + .../arch/x86/tremontx/pipeline.json | 111 +++ .../arch/x86/tremontx/uncore-memory.json | 73 ++ .../arch/x86/tremontx/uncore-other.json | 431 +++++++++ .../arch/x86/tremontx/uncore-power.json | 11 + .../arch/x86/tremontx/virtual-memory.json | 86 ++ tools/perf/pmu-events/jevents.c | 5 + tools/power/x86/turbostat/turbostat.c | 34 +- virt/kvm/kvm_main.c | 36 +- 68 files changed, 6981 insertions(+), 552 deletions(-) create mode 100644 tools/perf/pmu-events/arch/arm64/hisilicon/hip08/uncore-ddrc.json create mode 100644 tools/perf/pmu-events/arch/arm64/hisilicon/hip08/uncore-hha.json create mode 100644 tools/perf/pmu-events/arch/arm64/hisilicon/hip08/uncore-l3c.json create mode 100644 tools/perf/pmu-events/arch/x86/amdzen1/branch.json create mode 100644 tools/perf/pmu-events/arch/x86/amdzen1/cache.json create mode 100644 tools/perf/pmu-events/arch/x86/amdzen1/core.json create mode 100644 tools/perf/pmu-events/arch/x86/amdzen1/floating-point.json create mode 100644 tools/perf/pmu-events/arch/x86/amdzen1/memory.json create mode 100644 tools/perf/pmu-events/arch/x86/amdzen1/other.json create mode 100644 tools/perf/pmu-events/arch/x86/amdzen2/branch.json create mode 100644 tools/perf/pmu-events/arch/x86/amdzen2/cache.json create mode 100644 tools/perf/pmu-events/arch/x86/amdzen2/core.json create mode 100644 tools/perf/pmu-events/arch/x86/amdzen2/floating-point.json create mode 100644 tools/perf/pmu-events/arch/x86/amdzen2/memory.json create mode 100644 tools/perf/pmu-events/arch/x86/amdzen2/other.json create mode 100644 tools/perf/pmu-events/arch/x86/icelake/cache.json create mode 100644 tools/perf/pmu-events/arch/x86/icelake/floating-point.json create mode 100644 tools/perf/pmu-events/arch/x86/icelake/frontend.json create mode 100644 tools/perf/pmu-events/arch/x86/icelake/memory.json create mode 100644 tools/perf/pmu-events/arch/x86/icelake/other.json create mode 100644 tools/perf/pmu-events/arch/x86/icelake/pipeline.json create mode 100644 tools/perf/pmu-events/arch/x86/icelake/virtual-memory.json create mode 100644 tools/perf/pmu-events/arch/x86/tremontx/cache.json create mode 100644 tools/perf/pmu-events/arch/x86/tremontx/frontend.json create mode 100644 tools/perf/pmu-events/arch/x86/tremontx/memory.json create mode 100644 tools/perf/pmu-events/arch/x86/tremontx/other.json create mode 100644 tools/perf/pmu-events/arch/x86/tremontx/pipeline.json create mode 100644 tools/perf/pmu-events/arch/x86/tremontx/uncore-memory.json create mode 100644 tools/perf/pmu-events/arch/x86/tremontx/uncore-other.json create mode 100644 tools/perf/pmu-events/arch/x86/tremontx/uncore-power.json create mode 100644 tools/perf/pmu-events/arch/x86/tremontx/virtual-memory.json -- 2.22.0

1 93

[PATCH openEuler-1.0-LTS] netfilter: fix regression in looped (broad|multi)cast's MAC handling
by Yang Yingliang 28 Dec '21

28 Dec '21

From: Ignacy Gawędzki <ignacy.gawedzki(a)green-communications.fr> mainline inclusion from mainline-v5.16-rc7 commit ebb966d3bdfed581ecccbb4a7432341baf7619b4 category: bugfix bugzilla: NA CVE: NA -------------------------------- In commit 5648b5e1169f ("netfilter: nfnetlink_queue: fix OOB when mac header was cleared"), the test for non-empty MAC header introduced in commit 2c38de4c1f8da7 ("netfilter: fix looped (broad|multi)cast's MAC handling") has been replaced with a test for a set MAC header. This breaks the case when the MAC header has been reset (using skb_reset_mac_header), as is the case with looped-back multicast packets. As a result, the packets ending up in NFQUEUE get a bogus hwaddr interpreted from the first bytes of the IP header. This patch adds a test for a non-empty MAC header in addition to the test for a set MAC header. The same two tests are also implemented in nfnetlink_log.c, where the initial code of commit 2c38de4c1f8da7 ("netfilter: fix looped (broad|multi)cast's MAC handling") has not been touched, but where supposedly the same situation may happen. Fixes: 5648b5e1169f ("netfilter: nfnetlink_queue: fix OOB when mac header was cleared") Signed-off-by: Ignacy Gawędzki <ignacy.gawedzki(a)green-communications.fr> Reviewed-by: Florian Westphal <fw(a)strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> Reviewed-by: Yue Haibing <yuehaibing(a)huawei.com> Reviewed-by: Wei Yongjun <weiyongjun1(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- net/netfilter/nfnetlink_log.c | 3 ++- net/netfilter/nfnetlink_queue.c | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/net/netfilter/nfnetlink_log.c b/net/netfilter/nfnetlink_log.c index 25298b3eb8546..17ca9a681d47b 100644 --- a/net/netfilter/nfnetlink_log.c +++ b/net/netfilter/nfnetlink_log.c @@ -509,7 +509,8 @@ __build_packet_message(struct nfnl_log_net *log, goto nla_put_failure; if (indev && skb->dev && - skb->mac_header != skb->network_header) { + skb_mac_header_was_set(skb) && + skb_mac_header_len(skb) != 0) { struct nfulnl_msg_packet_hw phw; int len; diff --git a/net/netfilter/nfnetlink_queue.c b/net/netfilter/nfnetlink_queue.c index eb5a052d3b252..8955431f2ab26 100644 --- a/net/netfilter/nfnetlink_queue.c +++ b/net/netfilter/nfnetlink_queue.c @@ -566,7 +566,8 @@ nfqnl_build_packet_message(struct net *net, struct nfqnl_instance *queue, goto nla_put_failure; if (indev && entskb->dev && - skb_mac_header_was_set(entskb)) { + skb_mac_header_was_set(entskb) && + skb_mac_header_len(entskb) != 0) { struct nfqnl_msg_packet_hw phw; int len; -- 2.25.1

1 0

[PATCH openEuler-5.10 v2] Disable legacy DRM drivers
by Liu Zixian 28 Dec '21

28 Dec '21

euleros inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4OBDE CVE: NA ------------------------------------------------- This config enables dangerous old drivers. It is selected by CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT which is suggested by upstream community that "modern distros should consider turning it off". CONFIG_DRM_VM was selected by CONFIG_DRM_LEGACY and can be turned off now. Other distros has disabled this config: https://src.fedoraproject.org/rpms/kernel/blob/rawhide/f/kernel-aarch64-rhe… Signed-off-by: Liu Zixian <liuzixian4(a)huawei.com> --- arch/arm64/configs/openeuler_defconfig | 10 ++-------- arch/x86/configs/openeuler_defconfig | 10 ++-------- 2 files changed, 4 insertions(+), 16 deletions(-) diff --git a/arch/arm64/configs/openeuler_defconfig b/arch/arm64/configs/openeuler_defconfig index 17bc8750b..6949824e8 100644 --- a/arch/arm64/configs/openeuler_defconfig +++ b/arch/arm64/configs/openeuler_defconfig @@ -4673,7 +4673,6 @@ CONFIG_DRM_TTM_DMA_PAGE_POOL=y CONFIG_DRM_VRAM_HELPER=y CONFIG_DRM_TTM_HELPER=y CONFIG_DRM_GEM_SHMEM_HELPER=y -CONFIG_DRM_VM=y CONFIG_DRM_SCHED=m # @@ -4719,7 +4718,7 @@ CONFIG_DRM_AMD_DC_DCN=y # CONFIG_HSA_AMD is not set CONFIG_DRM_NOUVEAU=m -CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT=y +# CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT is not set CONFIG_NOUVEAU_DEBUG=5 CONFIG_NOUVEAU_DEBUG_DEFAULT=3 # CONFIG_NOUVEAU_DEBUG_MMU is not set @@ -4817,12 +4816,7 @@ CONFIG_DRM_CIRRUS_QEMU=m # CONFIG_DRM_LIMA is not set # CONFIG_DRM_PANFROST is not set # CONFIG_DRM_TIDSS is not set -CONFIG_DRM_LEGACY=y -# CONFIG_DRM_TDFX is not set -# CONFIG_DRM_R128 is not set -# CONFIG_DRM_MGA is not set -# CONFIG_DRM_VIA is not set -# CONFIG_DRM_SAVAGE is not set +# CONFIG_DRM_LEGACY is not set CONFIG_DRM_PANEL_ORIENTATION_QUIRKS=y # diff --git a/arch/x86/configs/openeuler_defconfig b/arch/x86/configs/openeuler_defconfig index 7b6083018..dbae04231 100644 --- a/arch/x86/configs/openeuler_defconfig +++ b/arch/x86/configs/openeuler_defconfig @@ -5040,7 +5040,6 @@ CONFIG_DRM_TTM_DMA_PAGE_POOL=y CONFIG_DRM_VRAM_HELPER=m CONFIG_DRM_TTM_HELPER=m CONFIG_DRM_GEM_SHMEM_HELPER=y -CONFIG_DRM_VM=y CONFIG_DRM_SCHED=m # @@ -5085,7 +5084,7 @@ CONFIG_DRM_AMD_DC_DCN=y # CONFIG_HSA_AMD is not set CONFIG_DRM_NOUVEAU=m -CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT=y +# CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT is not set CONFIG_NOUVEAU_DEBUG=5 CONFIG_NOUVEAU_DEBUG_DEFAULT=3 # CONFIG_NOUVEAU_DEBUG_MMU is not set @@ -5226,12 +5225,7 @@ CONFIG_DRM_CIRRUS_QEMU=m # CONFIG_TINYDRM_ST7735R is not set # CONFIG_DRM_XEN is not set # CONFIG_DRM_VBOXVIDEO is not set -CONFIG_DRM_LEGACY=y -# CONFIG_DRM_TDFX is not set -# CONFIG_DRM_R128 is not set -# CONFIG_DRM_MGA is not set -# CONFIG_DRM_VIA is not set -# CONFIG_DRM_SAVAGE is not set +# CONFIG_DRM_LEGACY is not set CONFIG_DRM_PANEL_ORIENTATION_QUIRKS=y # -- 2.27.0

1 0

【邀请函】诚邀您参与2021年华为生态健康度调研
by Ecosurvey 28 Dec '21

28 Dec '21

尊敬的女士/先生：您好！感谢您选择与华为合作及在双方合作中给予的支持！为了更好地实现共同成长、共同发展，我们目前在开展“2021年华为生态健康度调研”。为此，我们委托独立的第三方调研机构广州尼尔森市场研究有限公司（以下简称尼尔森），来开展相关调研，以了解您对华为生态系统的评价和建议，并分析改进。本次调研内容仅供项目研究使用，对外会严格保密。问卷答题时长约5-10分钟。参与答题请点击问卷链接： https://csurveys.nielseniq.cn/wix/p1611532.aspx 您对本次调查有任何疑问或需要任何帮助，可以通过Ecosurvey(a)huawei.xn--com,-os0g9z677h027f 为工作人员将会解答您的问题。感谢您的参与！ 2021华为生态健康度调研项目组

1 0

2024

2023

2022

2021

2020

2019

Kernel