[PATCH OpenHarmony-5.10 00/16] sync 5.10 bugfix

List overview All Threads
Download

newer

older

[PATCH OpenHarmony-5.10 00/16]...

yiyuchangchun＠126.com

11 Dec 2021 11 Dec '21

10:48 a.m.

From: Yu Changchun <yuchangchun1(a)huawei.com> Aili Yao (1): mm,hwpoison: return -EHWPOISON to denote that the page has already been poisoned Arnd Bergmann (2): asm-generic: fix ffs -Wshadow warning seqlock: avoid -Wshadow warnings Guoqing Jiang (1): md: revert io stats accounting Leah Rumancik (1): ext4: wipe ext4_dir_entry2 upon file deletion Li Huafei (2): perf env: Normalize aarch64.* and arm64.* to arm64 in normalize_arch() perf annotate: Add error log in symbol__annotate() Liang Wang (1): lib: use PFN_PHYS() in devmem_is_allowed() Paul E. McKenney (1): srcu: Take early exit on memory-allocation failure Russell King (1): ARM: footbridge: remove personal server platform Seunghun Han (2): acpi: acpica: fix acpi operand cache leak in dsutils.c acpi: acpica: fix acpi parse and parseext cache leaks Tony Luck (1): mm/memory-failure: use a mutex to avoid memory_failure() races Yang Yingliang (2): cgroup: disable kernel memory accounting for all memory cgroups by default hfs: fix null-ptr-deref in hfs_find_init() Yu Kuai (1): blk-mq: clear active_queues before clearing BLK_MQ_F_TAG_QUEUE_SHARED .../admin-guide/cgroup-v1/memory.rst | 6 +- .../admin-guide/kernel-parameters.txt | 1 + arch/arm/configs/footbridge_defconfig | 1 - arch/arm/mach-footbridge/Kconfig | 21 ------- arch/arm/mach-footbridge/Makefile | 2 - arch/arm/mach-footbridge/personal-pci.c | 57 ------------------- arch/arm/mach-footbridge/personal.c | 25 -------- arch/arm/mm/mmap.c | 2 +- block/blk-mq.c | 6 +- drivers/acpi/acpica/dsutils.c | 9 ++- drivers/acpi/acpica/psobject.c | 53 ++++++----------- drivers/md/md.c | 45 --------------- drivers/md/md.h | 1 - fs/ext4/namei.c | 24 +++++++- fs/hfs/bfind.c | 2 + include/asm-generic/bitops/builtin-ffs.h | 5 +- include/linux/seqlock.h | 14 ++--- kernel/rcu/srcutree.c | 4 +- mm/memcontrol.c | 6 +- mm/memory-failure.c | 40 ++++++++----- tools/perf/util/annotate.c | 4 +- tools/perf/util/env.c | 2 +- 22 files changed, 101 insertions(+), 229 deletions(-) delete mode 100644 arch/arm/mach-footbridge/personal-pci.c delete mode 100644 arch/arm/mach-footbridge/personal.c -- 2.25.1

Show replies by thread

yiyuchangchun＠126.com

11 Dec 11 Dec

10:48 a.m.

New subject: [PATCH OpenHarmony-5.10 01/16] cgroup: disable kernel memory accounting for all memory cgroups by default

