dm-devel.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Martin Wilck <mwilck@suse.com>
To: Benjamin Marzinski <bmarzins@redhat.com>
Cc: lixiaokeng@huawei.com, dm-devel@redhat.com
Subject: Re: [PATCH 18/23] libmultipath: fix log_thread startup and teardown
Date: Tue, 29 Sep 2020 11:18:13 +0200	[thread overview]
Message-ID: <f7e7f62ed6b79c08b2f494bcd45ba09e265de55b.camel@suse.com> (raw)
In-Reply-To: <20200928201523.GO3384@octiron.msp.redhat.com>

On Mon, 2020-09-28 at 15:15 -0500, Benjamin Marzinski wrote:
> On Thu, Sep 24, 2020 at 03:40:49PM +0200, mwilck@suse.com wrote:
> > From: Martin Wilck <mwilck@suse.com>
> > 
> > This fixes several issues with the log_thread. First, the running
> > flag logq_running should be set by the thread itself, not by
> > log_thread_start()/_stop(). Second, the thread was both cancelled
> > and
> > terminated via a flag (again, logq_running). It's sufficient,
> > and better, to just cancel it and use logq_running as indication
> > for
> > successful termination. Third, the locking wasn't cancel-safe in
> > some
> > places. Forth, log_thread_start() and log_thread_stop() didn't wait
> > for
> > startup/teardown properly. Fifth, using (pthread_t)0 is wrong
> > (pthread_t is
> > opaque; there's no guarantee that 0 is not a valid pthread_t
> > value). Finally,
> > pthread_cancel() was called under logq_lock, which doesn't make
> > sense to
> > me at all.
> > 
> > Signed-off-by: Martin Wilck <mwilck@suse.com>
> > ---
> >  
> >  	pthread_mutex_lock(&logev_lock);
> > -	logq_running = 0;
> > -	pthread_cond_signal(&logev_cond);
> > -	pthread_mutex_unlock(&logev_lock);
> > +	pthread_cleanup_push(cleanup_mutex, &logev_lock);
> > +	running = logq_running;
> > +	if (running) {
> > +		pthread_cancel(log_thr);
> > +		pthread_cond_signal(&logev_cond);
> > +	}
> > +	while (logq_running)
> > +		pthread_cond_wait(&logev_cond, &logev_lock);
> 
> If we're already going to join the thread, why do we have to wait for
> the cleanup handler first? Won't the join do the waiting we need?

Yes, I guess it would. I implemented it in a way analogous the startup
sequence, but it's really not necessary for shutdown. Thanks for
pointing it out.

Martin

  reply	other threads:[~2020-09-29  9:18 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-24 13:40 [PATCH 00/23] libmultipath: improve cleanup on exit mwilck
2020-09-24 13:40 ` [PATCH 01/23] multipathd: uxlsnr: avoid deadlock " mwilck
2020-09-26  1:52   ` Benjamin Marzinski
2020-09-26 13:00     ` Martin Wilck
2020-09-24 13:40 ` [PATCH 02/23] multipathd: Fix liburcu memory leak mwilck
2020-09-24 13:40 ` [PATCH 03/23] multipathd: move handling of io_err_stat_attr into libmultipath mwilck
2020-09-24 13:40 ` [PATCH 04/23] multipathd: move vecs desctruction into cleanup function mwilck
2020-09-24 13:40 ` [PATCH 05/23] multipathd: make some globals static mwilck
2020-09-24 13:40 ` [PATCH 06/23] multipathd: move threads destruction into separate function mwilck
2020-09-24 13:40 ` [PATCH 07/23] multipathd: move conf " mwilck
2020-09-28 18:03   ` Benjamin Marzinski
2020-09-29  9:12     ` Martin Wilck
2020-09-24 13:40 ` [PATCH 08/23] multipathd: move pid " mwilck
2020-09-24 13:40 ` [PATCH 09/23] multipathd: close pidfile on exit mwilck
2020-09-24 13:40 ` [PATCH 10/23] multipathd: add helper for systemd notification at exit mwilck
2020-09-24 13:40 ` [PATCH 11/23] multipathd: child(): call cleanups in failure case, too mwilck
2020-09-24 13:40 ` [PATCH 12/23] multipathd: unwatch_all_dmevents: check if waiter is initialized mwilck
2020-09-24 13:40 ` [PATCH 13/23] multipathd: print error message if config can't be loaded mwilck
2020-09-24 13:40 ` [PATCH 14/23] libmultipath: add libmp_dm_exit() mwilck
2020-09-28 18:41   ` Benjamin Marzinski
2020-09-24 13:40 ` [PATCH 15/23] multipathd: fixup libdm deinitialization mwilck
2020-09-24 13:40 ` [PATCH 16/23] libmultipath: log_thread_stop(): check if logarea is initialized mwilck
2020-09-24 13:40 ` [PATCH 17/23] multipathd: add cleanup_child() exit handler mwilck
2020-09-24 13:40 ` [PATCH 18/23] libmultipath: fix log_thread startup and teardown mwilck
2020-09-28 20:15   ` Benjamin Marzinski
2020-09-29  9:18     ` Martin Wilck [this message]
2020-09-24 13:40 ` [PATCH 19/23] multipathd: move cleanup_{prio, checkers, foreign} to libmultipath_exit mwilck
2020-09-28 20:26   ` Benjamin Marzinski
2020-09-29  9:31     ` Martin Wilck
2020-09-29 17:50       ` Benjamin Marzinski
2020-09-24 13:40 ` [PATCH 20/23] multipath: use atexit() for cleanup handlers mwilck
2020-09-24 13:40 ` [PATCH 21/23] mpathpersist: " mwilck
2020-09-24 13:40 ` [PATCH 22/23] multipath: fix leaks in check_path_valid() mwilck
2020-09-24 13:40 ` [PATCH 23/23] multipath-tools: mpath-tools.supp: file with valgrind suppressions mwilck
2020-09-24 20:58   ` Benjamin Marzinski
2020-09-25  9:53     ` Martin Wilck
2020-09-28 20:51 ` [PATCH 00/23] libmultipath: improve cleanup on exit 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=f7e7f62ed6b79c08b2f494bcd45ba09e265de55b.camel@suse.com \
    --to=mwilck@suse.com \
    --cc=bmarzins@redhat.com \
    --cc=dm-devel@redhat.com \
    --cc=lixiaokeng@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).