* [RFC]xfs: using GFP_NOFS for blkdev_issue_flush
@ 2012-04-16 6:49 Shaohua Li
2012-04-16 6:58 ` Shaohua Li
0 siblings, 1 reply; 6+ messages in thread
From: Shaohua Li @ 2012-04-16 6:49 UTC (permalink / raw)
To: xfs; +Cc: hch
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@fusionio.com>
---
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.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC]xfs: using GFP_NOFS for blkdev_issue_flush
2012-04-16 6:49 [RFC]xfs: using GFP_NOFS for blkdev_issue_flush Shaohua Li
@ 2012-04-16 6:58 ` Shaohua Li
2012-04-17 18:42 ` Mark Tinguely
2012-04-18 1:37 ` Dave Chinner
0 siblings, 2 replies; 6+ messages in thread
From: Shaohua Li @ 2012-04-16 6:58 UTC (permalink / raw)
To: xfs; +Cc: hch
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@fusionio.com>
> ---
> 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@fusionio.com>
---
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
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC]xfs: using GFP_NOFS for blkdev_issue_flush
2012-04-16 6:58 ` Shaohua Li
@ 2012-04-17 18:42 ` Mark Tinguely
2012-04-18 1:37 ` Dave Chinner
1 sibling, 0 replies; 6+ messages in thread
From: Mark Tinguely @ 2012-04-17 18:42 UTC (permalink / raw)
To: Shaohua Li; +Cc: xfs
On 04/16/12 01:58, 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@fusionio.com>
> ---
Looks good.
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC]xfs: using GFP_NOFS for blkdev_issue_flush
2012-04-16 6:58 ` Shaohua Li
2012-04-17 18:42 ` Mark Tinguely
@ 2012-04-18 1:37 ` Dave Chinner
2012-04-24 13:23 ` Shaohua Li
1 sibling, 1 reply; 6+ messages in thread
From: Dave Chinner @ 2012-04-18 1:37 UTC (permalink / raw)
To: Shaohua Li; +Cc: hch, xfs
On Mon, Apr 16, 2012 at 02:58:21PM +0800, Shaohua Li wrote:
> 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.
Can you update the commit message like I suggested previously?
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC]xfs: using GFP_NOFS for blkdev_issue_flush
2012-04-18 1:37 ` Dave Chinner
@ 2012-04-24 13:23 ` Shaohua Li
2012-04-25 0:25 ` Dave Chinner
0 siblings, 1 reply; 6+ messages in thread
From: Shaohua Li @ 2012-04-24 13:23 UTC (permalink / raw)
To: Dave Chinner; +Cc: hch, xfs
On Wed, Apr 18, 2012 at 11:37:46AM +1000, Dave Chinner wrote:
> On Mon, Apr 16, 2012 at 02:58:21PM +0800, Shaohua Li wrote:
> > 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.
>
> 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.
Signed-off-by: Shaohua Li <shli@fusionio.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
---
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
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC]xfs: using GFP_NOFS for blkdev_issue_flush
2012-04-24 13:23 ` Shaohua Li
@ 2012-04-25 0:25 ` Dave Chinner
0 siblings, 0 replies; 6+ messages in thread
From: Dave Chinner @ 2012-04-25 0:25 UTC (permalink / raw)
To: Shaohua Li; +Cc: hch, xfs
On Tue, Apr 24, 2012 at 09:23:46PM +0800, Shaohua Li wrote:
> On Wed, Apr 18, 2012 at 11:37:46AM +1000, Dave Chinner wrote:
> > On Mon, Apr 16, 2012 at 02:58:21PM +0800, Shaohua Li wrote:
> > > 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.
> >
> > 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.
>
> Signed-off-by: Shaohua Li <shli@fusionio.com>
> Reviewed-by: Mark Tinguely <tinguely@sgi.com>
> ---
> 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
Reviewed-by: Dave Chinner <dchinner@redhat.com>
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-04-25 0:25 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-04-16 6:49 [RFC]xfs: using GFP_NOFS for blkdev_issue_flush Shaohua Li
2012-04-16 6:58 ` Shaohua Li
2012-04-17 18:42 ` Mark Tinguely
2012-04-18 1:37 ` Dave Chinner
2012-04-24 13:23 ` Shaohua Li
2012-04-25 0:25 ` Dave Chinner
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.