Re: [PATCH v1 00/11] mm/kasan: support per-page shadow memory to reduce memory consumption

On 05/29/2017 06:29 PM, Dmitry Vyukov wrote: > Joonsoo, > > I guess mine (and Andrey's) main concern is the amount of additional > complexity (I am still struggling to understand how it all works) and > more arch-dependent code in exchange for moderate memory win. > > Joonsoo, Andrey, > > I

Re: KASAN vs. boot-time switching between 4- and 5-level paging

On 05/29/2017 02:45 PM, Andrey Ryabinin wrote: >>>>> Looks like KASAN will be a problem for boot-time paging mode switching. >>>>> It wants to know CONFIG_KASAN_SHADOW_OFFSET at compile-time to pass to >>>>> gcc -fasan-shadow-offset=. But this value

Re: KASAN vs. boot-time switching between 4- and 5-level paging

On 05/29/2017 02:45 PM, Andrey Ryabinin wrote: >>>>> Looks like KASAN will be a problem for boot-time paging mode switching. >>>>> It wants to know CONFIG_KASAN_SHADOW_OFFSET at compile-time to pass to >>>>> gcc -fasan-shadow-offset=. But this value

Re: KASAN vs. boot-time switching between 4- and 5-level paging

On 05/29/2017 02:19 PM, Dmitry Vyukov wrote: > On Mon, May 29, 2017 at 1:18 PM, Andrey Ryabinin > <aryabi...@virtuozzo.com> wrote: >> >> >> On 05/29/2017 01:02 PM, Dmitry Vyukov wrote: >>> On Sat, May 27, 2017 at 12:10 AM, Kirill A. Shutemov >>> &

Re: KASAN vs. boot-time switching between 4- and 5-level paging

On 05/29/2017 02:19 PM, Dmitry Vyukov wrote: > On Mon, May 29, 2017 at 1:18 PM, Andrey Ryabinin > wrote: >> >> >> On 05/29/2017 01:02 PM, Dmitry Vyukov wrote: >>> On Sat, May 27, 2017 at 12:10 AM, Kirill A. Shutemov >>> wrote: >>>> On Thu

Re: KASAN vs. boot-time switching between 4- and 5-level paging

On 05/29/2017 01:02 PM, Dmitry Vyukov wrote: > On Sat, May 27, 2017 at 12:10 AM, Kirill A. Shutemov > wrote: >> On Thu, May 25, 2017 at 11:33:33PM +0300, Kirill A. Shutemov wrote: >>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig >>> index 0bf81e837cbf..c795207d8a3c

Re: KASAN vs. boot-time switching between 4- and 5-level paging

On 05/29/2017 01:02 PM, Dmitry Vyukov wrote: > On Sat, May 27, 2017 at 12:10 AM, Kirill A. Shutemov > wrote: >> On Thu, May 25, 2017 at 11:33:33PM +0300, Kirill A. Shutemov wrote: >>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig >>> index 0bf81e837cbf..c795207d8a3c 100644 >>> ---

Re: [PATCH v1 00/11] mm/kasan: support per-page shadow memory to reduce memory consumption

On 05/19/2017 04:53 AM, Joonsoo Kim wrote: > On Wed, May 17, 2017 at 03:17:13PM +0300, Andrey Ryabinin wrote: >> On 05/16/2017 04:16 AM, js1...@gmail.com wrote: >>> From: Joonsoo Kim <iamjoonsoo@lge.com> >>> >>> Hello, all. >>> >>&

Re: [PATCH v1 00/11] mm/kasan: support per-page shadow memory to reduce memory consumption

On 05/19/2017 04:53 AM, Joonsoo Kim wrote: > On Wed, May 17, 2017 at 03:17:13PM +0300, Andrey Ryabinin wrote: >> On 05/16/2017 04:16 AM, js1...@gmail.com wrote: >>> From: Joonsoo Kim >>> >>> Hello, all. >>> >>> This is an attempt to recude

Re: [PATCH v1 00/11] mm/kasan: support per-page shadow memory to reduce memory consumption

On 05/16/2017 04:16 AM, js1...@gmail.com wrote: > From: Joonsoo Kim > > Hello, all. > > This is an attempt to recude memory consumption of KASAN. Please see > following description to get the more information. > > 1. What is per-page shadow memory > > This patch

Re: [PATCH v1 00/11] mm/kasan: support per-page shadow memory to reduce memory consumption

On 05/16/2017 04:16 AM, js1...@gmail.com wrote: > From: Joonsoo Kim > > Hello, all. > > This is an attempt to recude memory consumption of KASAN. Please see > following description to get the more information. > > 1. What is per-page shadow memory > > This patch introduces infrastructure to

Re: [PATCH] mm/kasan: use kasan_zero_pud for p4d table

joonsoo@lge.com> Acked-by: Andrey Ryabinin <aryabi...@virtuozzo.com> > --- > mm/kasan/kasan_init.c | 12 > 1 file changed, 12 insertions(+) > > diff --git a/mm/kasan/kasan_init.c b/mm/kasan/kasan_init.c > index b96a5f7..554e4c0 100644 > --- a/mm/kas

Re: [PATCH] mm/kasan: use kasan_zero_pud for p4d table

On 05/15/2017 09:20 AM, js1...@gmail.com wrote: > From: Joonsoo Kim > > There is missing optimization in zero_p4d_populate() that can save > some memory when mapping zero shadow. Implement it like as others. > > Signed-off-by: Joonsoo Kim Acked-by: Andrey Ryabinin

[PATCH v2 4/4] mm/truncate: avoid pointless cleancache_invalidate_inode() calls.

cleancache_invalidate_inode() called truncate_inode_pages_range() and invalidate_inode_pages2_range() twice - on entry and on exit. It's stupid and waste of time. It's enough to call it once at exit. Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> Acked-by: Konrad Rzeszute

[PATCH v2 4/4] mm/truncate: avoid pointless cleancache_invalidate_inode() calls.

cleancache_invalidate_inode() called truncate_inode_pages_range() and invalidate_inode_pages2_range() twice - on entry and on exit. It's stupid and waste of time. It's enough to call it once at exit. Signed-off-by: Andrey Ryabinin Acked-by: Konrad Rzeszutek Wilk --- mm/truncate.c | 12

[PATCH v2 3/4] mm/truncate: bail out early from invalidate_inode_pages2_range() if mapping is empty

If mapping is empty (both ->nrpages and ->nrexceptional is zero) we can avoid pointless lookups in empty radix tree and bail out immediately after cleancache invalidation. Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> Acked-by: Konrad Rzeszutek Wilk <konrad.w...@orac

[PATCH v2 3/4] mm/truncate: bail out early from invalidate_inode_pages2_range() if mapping is empty

If mapping is empty (both ->nrpages and ->nrexceptional is zero) we can avoid pointless lookups in empty radix tree and bail out immediately after cleancache invalidation. Signed-off-by: Andrey Ryabinin Acked-by: Konrad Rzeszutek Wilk --- mm/truncate.c | 3 +++ 1 file changed, 3 inse

[PATCH v2 2/4] fs/block_dev: always invalidate cleancache in invalidate_bdev()

uot;) Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> Acked-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com> Cc: <sta...@vger.kernel.org> --- fs/block_dev.c | 11 +-- 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/fs/block_dev.c b/fs/block_dev.c inde

[PATCH v2 2/4] fs/block_dev: always invalidate cleancache in invalidate_bdev()

uot;) Signed-off-by: Andrey Ryabinin Acked-by: Konrad Rzeszutek Wilk Cc: --- fs/block_dev.c | 11 +-- 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/fs/block_dev.c b/fs/block_dev.c index 065d7c5..f625dce 100644 --- a/fs/block_dev.c +++ b/fs/block_dev.c @@ -104,12 +104,11 @@ void

[PATCH v2 1/4] fs: fix data invalidation in the cleancache during direct IO

_range]() regardless of nrpages state. Note: nfs,cifs,9p doesn't need similar fix because the never call cleancache_get_page() (nor directly, nor via mpage_readpage[s]()), so they are not affected by this bug. Fixes: c515e1fd361c ("mm/fs: add hooks to support cleancache") Signed-off-by:

[PATCH v2 1/4] fs: fix data invalidation in the cleancache during direct IO

_range]() regardless of nrpages state. Note: nfs,cifs,9p doesn't need similar fix because the never call cleancache_get_page() (nor directly, nor via mpage_readpage[s]()), so they are not affected by this bug. Fixes: c515e1fd361c ("mm/fs: add hooks to support cleancache") Signed-off-by:

[PATCH v2 0/4] Properly invalidate data in the cleancache.

eck. - Patch 2 fixes similar case in invalidate_bdev(). Note: I only fixed conditional cleancache_invalidate_inode() here. Do we also need to add ->nrexceptional check in into invalidate_bdev()? - Patches 3-4: some optimizations. Andrey Ryabinin (4): fs: fix

[PATCH v2 0/4] Properly invalidate data in the cleancache.

eck. - Patch 2 fixes similar case in invalidate_bdev(). Note: I only fixed conditional cleancache_invalidate_inode() here. Do we also need to add ->nrexceptional check in into invalidate_bdev()? - Patches 3-4: some optimizations. Andrey Ryabinin (4): fs: fix

Re: [PATCH 1/4] fs: fix data invalidation in the cleancache during direct IO

On 04/19/2017 01:46 AM, Andrew Morton wrote: > On Fri, 14 Apr 2017 17:07:50 +0300 Andrey Ryabinin <aryabi...@virtuozzo.com> > wrote: > >> Some direct write fs hooks call invalidate_inode_pages2[_range]() >> conditionally iff mapping->nrpages is not zero. If pa

