Flexible I/O Tester development
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Sitsofe Wheeler <sitsofe@yahoo.com>, Bruce Cran <bruce@cran.org.uk>
Cc: fio@vger.kernel.org
Subject: Re: Mutex destruction, invalid memory accesses, leaks
Date: Mon, 10 Feb 2014 13:48:05 -0700	[thread overview]
Message-ID: <20140210204805.GB4096@kernel.dk> (raw)
In-Reply-To: <20140210202245.GA6747@sucs.org>



On 02/10/2014 01:22 PM, Sitsofe Wheeler wrote:
> On Mon, Feb 10, 2014 at 12:25:32PM -0700, Bruce Cran wrote:
>> On 2/9/2014 12:50 PM, Sitsofe Wheeler wrote:
>>>
>>> Yes it's still happening with -git from a moment ago. What is stopping a
>>> sleeping thread from holding a mutex that is destroyed and then waking
>>> up on it after the memory has been unmapped?
>>
>> In case it *is* a bug in winpthreads-1.dll, are you using version
>> 3.1.0-1? It was released on the 15th January and there appeared to
>> be some mutex-related fixes when I looked at the svn log a few weeks
>> ago.
>
> Yes I am using version 3.1.0-1 on Windows 7 installed about a week
> ago...

I think I see what is going on here... It's not that the mutexes are 
broken on Windows, it's just that it probably has different scheduling 
behaviour. If the pthread_cond_signal() ends up preempting to the thread 
being woken up, then the memory allocated to the mutex could be gone 
before we get a chance to inc and unlock it.

Could you test the below and see if it fixes it?

diff --git a/backend.c b/backend.c
index 501c59a..841e54b 100644
--- a/backend.c
+++ b/backend.c
@@ -1886,7 +1886,7 @@ static void run_threads(void)
 			m_rate += ddir_rw_sum(td->o.ratemin);
 			t_rate += ddir_rw_sum(td->o.rate);
 			todo--;
-			fio_mutex_up(td->mutex);
+			fio_mutex_up_for_removal(td->mutex);
 		}
 
 		reap_threads(&nr_running, &t_rate, &m_rate);
diff --git a/mutex.c b/mutex.c
index e1fbb60..5eb0af8 100644
--- a/mutex.c
+++ b/mutex.c
@@ -141,6 +141,21 @@ void fio_mutex_down(struct fio_mutex *mutex)
 	pthread_mutex_unlock(&mutex->lock);
 }
 
+/*
+ * Special case fio_mutex_up() that doesn't touch the mutex after
+ * waking up. As such it's only safe if we know the waker is immediately
+ * going to kill the mutex, as it's left in a half-undefined state.
+ */
+void fio_mutex_up_for_removal(struct fio_mutex *mutex)
+{
+	assert(mutex->magic == FIO_MUTEX_MAGIC);
+
+	pthread_mutex_lock(&mutex->lock);
+	read_barrier();
+	if (!mutex->value && mutex->waiters)
+		pthread_cond_signal(&mutex->cond);
+}
+
 void fio_mutex_up(struct fio_mutex *mutex)
 {
 	assert(mutex->magic == FIO_MUTEX_MAGIC);
diff --git a/mutex.h b/mutex.h
index 4f3486d..1b03ba1 100644
--- a/mutex.h
+++ b/mutex.h
@@ -27,6 +27,7 @@ enum {
 extern struct fio_mutex *fio_mutex_init(int);
 extern void fio_mutex_remove(struct fio_mutex *);
 extern void fio_mutex_up(struct fio_mutex *);
+extern void fio_mutex_up_for_removal(struct fio_mutex *);
 extern void fio_mutex_down(struct fio_mutex *);
 extern int fio_mutex_down_timeout(struct fio_mutex *, unsigned int);
 

-- 
Jens Axboe


  reply	other threads:[~2014-02-10 20:48 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-06 19:21 Fio 2.1.5 release upcoming Jens Axboe
2014-02-07  3:44 ` Mutex destruction, invalid memory accesses, leaks Sitsofe Wheeler
2014-02-07 16:11   ` Jens Axboe
2014-02-09 19:50     ` Sitsofe Wheeler
2014-02-09 20:49       ` Jens Axboe
2014-02-10  9:55         ` Sitsofe Wheeler
2014-02-10 19:25       ` Bruce Cran
2014-02-10 20:22         ` Sitsofe Wheeler
2014-02-10 20:48           ` Jens Axboe [this message]
2014-02-10 20:56           ` Jens Axboe
2014-02-11  0:12             ` Elliott, Robert (Server Storage)
2014-02-11  7:07               ` Sitsofe Wheeler
2014-02-11 15:30                 ` Elliott, Robert (Server Storage)
2014-02-11 15:38                   ` Jens Axboe
2014-02-11 22:51                     ` Sitsofe Wheeler
2014-02-12  6:32                       ` Sitsofe Wheeler
2014-02-08 19:52 ` Fio 2.1.5 release upcoming Matthew Eaton
2014-02-09 20:57   ` Jens Axboe
2014-02-10  0:26     ` Matthew Eaton
2014-02-10 22:14       ` Jens Axboe
2014-02-10 23:11         ` Matthew Eaton
2014-02-10 23:15           ` Jens Axboe
2014-02-11  0:00             ` Matthew Eaton
2014-02-11 15:09               ` Jens Axboe
2014-02-11 15:27               ` Jens Axboe
2014-02-11 19:18                 ` Matthew Eaton
2014-02-11 19:29                   ` Jens Axboe
2014-02-11 20:52                     ` Matthew Eaton
2014-02-11 21:21                       ` Jens Axboe
2014-02-11 21:38                         ` Matthew Eaton
2014-02-11 21:42                           ` Jens Axboe
2014-02-12  0:01                             ` Matthew Eaton
2014-02-12  1:46                               ` Jens Axboe
2014-02-12  2:30                                 ` Matthew Eaton
2014-02-11 11:22 ` Paul Alcorn
2014-02-11 15:39   ` 'Jens Axboe'

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=20140210204805.GB4096@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=bruce@cran.org.uk \
    --cc=fio@vger.kernel.org \
    --cc=sitsofe@yahoo.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