Re: [PATCH 2/7] xfs: allow attach of dfops to transaction

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> diff --git a/fs/xfs/libxfs/xfs_defer.c b/fs/xfs/libxfs/xfs_defer.c
> index 087fea02c389..f3aef54257d1 100644
> --- a/fs/xfs/libxfs/xfs_defer.c
> +++ b/fs/xfs/libxfs/xfs_defer.c
> @@ -525,6 +525,7 @@ xfs_defer_init_op_type(
>  /* Initialize a deferred operation. */
>  void
>  xfs_defer_init(
> +	struct xfs_trans		*tp,
>  	struct xfs_defer_ops		*dop,
>  	xfs_fsblock_t			*fbp)
>  {
> @@ -532,5 +533,7 @@ xfs_defer_init(
>  	*fbp = NULLFSBLOCK;
>  	INIT_LIST_HEAD(&dop->dop_intake);
>  	INIT_LIST_HEAD(&dop->dop_pending);
> -	trace_xfs_defer_init(NULL, dop);
> +	if (tp)
> +		tp->t_dfops = dop;
> +	trace_xfs_defer_init(tp ? tp->t_mountp : NULL, dop);

there is really no oint un doing this massive change of prototypes
everywhere just to move an assignment into xfs_defer_init.  Just keep
that assignment in the caller.


But in general I'm really concerned about making the dops in the
transaction conditional behavior.  This is just going down the rathole
of inconsistent behavior where some callers expect it in the transaction
vs other explcitit and every time something really to defered ops is
touched it will need a deep code audit.  I'd rather switch everything
over in a go and be done with it.
--
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



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux