All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] xfs: fix transaction allocation deadlock in IO path
@ 2018-03-05  4:11 Dave Chinner
  2018-03-05 14:40 ` Brian Foster
                   ` (3 more replies)
  0 siblings, 4 replies; 8+ messages in thread
From: Dave Chinner @ 2018-03-05  4:11 UTC (permalink / raw)
  To: linux-xfs

From: Dave Chinner <dchinner@redhat.com>

xfs_trans_alloc() does GFP_KERNEL allocation, and we can call it
while holding pages locked for writeback in the ->writepages path.
The memory allocation is allowed to wait on pages under writeback,
and so can wait on pages that are held locked in writeback by the
caller.

This affects both pre-IO submission and post-IO submission paths.
Hence xfs_setsize_trans_alloc(), xfs_reflink_end_cow(),
xfs_iomap_write_unwritten() and xfs_reflink_cancel_cow_range().
xfs_iomap_write_unwritten() already does the right thing, but the
others don't. Fix them.

Signed-Off-By: Dave Chinner <dchinner@redhat.com>
---
 fs/xfs/xfs_aops.c    | 3 ++-
 fs/xfs/xfs_reflink.c | 4 ++--
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/fs/xfs/xfs_aops.c b/fs/xfs/xfs_aops.c
index 9c6a830da0ee..a0afb6411417 100644
--- a/fs/xfs/xfs_aops.c
+++ b/fs/xfs/xfs_aops.c
@@ -209,7 +209,8 @@ xfs_setfilesize_trans_alloc(
 	struct xfs_trans	*tp;
 	int			error;
 
-	error = xfs_trans_alloc(mp, &M_RES(mp)->tr_fsyncts, 0, 0, 0, &tp);
+	error = xfs_trans_alloc(mp, &M_RES(mp)->tr_fsyncts, 0, 0,
+				XFS_TRANS_NOFS, &tp);
 	if (error)
 		return error;
 
diff --git a/fs/xfs/xfs_reflink.c b/fs/xfs/xfs_reflink.c
index 270246943a06..8c16177b33d4 100644
--- a/fs/xfs/xfs_reflink.c
+++ b/fs/xfs/xfs_reflink.c
@@ -668,7 +668,7 @@ xfs_reflink_cancel_cow_range(
 
 	/* Start a rolling transaction to remove the mappings */
 	error = xfs_trans_alloc(ip->i_mount, &M_RES(ip->i_mount)->tr_write,
-			0, 0, 0, &tp);
+			0, 0, XFS_TRANS_NOFS, &tp);
 	if (error)
 		goto out;
 
@@ -741,7 +741,7 @@ xfs_reflink_end_cow(
 			(unsigned int)(end_fsb - offset_fsb),
 			XFS_DATA_FORK);
 	error = xfs_trans_alloc(ip->i_mount, &M_RES(ip->i_mount)->tr_write,
-			resblks, 0, XFS_TRANS_RESERVE, &tp);
+			resblks, 0, XFS_TRANS_RESERVE | XFS_TRANS_NOFS, &tp);
 	if (error)
 		goto out;
 
-- 
2.16.1


^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH] xfs: fix transaction allocation deadlock in IO path
  2018-03-05  4:11 [PATCH] xfs: fix transaction allocation deadlock in IO path Dave Chinner
