All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Benjamin Marzinski" <bmarzins@redhat.com>
To: Hannes Reinecke <hare@suse.de>
Cc: dm-devel@redhat.com
Subject: Re: [PATCH v3 1/7] libmultipath: fix tur checker locking
Date: Tue, 13 Feb 2018 14:41:19 -0600	[thread overview]
Message-ID: <20180213204119.GC14513@octiron.msp.redhat.com> (raw)
In-Reply-To: <09963d9d-033c-222d-2302-8481de41d7c4@suse.de>

On Tue, Feb 13, 2018 at 11:20:39AM +0100, Hannes Reinecke wrote:
> On 02/13/2018 04:42 AM, Benjamin Marzinski wrote:

> I would rather set 'ct->running' from within the thread; otherwise there
> is a chance that pthread_create() returns without error, but the thread
> itself hasn't been run yet.

That worry is why I put ct->running where I did. If pthread_create
returns without an error, but ct->running isn't set yet because the
thread sets it, and it hasn't run yet, then it can appear to the checker
as if the thread has already completed.  This can cause it to return the
results of the thread before it actually has completed, and potentially
even start up a new thread, which would really mess with the value of
ct->running.

On the other hand, if you set running before starting the thread, the
checker won't do anything until the it hits the timeout, at which point
it will cancel the thread.  We are guaranteed that if pthread_create
returns successfully, we have the correct Thread ID to cancel the thread
with, so there's no problem with cancelling a thread that hasn't run.

Am I missing something here?

-Ben

> 
> Cheers,
> 
> Hannes
> -- 
> Dr. Hannes Reinecke		   Teamlead Storage & Networking
> hare@suse.de			               +49 911 74053 688
> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
> GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. 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-02-13 20:41 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-13  3:42 [PATCH v3 0/7] multipath: miscellaneous bug fixes Benjamin Marzinski
2018-02-13  3:42 ` [PATCH v3 1/7] libmultipath: fix tur checker locking Benjamin Marzinski
2018-02-13  9:16   ` Martin Wilck
2018-02-13 10:20   ` Hannes Reinecke
2018-02-13 20:41     ` Benjamin Marzinski [this message]
2018-02-13  3:42 ` [PATCH v3 2/7] multipath: fix DEF_TIMEOUT use Benjamin Marzinski
2018-02-13  3:42 ` [PATCH v3 3/7] multipathd: remove coalesce_paths from ev_add_map Benjamin Marzinski
2018-02-13  3:42 ` [PATCH v3 4/7] multipathd: remove unused configure parameter Benjamin Marzinski
2018-02-13  3:42 ` [PATCH v3 5/7] Fix set_no_path_retry() regression Benjamin Marzinski
2018-02-13  3:42 ` [PATCH v3 6/7] multipathd: change spurious uevent msg priority Benjamin Marzinski
2018-02-13  3:42 ` [PATCH v3 7/7] multipath: print sysfs state in fast list mode 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=20180213204119.GC14513@octiron.msp.redhat.com \
    --to=bmarzins@redhat.com \
    --cc=dm-devel@redhat.com \
    --cc=hare@suse.de \
    /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.