xfs
[Top] [All Lists]

[RFC]xfs: using GFP_NOFS for blkdev_issue_flush

To: <xfs@xxxxxxxxxxx>
Subject: [RFC]xfs: using GFP_NOFS for blkdev_issue_flush
From: Shaohua Li <shli@xxxxxxxxxxxx>
Date: Mon, 16 Apr 2012 14:49:54 +0800
Cc: <david@xxxxxxxxxxxxx>, <hch@xxxxxxxxxxxxx>
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1

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


This e-mail message, its contents and any attachments to it are confidential to 
the intended recipient, and may contain information that is privileged and/or 
exempt from disclosure under applicable law. If you are not the intended 
recipient, please immediately notify the sender and destroy the original e-mail 
message and any attachments (and any copies that may have been made) from your 
system or otherwise. Any unauthorized use, copying, disclosure or distribution 
of this information is strictly prohibited.  Email addresses that end with a 
?-c? identify the sender as a Fusion-io contractor.

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