Re: [PATCH 1/4] fs: fix data invalidation in the cleancache during direct IO

On 04/19/2017 01:46 AM, Andrew Morton wrote: > On Fri, 14 Apr 2017 17:07:50 +0300 Andrey Ryabinin > wrote: > >> Some direct write fs hooks call invalidate_inode_pages2[_range]() >> conditionally iff mapping->nrpages is not zero. If page cache is empty, >> buffer

Re: [PATCH 1/4] fs: fix data invalidation in the cleancache during direct IO

On 04/18/2017 10:38 PM, Ross Zwisler wrote: > On Fri, Apr 14, 2017 at 05:07:50PM +0300, Andrey Ryabinin wrote: >> Some direct write fs hooks call invalidate_inode_pages2[_range]() >> conditionally iff mapping->nrpages is not zero. If page cache is empty, >> buffered read f

Re: [PATCH 1/4] fs: fix data invalidation in the cleancache during direct IO

On 04/18/2017 10:38 PM, Ross Zwisler wrote: > On Fri, Apr 14, 2017 at 05:07:50PM +0300, Andrey Ryabinin wrote: >> Some direct write fs hooks call invalidate_inode_pages2[_range]() >> conditionally iff mapping->nrpages is not zero. If page cache is empty, >> buffered read f

Re: [PATCH 2/4] fs/block_dev: always invalidate cleancache in invalidate_bdev()

On 04/18/2017 09:51 PM, Nikolay Borisov wrote: > > > On 14.04.2017 17:07, Andrey Ryabinin wrote: >> invalidate_bdev() calls cleancache_invalidate_inode() iff ->nrpages != 0 >> which doen't make any sense. >> Make invalidate_bdev() always invalidate cleancache data.

Re: [PATCH 2/4] fs/block_dev: always invalidate cleancache in invalidate_bdev()

On 04/18/2017 09:51 PM, Nikolay Borisov wrote: > > > On 14.04.2017 17:07, Andrey Ryabinin wrote: >> invalidate_bdev() calls cleancache_invalidate_inode() iff ->nrpages != 0 >> which doen't make any sense. >> Make invalidate_bdev() always invalidate cleancache data.

[PATCH 1/4] fs: fix data invalidation in the cleancache during direct IO

ecause invalidate_inode_pages2[_range] invalidates exceptional entries as well. Fix this by calling invalidate_inode_pages2[_range]() regardless of nrpages state. Fixes: c515e1fd361c ("mm/fs: add hooks to support cleancache") Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> ---

[PATCH 1/4] fs: fix data invalidation in the cleancache during direct IO

ecause invalidate_inode_pages2[_range] invalidates exceptional entries as well. Fix this by calling invalidate_inode_pages2[_range]() regardless of nrpages state. Fixes: c515e1fd361c ("mm/fs: add hooks to support cleancache") Signed-off-by: Andrey Ryabinin --- fs/9p/vfs_file.c | 2 +- fs/ci

[PATCH 2/4] fs/block_dev: always invalidate cleancache in invalidate_bdev()

invalidate_bdev() calls cleancache_invalidate_inode() iff ->nrpages != 0 which doen't make any sense. Make invalidate_bdev() always invalidate cleancache data. Fixes: c515e1fd361c ("mm/fs: add hooks to support cleancache") Signed-off-by: Andrey Ryabinin <aryabi...@virtuo

[PATCH 4/4] mm/truncate: avoid pointless cleancache_invalidate_inode() calls.

cleancache_invalidate_inode() called truncate_inode_pages_range() and invalidate_inode_pages2_range() twice - on entry and on exit. It's stupid and waste of time. It's enough to call it once at exit. Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> --- mm/truncate.c | 12 +++--

[PATCH 2/4] fs/block_dev: always invalidate cleancache in invalidate_bdev()

invalidate_bdev() calls cleancache_invalidate_inode() iff ->nrpages != 0 which doen't make any sense. Make invalidate_bdev() always invalidate cleancache data. Fixes: c515e1fd361c ("mm/fs: add hooks to support cleancache") Signed-off-by: Andrey Ryabinin --- fs/block_dev.c | 11 +

[PATCH 4/4] mm/truncate: avoid pointless cleancache_invalidate_inode() calls.

cleancache_invalidate_inode() called truncate_inode_pages_range() and invalidate_inode_pages2_range() twice - on entry and on exit. It's stupid and waste of time. It's enough to call it once at exit. Signed-off-by: Andrey Ryabinin --- mm/truncate.c | 12 +++- 1 file changed, 7

[PATCH 0/4] Properly invalidate data in the cleancache.

atch 1 fixes direct IO writes by removing ->nrpages check. - Patch 2 fixes similar case in invalidate_bdev(). Note: I only fixed conditional cleancache_invalidate_inode() here. Do we also need to add ->nrexceptional check in into invalidate_bdev()? - Patches 3-4: some opti

