[PATCH 1/6] zram: fix lockdep warning of free block handling

ather than bottom half is swap_slot_free_notify could be called with irq disabled so it breaks local_bh_enable's rule. The irqlock works on only writebacked zram slot entry so it should be not frequent lock. Cc: sta...@vger.kernel.org # 4.14+ Signed-off-by: Minchan Kim --- drivers/block/zram/zra

[PATCH 3/6] zram: introduce ZRAM_IDLE flag

0th block is idle zpage. With this feature, user can how many zram has idle pages which are waste of memory. Signed-off-by: Minchan Kim --- Documentation/ABI/testing/sysfs-block-zram | 8 Documentation/blockdev/zram.txt| 10 +++-- drivers/block/zram/zram_

[PATCH 2/6] zram: refactoring flags and writeback stuff

This patch does renaming some variables and restructuring some codes for better redability in writeback and zs_free_page. Signed-off-by: Minchan Kim --- drivers/block/zram/zram_drv.c | 105 +- drivers/block/zram/zram_drv.h | 8 +-- 2 files changed, 44

[PATCH 0/6] zram idle page writeback

since X time ago" * Admin can define when zram should writeback them * Admin can define when zram should stop writeback to prevent wearout Detail is on each patch's description. Minchan Kim (6): zram: fix lockdep warning of free block handling zram: refactoring flags and writeback st

[PATCH 2/6] zram: refactoring flags and writeback stuff

This patch does renaming some variables and restructuring some codes for better redability in writeback and zs_free_page. Signed-off-by: Minchan Kim --- drivers/block/zram/zram_drv.c | 105 +- drivers/block/zram/zram_drv.h | 8 +-- 2 files changed, 44

[PATCH 0/6] zram idle page writeback

since X time ago" * Admin can define when zram should writeback them * Admin can define when zram should stop writeback to prevent wearout Detail is on each patch's description. Minchan Kim (6): zram: fix lockdep warning of free block handling zram: refactoring flags and writeback st

[PATCH] zram: close udev startup race condition as default groups

Reinecke Tested-by: Howard Chen Signed-off-by: Minchan Kim --- drivers/block/zram/zram_drv.c | 26 ++ 1 file changed, 6 insertions(+), 20 deletions(-) diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c index a1d6b5597c17..66921427d109 100644

[PATCH] zram: close udev startup race condition as default groups

Reinecke Tested-by: Howard Chen Signed-off-by: Minchan Kim --- drivers/block/zram/zram_drv.c | 26 ++ 1 file changed, 6 insertions(+), 20 deletions(-) diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c index a1d6b5597c17..66921427d109 100644

Re: [PATCH v1 1/3] arm: mm: reordering memory type table

Hi Catalin, Sorry for the late response. It was big holiday here. I will correct what you pointed out and resubmit patch next week. Thanks for the review! On Mon, Sep 24, 2018 at 05:22:03PM +0100, Catalin Marinas wrote: > On Mon, Sep 17, 2018 at 09:44:49AM +0900, Minchan Kim wrote: > &g

Re: [PATCH v1 1/3] arm: mm: reordering memory type table

Hi Catalin, Sorry for the late response. It was big holiday here. I will correct what you pointed out and resubmit patch next week. Thanks for the review! On Mon, Sep 24, 2018 at 05:22:03PM +0100, Catalin Marinas wrote: > On Mon, Sep 17, 2018 at 09:44:49AM +0900, Minchan Kim wrote: > &g

Re: [PATCH] zram: fix missing zero pages for memory tracking

On Wed, Sep 19, 2018 at 04:29:16PM +0900, Sergey Senozhatsky wrote: > On (09/19/18 14:18), Minchan Kim wrote: > > We need to count zero filled pages as well as other pages in zram. > > A nit, > > 'ZRAM_FLAG_SHIFT + 1' covers all ZRAM_SAME pages, not only > zero fill

Re: [PATCH] zram: fix missing zero pages for memory tracking

On Wed, Sep 19, 2018 at 04:29:16PM +0900, Sergey Senozhatsky wrote: > On (09/19/18 14:18), Minchan Kim wrote: > > We need to count zero filled pages as well as other pages in zram. > > A nit, > > 'ZRAM_FLAG_SHIFT + 1' covers all ZRAM_SAME pages, not only > zero fill

Re: [PATCH v1 1/3] arm: mm: reordering memory type table

Hi Guys, Could you have a chance to review this patchset? Thanks! On Mon, Sep 17, 2018 at 09:44:49AM +0900, Minchan Kim wrote: > To use bit 5 in page table as L_PTE_SPECIAL, we need a room for that. > It seems we don't need 4 bits for the memory type with ARMv6+. > If it's true, let'

Re: [PATCH v1 1/3] arm: mm: reordering memory type table

