stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Minchan Kim <minchan@kernel.org>
Cc: akpm@linux-foundation.org, harish@linux.ibm.com,
	hch@infradead.org, sergey.senozhatsky@gmail.com,
	stable@vger.kernel.org, tony@atomide.com,
	torvalds@linux-foundation.org, urezki@gmail.com
Subject: Re: FAILED: patch "[PATCH] mm/zsmalloc.c: drop ZSMALLOC_PGTABLE_MAPPING" failed to apply to 5.4-stable tree
Date: Fri, 11 Dec 2020 15:44:18 +0100	[thread overview]
Message-ID: <X9OFwvyRVQMTG2lI@kroah.com> (raw)
In-Reply-To: <X9JgpjCx9CDIt8ye@google.com>

On Thu, Dec 10, 2020 at 09:53:42AM -0800, Minchan Kim wrote:
> On Wed, Dec 09, 2020 at 10:07:04AM +0100, gregkh@linuxfoundation.org wrote:
> > 
> > The patch below does not apply to the 5.4-stable tree.
> > If someone wants it applied there, or to any other stable or longterm
> > tree, then please email the backport, including the original git commit
> > id to <stable@vger.kernel.org>.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> > ------------------ original commit in Linus's tree ------------------
> > 
> > From e91d8d78237de8d7120c320b3645b7100848f24d Mon Sep 17 00:00:00 2001
> > From: Minchan Kim <minchan@kernel.org>
> > Date: Sat, 5 Dec 2020 22:14:51 -0800
> > Subject: [PATCH] mm/zsmalloc.c: drop ZSMALLOC_PGTABLE_MAPPING
> > 
> > While I was doing zram testing, I found sometimes decompression failed
> > since the compression buffer was corrupted.  With investigation, I found
> > below commit calls cond_resched unconditionally so it could make a
> > problem in atomic context if the task is reschedule.
> > 
> >   BUG: sleeping function called from invalid context at mm/vmalloc.c:108
> >   in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 946, name: memhog
> >   3 locks held by memhog/946:
> >    #0: ffff9d01d4b193e8 (&mm->mmap_lock#2){++++}-{4:4}, at: __mm_populate+0x103/0x160
> >    #1: ffffffffa3d53de0 (fs_reclaim){+.+.}-{0:0}, at: __alloc_pages_slowpath.constprop.0+0xa98/0x1160
> >    #2: ffff9d01d56b8110 (&zspage->lock){.+.+}-{3:3}, at: zs_map_object+0x8e/0x1f0
> >   CPU: 0 PID: 946 Comm: memhog Not tainted 5.9.3-00011-gc5bfc0287345-dirty #316
> >   Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1 04/01/2014
> >   Call Trace:
> >     unmap_kernel_range_noflush+0x2eb/0x350
> >     unmap_kernel_range+0x14/0x30
> >     zs_unmap_object+0xd5/0xe0
> >     zram_bvec_rw.isra.0+0x38c/0x8e0
> >     zram_rw_page+0x90/0x101
> >     bdev_write_page+0x92/0xe0
> >     __swap_writepage+0x94/0x4a0
> >     pageout+0xe3/0x3a0
> >     shrink_page_list+0xb94/0xd60
> >     shrink_inactive_list+0x158/0x460
> > 
> > We can fix this by removing the ZSMALLOC_PGTABLE_MAPPING feature (which
> > contains the offending calling code) from zsmalloc.
> > 
> > Even though this option showed some amount improvement(e.g., 30%) in
> > some arm32 platforms, it has been headache to maintain since it have
> > abused APIs[1](e.g., unmap_kernel_range in atomic context).
> > 
> > Since we are approaching to deprecate 32bit machines and already made
> > the config option available for only builtin build since v5.8, lastly it
> > has been not default option in zsmalloc, it's time to drop the option
> > for better maintenance.
> > 
> > [1] http://lore.kernel.org/linux-mm/20201105170249.387069-1-minchan@kernel.org
> > 
> > Fixes: e47110e90584 ("mm/vunmap: add cond_resched() in vunmap_pmd_range")
> 
> This patch fixex e47110e90584 which merged at v5.9 so we could drop it
> for v5.4.

It was backported to 5.4.62, so are you _sure_?

thanks,

greg k-h

  reply	other threads:[~2020-12-11 15:41 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-09  9:07 FAILED: patch "[PATCH] mm/zsmalloc.c: drop ZSMALLOC_PGTABLE_MAPPING" failed to apply to 5.4-stable tree gregkh
2020-12-10 17:53 ` Minchan Kim
2020-12-11 14:44   ` Greg KH [this message]
2020-12-11 22:55     ` Minchan Kim
2020-12-14 15:47       ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=X9OFwvyRVQMTG2lI@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=harish@linux.ibm.com \
    --cc=hch@infradead.org \
    --cc=minchan@kernel.org \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=stable@vger.kernel.org \
    --cc=tony@atomide.com \
    --cc=torvalds@linux-foundation.org \
    --cc=urezki@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).