[dm-devel] [PATCH 19/23] multipathd: move cleanup_{prio, checkers, foreign} to libmultipath_exit

[Benjamin Marzinski]

On Tue, Sep 29, 2020 at 11:31:06AM +0200, Martin Wilck wrote:
> On Mon, 2020-09-28 at 15:26 -0500, Benjamin Marzinski wrote:
> > On Thu, Sep 24, 2020 at 03:40:50PM +0200, mwilck at suse.com wrote:
> > > 
> > >  /*
> > >   * We don't support re-initialization after
> > > @@ -65,6 +66,9 @@ int libmultipath_init(void)
> > >  static void _libmultipath_exit(void)
> > >  {
> > >  	libmultipath_exit_called = true;
> > > +	cleanup_foreign();
> > 
> > I don't really feel too strongly about this, but it seems to me that
> > there is a difference between the checkers and prioritizers, which
> > it seems like most users of libmultipath would want, and the foreign
> > code, which doesn't seem that way. libmpathpersist, for instance,
> > will use the checkers and prioritizers, but not the foreign code.
> > On the other hand, if the caller isn't using the foreign code,
> > then grabbing the lock and checking the foreign pointer shouldn't
> > take much time.
> 
> It would just be a few cycles. I want callers to have to worry about
> cleanup as little as possible. All else is error-prone IMO, and
> although I agree that the foreign functions are less important than
> checkers and prio, I thought it made sense to treat all our "plug-ins"
> the same way.
> 
> Ideally I'd like to do checker/prio/foreign initialization completely
> lazily too, in the sense that callers don't need to worry about calling
> init_checkers() etc., either. But this series had to stop at some
> point.
> 
> Either way, it's not a big issue, so please tell me if you feel
> strongly enough about it to ask me to revert the change.

I already ACKed this bug in my reply to:

[PATCH 00/23] libmultipath: improve cleanup on exit

https://www.redhat.com/archives/dm-devel/2020-September/msg00635.html

Sorry for the confusion.
-Ben
 
> Regards,
> Martin
>