@ 2018-03-05 14:40 ` Brian Foster
  2018-03-05 21:38   ` Dave Chinner
  2018-03-05 17:44 ` Luis R. Rodriguez
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 8+ messages in thread
From: Brian Foster @ 2018-03-05 14:40 UTC (permalink / raw)
  To: Dave Chinner; +Cc: linux-xfs

On Mon, Mar 05, 2018 at 03:11:20PM +1100, Dave Chinner wrote:
> From: Dave Chinner <dchinner@redhat.com>
> 
> xfs_trans_alloc() does GFP_KERNEL allocation, and we can call it
> while holding pages locked for writeback in the ->writepages path.
> The memory allocation is allowed to wait on pages under writeback,
> and so can wait on pages that are held locked in writeback by the
> caller.
> 

It looks like xfs_start_page_writeback() sets the page as writeback and
unlocks it. I suspect this doesn't affect the actual problem if
allocation waits on writeback, but rather something like "tagged as
writeback" might be more clear than "held locked in writeback."
Otherwise this seems fine to me:

Reviewed-by: Brian Foster <bfoster@redhat.com>

> This affects both pre-IO submission and post-IO submission paths.
> Hence xfs_setsize_trans_alloc(), xfs_reflink_end_cow(),
> xfs_iomap_write_unwritten() and xfs_reflink_cancel_cow_range().
> xfs_iomap_write_unwritten() already does the right thing, but the
> others don't. Fix them.
> 
> Signed-Off-By: Dave Chinner <dchinner@redhat.com>
> ---
>  fs/xfs/xfs_aops.c    | 3 ++-
>  fs/xfs/xfs_reflink.c | 4 ++--
>  2 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/xfs/xfs_aops.c b/fs/xfs/xfs_aops.c
> index 9c6a830da0ee..a0afb6411417 100644
> --- a/fs/xfs/xfs_aops.c
> +++ b/fs/xfs/xfs_aops.c
> @@ -209,7 +209,8 @@ xfs_setfilesize_trans_alloc(
>  	struct xfs_trans	*tp;
>  	int			error;
>  
> -	error = xfs_trans_alloc(mp, &M_RES(mp)->tr_fsyncts, 0, 0, 0, &tp);
> +	error = xfs_trans_alloc(mp, &M_RES(mp)->tr_fsyncts, 0, 0,
> +				XFS_TRANS_NOFS, &tp);

Was there another reason we preallocate this transaction where we don't
seem to for others?

Brian

>  	if (error)
>  		return error;
>  
> diff --git a/fs/xfs/xfs_reflink.c b/fs/xfs/xfs_reflink.c
> index 270246943a06..8c16177b33d4 100644
> --- a/fs/xfs/xfs_reflink.c
> +++ b/fs/xfs/xfs_reflink.c
> @@ -668,7 +668,7 @@ xfs_reflink_cancel_cow_range(
>  
>  	/* Start a rolling transaction to remove the mappings */
>  	error = xfs_trans_alloc(ip->i_mount, &M_RES(ip->i_mount)->tr_write,
> -			0, 0, 0, &tp);
> +			0, 0, XFS_TRANS_NOFS, &tp);
>  	if (error)
>  		goto out;
>  
> @@ -741,7 +741,7 @@ xfs_reflink_end_cow(
>  			(unsigned int)(end_fsb - offset_fsb),
>  			XFS_DATA_FORK);
>  	error = xfs_trans_alloc(ip->i_mount, &M_RES(ip->i_mount)->tr_write,
> -			resblks, 0, XFS_TRANS_RESERVE, &tp);
> +			resblks, 0, XFS_TRANS_RESERVE | XFS_TRANS_NOFS, &tp);
>  	if (error)
>  		goto out;
>  
> -- 
> 2.16.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] xfs: fix transaction allocation deadlock in IO path
  2018-03-05  4:11 [PATCH] xfs: fix transaction allocation deadlock in IO path Dave Chinner
  2018-03-05 14:40 ` Brian Foster
