Linux kernel -stable discussions
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: cem@kernel.org, stable@vger.kernel.org, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 6/6] xfs: adjust datadev sector count to reflect internal rt volumes
Date: Tue, 18 Aug 2026 23:33:05 -0700	[thread overview]
Message-ID: <aoVOIZqmmAI7FYlm@infradead.org> (raw)
In-Reply-To: <178659861593.833642.6889273918398598117.stgit@frogsfrogsfrogs>

On Wed, Aug 12, 2026 at 10:25:25PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
> 
> A media scan of a filesystem containing an internal rt volume produced
> an error in xfs_scrub phase 6 complaining about a truncated realtime
> device.  The rt device wasn't truncated, but the media scan code thought
> we were trying to start a scan past the end of m_rtdev_targp.  That in
> turn is an alias for m_ddev_targp, but in xfs_configure_buftarg we set
> nr_sectors to the size of the data section.  Oops.

Can you share your reproducer for this?

> 
> On these filesystems, the internal rt section comes immediately after
> the data section.  We need to set the sector count for the data device
> buftarg to the size of both sections.  Without this, media scans don't
> work and media failure notifications from the kernel will be discarded
> silently.
> 
> We also need to fix the superblock buffer recovery code to do the same.

I still think messing with the kernel buftarg nr_sectors is wrong for
this.  The kernel view of the buftarg should be correct and just include
the part of the device that matters.  So I think the right fix in the
kernel is changing xfs_verify_media to add the internal RT device offset
before sending the bios.   We might need additional userland fixes,
but from a quick look I think it should be fine (famous last words)

  reply	other threads:[~2026-08-19  6:33 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-13  5:23 [PATCHSET v2 1/2] xfs: LLM-inspired bug fixes, part 5 Darrick J. Wong
2026-08-13  5:24 ` [PATCH 1/6] xfs: fix unit conversions in per_binval computation Darrick J. Wong
2026-08-13  5:24 ` [PATCH 2/6] xfs: fix short ifork reaping computation in xreap_bmapi_binval Darrick J. Wong
2026-08-13  5:24 ` [PATCH 3/6] xfs: fix name string recording in slowpath pptr tracepoints Darrick J. Wong
2026-08-13  5:24 ` [PATCH 4/6] xfs: don't leak dqacct if rhashtable insertion fails Darrick J. Wong
2026-08-13  5:25 ` [PATCH 5/6] xfs: fix the rtrmap and rtrefcount _maxlevels_ondisk functions Darrick J. Wong
2026-08-13  5:25 ` [PATCH 6/6] xfs: adjust datadev sector count to reflect internal rt volumes Darrick J. Wong
2026-08-19  6:33   ` Christoph Hellwig [this message]
2026-08-19 23:08     ` Darrick J. Wong
2026-08-24  4:47       ` Christoph Hellwig

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=aoVOIZqmmAI7FYlm@infradead.org \
    --to=hch@infradead.org \
    --cc=cem@kernel.org \
    --cc=djwong@kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=stable@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox