| Message ID | 20180730164520.36882-2-bfoster@redhat.com (mailing list archive) |
|---|---|
| State | Accepted, archived |
| Headers | show |
| Series | xfs: condense dfops and automatic relogging | expand |
On Mon, Jul 30, 2018 at 12:45:06PM -0400, Brian Foster wrote: > The current transaction allocation code conditionally initializes > the ->t_dfops indirection pointer. Transaction commit/cancel check > the validity of the pointer to determine whether to finish/cancel > the internal dfops. > > This disallows the ability to use the internal dfops list as a > temporary container (via xfs_trans_alloc_empty()). Refactor > transaction allocation to always initialize ->t_dfops and check > permanent reservation state on transaction commit/cancel. > > Signed-off-by: Brian Foster <bfoster@redhat.com> > --- > fs/xfs/xfs_trans.c | 12 +++--------- > 1 file changed, 3 insertions(+), 9 deletions(-) > > diff --git a/fs/xfs/xfs_trans.c b/fs/xfs/xfs_trans.c > index 7bf5c1202719..8d3b7f28b193 100644 > --- a/fs/xfs/xfs_trans.c > +++ b/fs/xfs/xfs_trans.c > @@ -281,13 +281,7 @@ xfs_trans_alloc( > INIT_LIST_HEAD(&tp->t_items); > INIT_LIST_HEAD(&tp->t_busy); > tp->t_firstblock = NULLFSBLOCK; > - /* > - * We only roll transactions with permanent log reservation. Don't init > - * ->t_dfops to skip attempts to finish or cancel an empty dfops with a > - * non-permanent res. > - */ > - if (resp->tr_logflags & XFS_TRANS_PERM_LOG_RES) > - xfs_defer_init(tp, &tp->t_dfops_internal); > + xfs_defer_init(tp, &tp->t_dfops_internal); > > error = xfs_trans_reserve(tp, resp, blocks, rtextents); > if (error) { > @@ -932,7 +926,7 @@ __xfs_trans_commit( > trace_xfs_trans_commit(tp, _RET_IP_); > > /* finish deferred items on final commit */ > - if (!regrant && tp->t_dfops) { > + if (!regrant && (tp->t_flags & XFS_TRANS_PERM_LOG_RES)) { The usage model of deferred ops is that one has to create a transaction with a permanent reservation, and only then start attaching deferred ops to the dfops inside the transaction. It's a programming error if a caller tries to finish deferred ops using a non-permanent transaction, and prior to this patch t_dfops would be NULL and we'd blow up immediately in xfs_defer_add(..., tp->t_dfops, ...); However, now that we initialize t_dfops unconditionally, won't this cause the above programming mistake to leak silently any incorrectly queued defer ops? --D > error = xfs_defer_finish_noroll(&tp); > if (error) { > xfs_defer_cancel(tp); > @@ -1029,7 +1023,7 @@ xfs_trans_cancel( > > trace_xfs_trans_cancel(tp, _RET_IP_); > > - if (tp->t_dfops) > + if (tp->t_flags & XFS_TRANS_PERM_LOG_RES) > xfs_defer_cancel(tp); > > /* > -- > 2.17.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 -- 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
On Mon, Jul 30, 2018 at 12:30:48PM -0700, Darrick J. Wong wrote: > > trace_xfs_trans_commit(tp, _RET_IP_); > > > > /* finish deferred items on final commit */ > > - if (!regrant && tp->t_dfops) { > > + if (!regrant && (tp->t_flags & XFS_TRANS_PERM_LOG_RES)) { > > The usage model of deferred ops is that one has to create a transaction > with a permanent reservation, and only then start attaching deferred ops > to the dfops inside the transaction. It's a programming error if a > caller tries to finish deferred ops using a non-permanent transaction, > and prior to this patch t_dfops would be NULL and we'd blow up > immediately in xfs_defer_add(..., tp->t_dfops, ...); > > However, now that we initialize t_dfops unconditionally, won't this > cause the above programming mistake to leak silently any incorrectly > queued defer ops? I guess we'll just need an assert for a perment reservation in xfs_defer_add, although that'll have to wait for the patch that actually passes a transaction to it. Except for that this patch looks fine to me: Reviewed-by: Christoph Hellwig <hch@lst.de> -- 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
On Mon, Jul 30, 2018 at 12:30:48PM -0700, Darrick J. Wong wrote: > On Mon, Jul 30, 2018 at 12:45:06PM -0400, Brian Foster wrote: > > The current transaction allocation code conditionally initializes > > the ->t_dfops indirection pointer. Transaction commit/cancel check > > the validity of the pointer to determine whether to finish/cancel > > the internal dfops. > > > > This disallows the ability to use the internal dfops list as a > > temporary container (via xfs_trans_alloc_empty()). Refactor > > transaction allocation to always initialize ->t_dfops and check > > permanent reservation state on transaction commit/cancel. > > > > Signed-off-by: Brian Foster <bfoster@redhat.com> > > --- > > fs/xfs/xfs_trans.c | 12 +++--------- > > 1 file changed, 3 insertions(+), 9 deletions(-) > > > > diff --git a/fs/xfs/xfs_trans.c b/fs/xfs/xfs_trans.c > > index 7bf5c1202719..8d3b7f28b193 100644 > > --- a/fs/xfs/xfs_trans.c > > +++ b/fs/xfs/xfs_trans.c > > @@ -281,13 +281,7 @@ xfs_trans_alloc( > > INIT_LIST_HEAD(&tp->t_items); > > INIT_LIST_HEAD(&tp->t_busy); > > tp->t_firstblock = NULLFSBLOCK; > > - /* > > - * We only roll transactions with permanent log reservation. Don't init > > - * ->t_dfops to skip attempts to finish or cancel an empty dfops with a > > - * non-permanent res. > > - */ > > - if (resp->tr_logflags & XFS_TRANS_PERM_LOG_RES) > > - xfs_defer_init(tp, &tp->t_dfops_internal); > > + xfs_defer_init(tp, &tp->t_dfops_internal); > > > > error = xfs_trans_reserve(tp, resp, blocks, rtextents); > > if (error) { > > @@ -932,7 +926,7 @@ __xfs_trans_commit( > > trace_xfs_trans_commit(tp, _RET_IP_); > > > > /* finish deferred items on final commit */ > > - if (!regrant && tp->t_dfops) { > > + if (!regrant && (tp->t_flags & XFS_TRANS_PERM_LOG_RES)) { > > The usage model of deferred ops is that one has to create a transaction > with a permanent reservation, and only then start attaching deferred ops > to the dfops inside the transaction. It's a programming error if a > caller tries to finish deferred ops using a non-permanent transaction, > and prior to this patch t_dfops would be NULL and we'd blow up > immediately in xfs_defer_add(..., tp->t_dfops, ...); > > However, now that we initialize t_dfops unconditionally, won't this > cause the above programming mistake to leak silently any incorrectly > queued defer ops? > Yeah, I'm not sure the previous behavior was really appropriate in that regard either. I'll add the xfs_defer_add() assert suggested by Christoph. We could also add a WARN_ON_ONCE() or something in the commit path to make sure we never see a !perm transaction with dfops, if you think that's useful..? Brian > --D > > > error = xfs_defer_finish_noroll(&tp); > > if (error) { > > xfs_defer_cancel(tp); > > @@ -1029,7 +1023,7 @@ xfs_trans_cancel( > > > > trace_xfs_trans_cancel(tp, _RET_IP_); > > > > - if (tp->t_dfops) > > + if (tp->t_flags & XFS_TRANS_PERM_LOG_RES) > > xfs_defer_cancel(tp); > > > > /* > > -- > > 2.17.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 > -- > 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 -- 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
On Tue, Jul 31, 2018 at 07:47:36AM -0400, Brian Foster wrote: > On Mon, Jul 30, 2018 at 12:30:48PM -0700, Darrick J. Wong wrote: > > On Mon, Jul 30, 2018 at 12:45:06PM -0400, Brian Foster wrote: > > > The current transaction allocation code conditionally initializes > > > the ->t_dfops indirection pointer. Transaction commit/cancel check > > > the validity of the pointer to determine whether to finish/cancel > > > the internal dfops. > > > > > > This disallows the ability to use the internal dfops list as a > > > temporary container (via xfs_trans_alloc_empty()). Refactor > > > transaction allocation to always initialize ->t_dfops and check > > > permanent reservation state on transaction commit/cancel. > > > > > > Signed-off-by: Brian Foster <bfoster@redhat.com> > > > --- > > > fs/xfs/xfs_trans.c | 12 +++--------- > > > 1 file changed, 3 insertions(+), 9 deletions(-) > > > > > > diff --git a/fs/xfs/xfs_trans.c b/fs/xfs/xfs_trans.c > > > index 7bf5c1202719..8d3b7f28b193 100644 > > > --- a/fs/xfs/xfs_trans.c > > > +++ b/fs/xfs/xfs_trans.c > > > @@ -281,13 +281,7 @@ xfs_trans_alloc( > > > INIT_LIST_HEAD(&tp->t_items); > > > INIT_LIST_HEAD(&tp->t_busy); > > > tp->t_firstblock = NULLFSBLOCK; > > > - /* > > > - * We only roll transactions with permanent log reservation. Don't init > > > - * ->t_dfops to skip attempts to finish or cancel an empty dfops with a > > > - * non-permanent res. > > > - */ > > > - if (resp->tr_logflags & XFS_TRANS_PERM_LOG_RES) > > > - xfs_defer_init(tp, &tp->t_dfops_internal); > > > + xfs_defer_init(tp, &tp->t_dfops_internal); > > > > > > error = xfs_trans_reserve(tp, resp, blocks, rtextents); > > > if (error) { > > > @@ -932,7 +926,7 @@ __xfs_trans_commit( > > > trace_xfs_trans_commit(tp, _RET_IP_); > > > > > > /* finish deferred items on final commit */ > > > - if (!regrant && tp->t_dfops) { > > > + if (!regrant && (tp->t_flags & XFS_TRANS_PERM_LOG_RES)) { > > > > The usage model of deferred ops is that one has to create a transaction > > with a permanent reservation, and only then start attaching deferred ops > > to the dfops inside the transaction. It's a programming error if a > > caller tries to finish deferred ops using a non-permanent transaction, > > and prior to this patch t_dfops would be NULL and we'd blow up > > immediately in xfs_defer_add(..., tp->t_dfops, ...); > > > > However, now that we initialize t_dfops unconditionally, won't this > > cause the above programming mistake to leak silently any incorrectly > > queued defer ops? > > > > Yeah, I'm not sure the previous behavior was really appropriate in that > regard either. I'll add the xfs_defer_add() assert suggested by > Christoph. We could also add a WARN_ON_ONCE() or something in the commit > path to make sure we never see a !perm transaction with dfops, if you > think that's useful..? Yes -- some sort of warning that will help us catch programming mistakes even if !DEBUG. :) --D > Brian > > > --D > > > > > error = xfs_defer_finish_noroll(&tp); > > > if (error) { > > > xfs_defer_cancel(tp); > > > @@ -1029,7 +1023,7 @@ xfs_trans_cancel( > > > > > > trace_xfs_trans_cancel(tp, _RET_IP_); > > > > > > - if (tp->t_dfops) > > > + if (tp->t_flags & XFS_TRANS_PERM_LOG_RES) > > > xfs_defer_cancel(tp); > > > > > > /* > > > -- > > > 2.17.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 > > -- > > 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 > -- > 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 -- 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
diff --git a/fs/xfs/xfs_trans.c b/fs/xfs/xfs_trans.c index 7bf5c1202719..8d3b7f28b193 100644 --- a/fs/xfs/xfs_trans.c +++ b/fs/xfs/xfs_trans.c @@ -281,13 +281,7 @@ xfs_trans_alloc( INIT_LIST_HEAD(&tp->t_items); INIT_LIST_HEAD(&tp->t_busy); tp->t_firstblock = NULLFSBLOCK; - /* - * We only roll transactions with permanent log reservation. Don't init - * ->t_dfops to skip attempts to finish or cancel an empty dfops with a - * non-permanent res. - */ - if (resp->tr_logflags & XFS_TRANS_PERM_LOG_RES) - xfs_defer_init(tp, &tp->t_dfops_internal); + xfs_defer_init(tp, &tp->t_dfops_internal); error = xfs_trans_reserve(tp, resp, blocks, rtextents); if (error) { @@ -932,7 +926,7 @@ __xfs_trans_commit( trace_xfs_trans_commit(tp, _RET_IP_); /* finish deferred items on final commit */ - if (!regrant && tp->t_dfops) { + if (!regrant && (tp->t_flags & XFS_TRANS_PERM_LOG_RES)) { error = xfs_defer_finish_noroll(&tp); if (error) { xfs_defer_cancel(tp); @@ -1029,7 +1023,7 @@ xfs_trans_cancel( trace_xfs_trans_cancel(tp, _RET_IP_); - if (tp->t_dfops) + if (tp->t_flags & XFS_TRANS_PERM_LOG_RES) xfs_defer_cancel(tp); /*
The current transaction allocation code conditionally initializes the ->t_dfops indirection pointer. Transaction commit/cancel check the validity of the pointer to determine whether to finish/cancel the internal dfops. This disallows the ability to use the internal dfops list as a temporary container (via xfs_trans_alloc_empty()). Refactor transaction allocation to always initialize ->t_dfops and check permanent reservation state on transaction commit/cancel. Signed-off-by: Brian Foster <bfoster@redhat.com> --- fs/xfs/xfs_trans.c | 12 +++--------- 1 file changed, 3 insertions(+), 9 deletions(-)