Re: [PATCH 1/3] libxfs: don't set mp->m_rtdev_targp when no RT devices is provided

[Christoph Hellwig <hch@lst.de>]

On Fri, Sep 11, 2026 at 08:30:26AM -0700, Darrick J. Wong wrote:
> > And that is what we get with this patch.  The zeroing is done by
> > zeroing the entire mount structure in the callers of libxfs_mount
> > (don't ask me why..).
> 
> Sorry, but I don't see how we get to m_rtdev_targp==NULL with this
> patch?  The end of libxfs_buftarg_init becomes:

...

> In the case where the rt and data devices are not the same, we create a
> new buftarg object, even if xi->rt.dev == 0.  That only happens if we
> didn't set xi->rt.name to a path, which means that libxfs_device_open
> ignores it:

Yeah, you're right.  We'll have a separate m_rtdev_targp, but it
will have a NULL dev.  rtmount_init rejects this except for xfs_db,
but xfs_db can see a "weird" targp.

> OTOH there are other places that use other checks that clearly assume
> that m_rtdev_targp is always present:
> 
> libxfs/init.c:311:      if (mp->m_rtdev_targp->bt_bdev == 0 && !xfs_is_debugger(mp)) {
> libxfs/init.c:1034:     if (mp->m_rtdev_targp != mp->m_ddev_targp)
> libxfs/init.c:1035:             libxfs_buftarg_free(mp->m_rtdev_targp);
> 
> Ok maybe this patch is fine as-is?  But xfsprogs needs a treewide change
> to make the "do we have a rt device attached?" checks match the kernel
> code?

It has passed pretty extensive testing so it must be perfect (TM).
But I agree that another cleanup pass to better match the kernel
sounds like a good idea.  I'll add it to my bucket list.