[PATCH] kernel/memremap, kasan: Make ZONE_DEVICE with work with KASAN

memory. Reported-by: Dave Chinner Signed-off-by: Andrey Ryabinin Cc: Dan Williams Cc: Dmitry Vyukov Cc: Alexander Potapenko --- include/linux/kasan.h | 13 ++- kernel/memremap.c | 10 ++ mm/kasan/kasan_init.c | 316 +++--- 3 files changed

Re: [PATCH 1/1] kasan: fix shadow_size calculation error in kasan_module_alloc

gt; ... > memset(ptr, 0, mod->core_layout.size);//crashed > > Unable to handle kernel paging request at virtual address 0f97b000 > .. > Call trace: > [] __asan_storeN+0x174/0x1a8 > [] memset+0x24/0x48 > [] layout_and_allocate+0xcd8/0x1800 >

Re: [PATCH 1/1] kasan: fix shadow_size calculation error in kasan_module_alloc

gt; ... > memset(ptr, 0, mod->core_layout.size);//crashed > > Unable to handle kernel paging request at virtual address 0f97b000 > .. > Call trace: > [] __asan_storeN+0x174/0x1a8 > [] memset+0x24/0x48 > [] layout_and_allocate+0xcd8/0x1800 >

[PATCH] x86/mm: don't free p4d table when it is folded at runtime.

d p4d page table layer at runtime") Signed-off-by: Andrey Ryabinin --- arch/x86/include/asm/pgalloc.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/include/asm/pgalloc.h b/arch/x86/include/asm/pgalloc.h index ada6410fd2ec..fbd578daa66e 100644 --- a/arch/x86/include/asm/pgall

[PATCH] x86/mm: don't free p4d table when it is folded at runtime.

d p4d page table layer at runtime") Signed-off-by: Andrey Ryabinin --- arch/x86/include/asm/pgalloc.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/include/asm/pgalloc.h b/arch/x86/include/asm/pgalloc.h index ada6410fd2ec..fbd578daa66e 100644 --- a/arch/x86/include/asm/pgall

Re: [PATCH] slub: fix __kmem_cache_empty for !CONFIG_SLUB_DEBUG

On 06/20/2018 12:33 AM, Shakeel Butt wrote: > For !CONFIG_SLUB_DEBUG, SLUB does not maintain the number of slabs > allocated per node for a kmem_cache. Thus, slabs_node() in > __kmem_cache_empty() will always return 0. So, in such situation, it is > required to check per-cpu slabs to make sure

Re: [PATCH] slub: fix __kmem_cache_empty for !CONFIG_SLUB_DEBUG

On 06/20/2018 12:33 AM, Shakeel Butt wrote: > For !CONFIG_SLUB_DEBUG, SLUB does not maintain the number of slabs > allocated per node for a kmem_cache. Thus, slabs_node() in > __kmem_cache_empty() will always return 0. So, in such situation, it is > required to check per-cpu slabs to make sure

Re: Possible regression in "slab, slub: skip unnecessary kasan_cache_shutdown()"

On 06/19/2018 05:51 AM, Jason A. Donenfeld wrote: > Hello Shakeel, > > It may be the case that f9e13c0a5a33d1eaec374d6d4dab53a4f72756a0 has > introduced a regression. I've bisected a failing test to this commit, > and after staring at the my code for a long time, I'm unable to find a > bug

Re: Possible regression in "slab, slub: skip unnecessary kasan_cache_shutdown()"

On 06/19/2018 05:51 AM, Jason A. Donenfeld wrote: > Hello Shakeel, > > It may be the case that f9e13c0a5a33d1eaec374d6d4dab53a4f72756a0 has > introduced a regression. I've bisected a failing test to this commit, > and after staring at the my code for a long time, I'm unable to find a > bug

Re: [PATCH] mm/kasan: Don't vfree() nonexistent vm_area.

On 05/23/2018 12:03 AM, Andrew Morton wrote: > On Tue, 22 May 2018 19:44:06 +0300 Andrey Ryabinin <aryabi...@virtuozzo.com> > wrote: > >>> Obviously we can't call vfree() to free memory that wasn't allocated via >>> vmalloc(). Use find_vm_a

Re: [PATCH] mm/kasan: Don't vfree() nonexistent vm_area.

On 05/23/2018 12:03 AM, Andrew Morton wrote: > On Tue, 22 May 2018 19:44:06 +0300 Andrey Ryabinin > wrote: > >>> Obviously we can't call vfree() to free memory that wasn't allocated via >>> vmalloc(). Use find_vm_area() to see if we can call vfree(). >>>

Re: [PATCH v2 2/2] kasan: fix memory hotplug during boot

On 05/23/2018 12:07 AM, Andrew Morton wrote: > On Tue, 22 May 2018 22:50:12 +0300 Andrey Ryabinin <aryabi...@virtuozzo.com> > wrote: > >> >> >> On 05/22/2018 07:36 PM, David Hildenbrand wrote: >>> On 22.05.2018 18:26, Andrey Ryabinin wrote: &g