[PATCH 3/4] mm/truncate: bail out early from invalidate_inode_pages2_range() if mapping is empty

If mapping is empty (both ->nrpages and ->nrexceptional is zero) we can avoid pointless lookups in empty radix tree and bail out immediately after cleancache invalidation. Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> --- mm/truncate.c | 3 +++ 1 file changed, 3 inserti

[PATCH 0/4] Properly invalidate data in the cleancache.

atch 1 fixes direct IO writes by removing ->nrpages check. - Patch 2 fixes similar case in invalidate_bdev(). Note: I only fixed conditional cleancache_invalidate_inode() here. Do we also need to add ->nrexceptional check in into invalidate_bdev()? - Patches 3-4: some opti

[PATCH 3/4] mm/truncate: bail out early from invalidate_inode_pages2_range() if mapping is empty

If mapping is empty (both ->nrpages and ->nrexceptional is zero) we can avoid pointless lookups in empty radix tree and bail out immediately after cleancache invalidation. Signed-off-by: Andrey Ryabinin --- mm/truncate.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/mm/truncate.

[PATCH v2 2/5] x86/ldt: use vfree() instead of vfree_atomic()

vfree() can be used in any atomic context now, thus there is no point in vfree_atomic(). This reverts commit 8d5341a6260a ("x86/ldt: use vfree_atomic() to free ldt entries") Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> Reviewed-by: Thomas Gleixner <t...@linutroni

[PATCH v2 2/5] x86/ldt: use vfree() instead of vfree_atomic()

vfree() can be used in any atomic context now, thus there is no point in vfree_atomic(). This reverts commit 8d5341a6260a ("x86/ldt: use vfree_atomic() to free ldt entries") Signed-off-by: Andrey Ryabinin Reviewed-by: Thomas Gleixner --- arch/x86/kernel/ldt.c | 2 +- 1 file

[PATCH v2 4/5] mm/vmalloc: remove vfree_atomic()

vfree() can be used in any atomic context and there is no vfree_atomic() callers left, so let's remove it. This reverts commit bf22e37a6413 ("mm: add vfree_atomic()") Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> Acked-by: Michal Hocko <mho...@suse.com> --- i

[PATCH v2 4/5] mm/vmalloc: remove vfree_atomic()

vfree() can be used in any atomic context and there is no vfree_atomic() callers left, so let's remove it. This reverts commit bf22e37a6413 ("mm: add vfree_atomic()") Signed-off-by: Andrey Ryabinin Acked-by: Michal Hocko --- include/linux/vmalloc.h | 1 - mm/vmalloc.c

[PATCH v2 5/5] mm/vmalloc: Don't spawn workers if somebody already purging

. This should save kworkers from doing some useless job. Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> Suggested-by: Thomas Hellstrom <thellst...@vmware.com> Reviewed-by: Thomas Hellstrom <thellst...@vmware.com> --- mm/vmalloc.c | 3 ++- 1 file changed, 2 insertions(+), 1 delet

[PATCH v2 5/5] mm/vmalloc: Don't spawn workers if somebody already purging

. This should save kworkers from doing some useless job. Signed-off-by: Andrey Ryabinin Suggested-by: Thomas Hellstrom Reviewed-by: Thomas Hellstrom --- mm/vmalloc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index ee62c0a..1079555 100644 --- a/mm

[PATCH v2 0/5] allow to call vfree() in atomic context

Changes since v1: - Added small optmization as a separate patch 5/5 - Collected Acks/Review tags. Andrey Ryabinin (5): mm/vmalloc: allow to call vfree() in atomic context x86/ldt: use vfree() instead of vfree_atomic() kernel/fork: use vfree() instead of vfree_atomic() to free thread

[PATCH v2 0/5] allow to call vfree() in atomic context

Changes since v1: - Added small optmization as a separate patch 5/5 - Collected Acks/Review tags. Andrey Ryabinin (5): mm/vmalloc: allow to call vfree() in atomic context x86/ldt: use vfree() instead of vfree_atomic() kernel/fork: use vfree() instead of vfree_atomic() to free thread

[PATCH v2 1/5] mm/vmalloc: allow to call vfree() in atomic context

potentially sleeping") Reported-by: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> Reviewed-by: Thomas Hellstrom <thellst...@vmware.com> Acked-by: Michal Hocko <mho...@suse.com> Cc: <sta...@vger.kernel.org&g

[PATCH v2 3/5] kernel/fork: use vfree() instead of vfree_atomic() to free thread stack

vfree() can be used in any atomic context now, thus there is no point in using vfree_atomic(). This reverts commit 0f110a9b956c ("kernel/fork: use vfree_atomic() to free thread stack") Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> --- kernel/fork.c | 2 +- 1 file chan

[PATCH v2 1/5] mm/vmalloc: allow to call vfree() in atomic context