@ 2018-03-05 17:44 ` Luis R. Rodriguez
  2018-03-05 21:32   ` Dave Chinner
  2018-03-06 16:53   ` Eric Sandeen
  2018-03-07 15:52 ` Eric Sandeen
  2018-03-08  8:08 ` Christoph Hellwig
  3 siblings, 2 replies; 8+ messages in thread
From: Luis R. Rodriguez @ 2018-03-05 17:44 UTC (permalink / raw)
  To: Dave Chinner; +Cc: linux-xfs

On Mon, Mar 05, 2018 at 03:11:20PM +1100, Dave Chinner wrote:
> From: Dave Chinner <dchinner@redhat.com>
> 
> xfs_trans_alloc() does GFP_KERNEL allocation, and we can call it
> while holding pages locked for writeback in the ->writepages path.
> The memory allocation is allowed to wait on pages under writeback,
> and so can wait on pages that are held locked in writeback by the
> caller.
> 
> This affects both pre-IO submission and post-IO submission paths.
> Hence xfs_setsize_trans_alloc(), xfs_reflink_end_cow(),
> xfs_iomap_write_unwritten() and xfs_reflink_cancel_cow_range().
> xfs_iomap_write_unwritten() already does the right thing, but the
> others don't. Fix them.
> 
> Signed-Off-By: Dave Chinner <dchinner@redhat.com>

I believe these are two separate regressions though, introduced on separate
kernels Can we treat them as such and use respective Fixes tag for them?

> ---
>  fs/xfs/xfs_aops.c    | 3 ++-
>  fs/xfs/xfs_reflink.c | 4 ++--
>  2 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/xfs/xfs_aops.c b/fs/xfs/xfs_aops.c
> index 9c6a830da0ee..a0afb6411417 100644
> --- a/fs/xfs/xfs_aops.c
> +++ b/fs/xfs/xfs_aops.c
> @@ -209,7 +209,8 @@ xfs_setfilesize_trans_alloc(
>  	struct xfs_trans	*tp;
>  	int			error;
>  
> -	error = xfs_trans_alloc(mp, &M_RES(mp)->tr_fsyncts, 0, 0, 0, &tp);
> +	error = xfs_trans_alloc(mp, &M_RES(mp)->tr_fsyncts, 0, 0,
> +				XFS_TRANS_NOFS, &tp);
>  	if (error)
>  		return error;
>  

Fixes: 253f4911f297b ("xfs: better xfs_trans_alloc interface")

Introduced on v4.7

> diff --git a/fs/xfs/xfs_reflink.c b/fs/xfs/xfs_reflink.c
> index 270246943a06..8c16177b33d4 100644
> --- a/fs/xfs/xfs_reflink.c
> +++ b/fs/xfs/xfs_reflink.c
> @@ -668,7 +668,7 @@ xfs_reflink_cancel_cow_range(
>  
>  	/* Start a rolling transaction to remove the mappings */
>  	error = xfs_trans_alloc(ip->i_mount, &M_RES(ip->i_mount)->tr_write,
> -			0, 0, 0, &tp);
> +			0, 0, XFS_TRANS_NOFS, &tp);
>  	if (error)
>  		goto out;
>  
> @@ -741,7 +741,7 @@ xfs_reflink_end_cow(
>  			(unsigned int)(end_fsb - offset_fsb),
>  			XFS_DATA_FORK);
>  	error = xfs_trans_alloc(ip->i_mount, &M_RES(ip->i_mount)->tr_write,
> -			resblks, 0, XFS_TRANS_RESERVE, &tp);
> +			resblks, 0, XFS_TRANS_RESERVE | XFS_TRANS_NOFS, &tp);
>  	if (error)
>  		goto out;

For both of the above:

Fixes: 43caeb187deb9 ("xfs: move mappings from cow fork to data fork after copy-write)"

Introduced on v4.9.

  Luis

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] xfs: fix transaction allocation deadlock in IO path
  2018-03-05 17:44 ` Luis R. Rodriguez
@ 2018-03-05 21:32   ` Dave Chinner
  2018-03-06 16:53   ` Eric Sandeen
  1 sibling, 0 replies; 8+ messages in thread
From: Dave Chinner @ 2018-03-05 21:32 UTC (permalink / raw)
  To: Luis R. Rodriguez; +Cc: linux-xfs

On Mon, Mar 05, 2018 at 05:44:55PM +0000, Luis R. Rodriguez wrote:
> On Mon, Mar 05, 2018 at 03:11:20PM +1100, Dave Chinner wrote:
> > From: Dave Chinner <dchinner@redhat.com>
> > 
> > xfs_trans_alloc() does GFP_KERNEL allocation, and we can call it
> > while holding pages locked for writeback in the ->writepages path.
> > The memory allocation is allowed to wait on pages under writeback,
> > and so can wait on pages that are held locked in writeback by the
> > caller.
> > 
> > This affects both pre-IO submission and post-IO submission paths.
> > Hence xfs_setsize_trans_alloc(), xfs_reflink_end_cow(),
> > xfs_iomap_write_unwritten() and xfs_reflink_cancel_cow_range().
> > xfs_iomap_write_unwritten() already does the right thing, but the
> > others don't. Fix them.
> > 
> > Signed-Off-By: Dave Chinner <dchinner@redhat.com>
> 
> I believe these are two separate regressions though, introduced on separate
> kernels Can we treat them as such and use respective Fixes tag for them?

Neither are regressions - they are effectively zero-day bugs. In
general, I don't use Fixes tags for things that are not regressions
and are easily discoverable from the published git history...