From: Yang Yingliang <yangyingliang(a)huawei.com> ohos inclusion category: bugfix issue: #I4LRGQ CVE: NA ---------------------------------------- The kernel memory accounting for all memory cgroups is not stable, and it will cause a 100% regression in hackbench compared with kernel-4.19, so disable it by default. We can use the following command line to enable or disable it: cgroup.memory=kmem or cgroup.memory=kmem. Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> Reviewed-by: Kefeng Wang <wangkefeng.wang(a)huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai(a)huawei.com> Signed-off-by: Yu Changchun <yuchangchun1(a)huawei.com> --- Documentation/admin-guide/cgroup-v1/memory.rst | 6 +++--- Documentation/admin-guide/kernel-parameters.txt | 1 + mm/memcontrol.c | 6 ++++-- 3 files changed, 8 insertions(+), 5 deletions(-) diff --git a/Documentation/admin-guide/cgroup-v1/memory.rst b/Documentation/admin-guide/cgroup-v1/memory.rst index 12757e63b26c..fd913ae64ea8 100644 --- a/Documentation/admin-guide/cgroup-v1/memory.rst +++ b/Documentation/admin-guide/cgroup-v1/memory.rst @@ -308,9 +308,9 @@ the amount of kernel memory used by the system. Kernel memory is fundamentally different than user memory, since it can't be swapped out, which makes it possible to DoS the system by consuming too much of this precious resource. -Kernel memory accounting is enabled for all memory cgroups by default. But -it can be disabled system-wide by passing cgroup.memory=nokmem to the kernel -at boot time. In this case, kernel memory will not be accounted at all. +Kernel memory accounting is disabled for all memory cgroups by default. But +it can be enabled system-wide by passing cgroup.memory=kmem to the kernel +at boot time. In this case, kernel memory will all be accounted. Kernel memory limits are not imposed for the root cgroup. Usage for the root cgroup may or may not be accounted. The memory used is accumulated into diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index f103667d3727..4c0a0ca7542e 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -517,6 +517,7 @@ Format: <string> nosocket -- Disable socket memory accounting. nokmem -- Disable kernel memory accounting. + kmem -- Enable kernel memory accounting. checkreqprot [SELINUX] Set initial checkreqprot flag value. Format: { "0" | "1" } diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 92bf987d0a41..00156aebbcad 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -79,8 +79,8 @@ DEFINE_PER_CPU(struct mem_cgroup *, int_active_memcg); /* Socket memory accounting disabled? */ static bool cgroup_memory_nosocket; -/* Kernel memory accounting disabled? */ -static bool cgroup_memory_nokmem; +/* Kernel memory accounting disabled */ +static bool cgroup_memory_nokmem = true; /* Whether the swap controller is active */ #ifdef CONFIG_MEMCG_SWAP @@ -7134,6 +7134,8 @@ static int __init cgroup_memory(char *s) cgroup_memory_nosocket = true; if (!strcmp(token, "nokmem")) cgroup_memory_nokmem = true; + else if (!strcmp(token, "kmem")) + cgroup_memory_nokmem = false; } return 0; } -- 2.25.1

yiyuchangchun＠126.com

10:48 a.m.

New subject: [PATCH OpenHarmony-5.10 02/16] perf env: Normalize aarch64.* and arm64.* to arm64 in normalize_arch()

From: Li Huafei <lihuafei1(a)huawei.com> maillist inclusion category: bugfix issue: #I4LRGQ CVE: NA Reference: https://lkml.org/lkml/2021/7/26/599 -------------------------------- On my aarch64 big endian machine, the perf annotate does not work. # perf annotate Percent | Source code & Disassembly of [kernel.kallsyms] for cycles (253 samples, percent: local period) -------------------------------------------------------------------------------------------------------------- Percent | Source code & Disassembly of [kernel.kallsyms] for cycles (1 samples, percent: local period) ------------------------------------------------------------------------------------------------------------ Percent | Source code & Disassembly of [kernel.kallsyms] for cycles (47 samples, percent: local period) ------------------------------------------------------------------------------------------------------------- ... This is because the arch_find() function uses the normalized architecture name provided by normalize_arch(), and my machine's architecture name aarch64_be is not normalized to arm64. Like other architectures such as arm and powerpc, we can fuzzy match the architecture names associated with aarch64.* and normalize them. It seems that there is also arm64_be architecture name, which we also normalize to arm64. Signed-off-by: Li Huafei <lihuafei1(a)huawei.com> Reviewed-by: James Clark <james.clark(a)arm.com> Signed-off-by: Li Huafei <lihuafei1(a)huawei.com> Reviewed-by: Kuohai Xu <xukuohai(a)huawei.com> Signed-off-by: Chen Jun <chenjun102(a)huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai(a)huawei.com> Signed-off-by: Yu Changchun <yuchangchun1(a)huawei.com> --- tools/perf/util/env.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/util/env.c b/tools/perf/util/env.c index f0dceb527ca3..d5fd6bddaa6d 100644 --- a/tools/perf/util/env.c +++ b/tools/perf/util/env.c @@ -328,7 +328,7 @@ static const char *normalize_arch(char *arch) return "x86"; if (!strcmp(arch, "sun4u") || !strncmp(arch, "sparc", 5)) return "sparc"; - if (!strcmp(arch, "aarch64") || !strcmp(arch, "arm64")) + if (!strncmp(arch, "aarch64", 7) || !strncmp(arch, "arm64", 5)) return "arm64"; if (!strncmp(arch, "arm", 3) || !strcmp(arch, "sa110")) return "arm"; -- 2.25.1