potentially sleeping") Reported-by: Tetsuo Handa Signed-off-by: Andrey Ryabinin Reviewed-by: Thomas Hellstrom Acked-by: Michal Hocko Cc: --- mm/vmalloc.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 8ef8ea1..1c74b26 1006

[PATCH v2 3/5] kernel/fork: use vfree() instead of vfree_atomic() to free thread stack

vfree() can be used in any atomic context now, thus there is no point in using vfree_atomic(). This reverts commit 0f110a9b956c ("kernel/fork: use vfree_atomic() to free thread stack") Signed-off-by: Andrey Ryabinin --- kernel/fork.c | 2 +- 1 file changed, 1 insertion(+), 1 deletio

Re: [PATCH 1/4] mm: prevent potential recursive reclaim due to clearing PF_MEMALLOC

> gfp_flags or in_interrupt() is true. There is no such known context, but let's > play it safe and make __alloc_pages_direct_compact() robust for cases where > PF_MEMALLOC is already set. > > Fixes: a8161d1ed609 ("mm, page_alloc: restructure direct compactio

Re: [PATCH 1/4] mm: prevent potential recursive reclaim due to clearing PF_MEMALLOC

> gfp_flags or in_interrupt() is true. There is no such known context, but let's > play it safe and make __alloc_pages_direct_compact() robust for cases where > PF_MEMALLOC is already set. > > Fixes: a8161d1ed609 ("mm, page_alloc: restructure direct compaction hand

Re: [PATCH 1/4] mm/vmalloc: allow to call vfree() in atomic context

On 04/04/2017 12:41 PM, Michal Hocko wrote: > On Thu 30-03-17 17:48:39, Andrey Ryabinin wrote: >> From: Andrey Ryabinin <aryabi...@virtuozzo.com> >> Subject: mm/vmalloc: allow to call vfree() in atomic context fix >> >> Don't spawn worker if we already purging. >

Re: [PATCH 1/4] mm/vmalloc: allow to call vfree() in atomic context

On 04/04/2017 12:41 PM, Michal Hocko wrote: > On Thu 30-03-17 17:48:39, Andrey Ryabinin wrote: >> From: Andrey Ryabinin >> Subject: mm/vmalloc: allow to call vfree() in atomic context fix >> >> Don't spawn worker if we already purging. >> >> Signed-off-by: A

Re: [PATCH] mm/zswap: fix potential deadlock in zswap_frontswap_store()

On 04/03/2017 04:28 PM, Vlastimil Babka wrote: >> >> >> Seems it was broken by >> >> a8161d1ed6098506303c65b3701dedba876df42a >> Author: Vlastimil Babka >> Date: Thu Jul 28 15:49:19 2016 -0700 >> >> mm, page_alloc: restructure direct compaction handling in slowpath > >

Re: [PATCH] mm/zswap: fix potential deadlock in zswap_frontswap_store()

On 04/03/2017 04:28 PM, Vlastimil Babka wrote: >> >> >> Seems it was broken by >> >> a8161d1ed6098506303c65b3701dedba876df42a >> Author: Vlastimil Babka >> Date: Thu Jul 28 15:49:19 2016 -0700 >> >> mm, page_alloc: restructure direct compaction handling in slowpath > > Yeah, looks like

Re: [PATCH] mm/zswap: fix potential deadlock in zswap_frontswap_store()

On 04/03/2017 03:45 PM, Michal Hocko wrote: > On Mon 03-04-17 15:37:07, Andrey Ryabinin wrote: >> >> >> On 04/03/2017 11:47 AM, Michal Hocko wrote: >>> On Fri 31-03-17 10:00:30, Shakeel Butt wrote: >>>> On Fri, Mar 31, 2017 at 8:30 AM, Andrey Rya

Re: [PATCH] mm/zswap: fix potential deadlock in zswap_frontswap_store()

On 04/03/2017 03:45 PM, Michal Hocko wrote: > On Mon 03-04-17 15:37:07, Andrey Ryabinin wrote: >> >> >> On 04/03/2017 11:47 AM, Michal Hocko wrote: >>> On Fri 31-03-17 10:00:30, Shakeel Butt wrote: >>>> On Fri, Mar 31, 2017 at 8:30 AM, Andrey Ryabini

Re: [PATCH] mm/zswap: fix potential deadlock in zswap_frontswap_store()

On 04/03/2017 03:37 PM, Andrey Ryabinin wrote: > > > On 04/03/2017 11:47 AM, Michal Hocko wrote: >> On Fri 31-03-17 10:00:30, Shakeel Butt wrote: >>> On Fri, Mar 31, 2017 at 8:30 AM, Andrey Ryabinin >>> <aryabi...@virtuozzo.com> wrote: >>>&

Re: [PATCH] mm/zswap: fix potential deadlock in zswap_frontswap_store()

On 04/03/2017 03:37 PM, Andrey Ryabinin wrote: > > > On 04/03/2017 11:47 AM, Michal Hocko wrote: >> On Fri 31-03-17 10:00:30, Shakeel Butt wrote: >>> On Fri, Mar 31, 2017 at 8:30 AM, Andrey Ryabinin >>> wrote: >>>> zswap_frontswap