Hi Guys, Could you have a chance to review this patchset? Thanks! On Mon, Sep 17, 2018 at 09:44:49AM +0900, Minchan Kim wrote: > To use bit 5 in page table as L_PTE_SPECIAL, we need a room for that. > It seems we don't need 4 bits for the memory type with ARMv6+. > If it's true, let'

Re: [PATCH] zram: fix missing zero pages for memory tracking

Hi Sergey, On Wed, Sep 19, 2018 at 04:29:16PM +0900, Sergey Senozhatsky wrote: > On (09/19/18 14:18), Minchan Kim wrote: > > We need to count zero filled pages as well as other pages in zram. > > A nit, > > 'ZRAM_FLAG_SHIFT + 1' covers all ZRAM_SAME pages, not onl

Re: [PATCH] zram: fix missing zero pages for memory tracking

Hi Sergey, On Wed, Sep 19, 2018 at 04:29:16PM +0900, Sergey Senozhatsky wrote: > On (09/19/18 14:18), Minchan Kim wrote: > > We need to count zero filled pages as well as other pages in zram. > > A nit, > > 'ZRAM_FLAG_SHIFT + 1' covers all ZRAM_SAME pages, not onl

[PATCH] zram: fix missing zero pages for memory tracking

We need to count zero filled pages as well as other pages in zram. Otherwise, it doesn't match swap page count via pagemap of process so that memory tracking feature in zram doesn't provide accurate information. Cc: Sergey Senozhatsky Cc: [4.18+] Signed-off-by: Minchan Kim --- drivers

[PATCH] zram: fix missing zero pages for memory tracking

We need to count zero filled pages as well as other pages in zram. Otherwise, it doesn't match swap page count via pagemap of process so that memory tracking feature in zram doesn't provide accurate information. Cc: Sergey Senozhatsky Cc: [4.18+] Signed-off-by: Minchan Kim --- drivers

[PATCH v1 3/3] arm: mm: support get_user_pages_fast

: Catalin Marinas Cc: Will Deacon Cc: Steve Capper Signed-off-by: Minchan Kim --- arch/arm/mm/Makefile | 6 ++ arch/arm/mm/gup.c| 221 +++ 2 files changed, 227 insertions(+) create mode 100644 arch/arm/mm/gup.c diff --git a/arch/arm/mm/Makefile b/arch/arm

[PATCH v1 3/3] arm: mm: support get_user_pages_fast

: Catalin Marinas Cc: Will Deacon Cc: Steve Capper Signed-off-by: Minchan Kim --- arch/arm/mm/Makefile | 6 ++ arch/arm/mm/gup.c| 221 +++ 2 files changed, 227 insertions(+) create mode 100644 arch/arm/mm/gup.c diff --git a/arch/arm/mm/Makefile b/arch/arm

[PATCH v1 1/3] arm: mm: reordering memory type table

L_PTE_MT_DEV_SHARED, unless I miss any place where > DEV_NONSHARED is relevant on ARMv6 (adding Simon to confirm on shmbile). " Cc: Russell King Cc: Catalin Marinas Cc: Will Deacon Cc: Steve Capper Cc: Simon Horman Signed-off-by: Minchan Kim --- arch/arm/inclu

[PATCH v1 2/3] arm: mm: introduce L_PTE_SPECIAL

This patch introduces L_PTE_SPECIAL and pte functions for supporting get_user_pages_fast. Cc: Russell King Cc: Catalin Marinas Cc: Will Deacon Cc: Steve Capper Signed-off-by: Minchan Kim --- arch/arm/Kconfig | 2 +- arch/arm/include/asm/pgtable-2level.h | 3 +-- arch

[PATCH v1 1/3] arm: mm: reordering memory type table

L_PTE_MT_DEV_SHARED, unless I miss any place where > DEV_NONSHARED is relevant on ARMv6 (adding Simon to confirm on shmbile). " Cc: Russell King Cc: Catalin Marinas Cc: Will Deacon Cc: Steve Capper Cc: Simon Horman Signed-off-by: Minchan Kim --- arch/arm/inclu

[PATCH v1 2/3] arm: mm: introduce L_PTE_SPECIAL

This patch introduces L_PTE_SPECIAL and pte functions for supporting get_user_pages_fast. Cc: Russell King Cc: Catalin Marinas Cc: Will Deacon Cc: Steve Capper Signed-off-by: Minchan Kim --- arch/arm/Kconfig | 2 +- arch/arm/include/asm/pgtable-2level.h | 3 +-- arch

[PATCH v1 0/3] arm: support get_user_pages_fast

://lkml.kernel.org/r/20180910165011.zcighyuabshsm...@armageddon.cambridge.arm.com Minchan Kim (3): arm: mm: reordering memory type table arm: mm: introduce L_PTE_SPECIAL arm: mm: support get_user_pages_fast arch/arm/Kconfig | 2 +- arch/arm/include/asm/pgtable-2level.h

[PATCH v1 0/3] arm: support get_user_pages_fast

