All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Marzinski <bmarzins@redhat.com>
To: Martin Wilck <mwilck@suse.com>
Cc: Christophe Varoqui <christophe.varoqui@opensvc.com>,
	dm-devel@lists.linux.dev
Subject: Re: [PATCH 03/13] multipathd: allow map removal in do_sync_mpp()
Date: Thu, 12 Dec 2024 12:12:39 -0500	[thread overview]
Message-ID: <Z1sZh1WLCucwL61e@redhat.com> (raw)
In-Reply-To: <422fff82ad35293d9406ec07820ddad5b122d1f6.camel@suse.com>

On Wed, Dec 11, 2024 at 09:33:40PM +0100, Martin Wilck wrote:
> On Wed, 2024-12-11 at 21:20 +0100, Martin Wilck wrote:
> > On Wed, 2024-12-11 at 12:09 -0500, Benjamin Marzinski wrote:
> > 
> > 
> > > I'm not actually worried about the kernel so much as libdevmapper.
> > > It
> > > is
> > > not designed for multi-threaded processes, and that has bitten us
> > > in
> > > the
> > > past. For intance, it's why we don't delete devices in
> > > dmevent_loop()
> > > on
> > > libdevmapper errors. dm_get_events() just waits and retries if
> > > getting
> > > the device list fails, and for each device, it calls dm_is_mpath
> > > and
> > > will only delete a device on DM_IS_MPATH_NO, which is what I
> > > suggested
> > > for the cleanup function.
> > > 
> > > I'm pretty sure we've handled all of the known issues here, with
> > > fixes
> > > like:
> > > 02d4bf07 ("libmultipath: protect racy libdevmapper calls with a
> > > mutex")
> > > 34e01d2f ("multipath-tools: don't call dm_lib_release() any more")
> > > 
> > > I'd rather not risk having missed some issue that could cause a
> > > temporary error in a function that we call every couple of seconds
> > > (almost always unnecessarily).
> > 
> > Ok, getting it. I thought that an error in DM_TABLE_STATUS must
> > almost
> > neccessarily mean -ENXIO (from the kernel pov), which would mean that
> > some external entity removed the device, and that we should act as if
> > someone had used the "remove map" CLI command. But I didn't think
> > about
> > libdevmapper.
> 
> But will libdevmapper return ENXIO if it's somehow interally confused?
> I don't think so. I believe that if we see this error code, removing
> the map is the right thing to do.

I don't think that shouldn't ever happen.

https://github.com/lvmteam/lvm2/blob/928b8e9c6eaf871b3405b91c64eac5ea854f2572/device_mapper/ioctl/libdm-iface.c#L2100

If libdevmapper gets an ENXIO from the kernel, it ends up setting
dmi.exists to 0 instead of returning the error.

-Ben
 
> I consider adding a patch on top of the v4 series that does this. 
> If you reject it, fine :-)
> 
> Regards,
> Martin


  reply	other threads:[~2024-12-12 17:12 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-06 23:36 [PATCH 00/13] multipathd: More map reload handling, and checkerloop work Martin Wilck
2024-12-06 23:36 ` [PATCH 01/13] multipathd: don't reload map in update_mpp_prio() Martin Wilck
2024-12-06 23:36 ` [PATCH 02/13] multipathd: remove dm_get_info() call from refresh_multipath() Martin Wilck
2024-12-06 23:36 ` [PATCH 03/13] multipathd: allow map removal in do_sync_mpp() Martin Wilck
2024-12-10 19:02   ` Benjamin Marzinski
2024-12-10 19:44     ` Benjamin Marzinski
2024-12-10 21:05     ` Martin Wilck
2024-12-10 22:49       ` Benjamin Marzinski
2024-12-11 20:48         ` Martin Wilck
2024-12-10 23:30   ` Benjamin Marzinski
2024-12-11 12:06     ` Martin Wilck
2024-12-11 17:09       ` Benjamin Marzinski
2024-12-11 20:20         ` Martin Wilck
2024-12-11 20:33           ` Martin Wilck
2024-12-12 17:12             ` Benjamin Marzinski [this message]
2024-12-12 17:18               ` Martin Wilck
2024-12-12 17:50                 ` Benjamin Marzinski
2024-12-06 23:36 ` [PATCH 04/13] multipathd: reload maps in do_sync_mpp() if necessary Martin Wilck
2024-12-10 19:20   ` Benjamin Marzinski
2024-12-06 23:36 ` [PATCH 05/13] multipathd: move yielding for waiters to start of checkerloop Martin Wilck
2024-12-06 23:36 ` [PATCH 06/13] multipathd: add checker_finished() Martin Wilck
2024-12-06 23:36 ` [PATCH 07/13] multipathd: move "tick" calls into checker_finished() Martin Wilck
2024-12-06 23:36 ` [PATCH 08/13] multipathd: remove mpvec_garbage_collector() Martin Wilck
2024-12-10 23:34   ` Benjamin Marzinski
2024-12-06 23:36 ` [PATCH 09/13] multipathd: don't call reload_and_sync_map() from deferred_failback_tick() Martin Wilck
2024-12-06 23:36 ` [PATCH 10/13] multipathd: move retry_count_tick() into existing mpvec loop Martin Wilck
2024-12-06 23:36 ` [PATCH 11/13] multipathd: don't call update_map() from missing_uev_wait_tick() Martin Wilck
2024-12-10 23:13   ` Benjamin Marzinski
2024-12-06 23:36 ` [PATCH 12/13] multipathd: don't call udpate_map() from ghost_delay_tick() Martin Wilck
2024-12-06 23:36 ` [PATCH 13/13] multipathd: only call reload_and_sync_map() when ghost delay expires Martin Wilck
2024-12-11  0:02 ` [PATCH 00/13] multipathd: More map reload handling, and checkerloop work Benjamin Marzinski

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=Z1sZh1WLCucwL61e@redhat.com \
    --to=bmarzins@redhat.com \
    --cc=christophe.varoqui@opensvc.com \
    --cc=dm-devel@lists.linux.dev \
    --cc=mwilck@suse.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.