@@ -21,6 +21,16 @@ struct xfs_log_vec {
#define XFS_LOG_VEC_ORDERED (-1)
+/*
+ * We need to make sure the buffer pointer returned is naturally aligned for the
+ * biggest basic data type we put into it. We have already accounted for this
+ * padding when sizing the buffer.
+ *
+ * However, this padding does not get written into the log, and hence we have to
+ * track the space used by the log vectors separately to prevent log space hangs
+ * due to inaccurate accounting (i.e. a leak) of the used log space through the
+ * CIL context ticket.
+ */
static inline void *
xlog_prepare_iovec(struct xfs_log_vec *lv, struct xfs_log_iovec **vecp,
uint type)
@@ -34,6 +44,9 @@ xlog_prepare_iovec(struct xfs_log_vec *lv, struct xfs_log_iovec **vecp,
vec = &lv->lv_iovecp[0];
}
+ if (!IS_ALIGNED(lv->lv_buf_len, sizeof(uint64_t)))
+ lv->lv_buf_len = round_up(lv->lv_buf_len, sizeof(uint64_t));
+
vec->i_type = type;
vec->i_addr = lv->lv_buf + lv->lv_buf_len;
@@ -43,20 +56,10 @@ xlog_prepare_iovec(struct xfs_log_vec *lv, struct xfs_log_iovec **vecp,
return vec->i_addr;
}
-/*
- * We need to make sure the next buffer is naturally aligned for the biggest
- * basic data type we put into it. We already accounted for this padding when
- * sizing the buffer.
- *
- * However, this padding does not get written into the log, and hence we have to
- * track the space used by the log vectors separately to prevent log space hangs
- * due to inaccurate accounting (i.e. a leak) of the used log space through the
- * CIL context ticket.
- */
static inline void
xlog_finish_iovec(struct xfs_log_vec *lv, struct xfs_log_iovec *vec, int len)
{
- lv->lv_buf_len += round_up(len, sizeof(uint64_t));
+ lv->lv_buf_len += len;
lv->lv_bytes += len;
vec->i_len = len;
}