yiyuchangchun＠126.com

10:48 a.m.

New subject: [PATCH OpenHarmony-5.10 03/16] perf annotate: Add error log in symbol__annotate()

From: Li Huafei <lihuafei1(a)huawei.com> maillist inclusion category: bugfix issue: #I4LRGQ Reference: https://lkml.org/lkml/2021/7/26/406 -------------------------------- When users use the perf annotate feature on unsupported machines, error logs should be printed for user feedback. Signed-off-by: Li Huafei <lihuafei1(a)huawei.com> Reviewed-by: James Clark <james.clark(a)arm.com> Signed-off-by: Li Huafei <lihuafei1(a)huawei.com> Reviewed-by: Kuohai Xu <xukuohai(a)huawei.com> Signed-off-by: Chen Jun <chenjun102(a)huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai(a)huawei.com> Signed-off-by: Yu Changchun <yuchangchun1(a)huawei.com> --- tools/perf/util/annotate.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c index 308189454788..4aaaf23b4878 100644 --- a/tools/perf/util/annotate.c +++ b/tools/perf/util/annotate.c @@ -2178,8 +2178,10 @@ int symbol__annotate(struct map_symbol *ms, struct evsel *evsel, return errno; args.arch = arch = arch__find(arch_name); - if (arch == NULL) + if (arch == NULL) { + pr_err("%s: unsupported arch %s\n", __func__, arch_name); return ENOTSUP; + } if (parch) *parch = arch; -- 2.25.1

yiyuchangchun＠126.com

10:48 a.m.

New subject: [PATCH OpenHarmony-5.10 04/16] mm/memory-failure: use a mutex to avoid memory_failure() races

