xfs: using GFP_NOFS for blkdev_issue_flush
RFC 1/1 xfs: using GFP_NOFS for blkdev_issue_flush
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.
--- fs/xfs/xfs_super.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/xfs/xfs_super.c 2012-04-13 10:08:42.555496865 +0800 renamed from fs/xfs/xfs_super.c 2012-04-13 10:08:26.095496072 +0800 +1 -1
@@ -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.
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 27 lines · Shaohua Li
flush request is issued in transaction commit code path usually, so looks using
GFP_KERNELto allocate memory for flush request bio falls into the classic deadlock issue (memory reclaim recursion). UseGFP_NOFSto avoid recursion from reclaim context. Per Dave Chinner, there is onlyblkdev_issue_flushmight
be buggy here. But usingGFP_NOFSby default for all calls should not matter.Signed-off-by Shaohua Li <[email protected]>---
fs/xfs/xfs_super.c| 2 +-1 file changed, 1 insertion(+), 1 deletion(-)Index:
linux/fs/xfs/xfs_super.c
===================================================================fs/xfs/xfs_super.c 2012-04-13 10:08:42.555496865 +0800 renamed from fs/xfs/xfs_super.c 2012-04-13 10:08:26.095496072 +0800 +0
-0@@ -622,7 +622,7 @@ voidxfs_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); }
Quoted 2 lines
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.
--- fs/xfs/xfs_super.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/xfs/xfs_super.c +1 -1
@@ -622,7 +622,7 @@ voidxfs_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
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Mark Tinguely
Reviewed-byQuoted 11 lines · Shaohua Li
flush request is issued in transaction commit code path usually, so looks using
GFP_KERNELto allocate memory for flush request bio falls into the classic deadlock issue (memory reclaim recursion). UseGFP_NOFSto avoid recursion from reclaim context. Per Dave Chinner, there is onlyblkdev_issue_flushmight
be buggy here. But usingGFP_NOFSby default for all calls should not matter.Signed-off-by Shaohua Li <[email protected]>---
Looks good.
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 10 lines · Shaohua Li
Quoted 9 lines · Shaohua Li
flush request is issued in transaction commit code path usually, so looks using
GFP_KERNELto allocate memory for flush request bio falls into the classic deadlock issue (memory reclaim recursion). UseGFP_NOFSto avoid recursion from reclaim context. Per Dave Chinner, there is onlyblkdev_issue_flushmight
be buggy here. But usingGFP_NOFSby default for all calls should not matter.
Can you update the commit message like I suggested previously?
Cheers,
Dave.
Signature · 7 lines
Dave Chinner [email protected] _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Shaohua Li
Reviewed-by Mark TinguelyQuoted 12 lines · Dave Chinner
Quoted 10 lines · Shaohua Li
Quoted 9 lines · Shaohua Li
flush request is issued in transaction commit code path usually, so looks using
GFP_KERNELto allocate memory for flush request bio falls into the classic deadlock issue (memory reclaim recursion). UseGFP_NOFSto avoid recursion from reclaim context. Per Dave Chinner, there is onlyblkdev_issue_flushmight
be buggy here. But usingGFP_NOFSby default for all calls should not matter.
Quoted 1 line
Can you update the commit message like I suggested previously?
Copied exactly.
Issuing a block device flush request in transaction context using GFP_KERNEL directly can cause deadlocks due to memory reclaim recursion. Use GFP_NOFS to avoid recursion from reclaim context.
--- fs/xfs/xfs_super.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/xfs/xfs_super.c +1 -1
@@ -622,7 +622,7 @@ voidxfs_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
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Dave Chinner
Reviewed-byQuoted 32 lines · Shaohua Li
Quoted 12 lines · Dave Chinner
Quoted 10 lines · Shaohua Li
Quoted 9 lines · Shaohua Li
flush request is issued in transaction commit code path usually, so looks using
GFP_KERNELto allocate memory for flush request bio falls into the classic deadlock issue (memory reclaim recursion). UseGFP_NOFSto avoid recursion from reclaim context. Per Dave Chinner, there is onlyblkdev_issue_flushmight
be buggy here. But usingGFP_NOFSby default for all calls should not matter.Quoted 1 line
Can you update the commit message like I suggested previously?
Copied exactly.
Issuing a block device flush request in transaction context using
GFP_KERNELdirectly can cause deadlocks due to memory reclaim recursion. UseGFP_NOFSto avoid recursion from reclaim context.Signed-off-by Shaohua Li <[email protected]>Reviewed-by Mark Tinguely <[email protected]>--- fs/xfs/xfs_super.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)Index:
linux/fs/xfs/xfs_super.c
===================================================================
fs/xfs/xfs_super.c void · line 628
Quoted 8 lines
fs/xfs/xfs_super.c +1
-1@@ -622,7 +622,7 @@ voidxfs_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
Signature · 7 lines
Dave Chinner [email protected] _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs