All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Wilck <mwilck@suse.com>
To: Benjamin Marzinski <bmarzins@redhat.com>,
	Wuchongyun <wu.chongyun@h3c.com>
Cc: Guozhonghua <guozhonghua@h3c.com>,
	"dm-devel@redhat.com" <dm-devel@redhat.com>,
	Changwei Ge <ge.changwei@h3c.com>
Subject: Re: [PATCH V3] multipathd: release uxsocket and resource when cancel thread
Date: Wed, 17 Jan 2018 01:55:29 +0100	[thread overview]
Message-ID: <1516150529.23203.77.camel@suse.com> (raw)
In-Reply-To: <20180116223909.GP5638@octiron.msp.redhat.com>

On Tue, 2018-01-16 at 16:39 -0600, Benjamin Marzinski wrote:
> On Tue, Jan 16, 2018 at 02:19:20PM +0100, Martin Wilck wrote:
> > On Tue, 2018-01-16 at 11:48 +0000, Wuchongyun wrote:
> > > Hi Martin,
> > > Sorry to forget that, actually I found that dead_client() will
> > > not be
> > > interrupt by thread cancle, because after all dead_client()
> > > calling
> > > point be done then handle_signals() have chance to be called by
> > > uxsock_listen() which will call exit_daemon() and send 
> > > cancel threads signal to all child process include uxlsnr.
> > 
> > Fair enough.
> > 
> > > But your comments is good can make code more safer. Below is the
> > > new
> > > patch, please have a look, thanks.
> > 
> > I think it's really safer whis way, should anyone see the need to
> > cancel the listener thread from another point in the code.
> 
> I'm confused why this is safe. After uxsock_listen() calls
> exit_daemon()
> from handle_signals(), it doesn't exit. It loops around and polls
> again,
> and could in theory find a client that has died.  In fact if the
> client
> is killing multipathd via
> 
> # multipathd shutdown
> 
> instead of a signal, won't it be very likely that it will find a dead
> client when it loops right after calling exit_daemon() in
> cli_shutdown()? This could hit the deadlock that you noticed, where
> uxsock_cleanup() can't run because dead_client() already holding the
> mutex.
> 
> Or am I missing something here?

With "safer", I was only referring to the fact that Wuchongyun replaced
pthread_mutex_unlock() with pthread_cleanup_push(cleanup_lock,
&client_lock) ... pthread_cleanup_pop(). The original deadlock is
avoided either way, AFAICS.

Martin

-- 
Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

  reply	other threads:[~2018-01-17  0:55 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-16 11:48 [PATCH V3] multipathd: release uxsocket and resource when cancel thread Wuchongyun
2018-01-16 13:19 ` Martin Wilck
2018-01-16 22:39   ` Benjamin Marzinski
2018-01-17  0:55     ` Martin Wilck [this message]
2018-01-16 22:45 ` Benjamin Marzinski
  -- strict thread matches above, loose matches on Subject: below --
2018-01-17  2:04 Wuchongyun
2018-01-17 18:59 ` Benjamin Marzinski
2018-01-15 12:09 Wuchongyun
2018-01-15 14:10 ` 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=1516150529.23203.77.camel@suse.com \
    --to=mwilck@suse.com \
    --cc=bmarzins@redhat.com \
    --cc=dm-devel@redhat.com \
    --cc=ge.changwei@h3c.com \
    --cc=guozhonghua@h3c.com \
    --cc=wu.chongyun@h3c.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.