From: "Benjamin Marzinski" <bmarzins@redhat.com>
To: Martin Wilck <mwilck@suse.com>
Cc: mwilck+gmail@suse.de, device-mapper development <dm-devel@redhat.com>
Subject: Re: [PATCH v3 01/19] libmultipath: fix tur checker timeout
Date: Fri, 5 Oct 2018 12:02:59 -0500 [thread overview]
Message-ID: <20181005170259.GD3172@octiron.msp.redhat.com> (raw)
In-Reply-To: <fd4fb2bec1f7b4dfa5703b2fb395a8f7bc8974bb.camel@suse.com>
On Fri, Oct 05, 2018 at 12:11:18PM +0200, Martin Wilck wrote:
> On Thu, 2018-10-04 at 11:31 -0500, Benjamin Marzinski wrote:
> > It's been a while, and I'm not exactly sure what I was thinking here.
> > But IIRC the idea was that if the state isn't set yet, then the old
> > thread could mess with the results of a future thread. Also, it was
> > to
> > avoid a corner case where the tur checker was called, started the
> > thread, got the result before the checker exitted, cancelled the
> > thread
> > and returned the result and then was called very shortly afterwards,
> > before the thread could clean itself up. In that case, the right
> > thing
> > to do (I thought) would be to start a new thread, because the other
> > one
> > would be ending soon. In truth, starting a new thread at all is
> > probably a bad idea, since the old thread will still mess with the
> > checker context on exit.
> >
> > A better idea might be to simply fail back to a syncronous call to
> > tur_check() when you notice a cancelled thread that hasn't exitted.
> > That can cause all the other checkers to get delayed, but at least in
> > that case you are still checking paths. The other option is to do as
> > before and just not check this path, which won't effect the other
> > checkers. It seems very unlikely that the thread could remain
> > uncancelled forever, especially if the path was usable.
> >
> > thoughts?
>
> Generally speaking, we're deeply in the realm of highly unlikely
> situations I would say. But we should get it right eventually.
>
> Maybe we can add logic to the tur thread to keep its hands off the
> context if it's a "zombie", like below (just a thought, untested)?
This still wouldn't stop a thread from racing with new thread creation
to change ct->holders or ct->running.
-Ben
> Martin
>
>
> diff --git a/libmultipath/checkers/tur.c b/libmultipath/checkers/tur.c
> index bf8486d3..e8493ca8 100644
> --- a/libmultipath/checkers/tur.c
> +++ b/libmultipath/checkers/tur.c
> @@ -219,11 +219,18 @@ static void cleanup_func(void *data)
> rcu_unregister_thread();
> }
>
> +#define tur_thread_quit_unless_owner(__ct) \
> + if (__ct->thread != pthread_self()) { \
> + pthread_mutex_unlock(&__ct->lock); \
> + pthread_exit(NULL); \
> + }
> +
> static void copy_msg_to_tcc(void *ct_p, const char *msg)
> {
> struct tur_checker_context *ct = ct_p;
>
> pthread_mutex_lock(&ct->lock);
> + tur_thread_quit_unless_owner(ct);
> strlcpy(ct->message, msg, sizeof(ct->message));
> pthread_mutex_unlock(&ct->lock);
> }
> @@ -243,6 +250,7 @@ static void *tur_thread(void *ctx)
>
> /* TUR checker start up */
> pthread_mutex_lock(&ct->lock);
> + tur_thread_quit_unless_owner(ct);
> ct->state = PATH_PENDING;
> ct->message[0] = '\0';
> pthread_mutex_unlock(&ct->lock);
> @@ -252,6 +260,7 @@ static void *tur_thread(void *ctx)
>
> /* TUR checker done */
> pthread_mutex_lock(&ct->lock);
> + tur_thread_quit_unless_owner(ct);
> ct->state = state;
> pthread_cond_signal(&ct->active);
> pthread_mutex_unlock(&ct->lock);
>
>
>
>
> --
> Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107
> SUSELinux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton
> HRB 21284 (AG Nürnberg)
>
next prev parent reply other threads:[~2018-10-05 17:02 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-21 23:05 [PATCH v3 00/19] Misc Multipath patches Benjamin Marzinski
2018-09-21 23:05 ` [PATCH v3 01/19] libmultipath: fix tur checker timeout Benjamin Marzinski
2018-10-01 19:51 ` Martin Wilck
2018-10-04 16:31 ` Benjamin Marzinski
2018-10-05 10:11 ` Martin Wilck
2018-10-05 17:02 ` Benjamin Marzinski [this message]
2018-10-05 19:23 ` Martin Wilck
2018-09-21 23:05 ` [PATCH v3 02/19] libmultipath: fix tur checker double locking Benjamin Marzinski
2018-10-01 20:09 ` Martin Wilck
2018-10-01 20:44 ` Martin Wilck
2018-10-04 16:47 ` Benjamin Marzinski
2018-10-04 16:45 ` Benjamin Marzinski
2018-10-05 10:25 ` Martin Wilck
2018-10-05 17:10 ` Benjamin Marzinski
2018-10-05 19:07 ` Martin Wilck
2018-09-21 23:05 ` [PATCH v3 03/19] libmultipath: fix tur memory misuse Benjamin Marzinski
2018-10-01 20:59 ` Martin Wilck
2018-10-02 7:48 ` Martin Wilck
2018-09-21 23:05 ` [PATCH v3 04/19] libmultipath: cleanup tur locking Benjamin Marzinski
2018-10-01 21:08 ` Martin Wilck
2018-09-21 23:05 ` [PATCH v3 05/19] libmultipath: fix tur checker timeout issue Benjamin Marzinski
2018-10-01 21:09 ` Martin Wilck
2018-09-21 23:05 ` [PATCH v3 06/19] libmultipath: fix set_int error path Benjamin Marzinski
2018-10-01 21:17 ` Martin Wilck
2018-09-21 23:05 ` [PATCH v3 07/19] libmultipath: fix length issues in get_vpd_sgio Benjamin Marzinski
2018-10-01 21:25 ` Martin Wilck
2018-09-21 23:05 ` [PATCH v3 08/19] libmultipath: _install_keyword cleanup Benjamin Marzinski
2018-10-01 21:26 ` Martin Wilck
2018-09-21 23:05 ` [PATCH v3 09/19] libmultipath: remove unused code Benjamin Marzinski
2018-10-01 21:28 ` Martin Wilck
2018-09-21 23:05 ` [PATCH v3 10/19] libmultipath: fix memory issue in path_latency prio Benjamin Marzinski
2018-10-01 21:30 ` Martin Wilck
2018-09-21 23:05 ` [PATCH v3 11/19] libmultipath: fix null dereference int alloc_path_group Benjamin Marzinski
2018-10-01 21:33 ` Martin Wilck
2018-09-21 23:05 ` [PATCH v3 12/19] libmutipath: don't use malformed uevents Benjamin Marzinski
2018-10-01 21:31 ` Martin Wilck
2018-09-21 23:05 ` [PATCH v3 13/19] multipath: fix max array size in print_cmd_valid Benjamin Marzinski
2018-10-01 21:35 ` Martin Wilck
2018-09-21 23:05 ` [PATCH v3 14/19] multipathd: function return value tweaks Benjamin Marzinski
2018-10-01 21:37 ` Martin Wilck
2018-09-21 23:05 ` [PATCH v3 15/19] multipathd: minor fixes Benjamin Marzinski
2018-10-01 21:38 ` Martin Wilck
2018-09-21 23:05 ` [PATCH v3 16/19] multipathd: remove useless check and fix format Benjamin Marzinski
2018-10-01 21:40 ` Martin Wilck
2018-09-21 23:05 ` [PATCH v3 17/19] multipathd: fix memory leak on error in configure Benjamin Marzinski
2018-10-01 21:42 ` Martin Wilck
2018-09-21 23:05 ` [PATCH v3 18/19] libmultipath: Don't blank intialized paths Benjamin Marzinski
2018-10-01 22:00 ` Martin Wilck
2018-10-02 22:37 ` Martin Wilck
2018-10-05 19:38 ` Benjamin Marzinski
2018-10-08 9:41 ` Martin Wilck
2018-10-09 22:20 ` Benjamin Marzinski
2018-10-08 9:35 ` Martin Wilck
2018-09-21 23:05 ` [PATCH v3 19/19] libmultipath: Fixup updating paths Benjamin Marzinski
2018-10-01 22:30 ` Martin Wilck
2018-10-05 20:32 ` Benjamin Marzinski
2018-10-07 8:36 ` [PATCH v3 00/19] Misc Multipath patches Christophe Varoqui
2018-10-09 16:13 ` 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=20181005170259.GD3172@octiron.msp.redhat.com \
--to=bmarzins@redhat.com \
--cc=dm-devel@redhat.com \
--cc=mwilck+gmail@suse.de \
--cc=mwilck@suse.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