://lkml.kernel.org/r/20180910165011.zcighyuabshsm...@armageddon.cambridge.arm.com Minchan Kim (3): arm: mm: reordering memory type table arm: mm: introduce L_PTE_SPECIAL arm: mm: support get_user_pages_fast arch/arm/Kconfig | 2 +- arch/arm/include/asm/pgtable-2level.h

Re: [RFC 1/3] arm: mm: reordering memory type table

On Mon, Sep 10, 2018 at 05:50:11PM +0100, Catalin Marinas wrote: > On Thu, Sep 06, 2018 at 07:22:10PM +0900, Minchan Kim wrote: > > diff --git a/arch/arm/include/asm/pgtable-2level.h > > b/arch/arm/include/asm/pgtable-2level.h > > index 92fd2c8a9af0..91b99fadcba1 100644 >

Re: [RFC 1/3] arm: mm: reordering memory type table

On Mon, Sep 10, 2018 at 05:50:11PM +0100, Catalin Marinas wrote: > On Thu, Sep 06, 2018 at 07:22:10PM +0900, Minchan Kim wrote: > > diff --git a/arch/arm/include/asm/pgtable-2level.h > > b/arch/arm/include/asm/pgtable-2level.h > > index 92fd2c8a9af0..91b99fadcba1 100644 >

Re: KASAN: null-ptr-deref Write in binder_update_page_range

Thanks, Martijn, Greg, could you have a look to pick up? On Mon, Aug 27, 2018 at 03:35:24PM +0200, Martijn Coenen wrote: > Thanks Minchan! > > On Thu, Aug 23, 2018 at 7:29 AM, Minchan Kim wrote: > > Signed-off-by: Todd Kjos > > Signed-off-by: Minchan Kim > Rev

Re: KASAN: null-ptr-deref Write in binder_update_page_range

Thanks, Martijn, Greg, could you have a look to pick up? On Mon, Aug 27, 2018 at 03:35:24PM +0200, Martijn Coenen wrote: > Thanks Minchan! > > On Thu, Aug 23, 2018 at 7:29 AM, Minchan Kim wrote: > > Signed-off-by: Todd Kjos > > Signed-off-by: Minchan Kim > Rev

[RFC 3/3] arm: mm: support get_user_pages_fast

: Catalin Marinas Cc: Will Deacon Cc: Steve Capper Signed-off-by: Minchan Kim --- arch/arm/mm/Makefile | 6 ++ arch/arm/mm/gup.c| 221 +++ 2 files changed, 227 insertions(+) create mode 100644 arch/arm/mm/gup.c diff --git a/arch/arm/mm/Makefile b/arch/arm

[RFC 1/3] arm: mm: reordering memory type table

Signed-off-by: Minchan Kim --- arch/arm/include/asm/pgtable-2level.h | 13 +++-- arch/arm/mm/proc-macros.S | 16 2 files changed, 19 insertions(+), 10 deletions(-) diff --git a/arch/arm/include/asm/pgtable-2level.h b/arch/arm/include/asm/pgtable-2level.h index

[RFC 2/3] arm: mm: introduce L_PTE_SPECIAL

This patch introduces L_PTE_SPECIAL and pte functions for supporting get_user_pages_fast. Cc: Russell King Cc: Catalin Marinas Cc: Will Deacon Cc: Steve Capper Signed-off-by: Minchan Kim --- arch/arm/Kconfig | 2 +- arch/arm/include/asm/pgtable-2level.h | 3 +-- arch

[RFC 3/3] arm: mm: support get_user_pages_fast

: Catalin Marinas Cc: Will Deacon Cc: Steve Capper Signed-off-by: Minchan Kim --- arch/arm/mm/Makefile | 6 ++ arch/arm/mm/gup.c| 221 +++ 2 files changed, 227 insertions(+) create mode 100644 arch/arm/mm/gup.c diff --git a/arch/arm/mm/Makefile b/arch/arm

[RFC 1/3] arm: mm: reordering memory type table

Signed-off-by: Minchan Kim --- arch/arm/include/asm/pgtable-2level.h | 13 +++-- arch/arm/mm/proc-macros.S | 16 2 files changed, 19 insertions(+), 10 deletions(-) diff --git a/arch/arm/include/asm/pgtable-2level.h b/arch/arm/include/asm/pgtable-2level.h index

[RFC 2/3] arm: mm: introduce L_PTE_SPECIAL

This patch introduces L_PTE_SPECIAL and pte functions for supporting get_user_pages_fast. Cc: Russell King Cc: Catalin Marinas Cc: Will Deacon Cc: Steve Capper Signed-off-by: Minchan Kim --- arch/arm/Kconfig | 2 +- arch/arm/include/asm/pgtable-2level.h | 3 +-- arch

[RFC 0/3] arm: support get_user_pages_fast

