All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Marzinski <bmarzins@redhat.com>
To: Martin Wilck <Martin.Wilck@suse.com>
Cc: "dm-devel@redhat.com" <dm-devel@redhat.com>
Subject: Re: [PATCH 2/3] libmutipath: don't close fd on dm_lib_release
Date: Thu, 2 Jul 2020 15:06:32 -0500	[thread overview]
Message-ID: <20200702200632.GH11089@octiron.msp.redhat.com> (raw)
In-Reply-To: <4eaae3bfe0c383d23a839483e88ec093883f4e5a.camel@suse.com>

On Thu, Jul 02, 2020 at 11:52:21AM +0000, Martin Wilck wrote:
> 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.
> 
> Sorry for coming back to this so late. I've just stared at the libdm
> code again. 
> 
> We always set DM_UDEV_DISABLE_LIBRARY_FALLBACK. In the standard CREATE
> and REMOVE cases, libdm doesn't stack any operations if this flag is
> set. The only exceptions are 
> 
>  a) RESUME operations with DM_ADD_NODE_ON_RESUME set. This happens
> implicity when we create new maps
>  b) RENAME operations
> 
> In both cases, we call dm_udev_wait() after the libdm operation, which
> calls update_devs() and should thus have the same effect as
> dm_lib_release(). IOW, I still believe we don't need to call
> dm_lib_release() any more.

Sure. But can we leave this patch as is, and remove those calls in a
different patch?

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

  reply	other threads:[~2020-07-02 20:06 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-24 21:03 [PATCH 1/3] libmultipath: assign variable to make gcc happy Benjamin Marzinski
2020-03-24 21:03 ` [PATCH 2/3] libmutipath: don't close fd on dm_lib_release Benjamin Marzinski
2020-03-25 15:16   ` Martin Wilck
2020-03-25 20:52     ` Benjamin Marzinski
2020-03-25 22:00       ` Benjamin Marzinski
2020-03-25 22:11         ` Martin Wilck
2020-07-02 11:52         ` Martin Wilck
2020-07-02 20:06           ` Benjamin Marzinski [this message]
2020-07-03 14:05             ` Martin Wilck
2020-03-24 21:03 ` [PATCH 3/3] libmultipath: allow force reload with no active paths Benjamin Marzinski
2020-03-25 15:27   ` Martin Wilck
2020-03-25 15:22 ` [PATCH 1/3] libmultipath: assign variable to make gcc happy Martin Wilck

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=20200702200632.GH11089@octiron.msp.redhat.com \
    --to=bmarzins@redhat.com \
    --cc=Martin.Wilck@suse.com \
    --cc=dm-devel@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.