xfs
[Top] [All Lists]

Re: [RFC]xfs: using GFP_NOFS for blkdev_issue_flush

To: xfs@xxxxxxxxxxx
Subject: Re: [RFC]xfs: using GFP_NOFS for blkdev_issue_flush
From: Shaohua Li <shli@xxxxxxxxxx>
Date: Mon, 16 Apr 2012 14:58:21 +0800
Cc: david@xxxxxxxxxxxxx, hch@xxxxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=UoVdypDBjuvPcwhOyXKNXoekoxqPiVkAHaLQ+SItiTc=; b=X7qunVdAD0fJ4NqOfsTsw1sYLYj0Yi3LKPzmsc0dbCnkqOi95tx7zc6tMgr1RtQCuI xuxvbmdIBx9u6iOfPnR0ryXeoSfb4aIKJYuSLZF+JU0JVG9hzlKyAEHP/0c9VhNbv5XP yZ1KklNRO3tNHZUkQ80nNvM74TvdbBU663TYq0qSELo6GeSmYsMEoMCtWcH5sMKc9yOx UhwB+gehPQx9SxIGWu3OSQPgU88BMMI3O6tdY4Wwy6V4Gz2zbBC8yIjvijkZUPSEd9G/ yOMTkVThqLVlzPwXsejMRZ5EpZHU0wpT2e5vExgNAzlMeKsBuqRXxYMS99nYms/Ls+wu mjKA==
In-reply-to: <4F8BC112.9090508@xxxxxxxxxxxx>
References: <4F8BC112.9090508@xxxxxxxxxxxx>
Sender: Shaohua Li <shlikernel@xxxxxxxxx>
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
On 4/16/12 2:49 PM, Shaohua Li wrote:

flush request is issued in transaction commit code path usually, so
looks using
GFP_KERNEL to allocate memory for flush request bio falls into the classic
deadlock issue (memory reclaim recursion). Use GFP_NOFS to avoid recursion
from reclaim context. Per Dave Chinner, there is only blkdev_issue_flush
might
be buggy here. But using GFP_NOFS by default for all calls should not
matter.

Signed-off-by: Shaohua Li <shli@xxxxxxxxxxxx>
---
fs/xfs/xfs_super.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux/fs/xfs/xfs_super.c
===================================================================
--- linux.orig/fs/xfs/xfs_super.c 2012-04-13 10:08:26.095496072 +0800
+++ linux/fs/xfs/xfs_super.c 2012-04-13 10:08:42.555496865 +0800
@@ -622,7 +622,7 @@ void
xfs_blkdev_issue_flush(
xfs_buftarg_t *buftarg)
{
- blkdev_issue_flush(buftarg->bt_bdev, GFP_KERNEL, NULL);
+ blkdev_issue_flush(buftarg->bt_bdev, GFP_NOFS, NULL);
}

STATIC void

Oops, I apologize for the html mail, it slipped to wrong imap server. below one has correct format.

flush request is issued in transaction commit code path usually, so looks using
GFP_KERNEL to allocate memory for flush request bio falls into the classic
deadlock issue (memory reclaim recursion). Use GFP_NOFS to avoid recursion
from reclaim context. Per Dave Chinner, there is only blkdev_issue_flush might be buggy here. But using GFP_NOFS by default for all calls should not matter.

Signed-off-by: Shaohua Li <shli@xxxxxxxxxxxx>
---
 fs/xfs/xfs_super.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux/fs/xfs/xfs_super.c
===================================================================
--- linux.orig/fs/xfs/xfs_super.c       2012-04-13 10:08:26.095496072 +0800
+++ linux/fs/xfs/xfs_super.c    2012-04-13 10:08:42.555496865 +0800
@@ -622,7 +622,7 @@ void
 xfs_blkdev_issue_flush(
        xfs_buftarg_t           *buftarg)
 {
-       blkdev_issue_flush(buftarg->bt_bdev, GFP_KERNEL, NULL);
+       blkdev_issue_flush(buftarg->bt_bdev, GFP_NOFS, NULL);
 }

 STATIC void

<Prev in Thread] Current Thread [Next in Thread>