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@xxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
