Re: kasan: false use-after-scope warnings with KCOV

On 11/28/2017 03:35 PM, Mark Rutland wrote: > Hi, > > As a heads-up, I'm seeing a number of what appear to be false-positive > use-after-scope warnings when I enable both KCOV and KASAN (inline or > outline), > when using the Linaro 17.08 GCC7.1.1 for arm64. So far I haven't spotted these >

Re: [lkp-robot] [x86/mm/kasan] d17a1d97dc: WARNING:at_lib/stackdepot.c:#depot_save_stack

On 11/26/2017 10:58 AM, kernel test robot wrote: > > FYI, we noticed the following commit (built with gcc-7): > > commit: d17a1d97dc208d664c91cc387ffb752c7f85dc61 ("x86/mm/kasan: don't use > vmemmap_populate() to initialize shadow") >

Re: [lkp-robot] [x86/mm/kasan] d17a1d97dc: WARNING:at_lib/stackdepot.c:#depot_save_stack

On 11/26/2017 10:58 AM, kernel test robot wrote: > > FYI, we noticed the following commit (built with gcc-7): > > commit: d17a1d97dc208d664c91cc387ffb752c7f85dc61 ("x86/mm/kasan: don't use > vmemmap_populate() to initialize shadow") >

Re: [PATCH v3 05/19] x86/kasan/64: Teach KASAN about the cpu_entry_area

On 11/24/2017 07:27 PM, Andy Lutomirski wrote: >>> + cpu_entry_area_begin = (void >>> *)(__fix_to_virt(FIX_CPU_ENTRY_AREA_BOTTOM)); >>> + cpu_entry_area_end = (void *)(__fix_to_virt(FIX_CPU_ENTRY_AREA_TOP) + >>> PAGE_SIZE); >>> + >>>

Re: [PATCH v3 05/19] x86/kasan/64: Teach KASAN about the cpu_entry_area

On 11/24/2017 07:27 PM, Andy Lutomirski wrote: >>> + cpu_entry_area_begin = (void >>> *)(__fix_to_virt(FIX_CPU_ENTRY_AREA_BOTTOM)); >>> + cpu_entry_area_end = (void *)(__fix_to_virt(FIX_CPU_ENTRY_AREA_TOP) + >>> PAGE_SIZE); >>> + >>>

[PATCH v4] x86/mm/kasan: Teach KASAN about the cpu_entry_area

Andy Lutomirski <l...@kernel.org> Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> --- arch/x86/mm/kasan_init_64.c | 18 +- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/arch/x86/mm/kasan_init_64.c b/arch/x86/mm/kasan_init_64.c index 99dfed6dfef8..9ec7

[PATCH v4] x86/mm/kasan: Teach KASAN about the cpu_entry_area

From: Andy Lutomirski The cpu_entry_area will contain stacks. Make sure that KASAN has appropriate shadow mappings for them. Cc: Alexander Potapenko Cc: Dmitry Vyukov Cc: kasan-...@googlegroups.com Signed-off-by: Andy Lutomirski Signed-off-by: Andrey Ryabinin --- arch/x86/mm/kasan_init_64

Re: [PATCH v3 05/19] x86/kasan/64: Teach KASAN about the cpu_entry_area

On 11/24/2017 07:32 AM, Andy Lutomirski wrote: > The cpu_entry_area will contain stacks. Make sure that KASAN has > appropriate shadow mappings for them. > > Cc: Andrey Ryabinin <aryabi...@virtuozzo.com> > Cc: Alexander Potapenko <gli...@google.com> > Cc: Dmi

Re: [PATCH v3 05/19] x86/kasan/64: Teach KASAN about the cpu_entry_area

On 11/24/2017 07:32 AM, Andy Lutomirski wrote: > The cpu_entry_area will contain stacks. Make sure that KASAN has > appropriate shadow mappings for them. > > Cc: Andrey Ryabinin > Cc: Alexander Potapenko > Cc: Dmitry Vyukov > Cc: kasan-...@googlegroups.com > Signed

Re: [PATCH v2 06/18] x86/kasan/64: Teach KASAN about the cpu_entry_area

On 11/22/2017 06:22 PM, Andy Lutomirski wrote: > On Wed, Nov 22, 2017 at 1:05 AM, Andrey Ryabinin > <aryabi...@virtuozzo.com> wrote: >> >> >> On 11/22/2017 07:44 AM, Andy Lutomirski wrote: >>> The cpu_entry_area will contain stacks. Make sure that KA

Re: [PATCH v2 06/18] x86/kasan/64: Teach KASAN about the cpu_entry_area

On 11/22/2017 06:22 PM, Andy Lutomirski wrote: > On Wed, Nov 22, 2017 at 1:05 AM, Andrey Ryabinin > wrote: >> >> >> On 11/22/2017 07:44 AM, Andy Lutomirski wrote: >>> The cpu_entry_area will contain stacks. Make sure that KASAN has >>> appropriate sh

Re: [PATCH v2 06/18] x86/kasan/64: Teach KASAN about the cpu_entry_area

On 11/22/2017 07:44 AM, Andy Lutomirski wrote: > The cpu_entry_area will contain stacks. Make sure that KASAN has > appropriate shadow mappings for them. > > Cc: Andrey Ryabinin <aryabi...@virtuozzo.com> > Cc: Alexander Potapenko <gli...@google.com> > Cc: Dmi