From: Tony Luck <tony.luck(a)intel.com> mainline inclusion from mainline-v5.13 commit 171936ddaf97e6f4e1264f4128bb5cf15691339c category: bugfix issue: #I4LRGQ Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ------------------------------------------------- Patch series "mm,hwpoison: fix sending SIGBUS for Action Required MCE", v5. I wrote this patchset to materialize what I think is the current allowable solution mentioned by the previous discussion [1]. I simply borrowed Tony's mutex patch and Aili's return code patch, then I queued another one to find error virtual address in the best effort manner. I know that this is not a perfect solution, but should work for some typical case. [1]: https://lore.kernel.org/linux-mm/20210331192540.2141052f@alex-virtual-machi… This patch (of 2): There can be races when multiple CPUs consume poison from the same page. The first into memory_failure() atomically sets the HWPoison page flag and begins hunting for tasks that map this page. Eventually it invalidates those mappings and may send a SIGBUS to the affected tasks. But while all that work is going on, other CPUs see a "success" return code from memory_failure() and so they believe the error has been handled and continue executing. Fix by wrapping most of the internal parts of memory_failure() in a mutex. [akpm(a)linux-foundation.org: make mf_mutex local to memory_failure()] Link: https://lkml.kernel.org/r/20210521030156.2612074-1-nao.horiguchi@gmail.com Link: https://lkml.kernel.org/r/20210521030156.2612074-2-nao.horiguchi@gmail.com Signed-off-by: Tony Luck <tony.luck(a)intel.com> Signed-off-by: Naoya Horiguchi <naoya.horiguchi(a)nec.com> Reviewed-by: Borislav Petkov <bp(a)suse.de> Reviewed-by: Oscar Salvador <osalvador(a)suse.de> Cc: Aili Yao <yaoaili(a)kingsoft.com> Cc: Andy Lutomirski <luto(a)kernel.org> Cc: Borislav Petkov <bp(a)alien8.de> Cc: David Hildenbrand <david(a)redhat.com> Cc: Jue Wang <juew(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Conflicts: mm/memory-failure.c Signed-off-by: Nanyong Sun <sunnanyong(a)huawei.com> Reviewed-by: Chen Wandun <chenwandun(a)huawei.com> Signed-off-by: Chen Jun <chenjun102(a)huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai(a)huawei.com> Signed-off-by: Yu Changchun <yuchangchun1(a)huawei.com> --- mm/memory-failure.c | 37 +++++++++++++++++++++++-------------- 1 file changed, 23 insertions(+), 14 deletions(-) diff --git a/mm/memory-failure.c b/mm/memory-failure.c index d00d1b2e97da..8df59bb777a7 100644 --- a/mm/memory-failure.c +++ b/mm/memory-failure.c @@ -1329,8 +1329,9 @@ int memory_failure(unsigned long pfn, int flags) struct page *hpage; struct page *orig_head; struct dev_pagemap *pgmap; - int res; + int res = 0; unsigned long page_flags; + static DEFINE_MUTEX(mf_mutex); if (!sysctl_memory_failure_recovery) panic("Memory failure on page %lx", pfn); @@ -1348,12 +1349,17 @@ int memory_failure(unsigned long pfn, int flags) return -ENXIO; } - if (PageHuge(p)) - return memory_failure_hugetlb(pfn, flags); + mutex_lock(&mf_mutex); + + if (PageHuge(p)) { + res = memory_failure_hugetlb(pfn, flags); + goto unlock_mutex; + } + if (TestSetPageHWPoison(p)) { pr_err("Memory failure: %#lx: already hardware poisoned\n", pfn); - return 0; + goto unlock_mutex; } orig_head = hpage = compound_head(p); @@ -1373,17 +1379,18 @@ int memory_failure(unsigned long pfn, int flags) if (!(flags & MF_COUNT_INCREASED) && !get_hwpoison_page(p)) { if (is_free_buddy_page(p)) { action_result(pfn, MF_MSG_BUDDY, MF_DELAYED); - return 0; } else { action_result(pfn, MF_MSG_KERNEL_HIGH_ORDER, MF_IGNORED); - return -EBUSY; + res = -EBUSY; } + goto unlock_mutex; } if (PageTransHuge(hpage)) { if (try_to_split_thp_page(p, "Memory Failure") < 0) { action_result(pfn, MF_MSG_UNSPLIT_THP, MF_IGNORED); - return -EBUSY; + res = -EBUSY; + goto unlock_mutex; } VM_BUG_ON_PAGE(!page_count(p), p); } @@ -1403,7 +1410,7 @@ int memory_failure(unsigned long pfn, int flags) action_result(pfn, MF_MSG_BUDDY, MF_DELAYED); else action_result(pfn, MF_MSG_BUDDY_2ND, MF_DELAYED); - return 0; + goto unlock_mutex; } lock_page(p); @@ -1415,7 +1422,7 @@ int memory_failure(unsigned long pfn, int flags) if (PageCompound(p) && compound_head(p) != orig_head) { action_result(pfn, MF_MSG_DIFFERENT_COMPOUND, MF_IGNORED); res = -EBUSY; - goto out; + goto unlock_page; } /* @@ -1435,14 +1442,14 @@ int memory_failure(unsigned long pfn, int flags) num_poisoned_pages_dec(); unlock_page(p); put_page(p); - return 0; + goto unlock_mutex; } if (hwpoison_filter(p)) { if (TestClearPageHWPoison(p)) num_poisoned_pages_dec(); unlock_page(p); put_page(p); - return 0; + goto unlock_mutex; } /* @@ -1466,7 +1473,7 @@ int memory_failure(unsigned long pfn, int flags) if (!hwpoison_user_mappings(p, pfn, flags, &p)) { action_result(pfn, MF_MSG_UNMAP_FAILED, MF_IGNORED); res = -EBUSY; - goto out; + goto unlock_page; } /* @@ -1475,13 +1482,15 @@ int memory_failure(unsigned long pfn, int flags) if (PageLRU(p) && !PageSwapCache(p) && p->mapping == NULL) { action_result(pfn, MF_MSG_TRUNCATED_LRU, MF_IGNORED); res = -EBUSY; - goto out; + goto unlock_page; } identify_page_state: res = identify_page_state(pfn, p, page_flags); -out: +unlock_page: unlock_page(p); +unlock_mutex: + mutex_unlock(&mf_mutex); return res; } EXPORT_SYMBOL_GPL(memory_failure); -- 2.25.1

