All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Dave Chinner <david@fromorbit.com>
Cc: Christoph Hellwig <hch@lst.de>,
	"Darrick J. Wong" <djwong@kernel.org>,
	linux-xfs@vger.kernel.org, Dave Chinner <dchinner@redhat.com>
Subject: Re: XBF_DONE semantics
Date: Wed, 29 Nov 2023 07:18:05 +0100	[thread overview]
Message-ID: <20231129061805.GA1987@lst.de> (raw)
In-Reply-To: <ZWZW1bb+ih16tU+5@dread.disaster.area>

On Wed, Nov 29, 2023 at 08:08:37AM +1100, Dave Chinner wrote:
> > But places that use buf_get and manually fill in data only use it in a
> > few cases. 
> 
> Yes. the caller of buf_get always needs to set XBF_DONE if it is
> initialising a new buffer ready for it to be written. It should be
> done before the caller drops the buffer lock so that no other lookup
> can see the buffer in the state of "contains valid data but does not
> have XBF_DONE set".

That makes sense, but we do have a whole bunch of weird things going
on as well:

 - xfs_buf_ioend_handle_error sets XBF_DONE when retrying or failing
 - xfs_buf_ioend sets XBF_DONE on successful write completion as well
 - xfs_buf_ioend_fail drops XBF_DONE for any I/O failure
 - xfs_do_force_shutdown sets XBF_DONE on the super block buffer on
   a foced shutdown
 - xfs_trans_get_buf_map sets XBF_DONE on a forced shutdown

So there's definitively a bunch of weird things not fully in line
with the straight forward answer.


  reply	other threads:[~2023-11-29  6:18 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-28 15:38 XBF_DONE semantics Christoph Hellwig
2023-11-28 16:58 ` Darrick J. Wong
2023-11-28 17:13   ` Christoph Hellwig
2023-11-28 22:42   ` Dave Chinner
2023-11-28 21:08 ` Dave Chinner
2023-11-29  6:18   ` Christoph Hellwig [this message]
2023-11-29  8:21     ` 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=20231129061805.GA1987@lst.de \
    --to=hch@lst.de \
    --cc=david@fromorbit.com \
    --cc=dchinner@redhat.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.