Re: [PATCH v2 06/18] x86/kasan/64: Teach KASAN about the cpu_entry_area

On 11/22/2017 07:44 AM, Andy Lutomirski wrote: > The cpu_entry_area will contain stacks. Make sure that KASAN has > appropriate shadow mappings for them. > > Cc: Andrey Ryabinin > Cc: Alexander Potapenko > Cc: Dmitry Vyukov > Cc: kasan-...@googlegroups.com > Signed

[tip:x86/urgent] x86/mm/kasan: Don't use vmemmap_populate() to initialize shadow

Commit-ID: f68d62a56708b0c19dca7a998f408510f2fbc3a8 Gitweb: https://git.kernel.org/tip/f68d62a56708b0c19dca7a998f408510f2fbc3a8 Author: Andrey Ryabinin <aryabi...@virtuozzo.com> AuthorDate: Wed, 15 Nov 2017 17:36:35 -0800 Committer: Ingo Molnar <mi...@kernel.org> CommitDate:

[tip:x86/urgent] x86/mm/kasan: Don't use vmemmap_populate() to initialize shadow

Commit-ID: f68d62a56708b0c19dca7a998f408510f2fbc3a8 Gitweb: https://git.kernel.org/tip/f68d62a56708b0c19dca7a998f408510f2fbc3a8 Author: Andrey Ryabinin AuthorDate: Wed, 15 Nov 2017 17:36:35 -0800 Committer: Ingo Molnar CommitDate: Wed, 22 Nov 2017 07:18:35 +0100 x86/mm/kasan: Don't

Re: [PATCH 16/16] x86/entry/64: Move the IST stacks into cpu_entry_area