. It seems we don't use the bit in ARMv6+ but it needs double check from maintainers. Second patch introduces L_PTE_SPECIAL for arm so that last patch can support get_user_pags_fast. I would greatly appreciate if guys review that I screw up something, especially, architecture stuffs. Thanks. Minchan

[RFC 0/3] arm: support get_user_pages_fast

. It seems we don't use the bit in ARMv6+ but it needs double check from maintainers. Second patch introduces L_PTE_SPECIAL for arm so that last patch can support get_user_pags_fast. I would greatly appreciate if guys review that I screw up something, especially, architecture stuffs. Thanks. Minchan

Re: KASAN: null-ptr-deref Write in binder_update_page_range

On Thu, Aug 23, 2018 at 07:03:34PM +0900, Dae R. Jeong wrote: > > Could you test this patch? I found that bug a month ago but didn't submit > > yet. > > I don't have a reproducer now. I manually analzed a root cause of the > crash using a fuzzer's log. The log reported a race on 'alloc->vma'. >

Re: KASAN: null-ptr-deref Write in binder_update_page_range

On Thu, Aug 23, 2018 at 07:03:34PM +0900, Dae R. Jeong wrote: > > Could you test this patch? I found that bug a month ago but didn't submit > > yet. > > I don't have a reproducer now. I manually analzed a root cause of the > crash using a fuzzer's log. The log reported a race on 'alloc->vma'. >

Re: KASAN: null-ptr-deref Write in binder_update_page_range

because, while RaceFuzzer precisely interleaves the scheduling at the > kernel's instruction level when finding this bug, C repro cannot fully > utilize such a feature. Please disregard all code related to > "should_hypercall" in the C repro, as this is only for our debugging > purpos

Re: KASAN: null-ptr-deref Write in binder_update_page_range

because, while RaceFuzzer precisely interleaves the scheduling at the > kernel's instruction level when finding this bug, C repro cannot fully > utilize such a feature. Please disregard all code related to > "should_hypercall" in the C repro, as this is only for our debugging > purpos

Re: Re: [PATCH] zsmalloc: fix linking bug in init_zspage

71f 9783 > (d421)[pid:3471,cpu4,thread-3]---[ end trace 652caafc4c4b6d06 ]--- > Hi Sergey, > > On Mon, Aug 13, 2018 at 07:55:36PM +0900, Sergey Senozhatsky wrote: > On (08/13/18 15:05), Minchan Kim wrote: >From: zhouxianrong > >The last partial obj

Re: Re: [PATCH] zsmalloc: fix linking bug in init_zspage

71f 9783 > (d421)[pid:3471,cpu4,thread-3]---[ end trace 652caafc4c4b6d06 ]--- > Hi Sergey, > > On Mon, Aug 13, 2018 at 07:55:36PM +0900, Sergey Senozhatsky wrote: > On (08/13/18 15:05), Minchan Kim wrote: >From: zhouxianrong > >The last partial obj

Re: [PATCH] zsmalloc: fix linking bug in init_zspage

Hi Sergey, On Mon, Aug 13, 2018 at 07:55:36PM +0900, Sergey Senozhatsky wrote: > On (08/13/18 15:05), Minchan Kim wrote: > > > From: zhouxianrong > > > > > > The last partial object in last subpage of zspage should not be linked > > > in allocation

Re: [PATCH] zsmalloc: fix linking bug in init_zspage

Hi Sergey, On Mon, Aug 13, 2018 at 07:55:36PM +0900, Sergey Senozhatsky wrote: > On (08/13/18 15:05), Minchan Kim wrote: > > > From: zhouxianrong > > > > > > The last partial object in last subpage of zspage should not be linked > > > in allocation

Re: [PATCH] zram: fix bug storing backing_dev

> the new file_name buffer. This makes it possible to set the backing_dev > as follows: > > echo /dev/sdX > /sys/block/zram0/backing_dev > > Signed-off-by: Peter Kalauskas Acked-by: Minchan Kim Cc: Andrew Morton Cc: Sergey Senozhatsky CC: LKML Cc: [4.14+] > --- >

Re: [PATCH] zram: fix bug storing backing_dev

> the new file_name buffer. This makes it possible to set the backing_dev > as follows: > > echo /dev/sdX > /sys/block/zram0/backing_dev > > Signed-off-by: Peter Kalauskas Acked-by: Minchan Kim Cc: Andrew Morton Cc: Sergey Senozhatsky CC: LKML Cc: [4.14+] > --- >

Re: [PATCH] zsmalloc: fix linking bug in init_zspage

Hi, On Thu, Aug 09, 2018 at 08:28:17PM -0400, zhouxianrong wrote: > From: zhouxianrong > > The last partial object in last subpage of zspage should not be linked > in allocation list. Otherwise it could trigger BUG_ON explicitly at > function zs_map_object. But it happened rarely. Could you be

Re: [PATCH] zsmalloc: fix linking bug in init_zspage

Hi, On Thu, Aug 09, 2018 at 08:28:17PM -0400, zhouxianrong wrote: > From: zhouxianrong > > The last partial object in last subpage of zspage should not be linked > in allocation list. Otherwise it could trigger BUG_ON explicitly at > function zs_map_object. But it happened rarely. Could you be

[PATCH v2] zram: remove BD_CAP_SYNCHRONOUS_IO with writeback feature

.org/r/20180802051112.86174-1-minc...@kernel.org Signed-off-by: Minchan Kim Reported-by: Tino Lehnig Tested-by: Tino Lehnig Cc: Sergey Senozhatsky Cc: Jens Axboe Cc: [4.15+] Signed-off-by: Andrew Morton --- drivers/block/zram/zram_drv.c | 15 ++- 1 file changed, 14 insertions

[PATCH v2] zram: remove BD_CAP_SYNCHRONOUS_IO with writeback feature

.org/r/20180802051112.86174-1-minc...@kernel.org Signed-off-by: Minchan Kim Reported-by: Tino Lehnig Tested-by: Tino Lehnig Cc: Sergey Senozhatsky Cc: Jens Axboe Cc: [4.15+] Signed-off-by: Andrew Morton --- drivers/block/zram/zram_drv.c | 15 ++- 1 file changed, 14 insertions

Re: [PATCH 1/2] zram: remove BD_CAP_SYNCHRONOUS_IO with writeback feature

Hi Andrew, On Fri, Aug 03, 2018 at 04:28:18PM -0700, Andrew Morton wrote: > On Fri, 3 Aug 2018 11:51:43 +0900 Minchan Kim wrote: > > > > Is it legitimate to be altering the bdi capabilities at this level? Or > > > is this hacky? > > > > Most of device

Re: [PATCH 1/2] zram: remove BD_CAP_SYNCHRONOUS_IO with writeback feature

Hi Andrew, On Fri, Aug 03, 2018 at 04:28:18PM -0700, Andrew Morton wrote: > On Fri, 3 Aug 2018 11:51:43 +0900 Minchan Kim wrote: > > > > Is it legitimate to be altering the bdi capabilities at this level? Or > > > is this hacky? > > > > Most of device

Re: [PATCH 1/2] zram: remove BD_CAP_SYNCHRONOUS_IO with writeback feature

On Fri, Aug 03, 2018 at 01:13:02PM +0900, Sergey Senozhatsky wrote: > Hi Minchan, > > On (08/03/18 12:00), Minchan Kim wrote: > > > "Device is so fast that asynchronous IO would be inefficient." > > > > > > Which is not the reason why BDI_CAP_

Re: [PATCH 1/2] zram: remove BD_CAP_SYNCHRONOUS_IO with writeback feature

On Fri, Aug 03, 2018 at 01:13:02PM +0900, Sergey Senozhatsky wrote: > Hi Minchan, > > On (08/03/18 12:00), Minchan Kim wrote: > > > "Device is so fast that asynchronous IO would be inefficient." > > > > > > Which is not the reason why BDI_CAP_

Re: [PATCH 1/2] zram: remove BD_CAP_SYNCHRONOUS_IO with writeback feature

Hi Sergey, On Fri, Aug 03, 2018 at 11:39:29AM +0900, Sergey Senozhatsky wrote: > On (08/02/18 14:13), Andrew Morton wrote: > [..] > > That changelog is rather hard to follow. Please review my edits: > > > > : If zram supports writeback feature, it's no longer a BD_CAP_SYNCHRONOUS_IO >

Re: [PATCH 1/2] zram: remove BD_CAP_SYNCHRONOUS_IO with writeback feature

Hi Sergey, On Fri, Aug 03, 2018 at 11:39:29AM +0900, Sergey Senozhatsky wrote: > On (08/02/18 14:13), Andrew Morton wrote: > [..] > > That changelog is rather hard to follow. Please review my edits: > > > > : If zram supports writeback feature, it's no longer a BD_CAP_SYNCHRONOUS_IO >

Re: [PATCH 1/2] zram: remove BD_CAP_SYNCHRONOUS_IO with writeback feature

Hi Andrew, On Thu, Aug 02, 2018 at 02:13:04PM -0700, Andrew Morton wrote: > On Thu, 2 Aug 2018 14:11:12 +0900 Minchan Kim wrote: > > > If zram supports writeback feature, it's no more syncrhonous > > device beause zram does synchronous IO opeation for > > incompre

Re: [PATCH 1/2] zram: remove BD_CAP_SYNCHRONOUS_IO with writeback feature

Hi Andrew, On Thu, Aug 02, 2018 at 02:13:04PM -0700, Andrew Morton wrote: > On Thu, 2 Aug 2018 14:11:12 +0900 Minchan Kim wrote: > > > If zram supports writeback feature, it's no more syncrhonous > > device beause zram does synchronous IO opeation for > > incompre

Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...

