All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 03/10] xfs: hide log iovec alignment constraints
Date: Wed, 4 May 2022 09:07:58 +1000	[thread overview]
Message-ID: <20220503230758.GC1098723@dread.disaster.area> (raw)
In-Reply-To: <20220503224529.GD8265@magnolia>

On Tue, May 03, 2022 at 03:45:29PM -0700, Darrick J. Wong wrote:
> On Wed, May 04, 2022 at 08:17:21AM +1000, Dave Chinner wrote:
> > From: Dave Chinner <dchinner@redhat.com>
> > 
> > Callers currently have to round out the size of buffers to match the
> > aligment constraints of log iovecs and xlog_write(). They should not
> > need to know this detail, so introduce a new function to calculate
> > the iovec length (for use in ->iop_size implementations). Also
> > modify xlog_finish_iovec() to round up the length to the correct
> > alignment so the callers don't need to do this, either.
> > 
> > Convert the only user - inode forks - of this alignment rounding to
> > use the new interface.
....
> >  static inline void
> > -xlog_finish_iovec(struct xfs_log_vec *lv, struct xfs_log_iovec *vec, int len)
> > +xlog_finish_iovec(struct xfs_log_vec *lv, struct xfs_log_iovec *vec,
> > +		int data_len)
> >  {
> >  	struct xlog_op_header	*oph = vec->i_addr;
> > -
> > -	/* opheader tracks payload length, logvec tracks region length */
> > +	int			len;
> > +
> > +	/*
> > +	 * Always round up the length to the correct alignment so callers don't
> > +	 * need to know anything about this log vec layout requirement. This
> > +	 * means we have to zero the area the data to be written does not cover.
> > +	 * This is complicated by fact the payload region is offset into the
> > +	 * logvec region by the opheader that tracks the payload.
> > +	 */
> > +	len = xlog_calc_iovec_len(data_len);
> > +	if (len - data_len != 0) {
> > +		char	*buf = vec->i_addr + sizeof(struct xlog_op_header);
> > +
> > +		memset(buf + data_len, 0, len - data_len);
> 
> Assuming this is the replacement for the kzalloc/kzrealloc calls above
> so that we don't write junk to disk,

Yes, exactly that.

> Reviewed-by: Darrick J. Wong <djwong@kernel.org>

Thanks!

-Dave.
-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2022-05-03 23:08 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-03 22:17 [PATCH 00/10 v6] xfs: intent whiteouts Dave Chinner
2022-05-03 22:17 ` [PATCH 01/10] xfs: zero inode fork buffer at allocation Dave Chinner
2022-05-03 22:41   ` Darrick J. Wong
2022-05-03 22:42   ` Alli
2022-05-10 12:47   ` Christoph Hellwig
2022-05-03 22:17 ` [PATCH 02/10] xfs: fix potential log item leak Dave Chinner
2022-05-03 22:42   ` Alli
2022-05-03 22:44   ` Darrick J. Wong
2022-05-10 12:48   ` Christoph Hellwig
2022-05-03 22:17 ` [PATCH 03/10] xfs: hide log iovec alignment constraints Dave Chinner
2022-05-03 22:45   ` Darrick J. Wong
2022-05-03 23:07     ` Dave Chinner [this message]
2022-05-03 22:17 ` [PATCH 04/10] xfs: don't commit the first deferred transaction without intents Dave Chinner
2022-05-03 22:17 ` [PATCH 05/10] xfs: add log item flags to indicate intents Dave Chinner
2022-05-03 22:17 ` [PATCH 06/10] xfs: tag transactions that contain intent done items Dave Chinner
2022-05-03 22:17 ` [PATCH 07/10] xfs: factor and move some code in xfs_log_cil.c Dave Chinner
2022-05-03 22:17 ` [PATCH 08/10] xfs: add log item method to return related intents Dave Chinner
2022-05-03 22:17 ` [PATCH 09/10] xfs: whiteouts release intents that are not in the AIL Dave Chinner
2022-05-10 12:49   ` Christoph Hellwig
2022-05-03 22:17 ` [PATCH 10/10] xfs: intent item whiteouts Dave Chinner
2022-05-03 22:42   ` Alli
2022-05-03 22:50   ` Darrick J. Wong
2022-05-04  1:49     ` Dave Chinner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220503230758.GC1098723@dread.disaster.area \
    --to=david@fromorbit.com \
    --cc=djwong@kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.