On 11/21/2017 10:38 AM, Ingo Molnar wrote: > > * Andy Lutomirski wrote: > >> /* May not be marked __init: used by software suspend */ >> void syscall_init(void) >> { >> @@ -1627,7 +1637,7 @@ void cpu_init(void) >> * set up and load the per-CPU TSS >> */ >>

Re: [PATCH 16/16] x86/entry/64: Move the IST stacks into cpu_entry_area

On 11/21/2017 10:38 AM, Ingo Molnar wrote: > > * Andy Lutomirski wrote: > >> /* May not be marked __init: used by software suspend */ >> void syscall_init(void) >> { >> @@ -1627,7 +1637,7 @@ void cpu_init(void) >> * set up and load the per-CPU TSS >> */ >> if

Re: [PATCH] lib/stackdepot: use a non-instrumented version of memcmp()

On 11/15/2017 08:34 PM, Alexander Potapenko wrote: > stackdepot used to call memcmp(), which compiler tools normally > instrument, therefore every lookup used to unnecessarily call > instrumented code. > This is somewhat ok in the case of KASAN, but under KMSAN a lot of time > was spent in the

Re: [PATCH] lib/stackdepot: use a non-instrumented version of memcmp()

On 11/15/2017 08:34 PM, Alexander Potapenko wrote: > stackdepot used to call memcmp(), which compiler tools normally > instrument, therefore every lookup used to unnecessarily call > instrumented code. > This is somewhat ok in the case of KASAN, but under KMSAN a lot of time > was spent in the

Re: [PATCH v2 2/2] arm64/mm/kasan: don't use vmemmap_populate() to initialize shadow

save us some memory > wasted on page tables and reduce TLB pressure. > > Signed-off-by: Will Deacon <will.dea...@arm.com> > Signed-off-by: Pavel Tatashin <pasha.tatas...@oracle.com> > --- Acked-by: Andrey Ryabinin <aryabi...@virtuozzo.com>

Re: [PATCH v2 2/2] arm64/mm/kasan: don't use vmemmap_populate() to initialize shadow

ted on page tables and reduce TLB pressure. > > Signed-off-by: Will Deacon > Signed-off-by: Pavel Tatashin > --- Acked-by: Andrey Ryabinin

Re: [devkmsg_write] BUG: KASAN: slab-out-of-bounds in copyin+0xea/0x170

On 11/07/2017 02:59 PM, Sergey Senozhatsky wrote: > On (11/07/17 19:45), Sergey Senozhatsky wrote: > [..] > > a quite similar KASAN report > https://marc.info/?l=linux-kernel=150900582526314=2 Yours is different. It looks like a real bug, the report says that we read 34 bytes from kmalloc-32

Re: [devkmsg_write] BUG: KASAN: slab-out-of-bounds in copyin+0xea/0x170

On 11/07/2017 02:59 PM, Sergey Senozhatsky wrote: > On (11/07/17 19:45), Sergey Senozhatsky wrote: > [..] > > a quite similar KASAN report > https://marc.info/?l=linux-kernel=150900582526314=2 Yours is different. It looks like a real bug, the report says that we read 34 bytes from kmalloc-32

Re: [devkmsg_write] BUG: KASAN: slab-out-of-bounds in copyin+0xea/0x170

On 11/07/2017 12:39 PM, Fengguang Wu wrote: > Hello, > > FYI this happens in v4.14-rc8 -- it's not necessarily a new bug. > > [ 22.184920] Freeing unused kernel memory: 824K > [ 22.199198] Freeing unused kernel memory: 1436K > [ 22.228460] x86/mm: Checked W+X mappings: passed, no W+X

Re: [devkmsg_write] BUG: KASAN: slab-out-of-bounds in copyin+0xea/0x170

On 11/07/2017 12:39 PM, Fengguang Wu wrote: > Hello, > > FYI this happens in v4.14-rc8 -- it's not necessarily a new bug. > > [ 22.184920] Freeing unused kernel memory: 824K > [ 22.199198] Freeing unused kernel memory: 1436K > [ 22.228460] x86/mm: Checked W+X mappings: passed, no W+X

Re: [PATCH v12 08/11] arm64/kasan: add and use kasan_map_populate()

On 10/18/2017 08:23 PM, Pavel Tatashin wrote: > Hi Andrew and Michal, > > There are a few changes I need to do to my series: > > 1. Replace these two patches: > > arm64/kasan: add and use kasan_map_populate() > x86/kasan: add and use kasan_map_populate() > > With: > > x86/mm/kasan: don't

Re: [PATCH v12 08/11] arm64/kasan: add and use kasan_map_populate()

On 10/18/2017 08:23 PM, Pavel Tatashin wrote: > Hi Andrew and Michal, > > There are a few changes I need to do to my series: > > 1. Replace these two patches: > > arm64/kasan: add and use kasan_map_populate() > x86/kasan: add and use kasan_map_populate() > > With: > > x86/mm/kasan: don't

[tip:x86/mm] x86/kasan: Use the same shadow offset for 4- and 5-level paging

Commit-ID: 12a8cc7fcf54a8575f094be1e99032ec38aa045c Gitweb: https://git.kernel.org/tip/12a8cc7fcf54a8575f094be1e99032ec38aa045c Author: Andrey Ryabinin <aryabi...@virtuozzo.com> AuthorDate: Fri, 29 Sep 2017 17:08:18 +0300 Committer: Ingo Molnar <mi...@kernel.org> CommitDate:

[tip:x86/mm] x86/kasan: Use the same shadow offset for 4- and 5-level paging

Commit-ID: 12a8cc7fcf54a8575f094be1e99032ec38aa045c Gitweb: https://git.kernel.org/tip/12a8cc7fcf54a8575f094be1e99032ec38aa045c Author: Andrey Ryabinin AuthorDate: Fri, 29 Sep 2017 17:08:18 +0300 Committer: Ingo Molnar CommitDate: Fri, 20 Oct 2017 13:07:09 +0200 x86/kasan: Use

Re: [PATCH v12 07/11] x86/kasan: add and use kasan_map_populate()

On 10/18/2017 08:14 PM, Pavel Tatashin wrote: > Thank you Andrey, I will test this patch. Should it go on top or replace the > existing patch in mm-tree? ARM and x86 should be done the same either both as > follow-ups or both replace. > It's a replacement of your patch. > Pavel > > -- >

Re: [PATCH v12 07/11] x86/kasan: add and use kasan_map_populate()

On 10/18/2017 08:14 PM, Pavel Tatashin wrote: > Thank you Andrey, I will test this patch. Should it go on top or replace the > existing patch in mm-tree? ARM and x86 should be done the same either both as > follow-ups or both replace. > It's a replacement of your patch. > Pavel > > -- >

Re: [PATCH v12 08/11] arm64/kasan: add and use kasan_map_populate()

On 10/18/2017 08:08 PM, Pavel Tatashin wrote: >> >> As I said, I'm fine either way, I just didn't want to cause extra work >> or rebasing: >> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2017-October/535703.html > > Makes sense. I am also fine either way, I can submit a new patch

Re: [PATCH v12 08/11] arm64/kasan: add and use kasan_map_populate()

On 10/18/2017 08:08 PM, Pavel Tatashin wrote: >> >> As I said, I'm fine either way, I just didn't want to cause extra work >> or rebasing: >> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2017-October/535703.html > > Makes sense. I am also fine either way, I can submit a new patch

Re: [PATCH v12 07/11] x86/kasan: add and use kasan_map_populate()

tch bellow works for me. Could you please make sure that it works for you as well? Just in case. From: Andrey Ryabinin <aryabi...@virtuozzo.com> Subject: x86/mm/kasan: don't use vmemmap_populate() to initialize shadow The kasan shadow is currently mapped using vmemmap_populate() since

Re: [PATCH v12 07/11] x86/kasan: add and use kasan_map_populate()

tch bellow works for me. Could you please make sure that it works for you as well? Just in case. From: Andrey Ryabinin Subject: x86/mm/kasan: don't use vmemmap_populate() to initialize shadow The kasan shadow is currently mapped using vmemmap_populate() since that provides a se

Re: [PATCH v12 08/11] arm64/kasan: add and use kasan_map_populate()

On 10/13/2017 08:32 PM, Pavel Tatashin wrote: > During early boot, kasan uses vmemmap_populate() to establish its shadow > memory. But, that interface is intended for struct pages use. > > Because of the current project, vmemmap won't be zeroed during allocation, > but kasan expects that memory

Re: [PATCH v12 08/11] arm64/kasan: add and use kasan_map_populate()

On 10/13/2017 08:32 PM, Pavel Tatashin wrote: > During early boot, kasan uses vmemmap_populate() to establish its shadow > memory. But, that interface is intended for struct pages use. > > Because of the current project, vmemmap won't be zeroed during allocation, > but kasan expects that memory

[PATCH 2/2] x86/crypto/sha1-mb: fix panic due to unaligned access

. Unaligned vmovdqa will generate GP fault. Fix this by replacing vmovdqa with vmovdqu which doesn't have alignment requirements. Fixes: 2249cbb53ead ("crypto: sha-mb - SHA1 multibuffer submit and flush routines for AVX2") Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.

[PATCH 2/2] x86/crypto/sha1-mb: fix panic due to unaligned access

. Unaligned vmovdqa will generate GP fault. Fix this by replacing vmovdqa with vmovdqu which doesn't have alignment requirements. Fixes: 2249cbb53ead ("crypto: sha-mb - SHA1 multibuffer submit and flush routines for AVX2") Signed-off-by: Andrey Ryabinin Cc: --- arch/x86/cryp

[PATCH 1/2] x86/crypto/sha256-mb: fix panic due to unaligned access

that alignment. Unaligned vmovdqa will generate GP fault. Fix this by replacing vmovdqa with vmovdqu which doesn't have alignment requirements. Fixes: a377c6b1876e ("crypto: sha256-mb - submit/flush routines for AVX2") Reported-by: Josh Poimboeuf <jpoim...@redhat.com> Signed-off-by:

[PATCH 1/2] x86/crypto/sha256-mb: fix panic due to unaligned access

that alignment. Unaligned vmovdqa will generate GP fault. Fix this by replacing vmovdqa with vmovdqu which doesn't have alignment requirements. Fixes: a377c6b1876e ("crypto: sha256-mb - submit/flush routines for AVX2") Reported-by: Josh Poimboeuf Signed-off-by: Andrey Ryabinin Cc: ---

Re: [PATCH v2] stackdepot: ignore junk last entry in case of switch from user mode.

On 10/11/2017 03:43 PM, Maninder Singh wrote: > Issue observed on ARM. > > Whenever there is switch from user mode, we end up with invalid last entry > with some user space address as below:- > > save_stack+0x40/0xec > __set_page_owner+0x2c/0x64 > > > __handle_domain_irq+0x9c/0x130

Re: [PATCH v2] stackdepot: ignore junk last entry in case of switch from user mode.

On 10/11/2017 03:43 PM, Maninder Singh wrote: > Issue observed on ARM. > > Whenever there is switch from user mode, we end up with invalid last entry > with some user space address as below:- > > save_stack+0x40/0xec > __set_page_owner+0x2c/0x64 > > > __handle_domain_irq+0x9c/0x130

Re: [lkp-robot] [x86/kconfig] 81d3871900: BUG:unable_to_handle_kernel

On 10/13/2017 07:45 AM, Josh Poimboeuf wrote: > On Thu, Oct 12, 2017 at 12:05:04PM -0500, Christopher Lameter wrote: >> On Wed, 11 Oct 2017, Josh Poimboeuf wrote: >> >>> I failed to add the slab maintainers to CC on the last attempt. Trying >>> again. >> >> >> Hmmm... Yea. SLOB is rarely used and

Re: [lkp-robot] [x86/kconfig] 81d3871900: BUG:unable_to_handle_kernel

On 10/13/2017 07:45 AM, Josh Poimboeuf wrote: > On Thu, Oct 12, 2017 at 12:05:04PM -0500, Christopher Lameter wrote: >> On Wed, 11 Oct 2017, Josh Poimboeuf wrote: >> >>> I failed to add the slab maintainers to CC on the last attempt. Trying >>> again. >> >> >> Hmmm... Yea. SLOB is rarely used and

Re: [PATCH v3 2/3] Makefile: support flag -fsanitizer-coverage=trace-cmp

On 10/10/2017 06:27 PM, Alexander Potapenko wrote: > > v3: - Andrey Ryabinin's comments: reinstated scripts/Makefile.kcov > and moved CFLAGS_KCOV there, dropped CFLAGS_KCOV_COMPS Huh? Try again. > diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib > index

Re: [PATCH v3 2/3] Makefile: support flag -fsanitizer-coverage=trace-cmp

On 10/10/2017 06:27 PM, Alexander Potapenko wrote: > > v3: - Andrey Ryabinin's comments: reinstated scripts/Makefile.kcov > and moved CFLAGS_KCOV there, dropped CFLAGS_KCOV_COMPS Huh? Try again. > diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib > index

Re: [PATCH] UBSAN: Add __ubsan_handle_type_mismatch_v1 handler

On 10/10/2017 10:06 AM, Prasad Sodagudi wrote: > In LLVM __ubsan_handle_type_mismatch handler is renamed to > __ubsan_handle_type_mismatch_v1. Add support for > __ubsan_handle_type_mismatch_v1 handler to avoid compilation > issues with latest llvm tool chain. Also keeping >

Re: [PATCH] UBSAN: Add __ubsan_handle_type_mismatch_v1 handler

On 10/10/2017 10:06 AM, Prasad Sodagudi wrote: > In LLVM __ubsan_handle_type_mismatch handler is renamed to > __ubsan_handle_type_mismatch_v1. Add support for > __ubsan_handle_type_mismatch_v1 handler to avoid compilation > issues with latest llvm tool chain. Also keeping >

Re: [PATCH v2 2/3] Makefile: support flag -fsanitizer-coverage=trace-cmp

On 10/09/2017 06:05 PM, Alexander Potapenko wrote: > v2: - updated KCOV_ENABLE_COMPARISONS description > --- > Makefile | 5 +++-- > lib/Kconfig.debug| 10 ++ > scripts/Makefile.lib | 6 ++ > 3 files changed, 19 insertions(+), 2 deletions(-) > > diff --git

Re: [PATCH v2 2/3] Makefile: support flag -fsanitizer-coverage=trace-cmp

On 10/09/2017 06:05 PM, Alexander Potapenko wrote: > v2: - updated KCOV_ENABLE_COMPARISONS description > --- > Makefile | 5 +++-- > lib/Kconfig.debug| 10 ++ > scripts/Makefile.lib | 6 ++ > 3 files changed, 19 insertions(+), 2 deletions(-) > > diff --git

Re: [PATCH] lightnvm: pblk: remove spinlock when freeing line metadata

t sleep(in pblk_mfree). > > There is no need for holding the line manager free_lock while > freeing line metadata, so remove the lock. > > Signed-off-by: Hans Holmberg <hans.holmb...@cnexlabs.com> Reviewed-by: Andrey Ryabinin <aryabi...@virtuozzo.com> I guess this also deserves stab

Re: [PATCH] lightnvm: pblk: remove spinlock when freeing line metadata

for holding the line manager free_lock while > freeing line metadata, so remove the lock. > > Signed-off-by: Hans Holmberg Reviewed-by: Andrey Ryabinin I guess this also deserves stable tag. The bug was introduced in 4.13 by commit 588726d3ec68 ("lightnvm: pblk: fail gracefully on i

Re: __ubsan_handle_type_mismatch converted to __ubsan_handle_type_mismatch_v1

On 10/06/2017 05:29 AM, Sodagudi Prasad wrote: > Hi All, > > Based on below links __ubsan_handle_type_mismatch has been renamed to  > __ubsan_handle_type_mismatch_v1. > >

Re: __ubsan_handle_type_mismatch converted to __ubsan_handle_type_mismatch_v1

On 10/06/2017 05:29 AM, Sodagudi Prasad wrote: > Hi All, > > Based on below links __ubsan_handle_type_mismatch has been renamed to  > __ubsan_handle_type_mismatch_v1. > >

[PATCH v2] mm/mempolicy: fix NUMA_INTERLEAVE_HIT counter

to increment NUMA_INTERLEAVE_HIT. Fixes: 3a321d2a3dde ("mm: change the call sites of numa statistics items") Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> --- mm/mempolicy.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/mm/mempolicy.c b/mm/m

[PATCH v2] mm/mempolicy: fix NUMA_INTERLEAVE_HIT counter

to increment NUMA_INTERLEAVE_HIT. Fixes: 3a321d2a3dde ("mm: change the call sites of numa statistics items") Signed-off-by: Andrey Ryabinin --- mm/mempolicy.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/mm/mempolicy.c b/mm/mempolicy.c index 006ba625c0b8..a2

[PATCH] mm/mempolicy: fix NUMA_INTERLEAVE_HIT counter

to increment NUMA_INTERLEAVE_HIT. Fixes: 3a321d2a3dde ("mm: change the call sites of numa statistics items") Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> --- mm/mempolicy.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/mm/mempolicy.c b/mm/m

[PATCH] mm/mempolicy: fix NUMA_INTERLEAVE_HIT counter

to increment NUMA_INTERLEAVE_HIT. Fixes: 3a321d2a3dde ("mm: change the call sites of numa statistics items") Signed-off-by: Andrey Ryabinin --- mm/mempolicy.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/mm/mempolicy.c b/mm/mempolicy.c index 006ba625c0b8..3a

[PATCH] mm: remove unused pgdat->inactive_ratio

Since commit 59dc76b0d4df ("mm: vmscan: reduce size of inactive file list") 'pgdat->inactive_ratio' is not used, except for printing "node_inactive_ratio: 0" in /proc/zoneinfo output. Remove it. Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> --- include/

[PATCH] mm: remove unused pgdat->inactive_ratio

Since commit 59dc76b0d4df ("mm: vmscan: reduce size of inactive file list") 'pgdat->inactive_ratio' is not used, except for printing "node_inactive_ratio: 0" in /proc/zoneinfo output. Remove it. Signed-off-by: Andrey Ryabinin --- include/linux/mmzone.h | 6 -- mm/

Re: [PATCH] lightnvm: pblk: use vfree_atomic when freeing line metadata

On 10/03/2017 05:11 PM, Javier González wrote: >> On 3 Oct 2017, at 16.07, Andrey Ryabinin <aryabi...@virtuozzo.com> wrote: >> >> >> >> On 10/03/2017 04:48 PM, Hans Holmberg wrote: >>> From: Hans Holmberg <hans.holmb...@cnexlabs.com> >

Re: [PATCH] lightnvm: pblk: use vfree_atomic when freeing line metadata

On 10/03/2017 05:11 PM, Javier González wrote: >> On 3 Oct 2017, at 16.07, Andrey Ryabinin wrote: >> >> >> >> On 10/03/2017 04:48 PM, Hans Holmberg wrote: >>> From: Hans Holmberg >>> >>> The commit bf22e37a6413 ("mm: add vfree_atom

Re: [PATCH] lightnvm: pblk: use vfree_atomic when freeing line metadata

On 10/03/2017 04:48 PM, Hans Holmberg wrote: > From: Hans Holmberg > > The commit bf22e37a6413 ("mm: add vfree_atomic()") made vfree unsafe to > call in atomic context (unless the call came from an interrupt) and > introduced vfree_atomic that is safe to call in

Re: [PATCH] lightnvm: pblk: use vfree_atomic when freeing line metadata

On 10/03/2017 04:48 PM, Hans Holmberg wrote: > From: Hans Holmberg > > The commit bf22e37a6413 ("mm: add vfree_atomic()") made vfree unsafe to > call in atomic context (unless the call came from an interrupt) and > introduced vfree_atomic that is safe to call in atomic context. > > So, since

Re: [PATCH] string.h: work around for increased stack usage

On 10/02/2017 11:40 AM, Arnd Bergmann wrote: > The hardened strlen() function causes rather large stack usage > in at least one file in the kernel when CONFIG_KASAN is enabled: > > drivers/media/usb/em28xx/em28xx-dvb.c: In function 'em28xx_dvb_init': >

Re: [PATCH] string.h: work around for increased stack usage

On 10/02/2017 11:40 AM, Arnd Bergmann wrote: > The hardened strlen() function causes rather large stack usage > in at least one file in the kernel when CONFIG_KASAN is enabled: > > drivers/media/usb/em28xx/em28xx-dvb.c: In function 'em28xx_dvb_init': >

[tip:x86/urgent] x86/asm: Use register variable to get stack pointer value

Commit-ID: 196bd485ee4f03ce4c690bfcf38138abfcd0a4bc Gitweb: https://git.kernel.org/tip/196bd485ee4f03ce4c690bfcf38138abfcd0a4bc Author: Andrey Ryabinin <aryabi...@virtuozzo.com> AuthorDate: Fri, 29 Sep 2017 17:15:36 +0300 Committer: Ingo Molnar <mi...@kernel.org> CommitDate:

[tip:x86/urgent] x86/asm: Use register variable to get stack pointer value

Commit-ID: 196bd485ee4f03ce4c690bfcf38138abfcd0a4bc Gitweb: https://git.kernel.org/tip/196bd485ee4f03ce4c690bfcf38138abfcd0a4bc Author: Andrey Ryabinin AuthorDate: Fri, 29 Sep 2017 17:15:36 +0300 Committer: Ingo Molnar CommitDate: Fri, 29 Sep 2017 19:39:44 +0200 x86/asm: Use register

[PATCH v2] kcov: remove pointless current != NULL check

__sanitizer_cov_trace_pc() is a hot code, so it's worth to remove pointless '!current' check. Current is never NULL. Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> Acked-by: Dmitry Vyukov <dvyu...@google.com> Acked-by: Mark Rutland <mark.rutl...@arm.com> ---

[PATCH v2] kcov: remove pointless current != NULL check

__sanitizer_cov_trace_pc() is a hot code, so it's worth to remove pointless '!current' check. Current is never NULL. Signed-off-by: Andrey Ryabinin Acked-by: Dmitry Vyukov Acked-by: Mark Rutland --- Changes since v1: - Collect acks and drop other patches. kernel/kcov.c | 2 +- 1 file

Re: [PATCH 1/3] kcov: remove #ifdef CONFIG_RANDOMIZE_BASE

On 09/19/2017 04:47 PM, Dmitry Vyukov wrote: > On Tue, Sep 19, 2017 at 3:30 PM, Mark Rutland <mark.rutl...@arm.com> wrote: >> Hi, >> >> On Tue, Sep 19, 2017 at 03:46:46PM +0300, Andrey Ryabinin wrote: >>> There is no need to surround kaslr_offset() w

Re: [PATCH 1/3] kcov: remove #ifdef CONFIG_RANDOMIZE_BASE

On 09/19/2017 04:47 PM, Dmitry Vyukov wrote: > On Tue, Sep 19, 2017 at 3:30 PM, Mark Rutland wrote: >> Hi, >> >> On Tue, Sep 19, 2017 at 03:46:46PM +0300, Andrey Ryabinin wrote: >>> There is no need to surround kaslr_offset() with CONFIG_RANDOMIZE_BASE >>&

[PATCH] x86: use register variable to get stack pointer value

current_stack_pointer(), rename __asm_call_sp to current_stack_pointer and use it instead of removed function. Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> --- arch/x86/include/asm/asm.h | 4 ++-- arch/x86/include/asm/thread_info.h | 11 --- arch/x86/kernel/ir

[PATCH] x86: use register variable to get stack pointer value

tack_pointer and use it instead of removed function. Signed-off-by: Andrey Ryabinin --- arch/x86/include/asm/asm.h | 4 ++-- arch/x86/include/asm/thread_info.h | 11 --- arch/x86/kernel/irq_32.c | 6 +++--- arch/x86/kernel/traps.c| 2 +- arch/x86/mm/tlb.c

Re: [PATCH v4 4/9] em28xx: fix em28xx_dvb_init for KASAN

On 09/27/2017 04:26 PM, Arnd Bergmann wrote: > On Tue, Sep 26, 2017 at 9:49 AM, Andrey Ryabinin > <aryabi...@virtuozzo.com> wrote: >> >> >> On 09/26/2017 09:47 AM, Arnd Bergmann wrote: >>> On Mon, Sep 25, 2017 at 11:32 PM, Arnd Bergmann <a...@arndb.de>

Re: [PATCH v4 4/9] em28xx: fix em28xx_dvb_init for KASAN

On 09/27/2017 04:26 PM, Arnd Bergmann wrote: > On Tue, Sep 26, 2017 at 9:49 AM, Andrey Ryabinin > wrote: >> >> >> On 09/26/2017 09:47 AM, Arnd Bergmann wrote: >>> On Mon, Sep 25, 2017 at 11:32 PM, Arnd Bergmann wrote: > >>> + ret = __builtin_st

Re: [PATCH v4 9/9] kasan: rework Kconfig settings

ow_bug.cgi?id=81715) > and a workaround for older compilers, which means that KASAN_EXTRA is > now just as bad as before and will lead to an instant stack overflow in > a few extreme cases. > > This reverts parts of commit commit 3f181b4 ("lib/Kconfig.debug: disable > -Wframe-larger-than warnings with KASAN=y"). > > Signed-off-by: Arnd Bergmann <a...@arndb.de> Acked-by: Andrey Ryabinin <aryabi...@virtuozzo.com>

Re: [PATCH v4 9/9] kasan: rework Kconfig settings

ow_bug.cgi?id=81715) > and a workaround for older compilers, which means that KASAN_EXTRA is > now just as bad as before and will lead to an instant stack overflow in > a few extreme cases. > > This reverts parts of commit commit 3f181b4 ("lib/Kconfig.debug: disable > -Wframe-larger-than warnings with KASAN=y"). > > Signed-off-by: Arnd Bergmann Acked-by: Andrey Ryabinin

Re: [PATCH v4 4/9] em28xx: fix em28xx_dvb_init for KASAN

On 09/26/2017 09:47 AM, Arnd Bergmann wrote: > On Mon, Sep 25, 2017 at 11:32 PM, Arnd Bergmann wrote: >> On Mon, Sep 25, 2017 at 7:41 AM, David Laight >> wrote: >>> From: Arnd Bergmann Sent: 22 September 2017 22:29 >>> ... It seems that this

Re: [PATCH v4 4/9] em28xx: fix em28xx_dvb_init for KASAN

On 09/26/2017 09:47 AM, Arnd Bergmann wrote: > On Mon, Sep 25, 2017 at 11:32 PM, Arnd Bergmann wrote: >> On Mon, Sep 25, 2017 at 7:41 AM, David Laight >> wrote: >>> From: Arnd Bergmann Sent: 22 September 2017 22:29 >>> ... It seems that this is triggered in part by using strlcpy(),

Re: [PATCH 3/3] kcov: remove useless barrier()s

On 09/19/2017 04:54 PM, Dmitry Vyukov wrote: > On Tue, Sep 19, 2017 at 3:52 PM, Andrey Ryabinin > <aryabi...@virtuozzo.com> wrote: >> >> >> On 09/19/2017 03:57 PM, Dmitry Vyukov wrote: >>> On Tue, Sep 19, 2017 at 2:46 PM, Andrey Ryabinin >>> <a

Re: [PATCH 3/3] kcov: remove useless barrier()s

On 09/19/2017 04:54 PM, Dmitry Vyukov wrote: > On Tue, Sep 19, 2017 at 3:52 PM, Andrey Ryabinin > wrote: >> >> >> On 09/19/2017 03:57 PM, Dmitry Vyukov wrote: >>> On Tue, Sep 19, 2017 at 2:46 PM, Andrey Ryabinin >>> wrote: >>>> As commen

Re: [PATCH 3/3] kcov: remove useless barrier()s

On 09/19/2017 03:57 PM, Dmitry Vyukov wrote: > On Tue, Sep 19, 2017 at 2:46 PM, Andrey Ryabinin > <aryabi...@virtuozzo.com> wrote: >> As comment says barriers needed for preempt_schedule_irq() case >> where in_interrupt() returns false. But we don't use in_interrupt

Re: [PATCH 3/3] kcov: remove useless barrier()s

On 09/19/2017 03:57 PM, Dmitry Vyukov wrote: > On Tue, Sep 19, 2017 at 2:46 PM, Andrey Ryabinin > wrote: >> As comment says barriers needed for preempt_schedule_irq() case >> where in_interrupt() returns false. But we don't use in_interrupt() >> since b274c0bb394c (&qu

[PATCH 2/3] kcov: remove pointless current != NULL check

__sanitizer_cov_trace_pc() is a hot code, so it's worth to remove pointless '!current' check. Current is never NULL. Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> --- kernel/kcov.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/kcov.c b/kernel/kcov.c

[PATCH 2/3] kcov: remove pointless current != NULL check

__sanitizer_cov_trace_pc() is a hot code, so it's worth to remove pointless '!current' check. Current is never NULL. Signed-off-by: Andrey Ryabinin --- kernel/kcov.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/kcov.c b/kernel/kcov.c index 2f0e7a7c7afc

[PATCH 3/3] kcov: remove useless barrier()s

no barrier required. Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> --- kernel/kcov.c | 10 -- 1 file changed, 10 deletions(-) diff --git a/kernel/kcov.c b/kernel/kcov.c index 14cc8c1a7cad..b7fbcbef88c1 100644 --- a/kernel/kcov.c +++ b/kernel/kcov.c @@ -71,14 +71,6

[PATCH 3/3] kcov: remove useless barrier()s

no barrier required. Signed-off-by: Andrey Ryabinin --- kernel/kcov.c | 10 -- 1 file changed, 10 deletions(-) diff --git a/kernel/kcov.c b/kernel/kcov.c index 14cc8c1a7cad..b7fbcbef88c1 100644 --- a/kernel/kcov.c +++ b/kernel/kcov.c @@ -71,14 +71,6 @@ void notrace __sanitizer_cov_tra

[PATCH 1/3] kcov: remove #ifdef CONFIG_RANDOMIZE_BASE

There is no need to surround kaslr_offset() with CONFIG_RANDOMIZE_BASE ifdef. kaslr_offset() will just return 0 if CONFIG_RANDOMIZE_BASE isn't set. Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> --- kernel/kcov.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/kernel/kc

[PATCH 1/3] kcov: remove #ifdef CONFIG_RANDOMIZE_BASE

There is no need to surround kaslr_offset() with CONFIG_RANDOMIZE_BASE ifdef. kaslr_offset() will just return 0 if CONFIG_RANDOMIZE_BASE isn't set. Signed-off-by: Andrey Ryabinin --- kernel/kcov.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/kernel/kcov.c b/kernel/kcov.c index

Re: [RFC PATCH 3/4] x86/asm: Make alternative macro interfaces more clear and consistent

On 09/16/2017 02:29 AM, Josh Poimboeuf wrote: > On Fri, Sep 15, 2017 at 11:01:19AM -0700, Linus Torvalds wrote: >> On Fri, Sep 15, 2017 at 9:53 AM, Andrey Ryabinin >> <aryabi...@virtuozzo.com> wrote: >>> >>> I'm not so sure that this is disabled optimizati

Re: [RFC PATCH 3/4] x86/asm: Make alternative macro interfaces more clear and consistent

On 09/16/2017 02:29 AM, Josh Poimboeuf wrote: > On Fri, Sep 15, 2017 at 11:01:19AM -0700, Linus Torvalds wrote: >> On Fri, Sep 15, 2017 at 9:53 AM, Andrey Ryabinin >> wrote: >>> >>> I'm not so sure that this is disabled optimization. I assume that global &g

Re: [RFC PATCH 3/4] x86/asm: Make alternative macro interfaces more clear and consistent

On 08/31/2017 08:25 PM, Josh Poimboeuf wrote: > > There have been a few other ideas which have *almost* worked: > > 1) Make the 'register void *__sp asm(_ASM_SP)' a global variable instead >of a local one. This works for GCC and doesn't break clang. However >it resulted in a lot of

Re: [RFC PATCH 3/4] x86/asm: Make alternative macro interfaces more clear and consistent

On 08/31/2017 08:25 PM, Josh Poimboeuf wrote: > > There have been a few other ideas which have *almost* worked: > > 1) Make the 'register void *__sp asm(_ASM_SP)' a global variable instead >of a local one. This works for GCC and doesn't break clang. However >it resulted in a lot of