> 
> > ---
> >  fs/xfs/xfs_aops.c    | 3 ++-
> >  fs/xfs/xfs_reflink.c | 4 ++--
> >  2 files changed, 4 insertions(+), 3 deletions(-)
> > 
> > diff --git a/fs/xfs/xfs_aops.c b/fs/xfs/xfs_aops.c
> > index 9c6a830da0ee..a0afb6411417 100644
> > --- a/fs/xfs/xfs_aops.c
> > +++ b/fs/xfs/xfs_aops.c
> > @@ -209,7 +209,8 @@ xfs_setfilesize_trans_alloc(
> >  	struct xfs_trans	*tp;
> >  	int			error;
> >  
> > -	error = xfs_trans_alloc(mp, &M_RES(mp)->tr_fsyncts, 0, 0, 0, &tp);
> > +	error = xfs_trans_alloc(mp, &M_RES(mp)->tr_fsyncts, 0, 0,
> > +				XFS_TRANS_NOFS, &tp);
> >  	if (error)
> >  		return error;
> >  
> 
> Fixes: 253f4911f297b ("xfs: better xfs_trans_alloc interface")

No, thats wrong - that commit didn't change any behaviour. The
original commit:

281627df3eb5 ("xfs: log file size updates at I/O completion time")

called:

	tp = xfs_trans_alloc(mp, XFS_TRANS_FSYNC_TS);


which resulted in a GFP_KERNEL allocation via:

	tp = _xfs_trans_alloc(mp, type, KM_SLEEP);

So this is a zero-day bug in logging file size updates at IO
completion.

> Introduced on v4.7
> 
> > diff --git a/fs/xfs/xfs_reflink.c b/fs/xfs/xfs_reflink.c
> > index 270246943a06..8c16177b33d4 100644
> > --- a/fs/xfs/xfs_reflink.c
> > +++ b/fs/xfs/xfs_reflink.c
> > @@ -668,7 +668,7 @@ xfs_reflink_cancel_cow_range(
> >  
> >  	/* Start a rolling transaction to remove the mappings */
> >  	error = xfs_trans_alloc(ip->i_mount, &M_RES(ip->i_mount)->tr_write,
> > -			0, 0, 0, &tp);
> > +			0, 0, XFS_TRANS_NOFS, &tp);
> >  	if (error)
> >  		goto out;
> >  
> > @@ -741,7 +741,7 @@ xfs_reflink_end_cow(
> >  			(unsigned int)(end_fsb - offset_fsb),
> >  			XFS_DATA_FORK);
> >  	error = xfs_trans_alloc(ip->i_mount, &M_RES(ip->i_mount)->tr_write,
> > -			resblks, 0, XFS_TRANS_RESERVE, &tp);
> > +			resblks, 0, XFS_TRANS_RESERVE | XFS_TRANS_NOFS, &tp);
> >  	if (error)
> >  		goto out;
> 
> For both of the above:
> 
> Fixes: 43caeb187deb9 ("xfs: move mappings from cow fork to data fork after copy-write)"

And that's a zero-day, too. So neither are regressions.

-Dave.

-- 
Dave Chinner
david@fromorbit.com

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] xfs: fix transaction allocation deadlock in IO path
  2018-03-05 14:40 ` Brian Foster
@ 2018-03-05 21:38   ` Dave Chinner
  0 siblings, 0 replies; 8+ messages in thread
From: Dave Chinner @ 2018-03-05 21:38 UTC (permalink / raw)
  To: Brian Foster; +Cc: linux-xfs

On Mon, Mar 05, 2018 at 09:40:23AM -0500, Brian Foster wrote:
> On Mon, Mar 05, 2018 at 03:11:20PM +1100, Dave Chinner wrote:
> > From: Dave Chinner <dchinner@redhat.com>
> > 
> > xfs_trans_alloc() does GFP_KERNEL allocation, and we can call it
> > while holding pages locked for writeback in the ->writepages path.
> > The memory allocation is allowed to wait on pages under writeback,
> > and so can wait on pages that are held locked in writeback by the
> > caller.
> > 
> 
> It looks like xfs_start_page_writeback() sets the page as writeback and
> unlocks it. I suspect this doesn't affect the actual problem if
> allocation waits on writeback, but rather something like "tagged as
> writeback" might be more clear than "held locked in writeback."

Yeah, taht's what I meant.

