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 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.