From: Maarten Lankhorst <maarten.lankhorst@canonical.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
x86@kernel.org, dri-devel@lists.freedesktop.org,
linaro-mm-sig@lists.linaro.org, robclark@gmail.com,
rostedt@goodmis.org, tglx@linutronix.de, mingo@elte.hu,
linux-media@vger.kernel.org, Dave Airlie <airlied@redhat.com>
Subject: Re: [PATCH v3 2/3] mutex: add support for wound/wait style locks, v3
Date: Mon, 27 May 2013 12:52:00 +0200 [thread overview]
Message-ID: <51A33AD0.4030406@canonical.com> (raw)
In-Reply-To: <20130527102457.GA4341@laptop>
Op 27-05-13 12:24, Peter Zijlstra schreef:
> On Mon, May 27, 2013 at 12:01:50PM +0200, Maarten Lankhorst wrote:
>>> Again, early.. monday.. would a trylock, even if successful still need
>>> the ctx?
>> No ctx for trylock is supported. You can still do a trylock while
>> holding a context, but the mutex won't be a part of the context.
>> Normal lockdep rules apply. lib/locking-selftest.c:
>>
>> context + ww_mutex_lock first, then a trylock:
>> dotest(ww_test_context_try, SUCCESS, LOCKTYPE_WW);
>>
>> trylock first, then context + ww_mutex_lock:
>> dotest(ww_test_try_context, FAILURE, LOCKTYPE_WW);
>>
>> For now I don't want to add support for a trylock with context, I'm
>> very glad I managed to fix ttm locking to not require this any more,
>> and it was needed there only because it was a workaround for the
>> locking being wrong. There was no annotation for the buffer locking
>> it was using, so the real problem wasn't easy to spot.
> Ah, ok.
>
> My question really was whether there even was sense for a trylock with
> context. I couldn't come up with a case for it; but I think I see one
> now.
The reason ttm needed it was because there was another lock that interacted
with the ctx lock in a weird way. The ww lock it was using was inverted with another
lock, so it had to grab that lock first, perform a trylock on the ww lock, and if that failed
unlock the lock, wait for it to be unlocked, then retry the same thing again.
I'm so glad I managed to fix that mess, if you really need ww_mutex_trylock with a ctx,
it's an indication your locking is wrong.
For ww_mutex_trylock with a context to be of any use you would also need to return
0 or a -errno, (-EDEADLK, -EBUSY (already locked by someone else), or -EALREADY).
This would make the trylock very different from other trylocks, and very confusing because
if (ww_mutex_trylock(lock, ctx)) would not do what you would think it would do.
> The thing is; if there could exist something like:
>
> ww_mutex_trylock(struct ww_mutex *, struct ww_acquire_ctx *ctx);
>
> Then we should not now take away that name and make it mean something
> else; namely: ww_mutex_trylock_single().
>
> Unless we want to allow .ctx=NULL to mean _single.
>
> As to why I proposed that (.ctx=NULL meaning _single); I suppose because
> I'm a minimalist at heart.
Minimalism isn't bad, it's just knowing when to sto
next prev parent reply other threads:[~2013-05-27 10:52 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-28 17:03 [PATCH v3 0/3] Wait/wound mutex implementation, v3 Maarten Lankhorst
2013-04-28 17:03 ` [PATCH v3 1/3] arch: make __mutex_fastpath_lock_retval return whether fastpath succeeded or not Maarten Lankhorst
2013-04-28 17:04 ` [PATCH v3 2/3] mutex: add support for wound/wait style locks, v3 Maarten Lankhorst
2013-04-30 19:14 ` Daniel Vetter
2013-05-22 11:18 ` Maarten Lankhorst
2013-05-22 11:37 ` Peter Zijlstra
2013-05-22 11:47 ` Maarten Lankhorst
2013-05-22 12:07 ` Peter Zijlstra
2013-05-22 16:18 ` Peter Zijlstra
2013-05-22 16:49 ` Daniel Vetter
2013-05-22 16:49 ` Daniel Vetter
2013-05-27 8:29 ` Peter Zijlstra
2013-05-22 17:24 ` Maarten Lankhorst
2013-05-23 9:13 ` Maarten Lankhorst
2013-05-23 10:45 ` [Linaro-mm-sig] " Daniel Vetter
2013-05-27 8:00 ` Peter Zijlstra
2013-05-27 8:26 ` Maarten Lankhorst
2013-05-27 9:13 ` Peter Zijlstra
2013-05-27 9:58 ` Maarten Lankhorst
2013-05-27 8:21 ` Peter Zijlstra
2013-05-27 8:21 ` Peter Zijlstra
2013-05-27 10:01 ` Maarten Lankhorst
2013-05-27 10:24 ` Peter Zijlstra
2013-05-27 10:52 ` Maarten Lankhorst [this message]
2013-05-27 11:15 ` Peter Zijlstra
2013-05-27 11:24 ` Maarten Lankhorst
2013-05-27 14:47 ` Daniel Vetter
2013-05-27 14:55 ` Daniel Vetter
2013-04-28 17:04 ` [PATCH v3 3/3] mutex: Add ww tests to lib/locking-selftest.c. v3 Maarten Lankhorst
2013-04-30 18:45 ` [PATCH] [RFC] mutex: w/w mutex slowpath debugging Daniel Vetter
2013-04-30 19:29 ` Steven Rostedt
2013-04-30 20:38 ` Daniel Vetter
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=51A33AD0.4030406@canonical.com \
--to=maarten.lankhorst@canonical.com \
--cc=airlied@redhat.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=robclark@gmail.com \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/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.