> Otherwise this seems fine to me:
> 
> Reviewed-by: Brian Foster <bfoster@redhat.com>
> 
> > This affects both pre-IO submission and post-IO submission paths.
> > Hence xfs_setsize_trans_alloc(), xfs_reflink_end_cow(),
> > xfs_iomap_write_unwritten() and xfs_reflink_cancel_cow_range().
> > xfs_iomap_write_unwritten() already does the right thing, but the
> > others don't. Fix them.
> > 
> > Signed-Off-By: Dave Chinner <dchinner@redhat.com>
> > ---
> >  fs/xfs/xfs_aops.c    | 3 ++-
> >  fs/xfs/xfs_reflink.c | 4 ++--
> >  2 files changed, 4 insertions(+), 3 deletions(-)
> > 
> > diff --git a/fs/xfs/xfs_aops.c b/fs/xfs/xfs_aops.c
> > index 9c6a830da0ee..a0afb6411417 100644
> > --- a/fs/xfs/xfs_aops.c
> > +++ b/fs/xfs/xfs_aops.c
> > @@ -209,7 +209,8 @@ xfs_setfilesize_trans_alloc(
> >  	struct xfs_trans	*tp;
> >  	int			error;
> >  
> > -	error = xfs_trans_alloc(mp, &M_RES(mp)->tr_fsyncts, 0, 0, 0, &tp);
> > +	error = xfs_trans_alloc(mp, &M_RES(mp)->tr_fsyncts, 0, 0,
> > +				XFS_TRANS_NOFS, &tp);
> 
> Was there another reason we preallocate this transaction where we don't
> seem to for others?

Because it happens all the time for buffered IO and this prevents
stalling the completion workqueue for a simple size update.
Unwritten conversion and COW completion are less frequently done,
are much larger pieces of work, can require multiple transactions
and have many more potential blocking points, and so such an
optimisation is much less beneficial in those cases.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] xfs: fix transaction allocation deadlock in IO path
  2018-03-05 17:44 ` Luis R. Rodriguez
  2018-03-05 21:32   ` Dave Chinner
