All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: Tal Zussman <tz2294@columbia.edu>, Jens Axboe <axboe@kernel.dk>,
	Christoph Hellwig <hch@lst.de>,
	Johannes Thumshirn <johannes.thumshirn@wdc.com>,
	Luis Chamberlain <mcgrof@kernel.org>,
	"Matthew Wilcox (Oracle)" <willy@infradead.org>,
	John Garry <john.g.garry@oracle.com>,
	Christian Brauner <brauner@kernel.org>,
	"Darrick J. Wong" <djwong@kernel.org>,
	Keith Busch <kbusch@kernel.org>,
	"Martin K. Petersen" <martin.petersen@oracle.com>
Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
	Sashiko <sashiko-bot@kernel.org>
Subject: Re: [PATCH v2 1/7] block: use iomap_dirty_folio for block devices
Date: Wed, 2 Sep 2026 14:43:00 +0200	[thread overview]
Message-ID: <676f40aa-2804-4f5b-b0d6-a5f95984601d@suse.de> (raw)
In-Reply-To: <20260828-blkdev-fixes-v2-1-32f3f40cebed@columbia.edu>

On 8/28/26 3:49 PM, Tal Zussman wrote:
> With CONFIG_BUFFER_HEAD=n, block devices are written back through iomap,
> but def_blk_aops uses filemap_dirty_folio, which only sets PG_dirty. It
> does not set the per-block dirty bits in the folio's iomap_folio_state,
> so iomap_writeback_folio() finds no dirty range, submits no I/O and
> clears PG_dirty, resulting in data loss.
> 
> Other iomap users set .dirty_folio to iomap_dirty_folio, which marks the
> folio's blocks dirty before calling filemap_dirty_folio().
> 
> This is only observable with block size < folio size. With a single
> block there is no iomap_folio_state to get out of sync and
> iomap_writeback_folio() marks the whole folio dirty itself. For a
> page-aligned device, this may require using the BLKBSZSET ioctl to set
> the block size, which requires CAP_SYS_ADMIN. A device whose size is not
> page aligned already gets a sub-page block size from
> set_init_blocksize(), so no ioctl and no privilege is needed.
> 
> To reproduce, on a device with a sub-page block size, write a known
> pattern with O_DIRECT, mmap the same range, store to it, msync() and
> fsync(), then read it back with O_DIRECT. A reproducer is available at
> [1].
> 
> [1] https://gist.github.com/tzussman/18ab05cba4b3fdc79cce0a69d1fd05b4
> 
> Fixes: 925c86a19bac ("fs: add CONFIG_BUFFER_HEAD")
> Reported-by: Sashiko <sashiko-bot@kernel.org>
> Link: https://sashiko.dev/#/patchset/20260730-blk-dontcache-v7-0-3e8e6850068d%40columbia.edu?part=5
> Reviewed-by: Christoph Hellwig <hch@lst.de>
> Signed-off-by: Tal Zussman <tz2294@columbia.edu>
> ---
>   block/fops.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
Reviewed-by: Hannes Reinecke <hare@kernel.org>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                  Kernel Storage Architect
hare@suse.de                                +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich

  reply	other threads:[~2026-09-02 12:43 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-28 13:49 [PATCH v2 0/7] block device fixes for large block sizes, IOCB_NOWAIT, and direct I/O Tal Zussman
2026-08-28 13:49 ` [PATCH v2 1/7] block: use iomap_dirty_folio for block devices Tal Zussman
2026-09-02 12:43   ` Hannes Reinecke [this message]
2026-08-28 13:49 ` [PATCH v2 2/7] block: take i_rwsem for the direct I/O write fallback Tal Zussman
2026-09-02 12:47   ` Hannes Reinecke
2026-09-04 16:22     ` Tal Zussman
2026-08-28 13:49 ` [PATCH v2 3/7] block: take i_rwsem for the splice read path Tal Zussman
2026-09-02 12:52   ` Hannes Reinecke
2026-08-28 13:49 ` [PATCH v2 4/7] block: honor IOCB_NOWAIT in the block device buffered " Tal Zussman
2026-09-02 13:04   ` Hannes Reinecke
2026-08-28 13:49 ` [PATCH v2 5/7] block: fail atomic writes instead of falling back to buffered I/O Tal Zussman
2026-09-02 14:09   ` Hannes Reinecke
2026-08-28 13:49 ` [PATCH v2 6/7] block: unpin all pages of a bvec in bio_iov_iter_align_down() Tal Zussman
2026-08-28 14:36   ` Tal Zussman
2026-09-02 14:13   ` Hannes Reinecke
2026-08-28 13:49 ` [PATCH v2 7/7] block: remove dead metadata handling from the async direct I/O path Tal Zussman
2026-08-28 15:32 ` [PATCH v2 0/7] block device fixes for large block sizes, IOCB_NOWAIT, and direct I/O Tal Zussman
2026-09-04 16:19 ` Tal Zussman

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=676f40aa-2804-4f5b-b0d6-a5f95984601d@suse.de \
    --to=hare@suse.de \
    --cc=axboe@kernel.dk \
    --cc=brauner@kernel.org \
    --cc=djwong@kernel.org \
    --cc=hch@lst.de \
    --cc=johannes.thumshirn@wdc.com \
    --cc=john.g.garry@oracle.com \
    --cc=kbusch@kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=mcgrof@kernel.org \
    --cc=sashiko-bot@kernel.org \
    --cc=tz2294@columbia.edu \
    --cc=willy@infradead.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.