yiyuchangchun＠126.com

10:48 a.m.

New subject: [PATCH OpenHarmony-5.10 05/16] mm,hwpoison: return -EHWPOISON to denote that the page has already been poisoned

From: Aili Yao <yaoaili(a)kingsoft.com> mainline inclusion from mainline-v5.13 commit 47af12bae17f99b5e77f8651cb7f3e1877610acf category: bugfix issue: #I4LRGQ Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ------------------------------------------------- When memory_failure() is called with MF_ACTION_REQUIRED on the page that has already been hwpoisoned, memory_failure() could fail to send SIGBUS to the affected process, which results in infinite loop of MCEs. Currently memory_failure() returns 0 if it's called for already hwpoisoned page, then the caller, kill_me_maybe(), could return without sending SIGBUS to current process. An action required MCE is raised when the current process accesses to the broken memory, so no SIGBUS means that the current process continues to run and access to the error page again soon, so running into MCE loop. This issue can arise for example in the following scenarios: - Two or more threads access to the poisoned page concurrently. If local MCE is enabled, MCE handler independently handles the MCE events. So there's a race among MCE events, and the second or latter threads fall into the situation in question. - If there was a precedent memory error event and memory_failure() for the event failed to unmap the error page for some reason, the subsequent memory access to the error page triggers the MCE loop situation. To fix the issue, make memory_failure() return an error code when the error page has already been hwpoisoned. This allows memory error handler to control how it sends signals to userspace. And make sure that any process touching a hwpoisoned page should get a SIGBUS even in "already hwpoisoned" path of memory_failure() as is done in page fault path. Link: https://lkml.kernel.org/r/20210521030156.2612074-3-nao.horiguchi@gmail.com Signed-off-by: Aili Yao <yaoaili(a)kingsoft.com> Signed-off-by: Naoya Horiguchi <naoya.horiguchi(a)nec.com> Reviewed-by: Oscar Salvador <osalvador(a)suse.de> Cc: Andy Lutomirski <luto(a)kernel.org> Cc: Borislav Petkov <bp(a)alien8.de> Cc: Borislav Petkov <bp(a)suse.de> Cc: David Hildenbrand <david(a)redhat.com> Cc: Jue Wang <juew(a)google.com> Cc: Tony Luck <tony.luck(a)intel.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Nanyong Sun <sunnanyong(a)huawei.com> Reviewed-by: Chen Wandun <chenwandun(a)huawei.com> Signed-off-by: Chen Jun <chenjun102(a)huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai(a)huawei.com> Signed-off-by: Yu Changchun <yuchangchun1(a)huawei.com> --- mm/memory-failure.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/mm/memory-failure.c b/mm/memory-failure.c index 8df59bb777a7..c222d5a35338 100644 --- a/mm/memory-failure.c +++ b/mm/memory-failure.c @@ -1157,7 +1157,7 @@ static int memory_failure_hugetlb(unsigned long pfn, int flags) if (TestSetPageHWPoison(head)) { pr_err("Memory failure: %#lx: already hardware poisoned\n", pfn); - return 0; + return -EHWPOISON; } num_poisoned_pages_inc(); @@ -1359,6 +1359,7 @@ int memory_failure(unsigned long pfn, int flags) if (TestSetPageHWPoison(p)) { pr_err("Memory failure: %#lx: already hardware poisoned\n", pfn); + res = -EHWPOISON; goto unlock_mutex; } -- 2.25.1

yiyuchangchun＠126.com

10:48 a.m.

