From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1756592Ab3AYPJ0 (ORCPT <rfc822;w@1wt.eu>);
	Fri, 25 Jan 2013 10:09:26 -0500
Received: from e34.co.us.ibm.com ([32.97.110.152]:45764 "EHLO
	e34.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1755439Ab3AYPJY (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 25 Jan 2013 10:09:24 -0500
Message-ID: <51029FC3.4060402@linux.vnet.ibm.com>
Date: Fri, 25 Jan 2013 09:07:47 -0600
From: Seth Jennings <sjenning@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Minchan Kim <minchan@kernel.org>
CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Nitin Gupta <ngupta@vflare.org>,
        Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
        Dan Magenheimer <dan.magenheimer@oracle.com>,
        Robert Jennings <rcj@linux.vnet.ibm.com>,
        Jenifer Hopper <jhopper@us.ibm.com>, Mel Gorman <mgorman@suse.de>,
        Johannes Weiner <jweiner@redhat.com>, Rik van Riel <riel@redhat.com>,
        Larry Woodman <lwoodman@redhat.com>, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org, devel@driverdev.osuosl.org
Subject: Re: [PATCHv2 1/9] staging: zsmalloc: add gfp flags to zs_create_pool
References: <1357590280-31535-1-git-send-email-sjenning@linux.vnet.ibm.com> <1357590280-31535-2-git-send-email-sjenning@linux.vnet.ibm.com> <CAEwNFnDWpyvmN-fU=MczXKtcay6vMMCOOHUM2M09+wx7zOVxDQ@mail.gmail.com>
In-Reply-To: <CAEwNFnDWpyvmN-fU=MczXKtcay6vMMCOOHUM2M09+wx7zOVxDQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 13012515-2876-0000-0000-000004825619
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 01/24/2013 07:33 PM, Minchan Kim wrote:
> Hi Seth, frontswap guys
> 
> On Tue, Jan 8, 2013 at 5:24 AM, Seth Jennings
> <sjenning@linux.vnet.ibm.com> wrote:
>> zs_create_pool() currently takes a gfp flags argument
>> that is used when growing the memory pool.  However
>> it is not used in allocating the metadata for the pool
>> itself.  That is currently hardcoded to GFP_KERNEL.
>>
>> zswap calls zs_create_pool() at swapon time which is done
>> in atomic context, resulting in a "might sleep" warning.
> 
> I didn't review this all series, really sorry but totday I saw Nitin
> added Acked-by so I'm afraid Greg might get it under my radar. I'm not
> strong against but I would like know why we should call frontswap_init
> under swap_lock? Is there special reason?

The call stack is:

SYSCALL_DEFINE2(swapon.. <-- swapon_mutex taken here
enable_swap_info() <-- swap_lock taken here
frontswap_init()
__frontswap_init()
zswap_frontswap_init()
zs_create_pool()

It isn't entirely clear to me why frontswap_init() is called under
lock.  Then again, I'm not entirely sure what the swap_lock protects.
 There are no comments near the swap_lock definition to tell me.

I would guess that the intent is to block any writes to the swap
device until frontswap_init() has completed.

Dan care to weigh in?

Seth