linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>,
	linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org,
	brauner@kernel.org,
	syzbot+1fa947e7f09e136925b8@syzkaller.appspotmail.com
Subject: Re: [PATCH] iomap: add a workaround for racy i_size updates on block devices
Date: Mon, 25 Sep 2023 17:18:16 +0200	[thread overview]
Message-ID: <20230925151816.GA444@lst.de> (raw)
In-Reply-To: <20230925150902.GA11456@frogsfrogsfrogs>

On Mon, Sep 25, 2023 at 08:09:02AM -0700, Darrick J. Wong wrote:
> > +			/*
> > +			 * This can happen if truncating the block device races
> > +			 * with the check in the caller as i_size updates on
> > +			 * block devices aren't synchronized by i_rwsem for
> > +			 * block devices.
> 
> Why /are/ bdevs special like this (not holding i_rwsem during a
> truncate) anyway?  Is it because we require the sysadmin to coordinate
> device shrink vs. running programs?

It's not just truncate, they also don't hold a lock on write.

I think the reason is that there is no such things as the block allocator
and block truncation that happens for block devices, they historically
had a fixed size, and at some point we allowed to change that size
by various crude means that are only slowly becoming more standardized
and formal.  Real block device size changes are about 100% growing of
the device, as that is an actually useful feature.  Shrinks OTOH are
usuall a "cute" hack: block drivers set the size to 0 stop I/O when they
are shut down.  I've been wanting to replace that with an actual check
in the bdev fd I/O path for a while, but that would also mean the
shrinking case would still be around, just exercised a lot less.


  reply	other threads:[~2023-09-25 15:18 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-25  9:51 [PATCH] iomap: add a workaround for racy i_size updates on block devices Christoph Hellwig
2023-09-25 15:09 ` Darrick J. Wong
2023-09-25 15:18   ` Christoph Hellwig [this message]
2023-09-25 15:53     ` Darrick J. Wong

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=20230925151816.GA444@lst.de \
    --to=hch@lst.de \
    --cc=brauner@kernel.org \
    --cc=djwong@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=syzbot+1fa947e7f09e136925b8@syzkaller.appspotmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).