@ 2018-03-06 16:53   ` Eric Sandeen
  1 sibling, 0 replies; 8+ messages in thread
From: Eric Sandeen @ 2018-03-06 16:53 UTC (permalink / raw)
  To: Luis R. Rodriguez, Dave Chinner; +Cc: linux-xfs



On 3/5/18 11:44 AM, Luis R. Rodriguez wrote:
> On Mon, Mar 05, 2018 at 03:11:20PM +1100, Dave Chinner wrote:
>> From: Dave Chinner <dchinner@redhat.com>
>>
>> xfs_trans_alloc() does GFP_KERNEL allocation, and we can call it
>> while holding pages locked for writeback in the ->writepages path.
>> The memory allocation is allowed to wait on pages under writeback,
>> and so can wait on pages that are held locked in writeback by the
>> caller.
>>
>> This affects both pre-IO submission and post-IO submission paths.
>> Hence xfs_setsize_trans_alloc(), xfs_reflink_end_cow(),
>> xfs_iomap_write_unwritten() and xfs_reflink_cancel_cow_range().
>> xfs_iomap_write_unwritten() already does the right thing, but the
>> others don't. Fix them.
>>
>> Signed-Off-By: Dave Chinner <dchinner@redhat.com>
> 
> I believe these are two separate regressions though, introduced on separate
> kernels Can we treat them as such and use respective Fixes tag for them?
> 
>> ---
>>  fs/xfs/xfs_aops.c    | 3 ++-
>>  fs/xfs/xfs_reflink.c | 4 ++--
>>  2 files changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/fs/xfs/xfs_aops.c b/fs/xfs/xfs_aops.c
>> index 9c6a830da0ee..a0afb6411417 100644
>> --- a/fs/xfs/xfs_aops.c
>> +++ b/fs/xfs/xfs_aops.c
>> @@ -209,7 +209,8 @@ xfs_setfilesize_trans_alloc(
>>  	struct xfs_trans	*tp;
>>  	int			error;
>>  
>> -	error = xfs_trans_alloc(mp, &M_RES(mp)->tr_fsyncts, 0, 0, 0, &tp);
>> +	error = xfs_trans_alloc(mp, &M_RES(mp)->tr_fsyncts, 0, 0,
>> +				XFS_TRANS_NOFS, &tp);
>>  	if (error)
>>  		return error;
>>  
> 
> Fixes: 253f4911f297b ("xfs: better xfs_trans_alloc interface")
> 
> Introduced on v4.7

I don't think so - prior to that commit, this allocation could still
recurse into the filesystem, the only allocation flag used was KM_SLEEP,
AFAICT.
 
>> diff --git a/fs/xfs/xfs_reflink.c b/fs/xfs/xfs_reflink.c
>> index 270246943a06..8c16177b33d4 100644
>> --- a/fs/xfs/xfs_reflink.c
>> +++ b/fs/xfs/xfs_reflink.c
>> @@ -668,7 +668,7 @@ xfs_reflink_cancel_cow_range(
>>  
>>  	/* Start a rolling transaction to remove the mappings */
>>  	error = xfs_trans_alloc(ip->i_mount, &M_RES(ip->i_mount)->tr_write,
>> -			0, 0, 0, &tp);
>> +			0, 0, XFS_TRANS_NOFS, &tp);
>>  	if (error)
>>  		goto out;
>>  
>> @@ -741,7 +741,7 @@ xfs_reflink_end_cow(
>>  			(unsigned int)(end_fsb - offset_fsb),
>>  			XFS_DATA_FORK);
>>  	error = xfs_trans_alloc(ip->i_mount, &M_RES(ip->i_mount)->tr_write,
>> -			resblks, 0, XFS_TRANS_RESERVE, &tp);
>> +			resblks, 0, XFS_TRANS_RESERVE | XFS_TRANS_NOFS, &tp);
>>  	if (error)
>>  		goto out;
> 
> For both of the above:
> 
> Fixes: 43caeb187deb9 ("xfs: move mappings from cow fork to data fork after copy-write)"
> 
> Introduced on v4.9.

Perhaps, as that commit did add the new allocations which could recurse.

-Eric

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] xfs: fix transaction allocation deadlock in IO path
  2018-03-05  4:11 [PATCH] xfs: fix transaction allocation deadlock in IO path Dave Chinner
  2018-03-05 14:40 ` Brian Foster
  2018-03-05 17:44 ` Luis R. Rodriguez
@ 2018-03-07 15:52 ` Eric Sandeen
  2018-03-08  8:08 ` Christoph Hellwig
  3 siblings, 0 replies; 8+ messages in thread
From: Eric Sandeen @ 2018-03-07 15:52 UTC (permalink / raw)
  To: Dave Chinner, linux-xfs

On 3/4/18 10:11 PM, Dave Chinner wrote:
> From: Dave Chinner <dchinner@redhat.com>
> 
> xfs_trans_alloc() does GFP_KERNEL allocation, and we can call it
> while holding pages locked for writeback in the ->writepages path.
> The memory allocation is allowed to wait on pages under writeback,
> and so can wait on pages that are held locked in writeback by the
> caller.
> 
> This affects both pre-IO submission and post-IO submission paths.
> Hence xfs_setsize_trans_alloc(), xfs_reflink_end_cow(),
> xfs_iomap_write_unwritten() and xfs_reflink_cancel_cow_range().
> xfs_iomap_write_unwritten() already does the right thing, but the
> others don't. Fix them.
> 
> Signed-Off-By: Dave Chinner <dchinner@redhat.com>

Reviewed-by: Eric Sandeen <sandeen@redhat.com>


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] xfs: fix transaction allocation deadlock in IO path
  2018-03-05  4:11 [PATCH] xfs: fix transaction allocation deadlock in IO path Dave Chinner
                   ` (2 preceding siblings ...)
  2018-03-07 15:52 ` Eric Sandeen
@ 2018-03-08  8:08 ` Christoph Hellwig
  3 siblings, 0 replies; 8+ messages in thread
From: Christoph Hellwig @ 2018-03-08  8:08 UTC (permalink / raw)
  To: Dave Chinner; +Cc: linux-xfs

Looks fine,

Reviewed-by: Christoph Hellwig <hch@lst.de>

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2018-03-08  8:08 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-03-05  4:11 [PATCH] xfs: fix transaction allocation deadlock in IO path Dave Chinner
2018-03-05 14:40 ` Brian Foster
2018-03-05 21:38   ` Dave Chinner
2018-03-05 17:44 ` Luis R. Rodriguez
2018-03-05 21:32   ` Dave Chinner
2018-03-06 16:53   ` Eric Sandeen
2018-03-07 15:52 ` Eric Sandeen
2018-03-08  8:08 ` Christoph Hellwig

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.