linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Yu Zhao <yuzhao@google.com>
To: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Minchan Kim <minchan@kernel.org>, Nitin Gupta <ngupta@vflare.org>,
	linux-mm@kvack.org, Dan Streetman <ddstreet@ieee.org>,
	Seth Jennings <sjenning@redhat.com>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] zsmalloc: use workqueue to destroy pool in zpool callback
Date: Thu, 31 Mar 2016 14:46:45 -0700	[thread overview]
Message-ID: <20160331214645.GA31294@google.com> (raw)
In-Reply-To: <20160331084639.GB3343@swordfish>

On Thu, Mar 31, 2016 at 05:46:39PM +0900, Sergey Senozhatsky wrote:
> On (03/30/16 08:59), Minchan Kim wrote:
> > On Tue, Mar 29, 2016 at 03:02:57PM -0700, Yu Zhao wrote:
> > > zs_destroy_pool() might sleep so it shouldn't be used in zpool
> > > destroy callback which can be invoked in softirq context when
> > > zsmalloc is configured to work with zswap.
> > 
> > I think it's a limitation of zswap design, not zsmalloc.
> > Could you handle it in zswap?
> 
> agree. hm, looking at this backtrace
> 
> >   [<ffffffffaea0224b>] mutex_lock+0x1b/0x2f
> >   [<ffffffffaebca4f0>] kmem_cache_destroy+0x50/0x130
> >   [<ffffffffaec10405>] zs_destroy_pool+0x85/0xe0
> >   [<ffffffffaec1046e>] zs_zpool_destroy+0xe/0x10
> >   [<ffffffffaec101a4>] zpool_destroy_pool+0x54/0x70
> >   [<ffffffffaebedac2>] __zswap_pool_release+0x62/0x90
> >   [<ffffffffaeb1037e>] rcu_process_callbacks+0x22e/0x640
> >   [<ffffffffaeb15a3e>] ? run_timer_softirq+0x3e/0x280
> >   [<ffffffffaeabe13b>] __do_softirq+0xcb/0x250
> >   [<ffffffffaeabe4dc>] irq_exit+0x9c/0xb0
> >   [<ffffffffaea03e7a>] smp_apic_timer_interrupt+0x6a/0x80
> >   [<ffffffffaf0a394f>] apic_timer_interrupt+0x7f/0x90
> 
> it also can hit the following path
> 
> 	rcu_process_callbacks()
> 		__zswap_pool_release()
> 			zswap_pool_destroy()
> 				zswap_cpu_comp_destroy()
> 					cpu_notifier_register_begin()
> 						mutex_lock(&cpu_add_remove_lock);  <<<
> 
> can't it?
> 
> 	-ss

Thanks, Sergey. Now I'm convinced the problem should be fixed in
zswap. Since the rcu callback is already executed asynchronously,
using workqueue to defer the callback further more doesn't seem
to cause additional race condition at least.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2016-03-31 21:47 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-29 22:02 [PATCH] zsmalloc: use workqueue to destroy pool in zpool callback Yu Zhao
2016-03-30  0:54 ` Sergey Senozhatsky
     [not found] ` <20160329235950.GA19927@bbox>
2016-03-31  8:46   ` Sergey Senozhatsky
2016-03-31 21:46     ` Yu Zhao [this message]
2016-03-31 22:05       ` Dan Streetman
2016-04-25 21:20         ` [PATCH] mm/zpool: use workqueue for zpool_destroy Dan Streetman
2016-04-25 21:46           ` Andrew Morton
2016-04-25 22:18           ` Yu Zhao
2016-04-26  0:59             ` Sergey Senozhatsky
2016-04-26 11:07             ` Dan Streetman
2016-04-26 21:08           ` [PATCH] mm/zswap: use workqueue to destroy pool Dan Streetman
2016-04-27  0:58             ` Sergey Senozhatsky
2016-04-27 17:19               ` Dan Streetman
2016-04-28  1:40                 ` Sergey Senozhatsky
2016-04-28  4:09                   ` Sergey Senozhatsky
2016-04-28  8:21                   ` Dan Streetman
2016-04-28  9:13                 ` [PATCH] mm/zswap: provide unique zpool name Dan Streetman
2016-04-28 22:16                   ` Andrew Morton
2016-04-29  0:25                   ` Sergey Senozhatsky
2016-04-29  0:25             ` [PATCH] mm/zswap: use workqueue to destroy pool Sergey Senozhatsky

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=20160331214645.GA31294@google.com \
    --to=yuzhao@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=ddstreet@ieee.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=minchan@kernel.org \
    --cc=ngupta@vflare.org \
    --cc=sergey.senozhatsky.work@gmail.com \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=sjenning@redhat.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).