All of lore.kernel.org
 help / color / mirror / Atom feed
From: cem@kernel.org
To: kzak@redhat.com
Cc: util-linux@vger.kernel.org, zkabelac@redhat.com, amulhern@redhat.com
Subject: [PATCH RFC 0/2] Fix API breakage in libblkid
Date: Wed,  8 Apr 2026 12:35:24 +0200	[thread overview]
Message-ID: <20260408103538.134308-1-cem@kernel.org> (raw)

From: Carlos Maiolino <cem@kernel.org>

Patch d05a84b22e54 ("libblkid: check for private DM device before open")
broke blkid_new_probe_from_filename() API.

Before the patch users were able, via the low-level API, to open and
create blkid probes via the device's filename even from private
device-mapper devices.

This change broke Stratis project and xfsprogs.
xfsprogs uses blkid_new_probe_from_filename() to gather topology
information from the device, and the above mentioned change now prevents
it to be done on device-mapper private devices, as Stratis does by
attempting to initialize a XFS filesystem on it.

Quoting the patch description:

"
    blkid_new_probe_from_filename() opens the device before calling
    blkid_probe_set_device(), which checks sysfs_devno_is_dm_private()
    and sets BLKID_FL_NOSCAN_DEV.  But the open() itself bumps the
    kernel open count, so a concurrent DM_DEVICE_REMOVE ioctl sees
    EBUSY even though blkid never actually probes the device.
"

I don't think the last statement here is correct.
blkid_probe_set_device() marks the probe as BLKID_FL_NOSCAN_DEV, but it
does not error out, so, for low-level API calls, we simply ended up
with a probe with BLKID_FL_NOSCAN_DEV set. But the call succeeded and we
ended up with a probe to use and query device's information.

As far as I understood it, the patch aimed to close a possible race
window when issuing a DM_DEVICE_REMOVE ioctl() to the same device being
probed by blkid_new_probe_from_filename().

Regarding the race window which this patch, at least for the low-level
API users, this seems to be something that should be dealt in the user's
side, not within the library. But I didn't dig into the details of the
aforementioned race.

Please take the above with a grain of salt though, we've been using
libblkid for ages, but I never actually looked into the implementation
until today, so, hopefully I did get the details right.

As for xfsprogs, I have a patch which 'fixes' it replacing
blkid_new_probe_from_filename() by blkid_probe_set_device(), but this is
just taping over the root cause, which is the API breakage.


Carlos Maiolino (2):
  Revert "libblkid: add debug message for private DM device skip"
  Revert "libblkid: check for private DM device before open"

 libblkid/src/probe.c | 15 +--------------
 1 file changed, 1 insertion(+), 14 deletions(-)

Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
-- 
2.53.0


             reply	other threads:[~2026-04-08 10:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-08 10:35 cem [this message]
2026-04-08 10:35 ` [PATCH RFC 1/2] Revert "libblkid: add debug message for private DM device skip" cem
2026-04-08 10:35 ` [PATCH RFC 2/2] Revert "libblkid: check for private DM device before open" cem
2026-04-08 11:47 ` [PATCH RFC 0/2] Fix API breakage in libblkid Zdenek Kabelac
2026-04-08 13:19   ` Carlos Maiolino
2026-04-08 13:32     ` Zdenek Kabelac
2026-04-08 14:49       ` Carlos Maiolino
2026-04-08 15:10         ` Zdenek Kabelac

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=20260408103538.134308-1-cem@kernel.org \
    --to=cem@kernel.org \
    --cc=amulhern@redhat.com \
    --cc=kzak@redhat.com \
    --cc=util-linux@vger.kernel.org \
    --cc=zkabelac@redhat.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 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.