On Mon, Jul 30, 2018 at 08:09:33AM +0200, Tino Lehnig wrote: > On 07/28/2018 12:58 AM, Minchan Kim wrote: > > I made a mistake on previous patch. > > Could you test this patches? > > Thanks! Looking good so far! No errors whatsoever with the new patch. I will > let

Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...

On Mon, Jul 30, 2018 at 08:09:33AM +0200, Tino Lehnig wrote: > On 07/28/2018 12:58 AM, Minchan Kim wrote: > > I made a mistake on previous patch. > > Could you test this patches? > > Thanks! Looking good so far! No errors whatsoever with the new patch. I will > let

[PATCH 1/2] zram: remove BD_CAP_SYNCHRONOUS_IO with writeback feature

c66000 R14: R15: 5652b984e0f0 Link: https://lore.kernel.org/lkml/0516ae2d-b0fd-92c5-aa92-112ba7bd3...@contabo.de/ Reported-by: Tino Lehnig Cc: Sergey Senozhatsky Cc: Tino Lehnig Cc: # v4.15+ Tested-by: Tino Lehnig Signed-off-by: Minchan Kim --- drivers/block/zram/zram

[PATCH 1/2] zram: remove BD_CAP_SYNCHRONOUS_IO with writeback feature

c66000 R14: R15: 5652b984e0f0 Link: https://lore.kernel.org/lkml/0516ae2d-b0fd-92c5-aa92-112ba7bd3...@contabo.de/ Reported-by: Tino Lehnig Cc: Sergey Senozhatsky Cc: Tino Lehnig Cc: # v4.15+ Tested-by: Tino Lehnig Signed-off-by: Minchan Kim --- drivers/block/zram/zram

Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...

On Fri, Jul 27, 2018 at 02:13:57PM +0200, Tino Lehnig wrote: > On 07/27/2018 02:05 PM, Minchan Kim wrote: > > And bad page is always with writeback enable? > > > > writeback enable means "echo "some dev" > /sys/block/zram0/backing_dev, > > not just en

Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...

On Fri, Jul 27, 2018 at 02:13:57PM +0200, Tino Lehnig wrote: > On 07/27/2018 02:05 PM, Minchan Kim wrote: > > And bad page is always with writeback enable? > > > > writeback enable means "echo "some dev" > /sys/block/zram0/backing_dev, > > not just en

Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...

On Fri, Jul 27, 2018 at 01:00:01PM +0200, Tino Lehnig wrote: > On 07/27/2018 11:14 AM, Minchan Kim wrote: > > I tried to reproduce with KVM but was not successful and I don't have > > real mahcine to reproduce it. I am asking one device for it. > > > > Anyway, I want t

Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...

On Fri, Jul 27, 2018 at 01:00:01PM +0200, Tino Lehnig wrote: > On 07/27/2018 11:14 AM, Minchan Kim wrote: > > I tried to reproduce with KVM but was not successful and I don't have > > real mahcine to reproduce it. I am asking one device for it. > > > > Anyway, I want t

Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...

PM, Minchan Kim wrote: > > Huh, you see it without writeback? It's weird. Without writeback feature, > > zram operaion is always synchronous on memory compression/decompression > > so you shouldn't see below io_schedule logic which happens only for > > asynchronous IO operation. &

Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...

PM, Minchan Kim wrote: > > Huh, you see it without writeback? It's weird. Without writeback feature, > > zram operaion is always synchronous on memory compression/decompression > > so you shouldn't see below io_schedule logic which happens only for > > asynchronous IO operation. &

Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...

On Thu, Jul 26, 2018 at 12:00:44PM +0200, Tino Lehnig wrote: > On 07/26/2018 08:10 AM, Tino Lehnig wrote: > > > A thing I could imagine is > > > [0bcac06f27d75, skip swapcache for swapin of synchronous device] > > > It was merged into v4.15. Could you check it by bisecting? > > > > Thanks, I will

Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...

On Thu, Jul 26, 2018 at 12:00:44PM +0200, Tino Lehnig wrote: > On 07/26/2018 08:10 AM, Tino Lehnig wrote: > > > A thing I could imagine is > > > [0bcac06f27d75, skip swapcache for swapin of synchronous device] > > > It was merged into v4.15. Could you check it by bisecting? > > > > Thanks, I will

Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...

On Thu, Jul 26, 2018 at 08:10:41AM +0200, Tino Lehnig wrote: > Hi, > > On 07/26/2018 04:03 AM, Minchan Kim wrote: > > A thing I could imagine is > > [0bcac06f27d75, skip swapcache for swapin of synchronous device] > > It was merged into v4.15. Could you check it b

Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...

On Thu, Jul 26, 2018 at 08:10:41AM +0200, Tino Lehnig wrote: > Hi, > > On 07/26/2018 04:03 AM, Minchan Kim wrote: > > A thing I could imagine is > > [0bcac06f27d75, skip swapcache for swapin of synchronous device] > > It was merged into v4.15. Could you check it b

Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...