New subject: [PATCH OpenHarmony-5.10 06/16] asm-generic: fix ffs -Wshadow warning

From: Arnd Bergmann <arnd(a)arndb.de> mainline inclusion from mainline-v5.11 commit 6f6573a4044adefbd07f1bd951a2041150e888d7 category: bugfix issue: #I4LRGQ Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ------------------------------------------------- gcc -Wshadow warns about the ffs() definition that has the same name as the global ffs() built-in: include/asm-generic/bitops/builtin-ffs.h:13:28: warning: declaration of 'ffs' shadows a built-in function [-Wshadow] This is annoying because 'make W=2' warns every time this header gets included. Change it to use a #define instead, making callers directly reference the builtin. Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Zhang Jianhua <chris.zjh(a)huawei.com> Reviewed-by: He Ying <heying24(a)huawei.com> Signed-off-by: Chen Jun <chenjun102(a)huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai(a)huawei.com> Signed-off-by: Yu Changchun <yuchangchun1(a)huawei.com> --- include/asm-generic/bitops/builtin-ffs.h | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/include/asm-generic/bitops/builtin-ffs.h b/include/asm-generic/bitops/builtin-ffs.h index 458c85ebcd15..1dacfdb4247e 100644 --- a/include/asm-generic/bitops/builtin-ffs.h +++ b/include/asm-generic/bitops/builtin-ffs.h @@ -10,9 +10,6 @@ * the libc and compiler builtin ffs routines, therefore * differs in spirit from the above ffz (man ffs). */ -static __always_inline int ffs(int x) -{ - return __builtin_ffs(x); -} +#define ffs(x) __builtin_ffs(x) #endif -- 2.25.1

yiyuchangchun＠126.com

10:48 a.m.

New subject: [PATCH OpenHarmony-5.10 07/16] seqlock: avoid -Wshadow warnings

From: Arnd Bergmann <arnd(a)arndb.de> mainline inclusion from mainline-v5.11 commit a07c45312f06e288417049208c344ad76074627d category: bugfix issue: #I4LRGQ CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ------------------------------------------------- When building with W=2, there is a flood of warnings about the seqlock macros shadowing local variables: 19806 linux/seqlock.h:331:11: warning: declaration of 'seq' shadows a previous local [-Wshadow] 48 linux/seqlock.h:348:11: warning: declaration of 'seq' shadows a previous local [-Wshadow] 8 linux/seqlock.h:379:11: warning: declaration of 'seq' shadows a previous local [-Wshadow] Prefix the local variables to make the warning useful elsewhere again. Fixes: 52ac39e5db51 ("seqlock: seqcount_t: Implement all read APIs as statement expressions") Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Link: https://lkml.kernel.org/r/20201026165044.3722931-1-arnd@kernel.org Signed-off-by: Zhang Jianhua <chris.zjh(a)huawei.com> Reviewed-by: He Ying <heying24(a)huawei.com> Signed-off-by: Chen Jun <chenjun102(a)huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai(a)huawei.com> Signed-off-by: Yu Changchun <yuchangchun1(a)huawei.com> --- include/linux/seqlock.h | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/include/linux/seqlock.h b/include/linux/seqlock.h index 1ac20d75b061..fb89b05066f4 100644 --- a/include/linux/seqlock.h +++ b/include/linux/seqlock.h @@ -328,13 +328,13 @@ SEQCOUNT_LOCKNAME(ww_mutex, struct ww_mutex, true, &s->lock->base, ww_mu */ #define __read_seqcount_begin(s) \ ({ \ - unsigned seq; \ + unsigned __seq; \ \ - while ((seq = __seqcount_sequence(s)) & 1) \ + while ((__seq = __seqcount_sequence(s)) & 1) \ cpu_relax(); \ \ kcsan_atomic_next(KCSAN_SEQLOCK_REGION_MAX); \ - seq; \ + __seq; \ }) /** @@ -345,10 +345,10 @@ SEQCOUNT_LOCKNAME(ww_mutex, struct ww_mutex, true, &s->lock->base, ww_mu */ #define raw_read_seqcount_begin(s) \ ({ \ - unsigned seq = __read_seqcount_begin(s); \ + unsigned _seq = __read_seqcount_begin(s); \ \ smp_rmb(); \ - seq; \ + _seq; \ }) /** @@ -376,11 +376,11 @@ SEQCOUNT_LOCKNAME(ww_mutex, struct ww_mutex, true, &s->lock->base, ww_mu */ #define raw_read_seqcount(s) \ ({ \ - unsigned seq = __seqcount_sequence(s); \ + unsigned __seq = __seqcount_sequence(s); \ \ smp_rmb(); \ kcsan_atomic_next(KCSAN_SEQLOCK_REGION_MAX); \ - seq; \ + __seq; \ }) /** -- 2.25.1