Re: [PATCH] mm/zswap: fix potential deadlock in zswap_frontswap_store()

On 04/03/2017 11:47 AM, Michal Hocko wrote: > On Fri 31-03-17 10:00:30, Shakeel Butt wrote: >> On Fri, Mar 31, 2017 at 8:30 AM, Andrey Ryabinin >> <aryabi...@virtuozzo.com> wrote: >>> zswap_frontswap_store() is called during memory reclaim from >>> __front

Re: [PATCH] mm/zswap: fix potential deadlock in zswap_frontswap_store()

On 04/03/2017 11:47 AM, Michal Hocko wrote: > On Fri 31-03-17 10:00:30, Shakeel Butt wrote: >> On Fri, Mar 31, 2017 at 8:30 AM, Andrey Ryabinin >> wrote: >>> zswap_frontswap_store() is called during memory reclaim from >>> __frontswap_store() from swap_

Re: [PATCH] mm/zswap: fix potential deadlock in zswap_frontswap_store()

On 04/03/2017 11:47 AM, Michal Hocko wrote: > On Fri 31-03-17 10:00:30, Shakeel Butt wrote: >> On Fri, Mar 31, 2017 at 8:30 AM, Andrey Ryabinin >> <aryabi...@virtuozzo.com> wrote: >>> zswap_frontswap_store() is called during memory reclaim from >>> __front

Re: [PATCH] mm/zswap: fix potential deadlock in zswap_frontswap_store()

On 04/03/2017 11:47 AM, Michal Hocko wrote: > On Fri 31-03-17 10:00:30, Shakeel Butt wrote: >> On Fri, Mar 31, 2017 at 8:30 AM, Andrey Ryabinin >> wrote: >>> zswap_frontswap_store() is called during memory reclaim from >>> __frontswap_store() from swap_

[PATCH] mm/zswap: fix potential deadlock in zswap_frontswap_store()

to avoid recursion into itself. zswap_frontswap_store() call zpool_malloc() with __GFP_NORETRY | __GFP_NOWARN | __GFP_KSWAPD_RECLAIM, so let's use the same flags for zswap_entry_cache_alloc() as well, instead of GFP_KERNEL. Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> --- mm/z

[PATCH] mm/zswap: fix potential deadlock in zswap_frontswap_store()

to avoid recursion into itself. zswap_frontswap_store() call zpool_malloc() with __GFP_NORETRY | __GFP_NOWARN | __GFP_KSWAPD_RECLAIM, so let's use the same flags for zswap_entry_cache_alloc() as well, instead of GFP_KERNEL. Signed-off-by: Andrey Ryabinin --- mm/zswap.c | 7 +++ 1 file

Re: [PATCH 1/4] mm/vmalloc: allow to call vfree() in atomic context

On 03/31/2017 01:22 AM, Andrew Morton wrote: > On Thu, 30 Mar 2017 13:27:16 +0300 Andrey Ryabinin <aryabi...@virtuozzo.com> > wrote: > >> Commit 5803ed292e63 ("mm: mark all calls into the vmalloc subsystem >> as potentially sleeping") added might_slee

Re: [PATCH 1/4] mm/vmalloc: allow to call vfree() in atomic context

On 03/31/2017 01:22 AM, Andrew Morton wrote: > On Thu, 30 Mar 2017 13:27:16 +0300 Andrey Ryabinin > wrote: > >> Commit 5803ed292e63 ("mm: mark all calls into the vmalloc subsystem >> as potentially sleeping") added might_sleep() to remove_vm_area() from >

Re: [PATCH 4/4] mm/vmalloc: remove vfree_atomic()

On 03/30/2017 08:18 PM, Matthew Wilcox wrote: > On Thu, Mar 30, 2017 at 01:27:19PM +0300, Andrey Ryabinin wrote: >> vfree() can be used in any atomic context and there is no >> vfree_atomic() callers left, so let's remove it. > > We might still get warnings though. >

Re: [PATCH 4/4] mm/vmalloc: remove vfree_atomic()

On 03/30/2017 08:18 PM, Matthew Wilcox wrote: > On Thu, Mar 30, 2017 at 01:27:19PM +0300, Andrey Ryabinin wrote: >> vfree() can be used in any atomic context and there is no >> vfree_atomic() callers left, so let's remove it. > > We might still get warnings though. >

Re: [PATCH 1/4] mm/vmalloc: allow to call vfree() in atomic context

e, we don't need to spawn workers if we already purging. From: Andrey Ryabinin <aryabi...@virtuozzo.com> Subject: mm/vmalloc: allow to call vfree() in atomic context fix Don't spawn worker if we already purging. Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> --- mm/vmalloc.

Re: [PATCH 1/4] mm/vmalloc: allow to call vfree() in atomic context