Hi Tino, On Wed, Jul 25, 2018 at 05:12:13PM +0200, Tino Lehnig wrote: > Hi, > > On 07/25/2018 03:21 PM, Minchan Kim wrote: > > It would be much helpful if you could check more versions with git-bisect. > > I started bisecting today, but my results are not conclusive

Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...

Hi Tino, On Wed, Jul 25, 2018 at 05:12:13PM +0200, Tino Lehnig wrote: > Hi, > > On 07/25/2018 03:21 PM, Minchan Kim wrote: > > It would be much helpful if you could check more versions with git-bisect. > > I started bisecting today, but my results are not conclusive

Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...

ested some heavy swap workload(kernel build with multiple CPU on small memory) but I failed to reproduce, too. Please could you told me your method more detail? Thanks. > > On 07/24/2018 03:03 AM, Minchan Kim wrote: > > We didn't release v4.18 yet. Could you say what kern

Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...

ested some heavy swap workload(kernel build with multiple CPU on small memory) but I failed to reproduce, too. Please could you told me your method more detail? Thanks. > > On 07/24/2018 03:03 AM, Minchan Kim wrote: > > We didn't release v4.18 yet. Could you say what kern

Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...

On Tue, Jul 24, 2018 at 07:55:25PM -0700, Matthew Wilcox wrote: > On Wed, Jul 25, 2018 at 11:51:06AM +0900, Minchan Kim wrote: > > On Tue, Jul 24, 2018 at 07:35:32PM -0700, Matthew Wilcox wrote: > > > There is NOTHING in a union with _refcount. > > > > Confusi

Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...

On Tue, Jul 24, 2018 at 07:55:25PM -0700, Matthew Wilcox wrote: > On Wed, Jul 25, 2018 at 11:51:06AM +0900, Minchan Kim wrote: > > On Tue, Jul 24, 2018 at 07:35:32PM -0700, Matthew Wilcox wrote: > > > There is NOTHING in a union with _refcount. > > > > Confusi

Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...

On Tue, Jul 24, 2018 at 07:35:32PM -0700, Matthew Wilcox wrote: > On Wed, Jul 25, 2018 at 11:16:57AM +0900, Minchan Kim wrote: > > On Tue, Jul 24, 2018 at 06:55:02PM -0700, Matthew Wilcox wrote: > > > On Wed, Jul 25, 2018 at 10:32:50AM +0900, Minchan Kim wrot

Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...

On Tue, Jul 24, 2018 at 07:35:32PM -0700, Matthew Wilcox wrote: > On Wed, Jul 25, 2018 at 11:16:57AM +0900, Minchan Kim wrote: > > On Tue, Jul 24, 2018 at 06:55:02PM -0700, Matthew Wilcox wrote: > > > On Wed, Jul 25, 2018 at 10:32:50AM +0900, Minchan Kim wrot

Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...

On Tue, Jul 24, 2018 at 06:55:02PM -0700, Matthew Wilcox wrote: > On Wed, Jul 25, 2018 at 10:32:50AM +0900, Minchan Kim wrote: > > Hi Tino, > > > > On Tue, Jul 24, 2018 at 09:30:34AM +0200, Tino Lehnig wrote: > > > Hi, > > > > > > The first build I

Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...

On Tue, Jul 24, 2018 at 06:55:02PM -0700, Matthew Wilcox wrote: > On Wed, Jul 25, 2018 at 10:32:50AM +0900, Minchan Kim wrote: > > Hi Tino, > > > > On Tue, Jul 24, 2018 at 09:30:34AM +0200, Tino Lehnig wrote: > > > Hi, > > > > > > The first build I

Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...

e is an easier way to write this. The innermost union is of four things which are the size of an int, so > > On 07/24/2018 03:03 AM, Minchan Kim wrote: > > We didn't release v4.18 yet. Could you say what kernel tree/what version > > you used? > > -- > > [ 804.48

Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...

e is an easier way to write this. The innermost union is of four things which are the size of an int, so > > On 07/24/2018 03:03 AM, Minchan Kim wrote: > > We didn't release v4.18 yet. Could you say what kernel tree/what version > > you used? > > -- > > [ 804.48

Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...

On Tue, Jul 24, 2018 at 11:53:30AM +0900, Sergey Senozhatsky wrote: > On (07/24/18 10:03), Minchan Kim wrote: > > On Mon, Jul 23, 2018 at 02:29:32PM +0200, Tino Lehnig wrote: > > > Hello, > > > > > > after enabling the writeback feature in zram, I encountered t

Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...

On Tue, Jul 24, 2018 at 11:53:30AM +0900, Sergey Senozhatsky wrote: > On (07/24/18 10:03), Minchan Kim wrote: > > On Mon, Jul 23, 2018 at 02:29:32PM +0200, Tino Lehnig wrote: > > > Hello, > > > > > > after enabling the writeback feature in zram, I encountered t

Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...

