[dm-devel] [PATCH 2/3] libmutipath: don't close fd on dm_lib_release

[Martin Wilck]

On Wed, 2020-03-25 at 17:00 -0500, Benjamin Marzinski wrote:
> On Wed, Mar 25, 2020 at 03:52:55PM -0500, Benjamin Marzinski wrote:
> > On Wed, Mar 25, 2020 at 03:16:50PM +0000, Martin Wilck wrote:
> > > On Tue, 2020-03-24 at 16:03 -0500, Benjamin Marzinski wrote:
> > > 
> > > AFAICS, this function has been in libdm since 1.02.111. We
> > > support
> > > 1.02.89 (if all features enabled, otherwise even older). Perhaps
> > > we
> > > should make this function call conditional on the libdm verson?
> > > 
> > > But perhaps more importantly, why do we still need to call
> > > dm_lib_release()? AFAICS it's only needed for systems that have
> > > no udev
> > > support for creating device nodes (to call update_devs() via
> > > dm_lib_release()), and we don't support that anymore anyway, do
> > > we? 
> > > 
> > > Since 26c4bb0, we're always setting the
> > > DM_UDEV_DISABLE_LIBRARY_FALLBACK flag, and the cookie, too
> > > (we aren't setting it for DM_DEVICE_RELOAD, but it isn't needed
> > > for
> > > that, either, since no device nodes need to be created or
> > > removed); so
> > > dm_lib_release() should really have no effect.
> > > 
> > > Regards
> > > Martin
> > 
> > Good call. I'll redo this patch.
> 
> Actually, I've changed my mind. Calling dm_lib_release() lets us
> release
> the memory that device-mapper uses to store all the node ops that it
> was saving up.  Without calling dm_lib_release(), AFAICS, that memory
> keeps growing until the daemon exits.

Ok, I see. libdm stacks the node ops, even if it's told to rely on
udev. The question is, what for, as it will discard the stacked nodes
later on anyway. 

Fine, then. But please add a check for the libdm version.

Thanks,
Martin

-- 
Dr. Martin Wilck <mwilck at suse.com>, Tel. +49 (0)911 74053 2107
SUSE  Software Solutions Germany GmbH
HRB 36809, AG Nürnberg GF: Felix
Imendörffer