From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw0-f175.google.com (mail-yw0-f175.google.com [209.85.161.175]) by kanga.kvack.org (Postfix) with ESMTP id C2CBA6B007E for ; Thu, 31 Mar 2016 18:06:15 -0400 (EDT) Received: by mail-yw0-f175.google.com with SMTP id h129so116713487ywb.1 for ; Thu, 31 Mar 2016 15:06:15 -0700 (PDT) Received: from mail-yw0-x242.google.com (mail-yw0-x242.google.com. [2607:f8b0:4002:c05::242]) by mx.google.com with ESMTPS id a128si2117600ywc.156.2016.03.31.15.06.15 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 Mar 2016 15:06:15 -0700 (PDT) Received: by mail-yw0-x242.google.com with SMTP id f6so13744003ywa.1 for ; Thu, 31 Mar 2016 15:06:15 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20160331214645.GA31294@google.com> References: <1459288977-25562-1-git-send-email-yuzhao@google.com> <20160329235950.GA19927@bbox> <20160331084639.GB3343@swordfish> <20160331214645.GA31294@google.com> From: Dan Streetman Date: Thu, 31 Mar 2016 18:05:35 -0400 Message-ID: Subject: Re: [PATCH] zsmalloc: use workqueue to destroy pool in zpool callback Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: Yu Zhao Cc: Sergey Senozhatsky , Minchan Kim , Nitin Gupta , Linux-MM , Seth Jennings , Sergey Senozhatsky , Andrew Morton , linux-kernel On Thu, Mar 31, 2016 at 5:46 PM, Yu Zhao wrote: > 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 >> >> > [] mutex_lock+0x1b/0x2f >> > [] kmem_cache_destroy+0x50/0x130 >> > [] zs_destroy_pool+0x85/0xe0 >> > [] zs_zpool_destroy+0xe/0x10 >> > [] zpool_destroy_pool+0x54/0x70 >> > [] __zswap_pool_release+0x62/0x90 >> > [] rcu_process_callbacks+0x22e/0x640 >> > [] ? run_timer_softirq+0x3e/0x280 >> > [] __do_softirq+0xcb/0x250 >> > [] irq_exit+0x9c/0xb0 >> > [] smp_apic_timer_interrupt+0x6a/0x80 >> > [] 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. certainly seems appropriate to fix it in zswap, I'll work on a patch unless Seth or anyone else is already working on it. -- 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: email@kvack.org