yiyuchangchun＠126.com

10:48 a.m.

New subject: [PATCH OpenHarmony-5.10 08/16] lib: use PFN_PHYS() in devmem_is_allowed()

From: Liang Wang <wangliang101(a)huawei.com> maillist inclusion category: bugfix issue: #I4LRGQ CVE: NA Reference: https://lore.kernel.org/stable/20210731025057.78825-1-wangliang101@huawei.c… -------------------------------- The physical address may exceed 32 bits on 32-bit systems with more than 32 bits of physcial address,use PFN_PHYS() in devmem_is_allowed(), or the physical address may overflow and be truncated. We found this bug when mapping a high addresses through devmem tool, when CONFIG_STRICT_DEVMEM is enabled on the ARM with ARM_LPAE and devmem is used to map a high address that is not in the iomem address range, an unexpected error indicating no permission is returned. This bug was initially introduced from v2.6.37, and the function was moved to lib when v5.11. Link: https://lkml.kernel.org/r/20210731025057.78825-1-wangliang101@huawei.com Fixes: 087aaffcdf9c ("ARM: implement CONFIG_STRICT_DEVMEM by disabling access to RAM via /dev/mem") Fixes: 527701eda5f1 ("lib: Add a generic version of devmem_is_allowed()") Signed-off-by: Liang Wang <wangliang101(a)huawei.com> Reviewed-by: Luis Chamberlain <mcgrof(a)kernel.org> Cc: Palmer Dabbelt <palmerdabbelt(a)google.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Russell King <linux(a)armlinux.org.uk> Cc: Liang Wang <wangliang101(a)huawei.com> Cc: Xiaoming Ni <nixiaoming(a)huawei.com> Cc: Kefeng Wang <wangkefeng.wang(a)huawei.com> Cc: <stable(a)vger.kernel.org> [2.6.37+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Stephen Rothwell <sfr(a)canb.auug.org.au> [KF: fix devmem_is_allowed() on ARM] Signed-off-by: Kefeng Wang <wangkefeng.wang(a)huawei.com> Reviewed-by: Tong Tiangen <tongtiangen(a)huawei.com> Signed-off-by: Chen Jun <chenjun102(a)huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai(a)huawei.com> Signed-off-by: Yu Changchun <yuchangchun1(a)huawei.com> --- arch/arm/mm/mmap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mm/mmap.c b/arch/arm/mm/mmap.c index b8d912ac9e61..c64124fb34ea 100644 --- a/arch/arm/mm/mmap.c +++ b/arch/arm/mm/mmap.c @@ -179,7 +179,7 @@ int valid_mmap_phys_addr_range(unsigned long pfn, size_t size) */ int devmem_is_allowed(unsigned long pfn) { - if (iomem_is_exclusive(pfn << PAGE_SHIFT)) + if (iomem_is_exclusive(PFN_PHYS(pfn))) return 0; if (!page_is_ram(pfn)) return 1; -- 2.25.1

yiyuchangchun＠126.com

10:48 a.m.

New subject: [PATCH OpenHarmony-5.10 09/16] blk-mq: clear active_queues before clearing BLK_MQ_F_TAG_QUEUE_SHARED