e, we don't need to spawn workers if we already purging. From: Andrey Ryabinin Subject: mm/vmalloc: allow to call vfree() in atomic context fix Don't spawn worker if we already purging. Signed-off-by: Andrey Ryabinin --- mm/vmalloc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-

Re: [PATCH v2] module: check if memory leak by module.

On 03/30/2017 04:37 PM, Pavel Machek wrote: > >> 3) This might produce false positives. E.g. module may defer vfree() in >> workqueue, so the >> actual vfree() call happens after module unloaded. > > Umm. Really? > I should have been more specific. I meant vfree() called by module

Re: [PATCH v2] module: check if memory leak by module.

On 03/30/2017 04:37 PM, Pavel Machek wrote: > >> 3) This might produce false positives. E.g. module may defer vfree() in >> workqueue, so the >> actual vfree() call happens after module unloaded. > > Umm. Really? > I should have been more specific. I meant vfree() called by module

[PATCH 4/4] mm/vmalloc: remove vfree_atomic()

vfree() can be used in any atomic context and there is no vfree_atomic() callers left, so let's remove it. This reverts commit bf22e37a6413 ("mm: add vfree_atomic()") Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> --- include/linux/vmalloc.h | 1 - mm/vmalloc.c

[PATCH 1/4] mm/vmalloc: allow to call vfree() in atomic context

potentially sleeping") Reported-by: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> Cc: <sta...@vger.kernel.org> Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> --- mm/vmalloc.c | 9 -

[PATCH 4/4] mm/vmalloc: remove vfree_atomic()

vfree() can be used in any atomic context and there is no vfree_atomic() callers left, so let's remove it. This reverts commit bf22e37a6413 ("mm: add vfree_atomic()") Signed-off-by: Andrey Ryabinin --- include/linux/vmalloc.h | 1 - mm/vmalloc.c

[PATCH 1/4] mm/vmalloc: allow to call vfree() in atomic context

potentially sleeping") Reported-by: Tetsuo Handa Signed-off-by: Andrey Ryabinin Cc: Signed-off-by: Andrey Ryabinin --- mm/vmalloc.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 68eb002..ea1b4ab 100644 --- a/mm/vmall

[PATCH 2/4] x86/ldt: use vfree() instead of vfree_atomic()

vfree() can be used in any atomic context now, thus there is no point in vfree_atomic(). This reverts commit 8d5341a6260a ("x86/ldt: use vfree_atomic() to free ldt entries") Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> --- arch/x86/kernel/ldt.c | 2 +- 1 file chan

[PATCH 3/4] kernel/fork: use vfree() instead of vfree_atomic() to free thread stack

vfree() can be used in any atomic context now, thus there is no point in using vfree_atomic(). This reverts commit 0f110a9b956c ("kernel/fork: use vfree_atomic() to free thread stack") Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> --- kernel/fork.c | 2 +- 1 file chan

[PATCH 2/4] x86/ldt: use vfree() instead of vfree_atomic()

vfree() can be used in any atomic context now, thus there is no point in vfree_atomic(). This reverts commit 8d5341a6260a ("x86/ldt: use vfree_atomic() to free ldt entries") Signed-off-by: Andrey Ryabinin --- arch/x86/kernel/ldt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletio

[PATCH 3/4] kernel/fork: use vfree() instead of vfree_atomic() to free thread stack

vfree() can be used in any atomic context now, thus there is no point in using vfree_atomic(). This reverts commit 0f110a9b956c ("kernel/fork: use vfree_atomic() to free thread stack") Signed-off-by: Andrey Ryabinin --- kernel/fork.c | 2 +- 1 file changed, 1 insertion(+), 1 deletio

Re: [PATCH v4 0/9] kasan: improve error reports

| 5 +- > mm/kasan/kasan.h | 2 +- > mm/kasan/report.c | 172 > +++--- > mm/slab.c | 2 +- > mm/slub.c | 12 ++-- > 6 files changed, 121 insertions(+), 74 deletions(-) > Acked-by: Andrey Ryabinin <aryabi...@virtuozzo.com>

Re: [PATCH v4 0/9] kasan: improve error reports

| 5 +- > mm/kasan/kasan.h | 2 +- > mm/kasan/report.c | 172 > +++--- > mm/slab.c | 2 +- > mm/slub.c | 12 ++-- > 6 files changed, 121 insertions(+), 74 deletions(-) > Acked-by: Andrey Ryabinin

Re: [PATCH v2] module: check if memory leak by module.

On 03/29/2017 09:02 AM, Maninder Singh wrote: > diff --git a/kernel/module.c b/kernel/module.c > index f953df9..98a8018 100644 > --- a/kernel/module.c > +++ b/kernel/module.c > @@ -2117,9 +2117,31 @@ void __weak module_arch_freeing_init(struct module > *mod) > { > } > > +static void

Re: [PATCH v2] module: check if memory leak by module.