Hi Tino, Thanks for the report. On Mon, Jul 23, 2018 at 02:29:32PM +0200, Tino Lehnig wrote: > Hello, > > after enabling the writeback feature in zram, I encountered the kernel bug > below with heavy swap utilization. There is one specific workload that > triggers the bug reliably and that is

Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...

Hi Tino, Thanks for the report. On Mon, Jul 23, 2018 at 02:29:32PM +0200, Tino Lehnig wrote: > Hello, > > after enabling the writeback feature in zram, I encountered the kernel bug > below with heavy swap utilization. There is one specific workload that > triggers the bug reliably and that is

Re: [PATCH v2 6/7] mm, proc: add KReclaimable to /proc/meminfo

On Tue, Jun 19, 2018 at 09:30:03AM +0200, Vlastimil Babka wrote: > On 06/18/2018 11:33 PM, Andrew Morton wrote: > > On Mon, 18 Jun 2018 11:18:07 +0200 Vlastimil Babka wrote: > > > >> The vmstat NR_KERNEL_MISC_RECLAIMABLE counter is for kernel non-slab > >> allocations that can be reclaimed via

Re: [PATCH v2 6/7] mm, proc: add KReclaimable to /proc/meminfo

On Tue, Jun 19, 2018 at 09:30:03AM +0200, Vlastimil Babka wrote: > On 06/18/2018 11:33 PM, Andrew Morton wrote: > > On Mon, 18 Jun 2018 11:18:07 +0200 Vlastimil Babka wrote: > > > >> The vmstat NR_KERNEL_MISC_RECLAIMABLE counter is for kernel non-slab > >> allocations that can be reclaimed via

Re: [PATCH] memcg: force charge kmem counter too

On Thu, May 31, 2018 at 08:56:42AM +0200, Michal Hocko wrote: > On Thu 31-05-18 15:01:33, Minchan Kim wrote: > > On Wed, May 30, 2018 at 11:14:33AM -0700, Shakeel Butt wrote: > > > On Tue, May 29, 2018 at 1:31 AM, Michal Hocko wrote: > > > > On Mon 28-05-1

Re: [PATCH] memcg: force charge kmem counter too

On Thu, May 31, 2018 at 08:56:42AM +0200, Michal Hocko wrote: > On Thu 31-05-18 15:01:33, Minchan Kim wrote: > > On Wed, May 30, 2018 at 11:14:33AM -0700, Shakeel Butt wrote: > > > On Tue, May 29, 2018 at 1:31 AM, Michal Hocko wrote: > > > > On Mon 28-05-1

Re: [PATCH] memcg: force charge kmem counter too

On Wed, May 30, 2018 at 11:14:33AM -0700, Shakeel Butt wrote: > On Tue, May 29, 2018 at 1:31 AM, Michal Hocko wrote: > > On Mon 28-05-18 10:23:07, Shakeel Butt wrote: > >> On Mon, May 28, 2018 at 2:11 AM, Michal Hocko wrote: > >> Though is there a precedence where the broken feature is not fixed

Re: [PATCH] memcg: force charge kmem counter too

On Wed, May 30, 2018 at 11:14:33AM -0700, Shakeel Butt wrote: > On Tue, May 29, 2018 at 1:31 AM, Michal Hocko wrote: > > On Mon 28-05-18 10:23:07, Shakeel Butt wrote: > >> On Mon, May 28, 2018 at 2:11 AM, Michal Hocko wrote: > >> Though is there a precedence where the broken feature is not fixed

Re: [PATCH] mm: fix the NULL mapping case in __isolate_lru_page()

mpaction's async migration in 4.16. > > Fixes: 69d763fc6d3a ("mm: pin address_space before dereferencing it while > isolating an LRU page") > Signed-off-by: Hugh Dickins Acked-by: Minchan Kim Thanks, Hugh.

Re: [PATCH] mm: fix the NULL mapping case in __isolate_lru_page()

mpaction's async migration in 4.16. > > Fixes: 69d763fc6d3a ("mm: pin address_space before dereferencing it while > isolating an LRU page") > Signed-off-by: Hugh Dickins Acked-by: Minchan Kim Thanks, Hugh.

Re: [PATCH v6] ANDROID: binder: change down_write to down_read

On Tue, May 15, 2018 at 09:46:01AM +0200, Martijn Coenen wrote: < snip > > >> About the unmap at runtime part, your commit message was a bit confusing. > >> You > >> said "every binder buffers should be mapped in advance by binder_mmap." > >> but I > >> think the new binder shrinker mechanism

Re: [PATCH v6] ANDROID: binder: change down_write to down_read

On Tue, May 15, 2018 at 09:46:01AM +0200, Martijn Coenen wrote: < snip > > >> About the unmap at runtime part, your commit message was a bit confusing. > >> You > >> said "every binder buffers should be mapped in advance by binder_mmap." > >> but I > >> think the new binder shrinker mechanism

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