From: Yu Kuai <yukuai3(a)huawei.com> mainline inclusion from mainline-5.14-rc6 commit 454bb6775202d94f0f489c4632efecdb62d3c904 category: bugfix issue: #I4LRGQ CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ------------------------------------------------- We run a test that delete and recover devcies frequently(two devices on the same host), and we found that 'active_queues' is super big after a period of time. If device a and device b share a tag set, and a is deleted, then blk_mq_exit_queue() will clear BLK_MQ_F_TAG_QUEUE_SHARED because there is only one queue that are using the tag set. However, if b is still active, the active_queues of b might never be cleared even if b is deleted. Thus clear active_queues before BLK_MQ_F_TAG_QUEUE_SHARED is cleared. Signed-off-by: Yu Kuai <yukuai3(a)huawei.com> Reviewed-by: Ming Lei <ming.lei(a)redhat.com> Link: https://lore.kernel.org/r/20210731062130.1533893-1-yukuai3@huawei.com Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Reviewed-by: Jason Yan <yanaijie(a)huawei.com> Signed-off-by: Chen Jun <chenjun102(a)huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai(a)huawei.com> Signed-off-by: Yu Changchun <yuchangchun1(a)huawei.com> --- block/blk-mq.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/block/blk-mq.c b/block/blk-mq.c index 0116f6e928ae..b0e7ec85a41c 100644 --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -2958,10 +2958,12 @@ static void queue_set_hctx_shared(struct request_queue *q, bool shared) int i; queue_for_each_hw_ctx(q, hctx, i) { - if (shared) + if (shared) { hctx->flags |= BLK_MQ_F_TAG_QUEUE_SHARED; - else + } else { + blk_mq_tag_idle(hctx); hctx->flags &= ~BLK_MQ_F_TAG_QUEUE_SHARED; + } } } -- 2.25.1

yiyuchangchun＠126.com

10:48 a.m.

New subject: [PATCH OpenHarmony-5.10 10/16] srcu: Take early exit on memory-allocation failure

From: "Paul E. McKenney" <paulmck(a)kernel.org> mainline inclusion from mainline-v5.11-rc1 commit 50edb988534c621a56ca103c0c16ac59e7399f01 category: bugfix issue: #I4LRGQ CVE: NA ------------------------------------------------------------------------- It turns out that init_srcu_struct() can be invoked from usermode tasks, and that fatal signals received by these tasks can cause memory-allocation failures. These failures are not handled well by init_srcu_struct(), so much so that NULL pointer dereferences can result. This commit therefore causes init_srcu_struct() to take an early exit upon detection of memory-allocation failure. Link: https://lore.kernel.org/lkml/20200908144306.33355-1-aik@ozlabs.ru/ Reported-by: Alexey Kardashevskiy <aik(a)ozlabs.ru> Tested-by: Alexey Kardashevskiy <aik(a)ozlabs.ru> Signed-off-by: Paul E. McKenney <paulmck(a)kernel.org> Signed-off-by: Zhen Lei <thunder.leizhen(a)huawei.com> Reviewed-by: Xie XiuQi <xiexiuqi(a)huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai(a)huawei.com> Signed-off-by: Yu Changchun <yuchangchun1(a)huawei.com> --- kernel/rcu/srcutree.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c index b8821665c435..1ca734767b9d 100644 --- a/kernel/rcu/srcutree.c +++ b/kernel/rcu/srcutree.c @@ -180,11 +180,13 @@ static int init_srcu_struct_fields(struct srcu_struct *ssp, bool is_static) INIT_DELAYED_WORK(&ssp->work, process_srcu); if (!is_static) ssp->sda = alloc_percpu(struct srcu_data); + if (!ssp->sda) + return -ENOMEM; init_srcu_struct_nodes(ssp, is_static); ssp->srcu_gp_seq_needed_exp = 0; ssp->srcu_last_gp_end = ktime_get_mono_fast_ns(); smp_store_release(&ssp->srcu_gp_seq_needed, 0); /* Init done. */ - return ssp->sda ? 0 : -ENOMEM; + return 0; } #ifdef CONFIG_DEBUG_LOCK_ALLOC -- 2.25.1

882

days inactive

882

days old

kernel@openharmony.io

Manage subscription

10 comments

1 participants

tags (0)

participants (1)

yiyuchangchun＠126.com