On 03/29/2017 09:02 AM, Maninder Singh wrote: > diff --git a/kernel/module.c b/kernel/module.c > index f953df9..98a8018 100644 > --- a/kernel/module.c > +++ b/kernel/module.c > @@ -2117,9 +2117,31 @@ void __weak module_arch_freeing_init(struct module > *mod) > { > } > > +static void

[PATCH v3] kasan: report only the first error by default

ameter kasan_multi_shot must be used. Signed-off-by: Mark Rutland <mark.rutl...@arm.com> [ aryabinin: wrote changelog and doc, added missing include ] Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> --- Changes since v2: - Instead of using atomic report counter, use separate f

[PATCH v3] kasan: report only the first error by default

. Signed-off-by: Mark Rutland [ aryabinin: wrote changelog and doc, added missing include ] Signed-off-by: Andrey Ryabinin --- Changes since v2: - Instead of using atomic report counter, use separate flags to determine whether we're in multi-shot mode, and whether a (oneshot

Re: [PATCH v2] kasan: report only the first error by default

On 03/23/2017 03:41 PM, Mark Rutland wrote: > On Thu, Mar 23, 2017 at 02:49:16PM +0300, Andrey Ryabinin wrote: >> +kasan_multi_shot >> +[KNL] Enforce KASAN (Kernel Address Sanitizer) to print >> +report on every invalid m

Re: [PATCH v2] kasan: report only the first error by default

On 03/23/2017 03:41 PM, Mark Rutland wrote: > On Thu, Mar 23, 2017 at 02:49:16PM +0300, Andrey Ryabinin wrote: >> +kasan_multi_shot >> +[KNL] Enforce KASAN (Kernel Address Sanitizer) to print >> +report on every invalid m

[PATCH v2] kasan: report only the first error by default

-by: Andrey Ryabinin <aryabi...@virtuozzo.com> --- Changes since v1: - provide kasan_multi_shot boot parameter. Documentation/admin-guide/kernel-parameters.txt | 6 ++ lib/test_kasan.c| 12 mm/kasan/kasan.h

[PATCH v2] kasan: report only the first error by default

-by: Andrey Ryabinin --- Changes since v1: - provide kasan_multi_shot boot parameter. Documentation/admin-guide/kernel-parameters.txt | 6 ++ lib/test_kasan.c| 12 mm/kasan/kasan.h| 5 - mm/kasan/report.c

Re: [PATCH] kasan: report only the first error

On 03/22/2017 07:34 PM, Andrey Konovalov wrote: > On Wed, Mar 22, 2017 at 5:06 PM, Andrey Ryabinin > <aryabi...@virtuozzo.com> wrote: >> Disable kasan after the first report. There are several reasons for this: >> * Single bug quite often has multiple invalid memory acces

Re: [PATCH] kasan: report only the first error

On 03/22/2017 07:34 PM, Andrey Konovalov wrote: > On Wed, Mar 22, 2017 at 5:06 PM, Andrey Ryabinin > wrote: >> Disable kasan after the first report. There are several reasons for this: >> * Single bug quite often has multiple invalid memory accesses causing >> storm i

Re: [PATCH] x86: remove unused atomic_inc_short()

On 03/22/2017 05:10 PM, Dmitry Vyukov wrote: > It is completely unused and implemented only on x86. > Remove it. > > Signed-off-by: Dmitry Vyukov <dvyu...@google.com> > Suggested-by: Andrey Ryabinin <aryabi...@virtuozzo.com> Not me, it was Mark Rutland <mark.

Re: [PATCH] x86: remove unused atomic_inc_short()

On 03/22/2017 05:10 PM, Dmitry Vyukov wrote: > It is completely unused and implemented only on x86. > Remove it. > > Signed-off-by: Dmitry Vyukov > Suggested-by: Andrey Ryabinin Not me, it was Mark Rutland > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: "

[PATCH] kasan: report only the first error

the first easily could be not bugs by itself but just side effects of the first one. Given that multiple reports only do harm, it makes sense to disable kasan after the first one. Except for the tests in lib/test_kasan.c as we obviously want to see all reports from test. Signed-off-by: Andrey

[PATCH] kasan: report only the first error

the first easily could be not bugs by itself but just side effects of the first one. Given that multiple reports only do harm, it makes sense to disable kasan after the first one. Except for the tests in lib/test_kasan.c as we obviously want to see all reports from test. Signed-off-by: Andrey

Re: [PATCH 2/3] asm-generic, x86: wrap atomic operations

On 03/20/2017 08:17 PM, Mark Rutland wrote: > Hi, > > On Tue, Mar 14, 2017 at 08:24:13PM +0100, Dmitry Vyukov wrote: >> /** >> - * atomic_read - read atomic variable >> + * arch_atomic_read - read atomic variable >> * @v: pointer of type atomic_t >> * >> * Atomically reads the value of @v.

<    3   4   5   6   7   8   9   10   11   12   >