Re: [PATCH] [v3] kasan: avoid -Wmaybe-uninitialized warning

tps://patchwork.kernel.org/patch/9641417/ > Suggested-by: Alexander Potapenko <gli...@google.com> > Suggested-by: Andrey Ryabinin <aryabi...@virtuozzo.com> > Cc: Dmitry Vyukov <dvyu...@google.com> > Signed-off-by: Arnd Bergmann <a...@arndb.de> > --- Acked-by: Andrey Ryabinin <aryabi...@virtuozzo.com>

Re: [PATCH] [v3] kasan: avoid -Wmaybe-uninitialized warning

tps://patchwork.kernel.org/patch/9641417/ > Suggested-by: Alexander Potapenko > Suggested-by: Andrey Ryabinin > Cc: Dmitry Vyukov > Signed-off-by: Arnd Bergmann > --- Acked-by: Andrey Ryabinin

[tip:x86/mm] x86/mm/dump_pagetables: Speed up page tables dump for CONFIG_KASAN=y

Commit-ID: 04b67022fb6d5b13025591f61a487a6ef7f4f05c Gitweb: http://git.kernel.org/tip/04b67022fb6d5b13025591f61a487a6ef7f4f05c Author: Andrey Ryabinin <aryabi...@virtuozzo.com> AuthorDate: Mon, 24 Jul 2017 18:25:58 +0300 Committer: Ingo Molnar <mi...@kernel.org> CommitDate:

[tip:x86/mm] x86/mm/dump_pagetables: Speed up page tables dump for CONFIG_KASAN=y

Commit-ID: 04b67022fb6d5b13025591f61a487a6ef7f4f05c Gitweb: http://git.kernel.org/tip/04b67022fb6d5b13025591f61a487a6ef7f4f05c Author: Andrey Ryabinin AuthorDate: Mon, 24 Jul 2017 18:25:58 +0300 Committer: Ingo Molnar CommitDate: Tue, 25 Jul 2017 11:22:09 +0200 x86/mm/dump_pagetables

Re: [PATCH] [v2] kasan: avoid -Wmaybe-uninitialized warning

On 07/25/2017 10:17 AM, Arnd Bergmann wrote: > On Mon, Jul 24, 2017 at 1:35 PM, Alexander Potapenko > wrote: >> On Fri, Jul 21, 2017 at 11:02 PM, Arnd Bergmann wrote: > >>> diff --git a/mm/kasan/report.c b/mm/kasan/report.c >>> index 04bb1d3eb9ec..28fb222ab149

<    1   2   3   4   5   6   7   8   9   10   >