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
next prev parent 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