Re: [PATCH v2 2/2] kasan: fix memory hotplug during boot

On 05/23/2018 12:07 AM, Andrew Morton wrote: > On Tue, 22 May 2018 22:50:12 +0300 Andrey Ryabinin > wrote: > >> >> >> On 05/22/2018 07:36 PM, David Hildenbrand wrote: >>> On 22.05.2018 18:26, Andrey Ryabinin wrote: >>>> >>>> >&

Re: [PATCH v2 2/2] kasan: fix memory hotplug during boot

On 05/22/2018 07:36 PM, David Hildenbrand wrote: > On 22.05.2018 18:26, Andrey Ryabinin wrote: >> >> >> On 05/22/2018 01:07 PM, David Hildenbrand wrote: >>> Using module_init() is wrong. E.g. ACPI adds and onlines memory before >>> our memory notifier g

Re: [PATCH v2 2/2] kasan: fix memory hotplug during boot

On 05/22/2018 07:36 PM, David Hildenbrand wrote: > On 22.05.2018 18:26, Andrey Ryabinin wrote: >> >> >> On 05/22/2018 01:07 PM, David Hildenbrand wrote: >>> Using module_init() is wrong. E.g. ACPI adds and onlines memory before >>> our memory notifier g

Re: [PATCH] mm/kasan: Don't vfree() nonexistent vm_area.

