* [patch 01/11] device-dax: don't leak kernel memory to user space after unloading kmem
[not found] <20200522222217.ee14ad7eda7aab1e6697da6c@linux-foundation.org>
@ 2020-05-23 5:22 ` Andrew Morton
2020-05-23 5:22 ` [patch 03/11] rapidio: fix an error in get_user_pages_fast() error handling Andrew Morton
` (7 subsequent siblings)
8 siblings, 0 replies; 12+ messages in thread
From: Andrew Morton @ 2020-05-23 5:22 UTC (permalink / raw)
To: akpm, dan.j.williams, dave.jiang, david, linux-mm, mm-commits,
pasha.tatashin, stable, torvalds, vishal.l.verma
From: David Hildenbrand <david@redhat.com>
Subject: device-dax: don't leak kernel memory to user space after unloading kmem
Assume we have kmem configured and loaded:
[root@localhost ~]# cat /proc/iomem
...
140000000-33fffffff : Persistent Memory$
140000000-1481fffff : namespace0.0
150000000-33fffffff : dax0.0
150000000-33fffffff : System RAM
Assume we try to unload kmem. This force-unloading will work, even if
memory cannot get removed from the system.
[root@localhost ~]# rmmod kmem
[ 86.380228] removing memory fails, because memory [0x0000000150000000-0x0000000157ffffff] is onlined
...
[ 86.431225] kmem dax0.0: DAX region [mem 0x150000000-0x33fffffff] cannot be hotremoved until the next reboot
Now, we can reconfigure the namespace:
[root@localhost ~]# ndctl create-namespace --force --reconfig=namespace0.0 --mode=devdax
[ 131.409351] nd_pmem namespace0.0: could not reserve region [mem 0x140000000-0x33fffffff]dax
[ 131.410147] nd_pmem: probe of namespace0.0 failed with error -16namespace0.0 --mode=devdax
...
This fails as expected due to the busy memory resource, and the memory
cannot be used. However, the dax0.0 device is removed, and along its name.
The name of the memory resource now points at freed memory (name of the
device).
[root@localhost ~]# cat /proc/iomem
...
140000000-33fffffff : Persistent Memory
140000000-1481fffff : namespace0.0
150000000-33fffffff : �_�^7_��/_��wR��WQ���^��� ...
150000000-33fffffff : System RAM
We have to make sure to duplicate the string. While at it, remove the
superfluous setting of the name and fixup a stale comment.
Link: http://lkml.kernel.org/r/20200508084217.9160-2-david@redhat.com
Fixes: 9f960da72b25 ("device-dax: "Hotremove" persistent memory that is used like normal RAM")
Signed-off-by: David Hildenbrand <david@redhat.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Vishal Verma <vishal.l.verma@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: <stable@vger.kernel.org> [5.3]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/dax/kmem.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
--- a/drivers/dax/kmem.c~device-dax-dont-leak-kernel-memory-to-user-space-after-unloading-kmem
+++ a/drivers/dax/kmem.c
@@ -22,6 +22,7 @@ int dev_dax_kmem_probe(struct device *de
resource_size_t kmem_size;
resource_size_t kmem_end;
struct resource *new_res;
+ const char *new_res_name;
int numa_node;
int rc;
@@ -48,11 +49,16 @@ int dev_dax_kmem_probe(struct device *de
kmem_size &= ~(memory_block_size_bytes() - 1);
kmem_end = kmem_start + kmem_size;
- /* Region is permanently reserved. Hot-remove not yet implemented. */
- new_res = request_mem_region(kmem_start, kmem_size, dev_name(dev));
+ new_res_name = kstrdup(dev_name(dev), GFP_KERNEL);
+ if (!new_res_name)
+ return -ENOMEM;
+
+ /* Region is permanently reserved if hotremove fails. */
+ new_res = request_mem_region(kmem_start, kmem_size, new_res_name);
if (!new_res) {
dev_warn(dev, "could not reserve region [%pa-%pa]\n",
&kmem_start, &kmem_end);
+ kfree(new_res_name);
return -EBUSY;
}
@@ -63,12 +69,12 @@ int dev_dax_kmem_probe(struct device *de
* unknown to us that will break add_memory() below.
*/
new_res->flags = IORESOURCE_SYSTEM_RAM;
- new_res->name = dev_name(dev);
rc = add_memory(numa_node, new_res->start, resource_size(new_res));
if (rc) {
release_resource(new_res);
kfree(new_res);
+ kfree(new_res_name);
return rc;
}
dev_dax->dax_kmem_res = new_res;
@@ -83,6 +89,7 @@ static int dev_dax_kmem_remove(struct de
struct resource *res = dev_dax->dax_kmem_res;
resource_size_t kmem_start = res->start;
resource_size_t kmem_size = resource_size(res);
+ const char *res_name = res->name;
int rc;
/*
@@ -102,6 +109,7 @@ static int dev_dax_kmem_remove(struct de
/* Release and free dax resources */
release_resource(res);
kfree(res);
+ kfree(res_name);
dev_dax->dax_kmem_res = NULL;
return 0;
_
^ permalink raw reply [flat|nested] 12+ messages in thread* [patch 03/11] rapidio: fix an error in get_user_pages_fast() error handling
[not found] <20200522222217.ee14ad7eda7aab1e6697da6c@linux-foundation.org>
2020-05-23 5:22 ` [patch 01/11] device-dax: don't leak kernel memory to user space after unloading kmem Andrew Morton
@ 2020-05-23 5:22 ` Andrew Morton
2020-05-23 5:22 ` [patch 06/11] kasan: disable branch tracing for core runtime Andrew Morton
` (6 subsequent siblings)
8 siblings, 0 replies; 12+ messages in thread
From: Andrew Morton @ 2020-05-23 5:22 UTC (permalink / raw)
To: akpm, alex.bou9, dan.carpenter, jhubbard, linux-mm, mm-commits,
mporter, stable, sumit.semwal, torvalds
From: John Hubbard <jhubbard@nvidia.com>
Subject: rapidio: fix an error in get_user_pages_fast() error handling
In the case of get_user_pages_fast() returning fewer pages than requested,
rio_dma_transfer() does not quite do the right thing. It attempts to
release all the pages that were requested, rather than just the pages that
were pinned.
Fix the error handling so that only the pages that were successfully
pinned are released.
Link: http://lkml.kernel.org/r/20200517235620.205225-2-jhubbard@nvidia.com
Fixes: e8de370188d0 ("rapidio: add mport char device driver")
Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Matt Porter <mporter@kernel.crashing.org>
Cc: Alexandre Bounine <alex.bou9@gmail.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/rapidio/devices/rio_mport_cdev.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/rapidio/devices/rio_mport_cdev.c~rapidio-fix-an-error-in-get_user_pages_fast-error-handling
+++ a/drivers/rapidio/devices/rio_mport_cdev.c
@@ -877,6 +877,11 @@ rio_dma_transfer(struct file *filp, u32
rmcd_error("pinned %ld out of %ld pages",
pinned, nr_pages);
ret = -EFAULT;
+ /*
+ * Set nr_pages up to mean "how many pages to unpin, in
+ * the error handler:
+ */
+ nr_pages = pinned;
goto err_pg;
}
_
^ permalink raw reply [flat|nested] 12+ messages in thread* [patch 06/11] kasan: disable branch tracing for core runtime
[not found] <20200522222217.ee14ad7eda7aab1e6697da6c@linux-foundation.org>
2020-05-23 5:22 ` [patch 01/11] device-dax: don't leak kernel memory to user space after unloading kmem Andrew Morton
2020-05-23 5:22 ` [patch 03/11] rapidio: fix an error in get_user_pages_fast() error handling Andrew Morton
@ 2020-05-23 5:22 ` Andrew Morton
2020-05-23 5:23 ` [patch 07/11] sh: include linux/time_types.h for sockios Andrew Morton
` (5 subsequent siblings)
8 siblings, 0 replies; 12+ messages in thread
From: Andrew Morton @ 2020-05-23 5:22 UTC (permalink / raw)
To: akpm, andreyknvl, aryabinin, cai, dvyukov, elver, glider,
linux-mm, mm-commits, rong.a.chen, stable, torvalds
From: Marco Elver <elver@google.com>
Subject: kasan: disable branch tracing for core runtime
During early boot, while KASAN is not yet initialized, it is possible to
enter reporting code-path and end up in kasan_report(). While
uninitialized, the branch there prevents generating any reports, however,
under certain circumstances when branches are being traced
(TRACE_BRANCH_PROFILING), we may recurse deep enough to cause kernel
reboots without warning.
To prevent similar issues in future, we should disable branch tracing for
the core runtime.
[elver@google.com: remove duplicate DISABLE_BRANCH_PROFILING, per Qian Cai]
Link: https://lore.kernel.org/lkml/20200517011732.GE24705@shao2-debian/
Link: http://lkml.kernel.org/r/20200522075207.157349-1-elver@google.com
Link: http://lkml.kernel.org/r//20200517011732.GE24705@shao2-debian/
Link: http://lkml.kernel.org/r/20200519182459.87166-1-elver@google.com
Signed-off-by: Marco Elver <elver@google.com>
Reported-by: kernel test robot <rong.a.chen@intel.com>
Reviewed-by: Andrey Konovalov <andreyknvl@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Qian Cai <cai@lca.pw>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/kasan/Makefile | 16 ++++++++--------
mm/kasan/generic.c | 1 -
mm/kasan/tags.c | 1 -
3 files changed, 8 insertions(+), 10 deletions(-)
--- a/mm/kasan/generic.c~kasan-disable-branch-tracing-for-core-runtime
+++ a/mm/kasan/generic.c
@@ -15,7 +15,6 @@
*/
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-#define DISABLE_BRANCH_PROFILING
#include <linux/export.h>
#include <linux/interrupt.h>
--- a/mm/kasan/Makefile~kasan-disable-branch-tracing-for-core-runtime
+++ a/mm/kasan/Makefile
@@ -15,14 +15,14 @@ CFLAGS_REMOVE_tags_report.o = $(CC_FLAGS
# Function splitter causes unnecessary splits in __asan_load1/__asan_store1
# see: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63533
-CFLAGS_common.o := $(call cc-option, -fno-conserve-stack -fno-stack-protector)
-CFLAGS_generic.o := $(call cc-option, -fno-conserve-stack -fno-stack-protector)
-CFLAGS_generic_report.o := $(call cc-option, -fno-conserve-stack -fno-stack-protector)
-CFLAGS_init.o := $(call cc-option, -fno-conserve-stack -fno-stack-protector)
-CFLAGS_quarantine.o := $(call cc-option, -fno-conserve-stack -fno-stack-protector)
-CFLAGS_report.o := $(call cc-option, -fno-conserve-stack -fno-stack-protector)
-CFLAGS_tags.o := $(call cc-option, -fno-conserve-stack -fno-stack-protector)
-CFLAGS_tags_report.o := $(call cc-option, -fno-conserve-stack -fno-stack-protector)
+CFLAGS_common.o := $(call cc-option, -fno-conserve-stack -fno-stack-protector) -DDISABLE_BRANCH_PROFILING
+CFLAGS_generic.o := $(call cc-option, -fno-conserve-stack -fno-stack-protector) -DDISABLE_BRANCH_PROFILING
+CFLAGS_generic_report.o := $(call cc-option, -fno-conserve-stack -fno-stack-protector) -DDISABLE_BRANCH_PROFILING
+CFLAGS_init.o := $(call cc-option, -fno-conserve-stack -fno-stack-protector) -DDISABLE_BRANCH_PROFILING
+CFLAGS_quarantine.o := $(call cc-option, -fno-conserve-stack -fno-stack-protector) -DDISABLE_BRANCH_PROFILING
+CFLAGS_report.o := $(call cc-option, -fno-conserve-stack -fno-stack-protector) -DDISABLE_BRANCH_PROFILING
+CFLAGS_tags.o := $(call cc-option, -fno-conserve-stack -fno-stack-protector) -DDISABLE_BRANCH_PROFILING
+CFLAGS_tags_report.o := $(call cc-option, -fno-conserve-stack -fno-stack-protector) -DDISABLE_BRANCH_PROFILING
obj-$(CONFIG_KASAN) := common.o init.o report.o
obj-$(CONFIG_KASAN_GENERIC) += generic.o generic_report.o quarantine.o
--- a/mm/kasan/tags.c~kasan-disable-branch-tracing-for-core-runtime
+++ a/mm/kasan/tags.c
@@ -12,7 +12,6 @@
*/
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-#define DISABLE_BRANCH_PROFILING
#include <linux/export.h>
#include <linux/interrupt.h>
_
^ permalink raw reply [flat|nested] 12+ messages in thread* [patch 07/11] sh: include linux/time_types.h for sockios
[not found] <20200522222217.ee14ad7eda7aab1e6697da6c@linux-foundation.org>
` (2 preceding siblings ...)
2020-05-23 5:22 ` [patch 06/11] kasan: disable branch tracing for core runtime Andrew Morton
@ 2020-05-23 5:23 ` Andrew Morton
2020-05-23 5:23 ` [patch 09/11] sparc32: use PUD rather than PGD to get PMD in srmmu_nocache_init() Andrew Morton
` (4 subsequent siblings)
8 siblings, 0 replies; 12+ messages in thread
From: Andrew Morton @ 2020-05-23 5:23 UTC (permalink / raw)
To: akpm, arnd, dalias, davem, glaubitz, linux-mm, mm-commits,
stable, torvalds, ysato
From: Arnd Bergmann <arnd@arndb.de>
Subject: sh: include linux/time_types.h for sockios
Using the socket ioctls on arch/sh (and only there) causes build time
problems when __kernel_old_timeval/__kernel_old_timespec are not already
visible to the compiler.
Add an explict include line for the header that defines these
structures.
Link: http://lkml.kernel.org/r/20200519131327.1836482-1-arnd@arndb.de
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reported-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Tested-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Fixes: 8c709f9a0693 ("y2038: sh: remove timeval/timespec usage from headers")
Fixes: 0768e17073dc ("net: socket: implement 64-bit timestamps")
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: Rich Felker <dalias@libc.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/sh/include/uapi/asm/sockios.h | 2 ++
1 file changed, 2 insertions(+)
--- a/arch/sh/include/uapi/asm/sockios.h~sh-include-linux-time_typesh-for-sockios
+++ a/arch/sh/include/uapi/asm/sockios.h
@@ -2,6 +2,8 @@
#ifndef __ASM_SH_SOCKIOS_H
#define __ASM_SH_SOCKIOS_H
+#include <linux/time_types.h>
+
/* Socket-level I/O control calls. */
#define FIOGETOWN _IOR('f', 123, int)
#define FIOSETOWN _IOW('f', 124, int)
_
^ permalink raw reply [flat|nested] 12+ messages in thread* [patch 09/11] sparc32: use PUD rather than PGD to get PMD in srmmu_nocache_init()
[not found] <20200522222217.ee14ad7eda7aab1e6697da6c@linux-foundation.org>
` (3 preceding siblings ...)
2020-05-23 5:23 ` [patch 07/11] sh: include linux/time_types.h for sockios Andrew Morton
@ 2020-05-23 5:23 ` Andrew Morton
2020-05-23 19:01 ` Mike Rapoport
2020-05-23 5:23 ` [patch 10/11] z3fold: fix use-after-free when freeing handles Andrew Morton
` (3 subsequent siblings)
8 siblings, 1 reply; 12+ messages in thread
From: Andrew Morton @ 2020-05-23 5:23 UTC (permalink / raw)
To: akpm, davem, linux-mm, lkp, matorola, mm-commits, rppt, stable, torvalds
From: Mike Rapoport <rppt@linux.ibm.com>
Subject: sparc32: use PUD rather than PGD to get PMD in srmmu_nocache_init()
The kbuild test robot reported the following warning:
arch/sparc/mm/srmmu.c: In function 'srmmu_nocache_init':
>> arch/sparc/mm/srmmu.c:300:9: error: variable 'pud' set but not used
>> [-Werror=unused-but-set-variable]
300 | pud_t *pud;
This warning is caused by misprint in the page table traversal in
srmmu_nocache_init() function which accessed a PMD entry using PGD rather
than PUD.
Since sparc32 has only 3 page table levels, the PGD and PUD are
essentially the same and usage of __nocache_fix() removed the type
checking.
Use PUD for the consistency and to silence the compiler warning.
Link: http://lkml.kernel.org/r/20200520132005.GM1059226@linux.ibm.com
Fixes: 7235db268a2777bc38 ("sparc32: use pgtable-nopud instead of 4level-fixup")
Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
Reported-by: kbuild test robot <lkp@intel.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Anatoly Pugachev <matorola@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/sparc/mm/srmmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/sparc/mm/srmmu.c~sparc32-use-pud-rather-than-pgd-to-get-pmd-in-srmmu_nocache_init
+++ a/arch/sparc/mm/srmmu.c
@@ -333,7 +333,7 @@ static void __init srmmu_nocache_init(vo
pgd = pgd_offset_k(vaddr);
p4d = p4d_offset(__nocache_fix(pgd), vaddr);
pud = pud_offset(__nocache_fix(p4d), vaddr);
- pmd = pmd_offset(__nocache_fix(pgd), vaddr);
+ pmd = pmd_offset(__nocache_fix(pud), vaddr);
pte = pte_offset_kernel(__nocache_fix(pmd), vaddr);
pteval = ((paddr >> 4) | SRMMU_ET_PTE | SRMMU_PRIV);
_
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [patch 09/11] sparc32: use PUD rather than PGD to get PMD in srmmu_nocache_init()
2020-05-23 5:23 ` [patch 09/11] sparc32: use PUD rather than PGD to get PMD in srmmu_nocache_init() Andrew Morton
@ 2020-05-23 19:01 ` Mike Rapoport
2020-05-23 19:10 ` Linus Torvalds
0 siblings, 1 reply; 12+ messages in thread
From: Mike Rapoport @ 2020-05-23 19:01 UTC (permalink / raw)
To: Andrew Morton
Cc: davem, linux-mm, lkp, matorola, mm-commits, stable, torvalds
On Fri, May 22, 2020 at 10:23:09PM -0700, Andrew Morton wrote:
> From: Mike Rapoport <rppt@linux.ibm.com>
> Subject: sparc32: use PUD rather than PGD to get PMD in srmmu_nocache_init()
>
> The kbuild test robot reported the following warning:
>
> arch/sparc/mm/srmmu.c: In function 'srmmu_nocache_init':
> >> arch/sparc/mm/srmmu.c:300:9: error: variable 'pud' set but not used
> >> [-Werror=unused-but-set-variable]
> 300 | pud_t *pud;
>
> This warning is caused by misprint in the page table traversal in
> srmmu_nocache_init() function which accessed a PMD entry using PGD rather
> than PUD.
>
> Since sparc32 has only 3 page table levels, the PGD and PUD are
> essentially the same and usage of __nocache_fix() removed the type
> checking.
>
> Use PUD for the consistency and to silence the compiler warning.
Unfortunately, this fixes a compile warning but breaks the boot :(
Since pgd, p4d and pud are eesentially the same thing and pgd_offset()
and p4d_offset() are no-ops, the __nocache_fix() should be done only at
pud level.
The correcteted patch is below, boot tested with qemu-systems-sparc.
> Link: http://lkml.kernel.org/r/20200520132005.GM1059226@linux.ibm.com
> Fixes: 7235db268a2777bc38 ("sparc32: use pgtable-nopud instead of 4level-fixup")
> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
> Reported-by: kbuild test robot <lkp@intel.com>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Anatoly Pugachev <matorola@gmail.com>
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
From 9b8b3214f7f079864dca0c6a7b684ab442eeb437 Mon Sep 17 00:00:00 2001
From: Mike Rapoport <rppt@linux.ibm.com>
Date: Wed, 20 May 2020 15:39:22 +0300
Subject: [PATCH] sparc32: use PUD rather than PGD to get PMD in srmmu_nocache_init()
The kbuild test robot reported the following warning:
arch/sparc/mm/srmmu.c: In function 'srmmu_nocache_init':
>> arch/sparc/mm/srmmu.c:300:9: error: variable 'pud' set but not used
>> [-Werror=unused-but-set-variable]
300 | pud_t *pud;
This warning is caused by misprint in the page table traversal in
srmmu_nocache_init() function which accessed a PMD entry using PGD rather
than PUD.
Since pgd, p4d and pud are eesentially the same thing and pgd_offset()
and p4d_offset() are no-ops, the __nocache_fix() should be done only at
pud level.
Remove __nocache_fix() for p4d_offset() and pud_offset() and use it only
for PUD and lower levels.
Link: http://lkml.kernel.org/r/20200520132005.GM1059226@linux.ibm.com
Fixes: 7235db268a2777bc38 ("sparc32: use pgtable-nopud instead of 4level-fixup")
Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
Reported-by: kbuild test robot <lkp@intel.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Anatoly Pugachev <matorola@gmail.com>
Cc: <stable@vger.kernel.org>
---
arch/sparc/mm/srmmu.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/sparc/mm/srmmu.c b/arch/sparc/mm/srmmu.c
index 6cb1ea2d2b5c..3d9690d940a3 100644
--- a/arch/sparc/mm/srmmu.c
+++ b/arch/sparc/mm/srmmu.c
@@ -302,9 +302,9 @@ static void __init srmmu_nocache_init(void)
while (vaddr < srmmu_nocache_end) {
pgd = pgd_offset_k(vaddr);
- p4d = p4d_offset(__nocache_fix(pgd), vaddr);
- pud = pud_offset(__nocache_fix(p4d), vaddr);
- pmd = pmd_offset(__nocache_fix(pgd), vaddr);
+ p4d = p4d_offset(pgd, vaddr);
+ pud = pud_offset(p4d, vaddr);
+ pmd = pmd_offset(__nocache_fix(pud), vaddr);
pte = pte_offset_kernel(__nocache_fix(pmd), vaddr);
pteval = ((paddr >> 4) | SRMMU_ET_PTE | SRMMU_PRIV);
--
2.26.2
^ permalink raw reply related [flat|nested] 12+ messages in thread* Re: [patch 09/11] sparc32: use PUD rather than PGD to get PMD in srmmu_nocache_init()
2020-05-23 19:01 ` Mike Rapoport
@ 2020-05-23 19:10 ` Linus Torvalds
2020-05-23 19:57 ` Mike Rapoport
0 siblings, 1 reply; 12+ messages in thread
From: Linus Torvalds @ 2020-05-23 19:10 UTC (permalink / raw)
To: Mike Rapoport
Cc: Andrew Morton, David Miller, Linux-MM, kernel test robot,
Anatoly Pugachev, mm-commits, stable
On Sat, May 23, 2020 at 12:02 PM Mike Rapoport <rppt@linux.ibm.com> wrote:
>
> Unfortunately, this fixes a compile warning but breaks the boot :(
Argh. I delayed applying/merging this overnight to see if there were
any reports, but this came in after I'd already merged Andrew's
patches and pushed them out.
So it's in my tree now as commit c2bc26f7ca1f ("sparc32: use PUD
rather than PGD to get PMD in srmmu_nocache_init()")
> The correcteted patch is below, boot tested with qemu-systems-sparc.
Mind sending a patch relative to the previous one that already got merged?
Also, would it perhaps be worth it to just make __nocache_fix() not
throw the type away? IOW, make it do something like
#define __nocache_fix(VADDR) \
((__typeof__(VADDR))__va(__nocache_pa(VADDR)))
or whatever? Wouldn't that show when those pgd/p4d/pud pointers get
mis-used because they don't end up dropping the type info..
Linus
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [patch 09/11] sparc32: use PUD rather than PGD to get PMD in srmmu_nocache_init()
2020-05-23 19:10 ` Linus Torvalds
@ 2020-05-23 19:57 ` Mike Rapoport
0 siblings, 0 replies; 12+ messages in thread
From: Mike Rapoport @ 2020-05-23 19:57 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andrew Morton, David Miller, Linux-MM, kernel test robot,
Anatoly Pugachev, mm-commits, stable
On Sat, May 23, 2020 at 12:10:27PM -0700, Linus Torvalds wrote:
> On Sat, May 23, 2020 at 12:02 PM Mike Rapoport <rppt@linux.ibm.com> wrote:
> >
> > Unfortunately, this fixes a compile warning but breaks the boot :(
>
> Argh. I delayed applying/merging this overnight to see if there were
> any reports, but this came in after I'd already merged Andrew's
> patches and pushed them out.
Actually, it's really by chance I noticed it tonight, although still it
was too late :)
> So it's in my tree now as commit c2bc26f7ca1f ("sparc32: use PUD
> rather than PGD to get PMD in srmmu_nocache_init()")
>
> > The correcteted patch is below, boot tested with qemu-systems-sparc.
>
> Mind sending a patch relative to the previous one that already got merged?
Sure.
> Also, would it perhaps be worth it to just make __nocache_fix() not
> throw the type away? IOW, make it do something like
>
> #define __nocache_fix(VADDR) \
> ((__typeof__(VADDR))__va(__nocache_pa(VADDR)))
>
> or whatever? Wouldn't that show when those pgd/p4d/pud pointers get
> mis-used because they don't end up dropping the type info..
Yes, I'll look into it.
> Linus
--
Sincerely yours,
Mike.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [patch 10/11] z3fold: fix use-after-free when freeing handles
[not found] <20200522222217.ee14ad7eda7aab1e6697da6c@linux-foundation.org>
` (4 preceding siblings ...)
2020-05-23 5:23 ` [patch 09/11] sparc32: use PUD rather than PGD to get PMD in srmmu_nocache_init() Andrew Morton
@ 2020-05-23 5:23 ` Andrew Morton
2020-05-25 0:08 ` + mmthp-stop-leaking-unreleased-file-pages.patch added to -mm tree Andrew Morton
` (2 subsequent siblings)
8 siblings, 0 replies; 12+ messages in thread
From: Andrew Morton @ 2020-05-23 5:23 UTC (permalink / raw)
To: akpm, cai, linux-mm, mm-commits, shentino, stable, torvalds,
uladzislau.rezki, vitaly.wool
From: Uladzislau Rezki <uladzislau.rezki@sony.com>
Subject: z3fold: fix use-after-free when freeing handles
free_handle() for a foreign handle may race with inter-page compaction,
what can lead to memory corruption. To avoid that, take write lock not
read lock in free_handle to be synchronized with __release_z3fold_page().
For example KASAN can detect it:
[ 33.723357] ==================================================================
[ 33.723401] BUG: KASAN: use-after-free in LZ4_decompress_safe+0x2c4/0x3b8
[ 33.723418] Read of size 1 at addr ffffffc976695ca3 by task GoogleApiHandle/4121
[ 33.723428]
[ 33.723449] CPU: 0 PID: 4121 Comm: GoogleApiHandle Tainted: P S OE 4.19.81-perf+ #162
[ 33.723461] Hardware name: Sony Mobile Communications. PDX-203(KONA) (DT)
[ 33.723473] Call trace:
[ 33.723495] dump_backtrace+0x0/0x288
[ 33.723512] show_stack+0x14/0x20
[ 33.723533] dump_stack+0xe4/0x124
[ 33.723551] print_address_description+0x80/0x2e0
[ 33.723566] kasan_report+0x268/0x2d0
[ 33.723584] __asan_load1+0x4c/0x58
[ 33.723601] LZ4_decompress_safe+0x2c4/0x3b8
[ 33.723619] lz4_decompress_crypto+0x3c/0x70
[ 33.723636] crypto_decompress+0x58/0x70
[ 33.723656] zcomp_decompress+0xd4/0x120
...
Apart from that, initialize zhdr->mapped_count in init_z3fold_page() and
remove "newpage" variable because it is not used anywhere.
Link: http://lkml.kernel.org/r/20200520082100.28876-1-vitaly.wool@konsulko.com
Signed-off-by: Uladzislau Rezki <uladzislau.rezki@sony.com>
Signed-off-by: Vitaly Wool <vitaly.wool@konsulko.com>
Cc: Qian Cai <cai@lca.pw>
Cc: Raymond Jennings <shentino@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/z3fold.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
--- a/mm/z3fold.c~z3fold-fix-use-after-free-when-freeing-handles
+++ a/mm/z3fold.c
@@ -318,16 +318,16 @@ static inline void free_handle(unsigned
slots = handle_to_slots(handle);
write_lock(&slots->lock);
*(unsigned long *)handle = 0;
- write_unlock(&slots->lock);
- if (zhdr->slots == slots)
+ if (zhdr->slots == slots) {
+ write_unlock(&slots->lock);
return; /* simple case, nothing else to do */
+ }
/* we are freeing a foreign handle if we are here */
zhdr->foreign_handles--;
is_free = true;
- read_lock(&slots->lock);
if (!test_bit(HANDLES_ORPHANED, &slots->pool)) {
- read_unlock(&slots->lock);
+ write_unlock(&slots->lock);
return;
}
for (i = 0; i <= BUDDY_MASK; i++) {
@@ -336,7 +336,7 @@ static inline void free_handle(unsigned
break;
}
}
- read_unlock(&slots->lock);
+ write_unlock(&slots->lock);
if (is_free) {
struct z3fold_pool *pool = slots_to_pool(slots);
@@ -422,6 +422,7 @@ static struct z3fold_header *init_z3fold
zhdr->start_middle = 0;
zhdr->cpu = -1;
zhdr->foreign_handles = 0;
+ zhdr->mapped_count = 0;
zhdr->slots = slots;
zhdr->pool = pool;
INIT_LIST_HEAD(&zhdr->buddy);
_
^ permalink raw reply [flat|nested] 12+ messages in thread* + mmthp-stop-leaking-unreleased-file-pages.patch added to -mm tree
[not found] <20200522222217.ee14ad7eda7aab1e6697da6c@linux-foundation.org>
` (5 preceding siblings ...)
2020-05-23 5:23 ` [patch 10/11] z3fold: fix use-after-free when freeing handles Andrew Morton
@ 2020-05-25 0:08 ` Andrew Morton
2020-05-25 0:49 ` + mm-remove-vm_bug_onpageslab-from-page_mapcount.patch " Andrew Morton
2020-05-28 0:10 ` + relay-handle-alloc_percpu-returning-null-in-relay_open.patch " Andrew Morton
8 siblings, 0 replies; 12+ messages in thread
From: Andrew Morton @ 2020-05-25 0:08 UTC (permalink / raw)
To: hannes, hughd, kirill.shutemov, mm-commits, riel, songliubraving, stable
The patch titled
Subject: mm,thp: stop leaking unreleased file pages
has been added to the -mm tree. Its filename is
mmthp-stop-leaking-unreleased-file-pages.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mmthp-stop-leaking-unreleased-file-pages.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mmthp-stop-leaking-unreleased-file-pages.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Hugh Dickins <hughd@google.com>
Subject: mm,thp: stop leaking unreleased file pages
When collapse_file() calls try_to_release_page(), it has already isolated
the page: so if releasing buffers happens to fail (as it sometimes does),
remember to putback_lru_page(): otherwise that page is left unreclaimable
and unfreeable, and the file extent uncollapsible.
Link: http://lkml.kernel.org/r/alpine.LSU.2.11.2005231837500.1766@eggly.anvils
Fixes: 99cb0dbd47a1 ("mm,thp: add read-only THP support for (non-shmem) FS")
Signed-off-by: Hugh Dickins <hughd@google.com>
Cc: Song Liu <songliubraving@fb.com>
Cc: Rik van Riel <riel@surriel.com>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: <stable@vger.kernel.org> [5.4+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/khugepaged.c | 1 +
1 file changed, 1 insertion(+)
--- a/mm/khugepaged.c~mmthp-stop-leaking-unreleased-file-pages
+++ a/mm/khugepaged.c
@@ -1692,6 +1692,7 @@ static void collapse_file(struct mm_stru
if (page_has_private(page) &&
!try_to_release_page(page, GFP_KERNEL)) {
result = SCAN_PAGE_HAS_PRIVATE;
+ putback_lru_page(page);
goto out_unlock;
}
_
Patches currently in -mm which might be from hughd@google.com are
mmthp-stop-leaking-unreleased-file-pages.patch
mm-memcontrol-charge-swapin-pages-on-instantiation-fix.patch
mm-vmstat-add-events-for-pmd-based-thp-migration-without-split-fix.patch
^ permalink raw reply [flat|nested] 12+ messages in thread* + mm-remove-vm_bug_onpageslab-from-page_mapcount.patch added to -mm tree
[not found] <20200522222217.ee14ad7eda7aab1e6697da6c@linux-foundation.org>
` (6 preceding siblings ...)
2020-05-25 0:08 ` + mmthp-stop-leaking-unreleased-file-pages.patch added to -mm tree Andrew Morton
@ 2020-05-25 0:49 ` Andrew Morton
2020-05-28 0:10 ` + relay-handle-alloc_percpu-returning-null-in-relay_open.patch " Andrew Morton
8 siblings, 0 replies; 12+ messages in thread
From: Andrew Morton @ 2020-05-25 0:49 UTC (permalink / raw)
To: hughd, khlebnikov, kirill.shutemov, mm-commits, rientjes, stable, vbabka
The patch titled
Subject: mm: remove VM_BUG_ON(PageSlab()) from page_mapcount()
has been added to the -mm tree. Its filename is
mm-remove-vm_bug_onpageslab-from-page_mapcount.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-remove-vm_bug_onpageslab-from-page_mapcount.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-remove-vm_bug_onpageslab-from-page_mapcount.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Subject: mm: remove VM_BUG_ON(PageSlab()) from page_mapcount()
Replace superfluous VM_BUG_ON() with comment about correct usage.
Technically reverts commit 1d148e218a0d0566b1c06f2f45f1436d53b049b2
("mm: add VM_BUG_ON_PAGE() to page_mapcount()"), but context have changed.
Function isolate_migratepages_block() runs some checks out of lru_lock
when choose pages for migration. After checking PageLRU() it checks extra
page references by comparing page_count() and page_mapcount(). Between
these two checks page could be removed from lru, freed and taken by slab.
As a result this race triggers VM_BUG_ON(PageSlab()) in page_mapcount().
Race window is tiny. For certain workload this happens around once a year.
page:ffffea0105ca9380 count:1 mapcount:0 mapping:ffff88ff7712c180 index:0x0 compound_mapcount: 0
flags: 0x500000000008100(slab|head)
raw: 0500000000008100 dead000000000100 dead000000000200 ffff88ff7712c180
raw: 0000000000000000 0000000080200020 00000001ffffffff 0000000000000000
page dumped because: VM_BUG_ON_PAGE(PageSlab(page))
------------[ cut here ]------------
kernel BUG at ./include/linux/mm.h:628!
invalid opcode: 0000 [#1] SMP NOPTI
CPU: 77 PID: 504 Comm: kcompactd1 Tainted: G W 4.19.109-27 #1
Hardware name: Yandex T175-N41-Y3N/MY81-EX0-Y3N, BIOS R05 06/20/2019
RIP: 0010:isolate_migratepages_block+0x986/0x9b0
Code in isolate_migratepages_block() was added in commit 119d6d59dcc0
("mm, compaction: avoid isolating pinned pages") before adding VM_BUG_ON
into page_mapcount().
This race has been predicted in 2015 by Vlastimil Babka (see link below).
Link: http://lkml.kernel.org/r/159032779896.957378.7852761411265662220.stgit@buzz
Link: https://lore.kernel.org/lkml/557710E1.6060103@suse.cz/
Link: https://lore.kernel.org/linux-mm/158937872515.474360.5066096871639561424.stgit@buzz/T/ (v1)
Fixes: 1d148e218a0d ("mm: add VM_BUG_ON_PAGE() to page_mapcount()")
Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Acked-by: Hugh Dickins <hughd@google.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: David Rientjes <rientjes@google.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
include/linux/mm.h | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
--- a/include/linux/mm.h~mm-remove-vm_bug_onpageslab-from-page_mapcount
+++ a/include/linux/mm.h
@@ -782,6 +782,11 @@ static inline void *kvcalloc(size_t n, s
extern void kvfree(const void *addr);
+/*
+ * Mapcount of compound page as a whole, not includes mapped sub-pages.
+ *
+ * Must be called only for compound pages or any their tail sub-pages.
+ */
static inline int compound_mapcount(struct page *page)
{
VM_BUG_ON_PAGE(!PageCompound(page), page);
@@ -801,10 +806,15 @@ static inline void page_mapcount_reset(s
int __page_mapcount(struct page *page);
+/*
+ * Mapcount of 0-order page, for sub-page includes compound_mapcount().
+ *
+ * Result is undefined for pages which cannot be mapped into userspace.
+ * For example SLAB or special types of pages. See function page_has_type().
+ * They use this place in struct page differently.
+ */
static inline int page_mapcount(struct page *page)
{
- VM_BUG_ON_PAGE(PageSlab(page), page);
-
if (unlikely(PageCompound(page)))
return __page_mapcount(page);
return atomic_read(&page->_mapcount) + 1;
_
Patches currently in -mm which might be from khlebnikov@yandex-team.ru are
mm-compaction-avoid-vm_bug_onpageslab-in-page_mapcount.patch
mm-remove-vm_bug_onpageslab-from-page_mapcount.patch
kernel-watchdog-flush-all-printk-nmi-buffers-when-hardlockup-detected.patch
doc-cgroup-update-note-about-conditions-when-oom-killer-is-invoked.patch
^ permalink raw reply [flat|nested] 12+ messages in thread* + relay-handle-alloc_percpu-returning-null-in-relay_open.patch added to -mm tree
[not found] <20200522222217.ee14ad7eda7aab1e6697da6c@linux-foundation.org>
` (7 preceding siblings ...)
2020-05-25 0:49 ` + mm-remove-vm_bug_onpageslab-from-page_mapcount.patch " Andrew Morton
@ 2020-05-28 0:10 ` Andrew Morton
8 siblings, 0 replies; 12+ messages in thread
From: Andrew Morton @ 2020-05-28 0:10 UTC (permalink / raw)
To: ajd, akash.goel, carnil, dja, linux, mm-commits, mpe, rientjes, stable
The patch titled
Subject: kernel/relay.c: handle alloc_percpu returning NULL in relay_open
has been added to the -mm tree. Its filename is
relay-handle-alloc_percpu-returning-null-in-relay_open.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/relay-handle-alloc_percpu-returning-null-in-relay_open.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/relay-handle-alloc_percpu-returning-null-in-relay_open.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Daniel Axtens <dja@axtens.net>
Subject: kernel/relay.c: handle alloc_percpu returning NULL in relay_open
alloc_percpu() may return NULL, which means chan->buf may be set to NULL.
In that case, when we do *per_cpu_ptr(chan->buf, ...), we dereference an
invalid pointer:
BUG: Unable to handle kernel data access at 0x7dae0000
Faulting instruction address: 0xc0000000003f3fec
...
NIP [c0000000003f3fec] relay_open+0x29c/0x600
LR [c0000000003f3fc0] relay_open+0x270/0x600
Call Trace:
[c000000054353a70] [c0000000003f3fb4] relay_open+0x264/0x600 (unreliable)
[c000000054353b00] [c000000000451764] __blk_trace_setup+0x254/0x600
[c000000054353bb0] [c000000000451b78] blk_trace_setup+0x68/0xa0
[c000000054353c10] [c0000000010da77c] sg_ioctl+0x7bc/0x2e80
[c000000054353cd0] [c000000000758cbc] do_vfs_ioctl+0x13c/0x1300
[c000000054353d90] [c000000000759f14] ksys_ioctl+0x94/0x130
[c000000054353de0] [c000000000759ff8] sys_ioctl+0x48/0xb0
[c000000054353e20] [c00000000000bcd0] system_call+0x5c/0x68
Check if alloc_percpu returns NULL.
This was found by syzkaller both on x86 and powerpc, and the reproducer it
found on powerpc is capable of hitting the issue as an unprivileged user.
Link: http://lkml.kernel.org/r/20191219121256.26480-1-dja@axtens.net
Fixes: 017c59c042d0 ("relay: Use per CPU constructs for the relay channel buffer pointers")
Signed-off-by: Daniel Axtens <dja@axtens.net>
Reviewed-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com>
Acked-by: David Rientjes <rientjes@google.com>
Reported-by: syzbot+1e925b4b836afe85a1c6@syzkaller-ppc64.appspotmail.com
Reported-by: syzbot+587b2421926808309d21@syzkaller-ppc64.appspotmail.com
Reported-by: syzbot+58320b7171734bf79d26@syzkaller.appspotmail.com
Reported-by: syzbot+d6074fb08bdb2e010520@syzkaller.appspotmail.com
Cc: Akash Goel <akash.goel@intel.com>
Cc: Andrew Donnellan <ajd@linux.ibm.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Salvatore Bonaccorso <carnil@debian.org>
Cc: <stable@vger.kernel.org> [4.10+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
kernel/relay.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/kernel/relay.c~relay-handle-alloc_percpu-returning-null-in-relay_open
+++ a/kernel/relay.c
@@ -581,6 +581,11 @@ struct rchan *relay_open(const char *bas
return NULL;
chan->buf = alloc_percpu(struct rchan_buf *);
+ if (!chan->buf) {
+ kfree(chan);
+ return NULL;
+ }
+
chan->version = RELAYFS_CHANNEL_VERSION;
chan->n_subbufs = n_subbufs;
chan->subbuf_size = subbuf_size;
_
Patches currently in -mm which might be from dja@axtens.net are
kasan-stop-tests-being-eliminated-as-dead-code-with-fortify_source.patch
kasan-stop-tests-being-eliminated-as-dead-code-with-fortify_source-v4.patch
stringh-fix-incompatibility-between-fortify_source-and-kasan.patch
relay-handle-alloc_percpu-returning-null-in-relay_open.patch
^ permalink raw reply [flat|nested] 12+ messages in thread