On 02/01/2018 07:33 PM, Andrey Ryabinin wrote: > KASAN uses different routines to map shadow for hot added memory and memory > obtained in boot process. Attempt to offline memory onlined by normal boot > process leads to this: > > Trying to vfree() nonexistent vm area (0

Re: [PATCH] mm/kasan: Don't vfree() nonexistent vm_area.

On 02/01/2018 07:33 PM, Andrey Ryabinin wrote: > KASAN uses different routines to map shadow for hot added memory and memory > obtained in boot process. Attempt to offline memory onlined by normal boot > process leads to this: > > Trying to vfree() nonexistent vm area (0

Re: [PATCH v2 1/2] kasan: free allocated shadow memory on MEM_CANCEL_ONLINE

for memory hotplug") Acked-by: Andrey Ryabinin <aryabi...@virtuozzo.com> Cc: <sta...@vger.kernel.org> > mm/kasan/kasan.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c > index 135ce2838c89..53564229674b 100644 > --- a

Re: [PATCH v2 2/2] kasan: fix memory hotplug during boot

eproducable with QEMU, just specify a DIMM when starting up. reproducible > > Signed-off-by: David Hildenbrand <da...@redhat.com> > --- Fixes: fa69b5989bb0 ("mm/kasan: add support for memory hotplug") Acked-by: Andrey Ryabinin <aryabi...@virtuozzo.com> C

Re: [PATCH v2 1/2] kasan: free allocated shadow memory on MEM_CANCEL_ONLINE

On 05/22/2018 01:07 PM, David Hildenbrand wrote: > We have to free memory again when we cancel onlining, otherwise a later > onlining attempt will fail. > > Signed-off-by: David Hildenbrand > --- Fixes: fa69b5989bb0 ("mm/kasan: add support for memory hotplug") Acke

Re: [PATCH v2 2/2] kasan: fix memory hotplug during boot

eproducable with QEMU, just specify a DIMM when starting up. reproducible > > Signed-off-by: David Hildenbrand > --- Fixes: fa69b5989bb0 ("mm/kasan: add support for memory hotplug") Acked-by: Andrey Ryabinin Cc: > mm/kasan/kasan.c | 2 +- > 1 file changed,

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

me was spent in the instrumentation. > > (A similar change has been previously committed for memcmp()) > > Signed-off-by: Alexander Potapenko <gli...@google.com> > Cc: Andrey Ryabinin <aryabi...@virtuozzo.com> > Cc: Dmitry Vyukov <dvyu...@google.com> > --- > lib/st

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

me was spent in the instrumentation. > > (A similar change has been previously committed for memcmp()) > > Signed-off-by: Alexander Potapenko > Cc: Andrey Ryabinin > Cc: Dmitry Vyukov > --- > lib/stackdepot.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > dif

Re: [PATCH 2/3] kcov: prefault the kcov_area

On 05/04/2018 05:38 PM, Mark Rutland wrote: > On Fri, May 04, 2018 at 05:36:49PM +0300, Andrey Ryabinin wrote: >> >> >> On 05/04/2018 04:55 PM, Mark Rutland wrote: >> >>> >>> +static void kcov_fault_in_area(struct kcov *kcov) >>> +{ >

Re: [PATCH 2/3] kcov: prefault the kcov_area

On 05/04/2018 05:38 PM, Mark Rutland wrote: > On Fri, May 04, 2018 at 05:36:49PM +0300, Andrey Ryabinin wrote: >> >> >> On 05/04/2018 04:55 PM, Mark Rutland wrote: >> >>> >>> +static void kcov_fault_in_area(struct kcov *kcov) >>> +{ >

Re: [PATCH 2/3] kcov: prefault the kcov_area

On 05/04/2018 04:55 PM, Mark Rutland wrote: > > +static void kcov_fault_in_area(struct kcov *kcov) > +{ > + unsigned long stride = PAGE_SIZE / sizeof(unsigned long); > + unsigned long *area = kcov->area; > + unsigned long offset; > + > + for (offset = 0; offset < kcov->size;

Re: [PATCH 2/3] kcov: prefault the kcov_area

On 05/04/2018 04:55 PM, Mark Rutland wrote: > > +static void kcov_fault_in_area(struct kcov *kcov) > +{ > + unsigned long stride = PAGE_SIZE / sizeof(unsigned long); > + unsigned long *area = kcov->area; > + unsigned long offset; > + > + for (offset = 0; offset < kcov->size;

Re: [PATCH 3/3] sched/core / kcov: avoid kcov_area during task switch

On 05/04/2018 04:55 PM, Mark Rutland wrote: > +#define kcov_prepare_switch(t) \ > +do { \ > + (t)->kcov_mode |= KCOV_IN_CTXSW;\ > +} while (0) > + > +#define kcov_finish_switch(t)\ > +do {

Re: [PATCH 3/3] sched/core / kcov: avoid kcov_area during task switch

On 05/04/2018 04:55 PM, Mark Rutland wrote: > +#define kcov_prepare_switch(t) \ > +do { \ > + (t)->kcov_mode |= KCOV_IN_CTXSW;\ > +} while (0) > + > +#define kcov_finish_switch(t)\ > +do {

Re: [kcov] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:1]

On 04/20/2018 07:45 PM, Yury Norov wrote: > On Fri, Apr 20, 2018 at 05:08:23PM +0300, Andrey Ryabinin wrote: >> >> >> On 04/19/2018 06:01 AM, Fengguang Wu wrote: >>> Hello, >>> >>> FYI this happens in mainline kernel 4.17.0-rc1. >>&g

Re: [kcov] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:1]

On 04/20/2018 07:45 PM, Yury Norov wrote: > On Fri, Apr 20, 2018 at 05:08:23PM +0300, Andrey Ryabinin wrote: >> >> >> On 04/19/2018 06:01 AM, Fengguang Wu wrote: >>> Hello, >>> >>> FYI this happens in mainline kernel 4.17.0-rc1. >>&g

Re: [kcov] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:1]

On 04/19/2018 06:01 AM, Fengguang Wu wrote: > Hello, > > FYI this happens in mainline kernel 4.17.0-rc1. > It at least dates back to v4.8 . > > [ 25.697463] > [ 25.697463] Start testing find_bit() with random-filled bitmap > [ 25.736615] find_next_bit:30203201 ns, 163965

Re: [kcov] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:1]

On 04/19/2018 06:01 AM, Fengguang Wu wrote: > Hello, > > FYI this happens in mainline kernel 4.17.0-rc1. > It at least dates back to v4.8 . > > [ 25.697463] > [ 25.697463] Start testing find_bit() with random-filled bitmap > [ 25.736615] find_next_bit:30203201 ns, 163965

Re: [cfs_trace_lock_tcd] BUG: KASAN: null-ptr-deref in cfs_trace_lock_tcd+0x25/0xeb

On 04/19/2018 04:35 PM, Andrey Ryabinin wrote: > > > On 04/18/2018 09:37 PM, Linus Torvalds wrote: >> Ugh, that lustre code is disgusting. >> >> I thought we were getting rid of it. >> >> Anyway, I started looking at why the stack trace is such an incredi

Re: [cfs_trace_lock_tcd] BUG: KASAN: null-ptr-deref in cfs_trace_lock_tcd+0x25/0xeb

On 04/19/2018 04:35 PM, Andrey Ryabinin wrote: > > > On 04/18/2018 09:37 PM, Linus Torvalds wrote: >> Ugh, that lustre code is disgusting. >> >> I thought we were getting rid of it. >> >> Anyway, I started looking at why the stack trace is such an incredi

Re: [cfs_trace_lock_tcd] BUG: KASAN: null-ptr-deref in cfs_trace_lock_tcd+0x25/0xeb

On 04/18/2018 09:37 PM, Linus Torvalds wrote: > Ugh, that lustre code is disgusting. > > I thought we were getting rid of it. > > Anyway, I started looking at why the stack trace is such an incredible > mess, with lots of stale entries. > > The reason (well, _one_ reason) seems to be

Re: [cfs_trace_lock_tcd] BUG: KASAN: null-ptr-deref in cfs_trace_lock_tcd+0x25/0xeb

On 04/18/2018 09:37 PM, Linus Torvalds wrote: > Ugh, that lustre code is disgusting. > > I thought we were getting rid of it. > > Anyway, I started looking at why the stack trace is such an incredible > mess, with lots of stale entries. > > The reason (well, _one_ reason) seems to be

Re: [PATCH] kasan: add no_sanitize attribute for clang builds

On 04/13/2018 08:34 PM, Andrey Konovalov wrote: > On Fri, Apr 13, 2018 at 5:31 PM, Andrey Ryabinin > <aryabi...@virtuozzo.com> wrote: >> >> >> On 04/12/2018 08:29 PM, Andrey Konovalov wrote: >>> KASAN uses the __no_sanitize_address macro to disable inst

Re: [PATCH] kasan: add no_sanitize attribute for clang builds

On 04/13/2018 08:34 PM, Andrey Konovalov wrote: > On Fri, Apr 13, 2018 at 5:31 PM, Andrey Ryabinin > wrote: >> >> >> On 04/12/2018 08:29 PM, Andrey Konovalov wrote: >>> KASAN uses the __no_sanitize_address macro to disable instrumentation >>> of particu

Re: [PATCH] kasan: add no_sanitize attribute for clang builds

On 04/12/2018 08:29 PM, Andrey Konovalov wrote: > KASAN uses the __no_sanitize_address macro to disable instrumentation > of particular functions. Right now it's defined only for GCC build, > which causes false positives when clang is used. > > This patch adds a definition for clang. > > Note,

Re: [PATCH] kasan: add no_sanitize attribute for clang builds

On 04/12/2018 08:29 PM, Andrey Konovalov wrote: > KASAN uses the __no_sanitize_address macro to disable instrumentation > of particular functions. Right now it's defined only for GCC build, > which causes false positives when clang is used. > > This patch adds a definition for clang. > > Note,

[PATCH v3 2/2] mm/vmscan: don't mess with pgdat->flags in memcg reclaim

r0m0.487s sys 1m8.505s According to the tracepoint in wait_iff_congested(), the 'cat' spent 50% of the time sleeping there. With the patch, cat don't waste time anymore: # time cat /dev/sda > /dev/null real5m32.911s user 0m0.411s sys 0m56.664s Signed-off-by:

[PATCH v3 2/2] mm/vmscan: don't mess with pgdat->flags in memcg reclaim

r0m0.487s sys 1m8.505s According to the tracepoint in wait_iff_congested(), the 'cat' spent 50% of the time sleeping there. With the patch, cat don't waste time anymore: # time cat /dev/sda > /dev/null real5m32.911s user 0m0.411s sys 0m56.664s Signed-off-by: Andr

[PATCH v3 1/2] mm/vmscan: don't change pgdat state on base of a single LRU list state

reclaim may alter global pgdat flags too, which is wrong. But that is separate issue and will be addressed in the next patch. This change will not have any effect on a systems with all workload concentrated in a single cgroup. Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> Re

[PATCH v3 1/2] mm/vmscan: don't change pgdat state on base of a single LRU list state

reclaim may alter global pgdat flags too, which is wrong. But that is separate issue and will be addressed in the next patch. This change will not have any effect on a systems with all workload concentrated in a single cgroup. Signed-off-by: Andrey Ryabinin Reviewed-by: Shakeel Butt Cc: Mel

Re: [PATCH v2 3/4] mm/vmscan: Don't change pgdat state on base of a single LRU list state.

On 04/06/2018 07:28 PM, Johannes Weiner wrote: > > This isn't quite equivalent to what we have right now. > > Yes, nr_dirty, nr_unqueued_dirty and nr_congested apply to file pages > only. That part is about waking the flushers and avoiding writing > files in 4k chunks from reclaim context. So

Re: [PATCH v2 3/4] mm/vmscan: Don't change pgdat state on base of a single LRU list state.

On 04/06/2018 07:28 PM, Johannes Weiner wrote: > > This isn't quite equivalent to what we have right now. > > Yes, nr_dirty, nr_unqueued_dirty and nr_congested apply to file pages > only. That part is about waking the flushers and avoiding writing > files in 4k chunks from reclaim context. So

Re: [PATCH] mm-vmscan-dont-mess-with-pgdat-flags-in-memcg-reclaim-v2-fix

On 04/06/2018 05:37 PM, Shakeel Butt wrote: >> >> @@ -2482,7 +2494,7 @@ static inline bool should_continue_reclaim(struct >> pglist_data *pgdat, >> static bool pgdat_memcg_congested(pg_data_t *pgdat, struct mem_cgroup >> *memcg) >> { >> return test_bit(PGDAT_CONGESTED, >flags) || >>

Re: [PATCH] mm-vmscan-dont-mess-with-pgdat-flags-in-memcg-reclaim-v2-fix

On 04/06/2018 05:37 PM, Shakeel Butt wrote: >> >> @@ -2482,7 +2494,7 @@ static inline bool should_continue_reclaim(struct >> pglist_data *pgdat, >> static bool pgdat_memcg_congested(pg_data_t *pgdat, struct mem_cgroup >> *memcg) >> { >> return test_bit(PGDAT_CONGESTED, >flags) || >>

[PATCH] mm-vmscan-dont-mess-with-pgdat-flags-in-memcg-reclaim-v2-fix

node B. Make congestion state per-cgroup-per-node and record it in 'struct mem_cgroup_per_node'. Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> --- include/linux/memcontrol.h | 5 +++-- mm/vmscan.c| 39 +-- 2 files changed, 2

[PATCH] mm-vmscan-dont-mess-with-pgdat-flags-in-memcg-reclaim-v2-fix

node B. Make congestion state per-cgroup-per-node and record it in 'struct mem_cgroup_per_node'. Signed-off-by: Andrey Ryabinin --- include/linux/memcontrol.h | 5 +++-- mm/vmscan.c| 39 +-- 2 files changed, 28 insertions(+), 16 deletions(-)

Re: [PATCH v2 4/4] mm/vmscan: Don't mess with pgdat->flags in memcg reclaim.

On 04/06/2018 05:13 AM, Shakeel Butt wrote: > On Fri, Mar 23, 2018 at 8:20 AM, Andrey Ryabinin > <aryabi...@virtuozzo.com> wrote: >> memcg reclaim may alter pgdat->flags based on the state of LRU lists >> in cgroup and its children. PGDAT_WRITEBACK may force kswapd

Re: [PATCH v2 4/4] mm/vmscan: Don't mess with pgdat->flags in memcg reclaim.

On 04/06/2018 05:13 AM, Shakeel Butt wrote: > On Fri, Mar 23, 2018 at 8:20 AM, Andrey Ryabinin > wrote: >> memcg reclaim may alter pgdat->flags based on the state of LRU lists >> in cgroup and its children. PGDAT_WRITEBACK may force kswapd to sleep >> congested_wa

Re: general protection fault in __mem_cgroup_free

t; Reported-by: syzbot+8a5de3cce7cdc70e9...@syzkaller.appspotmail.com > Fixes: 00f3ca2c2d66 ("mm: memcontrol: per-lruvec stats infrastructure") > Signed-off-by: Michal Hocko <mho...@suse.com> Reviewed-by: Andrey Ryabinin <aryabi...@virtuozzo.com> > --- > mm/memc

Re: general protection fault in __mem_cgroup_free

: syzbot+8a5de3cce7cdc70e9...@syzkaller.appspotmail.com > Fixes: 00f3ca2c2d66 ("mm: memcontrol: per-lruvec stats infrastructure") > Signed-off-by: Michal Hocko Reviewed-by: Andrey Ryabinin > --- > mm/memcontrol.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff

Re: [PATCH] x86/mm: Fix documentation of module mapping with 4-level paging

A. Shutemov <kirill.shute...@linux.intel.com> > Fixes: f5a40711fa58 ("x86/mm: Set MODULES_END to 0xff00") > Cc: Andrey Ryabinin <aryabi...@virtuozzo.com> > --- Acked-by: Andrey Ryabinin <aryabi...@virtuozzo.com> > Documentation/x86/x86_64/mm.txt | 2 +-

Re: [PATCH] x86/mm: Fix documentation of module mapping with 4-level paging

t; Fixes: f5a40711fa58 ("x86/mm: Set MODULES_END to 0xffffff00") > Cc: Andrey Ryabinin > --- Acked-by: Andrey Ryabinin > Documentation/x86/x86_64/mm.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Documentation/x86/x86_64/mm.tx

Re: [PATCH] slab, slub: skip unnecessary kasan_cache_shutdown()

stuck for couple of hours. With the > patch the script completed within a second. > > Signed-off-by: Shakeel Butt <shake...@google.com> > Acked-by: Andrey Ryabinin <aryabi...@virtuozzo.com>

Re: [PATCH] slab, slub: skip unnecessary kasan_cache_shutdown()

s_one_work > worker_thread > kthread > ret_from_fork > > This patch is based on the observation that if the kmem_cache to be > destroyed is empty then there should not be any objects of this cache in > the quarantine. > > Without the patch the script got s

[PATCH v2 1/4] mm/vmscan: Update stale comments

Update some comments that become stale since transiton from per-zone to per-node reclaim. Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> Acked-by: Michal Hocko <mho...@suse.com> --- mm/vmscan.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/m

[PATCH v2 1/4] mm/vmscan: Update stale comments

Update some comments that become stale since transiton from per-zone to per-node reclaim. Signed-off-by: Andrey Ryabinin Acked-by: Michal Hocko --- mm/vmscan.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index 4390a8d5be41

[PATCH v2 3/4] mm/vmscan: Don't change pgdat state on base of a single LRU list state.

reclaim may alter global pgdat flags too, which is wrong. But that is separate issue and will be addressed in the next patch. This change will not have any effect on a systems with all workload concentrated in a single cgroup. Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> --- mm/vm

[PATCH v2 3/4] mm/vmscan: Don't change pgdat state on base of a single LRU list state.

reclaim may alter global pgdat flags too, which is wrong. But that is separate issue and will be addressed in the next patch. This change will not have any effect on a systems with all workload concentrated in a single cgroup. Signed-off-by: Andrey Ryabinin --- mm/vmscan.c | 124

[PATCH v2 0/4] vmscan per-cgroup reclaim fixes

good. Yes, these numbers could be obtained from mm_vmscan_lru_isolate tracepoint, but it's easier when it's all in one place. - Compare with nr_writeback,dirty, etc only isolated file pages as it always was. - Minor changelog tweaks. Andrey Ryabinin (4): mm/vmscan: Update stale comments

[PATCH v2 0/4] vmscan per-cgroup reclaim fixes

good. Yes, these numbers could be obtained from mm_vmscan_lru_isolate tracepoint, but it's easier when it's all in one place. - Compare with nr_writeback,dirty, etc only isolated file pages as it always was. - Minor changelog tweaks. Andrey Ryabinin (4): mm/vmscan: Update stale comments

[PATCH v2 2/4] mm/vmscan: remove redundant current_may_throttle() check

Only kswapd can have non-zero nr_immediate, and current_may_throttle() is always true for kswapd (PF_LESS_THROTTLE bit is never set) thus it's enough to check stat.nr_immediate only. Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> Acked-by: Michal Hocko <mho...@suse.com> ---

[PATCH v2 2/4] mm/vmscan: remove redundant current_may_throttle() check

Only kswapd can have non-zero nr_immediate, and current_may_throttle() is always true for kswapd (PF_LESS_THROTTLE bit is never set) thus it's enough to check stat.nr_immediate only. Signed-off-by: Andrey Ryabinin Acked-by: Michal Hocko --- mm/vmscan.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH v2 4/4] mm/vmscan: Don't mess with pgdat->flags in memcg reclaim.

al10m15.054s user0m0.487s sys 1m8.505s According to the tracepoint in wait_iff_congested(), the 'cat' spent 50% of the time sleeping there. With the patch, cat don't waste time anymore: # time cat /dev/sda > /dev/null real5m32.911s user 0m0.411s s

[PATCH v2 4/4] mm/vmscan: Don't mess with pgdat->flags in memcg reclaim.

al10m15.054s user0m0.487s sys 1m8.505s According to the tracepoint in wait_iff_congested(), the 'cat' spent 50% of the time sleeping there. With the patch, cat don't waste time anymore: # time cat /dev/sda > /dev/null real5m32.911s user 0m0.411s s

Re: [PATCH] mm, vmscan, tracing: Use pointer to reclaim_stat struct in trace event

On 03/23/2018 12:10 AM, Andrew Morton wrote: > On Thu, 22 Mar 2018 12:10:03 -0400 Steven Rostedt wrote: > >> >> The trace event trace_mm_vmscan_lru_shrink_inactive() currently has 12 >> parameters! Seven of them are from the reclaim_stat structure. This >> structure is

Re: [PATCH] mm, vmscan, tracing: Use pointer to reclaim_stat struct in trace event

On 03/23/2018 12:10 AM, Andrew Morton wrote: > On Thu, 22 Mar 2018 12:10:03 -0400 Steven Rostedt wrote: > >> >> The trace event trace_mm_vmscan_lru_shrink_inactive() currently has 12 >> parameters! Seven of them are from the reclaim_stat structure. This >> structure is currently local to

Re: [PATCH 6/6] mm/vmscan: Don't mess with pgdat->flags in memcg reclaim.

On 03/21/2018 02:43 PM, Michal Hocko wrote: > On Wed 21-03-18 14:14:35, Andrey Ryabinin wrote: >> >> >> On 03/20/2018 06:29 PM, Michal Hocko wrote: >> >>>> Leave all pgdat->flags manipulations to kswapd. kswapd scans the whole >>>> pgdat, so

Re: [PATCH 6/6] mm/vmscan: Don't mess with pgdat->flags in memcg reclaim.

On 03/21/2018 02:43 PM, Michal Hocko wrote: > On Wed 21-03-18 14:14:35, Andrey Ryabinin wrote: >> >> >> On 03/20/2018 06:29 PM, Michal Hocko wrote: >> >>>> Leave all pgdat->flags manipulations to kswapd. kswapd scans the whole >>>> pgdat, so

Re: [PATCH 5/6] mm/vmscan: Don't change pgdat state on base of a single LRU list state.

On 03/21/2018 02:32 PM, Michal Hocko wrote: > On Wed 21-03-18 13:40:32, Andrey Ryabinin wrote: >> On 03/20/2018 06:25 PM, Michal Hocko wrote: >>> On Thu 15-03-18 19:45:52, Andrey Ryabinin wrote: >>>> We have separate LRU list for each memory cgroup. Memory recl

Re: [PATCH 5/6] mm/vmscan: Don't change pgdat state on base of a single LRU list state.

On 03/21/2018 02:32 PM, Michal Hocko wrote: > On Wed 21-03-18 13:40:32, Andrey Ryabinin wrote: >> On 03/20/2018 06:25 PM, Michal Hocko wrote: >>> On Thu 15-03-18 19:45:52, Andrey Ryabinin wrote: >>>> We have separate LRU list for each memory cgroup. Memory recl

Re: [PATCH 6/6] mm/vmscan: Don't mess with pgdat->flags in memcg reclaim.

the tracepoint in wait_iff_congested(), the 'cat' spent 50% >> of the time sleeping there. >> >> With the patch, cat don't waste time anymore: >> >> # time cat /dev/sda > /dev/null >> real5m32.911s >>

Re: [PATCH 6/6] mm/vmscan: Don't mess with pgdat->flags in memcg reclaim.

the tracepoint in wait_iff_congested(), the 'cat' spent 50% >> of the time sleeping there. >> >> With the patch, cat don't waste time anymore: >> >> # time cat /dev/sda > /dev/null >> real5m32.911s >> user0m0.411s >> sys

Re: [PATCH 5/6] mm/vmscan: Don't change pgdat state on base of a single LRU list state.

On 03/20/2018 06:25 PM, Michal Hocko wrote: > On Thu 15-03-18 19:45:52, Andrey Ryabinin wrote: >> We have separate LRU list for each memory cgroup. Memory reclaim iterates >> over cgroups and calls shrink_inactive_list() every inactive LRU list. >> Based on the

Re: [PATCH 5/6] mm/vmscan: Don't change pgdat state on base of a single LRU list state.

On 03/20/2018 06:25 PM, Michal Hocko wrote: > On Thu 15-03-18 19:45:52, Andrey Ryabinin wrote: >> We have separate LRU list for each memory cgroup. Memory reclaim iterates >> over cgroups and calls shrink_inactive_list() every inactive LRU list. >> Based on the

Re: 答复: 答复: [PATCH] mm/memcontrol.c: speed up to force empty a memory cgroup

On 03/21/2018 01:15 AM, David Rientjes wrote: > On Wed, 21 Mar 2018, Andrey Ryabinin wrote: > >>>>> It would probably be best to limit the >>>>> nr_pages to the amount that needs to be reclaimed, though, rather than >>>>> over reclaiming. &

Re: 答复: 答复: [PATCH] mm/memcontrol.c: speed up to force empty a memory cgroup

On 03/21/2018 01:15 AM, David Rientjes wrote: > On Wed, 21 Mar 2018, Andrey Ryabinin wrote: > >>>>> It would probably be best to limit the >>>>> nr_pages to the amount that needs to be reclaimed, though, rather than >>>>> over reclaiming. &

Re: 答复: 答复: [PATCH] mm/memcontrol.c: speed up to force empty a memory cgroup

On 03/20/2018 11:29 PM, David Rientjes wrote: > On Tue, 20 Mar 2018, Michal Hocko wrote: > >> Although SWAP_CLUSTER_MAX is used at the lower level, but the call >> stack of try_to_free_mem_cgroup_pages is too long, increase the >> nr_to_reclaim can reduce times of calling >>

Re: 答复: 答复: [PATCH] mm/memcontrol.c: speed up to force empty a memory cgroup

On 03/20/2018 11:29 PM, David Rientjes wrote: > On Tue, 20 Mar 2018, Michal Hocko wrote: > >> Although SWAP_CLUSTER_MAX is used at the lower level, but the call >> stack of try_to_free_mem_cgroup_pages is too long, increase the >> nr_to_reclaim can reduce times of calling >>

Re: [PATCH v5 2/2] Remove false-positive VLAs when using max()

On 03/16/2018 07:25 AM, Kees Cook wrote: > As part of removing VLAs from the kernel[1], we want to build with -Wvla, > but it is overly pessimistic and only accepts constant expressions for > stack array sizes, instead of also constant values. The max() macro > triggers the warning, so this

Re: [PATCH v5 2/2] Remove false-positive VLAs when using max()

On 03/16/2018 07:25 AM, Kees Cook wrote: > As part of removing VLAs from the kernel[1], we want to build with -Wvla, > but it is overly pessimistic and only accepts constant expressions for > stack array sizes, instead of also constant values. The max() macro > triggers the warning, so this

[PATCH 2/6] mm/vmscan: Update stale comments

Update some comments that become stale since transiton from per-zone to per-node reclaim. Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> --- mm/vmscan.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index 4390a8

[PATCH 2/6] mm/vmscan: Update stale comments

Update some comments that become stale since transiton from per-zone to per-node reclaim. Signed-off-by: Andrey Ryabinin --- mm/vmscan.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index 4390a8d5be41..6d74b12099bd 100644 --- a/mm

[PATCH 1/6] mm/vmscan: Wake up flushers for legacy cgroups too

(dd) total-vm:8484kB, anon-rss:1052kB, file-rss:1720kB, shmem-rss:0kB oom_reaper: reaped process 3876 (dd), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB Wake up flushers in legacy cgroup reclaim too. Fixes: bbef938429f5 ("mm: vmscan: remove old flusher wakeup from direct reclaim path&q

[PATCH 1/6] mm/vmscan: Wake up flushers for legacy cgroups too

(dd) total-vm:8484kB, anon-rss:1052kB, file-rss:1720kB, shmem-rss:0kB oom_reaper: reaped process 3876 (dd), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB Wake up flushers in legacy cgroup reclaim too. Fixes: bbef938429f5 ("mm: vmscan: remove old flusher wakeup from direct reclaim path&q

[PATCH 4/6] mm/vmscan: remove redundant current_may_throttle() check

Only kswapd can have non-zero nr_immediate, and current_may_throttle() is always true for kswapd (PF_LESS_THROTTLE bit is never set) thus it's enough to check stat.nr_immediate only. Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> --- mm/vmscan.c | 2 +- 1 file changed, 1 ins

[PATCH 4/6] mm/vmscan: remove redundant current_may_throttle() check

Only kswapd can have non-zero nr_immediate, and current_may_throttle() is always true for kswapd (PF_LESS_THROTTLE bit is never set) thus it's enough to check stat.nr_immediate only. Signed-off-by: Andrey Ryabinin --- mm/vmscan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 5/6] mm/vmscan: Don't change pgdat state on base of a single LRU list state.

-by: Andrey Ryabinin <aryabi...@virtuozzo.com> --- mm/vmscan.c | 131 +--- 1 file changed, 73 insertions(+), 58 deletions(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index a8f6e4882e00..522b480caeb2 100644 --- a/mm/vmscan.c +++ b/mm/vm

[PATCH 5/6] mm/vmscan: Don't change pgdat state on base of a single LRU list state.

-by: Andrey Ryabinin --- mm/vmscan.c | 131 +--- 1 file changed, 73 insertions(+), 58 deletions(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index a8f6e4882e00..522b480caeb2 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -61,6 +61,15 @@ #define

[PATCH 3/6] mm/vmscan: replace mm_vmscan_lru_shrink_inactive with shrink_page_list tracepoint

-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> --- include/trace/events/vmscan.h | 36 +++- mm/vmscan.c | 18 +- 2 files changed, 20 insertions(+), 34 deletions(-) diff --git a/include/trace/events/vmscan.h b/include/trace/

[PATCH 3/6] mm/vmscan: replace mm_vmscan_lru_shrink_inactive with shrink_page_list tracepoint

-off-by: Andrey Ryabinin --- include/trace/events/vmscan.h | 36 +++- mm/vmscan.c | 18 +- 2 files changed, 20 insertions(+), 34 deletions(-) diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h index

[PATCH 6/6] mm/vmscan: Don't mess with pgdat->flags in memcg reclaim.

. With the patch, cat don't waste time anymore: # time cat /dev/sda > /dev/null real5m32.911s user0m0.411s sys 0m56.664s Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> --- include/linux/backing-dev.h | 2 +- include/linux/memcontrol.h | 2 ++ mm/backi

[PATCH 6/6] mm/vmscan: Don't mess with pgdat->flags in memcg reclaim.

. With the patch, cat don't waste time anymore: # time cat /dev/sda > /dev/null real5m32.911s user0m0.411s sys 0m56.664s Signed-off-by: Andrey Ryabinin --- include/linux/backing-dev.h | 2 +- include/linux/memcontrol.h | 2 ++ mm/backing-dev.c| 19 ++

Re: [PATCH] kasan, slub: fix handling of kasan_slab_free hook

On 03/06/2018 08:42 PM, Andrey Konovalov wrote: >>> - if (s->flags & SLAB_KASAN && !(s->flags & SLAB_TYPESAFE_BY_RCU)) >>> - return; >>> - do_slab_free(s, page, head, tail, cnt, addr); >>> + slab_free_freelist_hook(s, , ); >>> + if (head != NULL) >> >> That's an

Re: [PATCH] kasan, slub: fix handling of kasan_slab_free hook

On 03/06/2018 08:42 PM, Andrey Konovalov wrote: >>> - if (s->flags & SLAB_KASAN && !(s->flags & SLAB_TYPESAFE_BY_RCU)) >>> - return; >>> - do_slab_free(s, page, head, tail, cnt, addr); >>> + slab_free_freelist_hook(s, , ); >>> + if (head != NULL) >> >> That's an

Re: [PATCH v2] kasan, slub: fix handling of kasan_slab_free hook

s, whose >reuse must be delayed. > > Signed-off-by: Andrey Konovalov <andreyk...@google.com> > --- Acked-by: Andrey Ryabinin <aryabi...@virtuozzo.com>

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