Re: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

* Linus Torvalds wrote: > So an error message like > >warning: ISO C90 requires array sizes to be constant-expressions > > would be technically correct and useful from a portability angle. It > tells you when you're doing something non-portable, and should be > automatically enabled with "

Re: [PATCH 2/4] btrfs: make open_ctree error injectable

in the BPF_*() namespace then it should include and not a random asm/* header... With that detail fixed: Acked-by: Ingo Molnar for the whole series. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: bio linked list corruption.

* Peter Zijlstra wrote: > $ git grep DECLARE_WAIT_QUEUE_HEAD_ONSTACK | wc -l > 28 This debug facility looks sensible. A couple of minor suggestions: > --- a/include/linux/wait.h > +++ b/include/linux/wait.h > @@ -39,6 +39,9 @@ struct wait_bit_queue { > struct __wait_queue_head { > spinl

Re: bio linked list corruption.

* Linus Torvalds wrote: > On Wed, Oct 19, 2016 at 10:09 AM, Philipp Hahn wrote: > > > > Nearly a month ago I reported also a "list_add corruption", but with 4.1.6: > > > > > > That server rungs Samba4, which also is a heavy user of xattr.

Re: [PATCH 1/2] rwsem: add rwsem_is_contended V3

> 100% accurate and called by somebody already holding on to the rwsem in either > read or write. Thanks, > > Signed-off-by: Josef Bacik Acked-by: Ingo Molnar Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a

Re: [PATCH 2/2] Btrfs: stop caching thread if extetn_commit_sem is contended

* Josef Bacik wrote: > On Fri, Sep 20, 2013 at 07:12:47AM +0200, Ingo Molnar wrote: > > > > * Josef Bacik wrote: > > > > > We can starve out the transaction commit with a bunch of caching threads > > > all running at the same time.

Re: [PATCH 2/2] Btrfs: stop caching thread if extetn_commit_sem is contended

They'd all rush to try to release the fs_info->extent_commit_sem, and they'd block in the down_read() because there's a writer waiting. So there's a guarantee of forward progress. This should answer akpm's concern I think. If this analysis is correct then: Acked-by:

Re: [PATCH] rwsem: add rwsem_is_contended

* Andrew Morton wrote: > On Fri, 30 Aug 2013 10:14:01 -0400 Josef Bacik wrote: > > > Btrfs uses an rwsem to control access to its extent tree. Threads > > will hold a read lock on this rwsem while they scan the extent tree, > > and if need_resched() they will drop the lock and schedule. Th

Re: [PATCH] Btrfs: fix 64 bit divide problem

make the counters u64 to match up with rw_devices. Thanks, > > Signed-off-by: Josef Bacik Acked-and-tested-by: Ingo Molnar Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.ke

[build breakage] Re: [GIT PULL] Btrfs pull round two

* Chris Mason wrote: > Hi everyone, > > This has the rest of the btrfs cleanups for 3.1. The bulk of this is > error handing fixes from SUSE and cleanups from Fujitsu. I havent seen a lkml mail of this pull request: 5c80c71b9a0e: Merge branch 'for-linus' of git://git.kernel.org/pub/scm/lin

Re: [PATCH 2/2] mutex: Apply adaptive spinning on mutex_trylock()

* Steven Rostedt wrote: > On Fri, 2011-03-25 at 16:50 +0300, Andrey Kuzmin wrote: > > On Fri, Mar 25, 2011 at 4:12 PM, Steven Rostedt wrote: > > > On Fri, 2011-03-25 at 14:13 +0300, Andrey Kuzmin wrote: > > >> Turning try_lock into indefinitely spinning one breaks its semantics, > > >> so deadl

Re: [PATCH 2/2] mutex: Apply adaptive spinning on mutex_trylock()

* Tejun Heo wrote: > Hello, > > On Thu, Mar 24, 2011 at 10:41:51AM +0100, Tejun Heo wrote: > > USER SYSTEM SIRQCXTSW THROUGHPUT > > SIMPLE 61107 354977217 8099529 845.100 MB/sec > > SPIN 63140 364888214 6840527 879.077 MB/sec > > > > On various runs, the adap

Re: [RFC PATCH] mutex: Apply adaptive spinning on mutex_trylock()

* Steven Rostedt wrote: > On Thu, Mar 24, 2011 at 09:18:16AM +0100, Ingo Molnar wrote: > > > > * Tejun Heo wrote: > > > > > NOT-Signed-off-by: Tejun Heo > > > > s/NOT-// ? > > > > Perhaps because it is still in RFC context? Ok, i

Re: [RFC PATCH] mutex: Apply adaptive spinning on mutex_trylock()

* Tejun Heo wrote: > NOT-Signed-off-by: Tejun Heo s/NOT-// ? Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 0/3] improve the performance of some memory copy functions

* Miao Xie wrote: > - change the version of GPL from version 2.1 to version 2 How were you able to do this? If the code derives from glibc (as your comments in the patches suggest), and if glibc is under the GPL v2.1, then you probably cannot simply change the license to v2. Ingo --

Re: gcc inlining heuristics was Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning

* Linus Torvalds wrote: > On Tue, 20 Jan 2009, Ingo Molnar wrote: > > > > (Different-type pointer uses are a common pattern: we have a lot of > > places where we have pointers to structures with different types so > > strict-aliasing optimization opport

Re: gcc inlining heuristics was Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning

* David Woodhouse wrote: > On Tue, 2009-01-20 at 13:38 +0100, Ingo Molnar wrote: > > > > * Nick Piggin wrote: > > > > > > > it seems like a nice opt-in thing that can be used where the aliases > > > > > are verified and the code is partic

Re: gcc inlining heuristics was Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning

* Nick Piggin wrote: > > > it seems like a nice opt-in thing that can be used where the aliases > > > are verified and the code is particularly performance critical... > > > > Yes. I think we could use it in the kernel, although I'm not sure how > > many cases we would ever find where we real

Re: gcc inlining heuristics was Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning

* Bernd Schmidt wrote: > Linus Torvalds wrote: > > But you'll need some background to it: > > You paint a somewhat one-sided picture bordering on FUD. > > > Type-based aliasing is _stupid_. > > Type-based aliasing is simply an application of the language definition, > and depending on the co

Re: [GIT PULL] adaptive spinning mutexes

* Chris Mason wrote: > [ re: pipes, ok I don't know of realistic pipe benchmarks but I'll run > them if people can suggest one ] Threaded servers making heavy use of sys_splice() ought to hit the pipe mutex all the time. Ingo -- To unsubscribe from this list: send the line "unsubscri

Re: [GIT PULL] adaptive spinning mutexes

* Linus Torvalds wrote: > > Has anyone found a non-synthetic benchmark where this makes a > > significant difference? Aside from btrfs, I mean. > > Yea, if you have some particular filesystem (or other subsystem) that > uses a global mutex, you'll obviously see way more contention. Btrfs may

Re: [GIT PULL] adaptive spinning mutexes

* Matthew Wilcox wrote: > On Wed, Jan 14, 2009 at 08:28:11PM +0100, Ingo Molnar wrote: > > [v2.6.14] [v2.6.29] > > > > Semaphores | Mutexes > > -- > >

Re: [GIT PULL] adaptive spinning mutexes

* Chris Mason wrote: > On Wed, 2009-01-14 at 19:33 +0100, Ingo Molnar wrote: > > * Peter Zijlstra wrote: > > > > > Full series, including changelogs available at: > > > > > > http://programming.kicks-ass.net/kernel-patches/mutex-adaptive-spin/ >

Re: [GIT PULL] adaptive spinning mutexes

* Andrew Morton wrote: > > I also checked Fedora and it has SCHED_DEBUG=y > > in its kernel rpms. > > If all distros set SCHED_DEBUG=y then fine. 95% of the distros and significant majority of the lkml traffic. And no, we dont generally dont provide knobs for essential performance features

Re: [GIT PULL] adaptive spinning mutexes

* Kay Sievers wrote: > On Wed, Jan 14, 2009 at 22:41, Ingo Molnar wrote: > > > > * Ingo Molnar wrote: > > > >> > You just disproved your own case :( > >> > >> how so? 80% is not enough? I also checked Fedora and it has > &

Re: [GIT PULL] adaptive spinning mutexes

* Ingo Molnar wrote: > > You just disproved your own case :( > > how so? 80% is not enough? I also checked Fedora and it has > SCHED_DEBUG=y in its kernel rpms. Ubuntu has CONFIG_SCHED_DEBUG=y as well in their kernels. > note that there's also a performance issue h

Re: [GIT PULL] adaptive spinning mutexes

* Andrew Morton wrote: > On Wed, 14 Jan 2009 21:51:22 +0100 > Ingo Molnar wrote: > > > > > * Andrew Morton wrote: > > > > > > > Do people enable CONFIG_SCHED_DEBUG? > > > > > > > > If they suspect performance problems an

Re: [GIT PULL] adaptive spinning mutexes

* Andrew Morton wrote: > > > Do people enable CONFIG_SCHED_DEBUG? > > > > If they suspect performance problems and want to analyze them? > > The vast majority of users do not and usually cannot compile their own > kernels. ... which they derive from distro kernels or some old .config they al

Re: [GIT PULL] adaptive spinning mutexes

* Peter Zijlstra wrote: > On Wed, 2009-01-14 at 11:36 -0800, Andrew Morton wrote: > > > Do people enable CONFIG_SCHED_DEBUG? > > Well, I have it always enabled, but I've honestly no idea if that makes > me weird. > > > CONFIG_DEBUG_MUTEXES=n, CONFIG_SCHED_DEBUG=y is getting to be a pretty >

Re: [GIT PULL] adaptive spinning mutexes

* Andrew Morton wrote: > On Wed, 14 Jan 2009 20:00:08 +0100 > Ingo Molnar wrote: > > > > > * Andrew Morton wrote: > > > > > On Wed, 14 Jan 2009 19:33:19 +0100 Ingo Molnar wrote: > > > > > > > Please pull the adaptive-mutexes-f

Re: [GIT PULL] adaptive spinning mutexes

* Peter Zijlstra wrote: > On Wed, 2009-01-14 at 10:53 -0800, Andrew Morton wrote: > > On Wed, 14 Jan 2009 19:33:19 +0100 Ingo Molnar wrote: > > > > > Please pull the adaptive-mutexes-for-linus git tree > > > > > > > > - It seems a m

Re: [GIT PULL] adaptive spinning mutexes

* Ingo Molnar wrote: > Latest performance figures, on a 2-socket 16-way Nehalem test-system, > running the code above, measured via "test-mutex V 128 10" VFS > creat+unlink scalability test on tmpfs and ext3: > > no-spin spin

Re: [GIT PULL] adaptive spinning mutexes

* Andrew Morton wrote: > On Wed, 14 Jan 2009 19:33:19 +0100 Ingo Molnar wrote: > > > Please pull the adaptive-mutexes-for-linus git tree > > > > - It seems a major shortcoming that the feature is disabled if > CONFIG_DEBUG_MUTEXES=y. It means that l

Re: [GIT PULL] adaptive spinning mutexes

* Ingo Molnar wrote: > Linus, > > Please pull the adaptive-mutexes-for-linus git tree from: > >git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git > adaptive-mutexes-for-linus > > We dropped two fresh patches from v11 for the time being: the tw

[GIT PULL] adaptive spinning mutexes

* Peter Zijlstra wrote: > Full series, including changelogs available at: > > http://programming.kicks-ass.net/kernel-patches/mutex-adaptive-spin/ > > and should shortly appear in a git tree near Ingo :-) Linus, Please pull the adaptive-mutexes-for-linus git tree from: git://git.kernel.

[PATCH -v11 delta] mutex: implement adaptive spinning

* Linus Torvalds wrote: > > > If I take out: > > > /* > > >* If there are pending waiters, join them. > > >*/ > > > if (!list_empty(&lock->wait_list)) > > > break; > > > > > > > > > v10 pops dbench 50 up to 1800MB/s. The other tests soundly beat my > > > spinning and ar

Re: [PATCH -v9][RFC] mutex: implement adaptive spinning

* Chris Mason wrote: > v10 is better that not spinning, but its in the 5-10% range. So, I've > been trying to find ways to close the gap, just to understand exactly > where it is different. > > If I take out: > /* >* If there are pending waiters, join them. >*/ >

Re: [PATCH -v9][RFC] mutex: implement adaptive spinning

* Linus Torvalds wrote: > > > On Tue, 13 Jan 2009, Ingo Molnar wrote: > > > > below is the v8 -> v10 delta patch - for all who'd like to review the > > changes. > > Hmm. This does seem to indicate that v10 lost many of the preempt > change

Re: [PATCH -v9][RFC] mutex: implement adaptive spinning

o NO_OWNER_SPIN > /debug/sched_features This command re-enables spinning again (this is also the default): # echo OWNER_SPIN > /debug/sched_features Changes since -v9: - cmpxchg acquire in the spin loop Changes since -v8: - dropped the fairness Signed-off-by: Peter Zijlstra Signed-of

Re: [PATCH -v9][RFC] mutex: implement adaptive spinning

* Linus Torvalds wrote: > On Tue, 13 Jan 2009, Ingo Molnar wrote: > > > > And v8 is rock solid in all my testing - and i'll give v10 a similar > > workout as well. > > The differences between v8 and v10 are very fundamental, since v8 does > the spinni

Re: [PATCH -v9][RFC] mutex: implement adaptive spinning

* Linus Torvalds wrote: > > > On Tue, 13 Jan 2009, Peter Zijlstra wrote: > > > > Ok, tested only 1, but that was the one I remember lockups from -- and > > that seems to be good with the cmpxchg. > > > > Do you fancy me sending v10 or will you make that change locally? > > I'd like to get t

Re: [PATCH -v9][RFC] mutex: implement adaptive spinning

* Peter Zijlstra wrote: > > Now you're forcing the slow-path on unlock. Maybe it was intentional, > > maybe it wasn't. Did you perhaps mean > > > > if (atomic_cmpxchg(&lock->count, 1, 0) == 1) { > > > > here? I thought we agreed it was safe, if only because it should be > > equivalent to

Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning

* Jamie Lokier wrote: > Ingo Molnar wrote: > > If it's used once in a single .c file it should be inlined even if > > it's large. > > As Linus has pointed out, because of GCC not sharing stack among > different inlined functions, the above is surprisingly

Re: source line numbers with x86_64 modules? [Was: Re: [patch] measurements, numbers about CONFIG_OPTIMIZE_INLINING=y impact]

* Mike Snitzer wrote: > On Sat, Jan 10, 2009 at 10:34 AM, Ingo Molnar wrote: > > > > * Mike Snitzer wrote: > > > >> Yes, especially from someone who lacks the ability to properly > >> configure kdump. I'm fairly surprised others are giving you a

Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning

* Linus Torvalds wrote: > On Fri, 9 Jan 2009, H. Peter Anvin wrote: > > > > I was thinking about experimenting with this, to see what level of > > upside it might add. Ingo showed me numbers which indicate that a > > fairly significant fraction of the cases where removing inline helps > > i

Re: source line numbers with x86_64 modules? [Was: Re: [patch] measurements, numbers about CONFIG_OPTIMIZE_INLINING=y impact]

* Linus Torvalds wrote: > As far as I'm concerned, digital cameras have been more useful than > kernel dumps to kernel debugging. Yes, especially ones with VGA video capture. (I caught a "oops+triple-fault" crash via that trick once, which was not serial-console capture-able and which was ju

Re: source line numbers with x86_64 modules? [Was: Re: [patch] measurements, numbers about CONFIG_OPTIMIZE_INLINING=y impact]

* Mike Snitzer wrote: > Yes, especially from someone who lacks the ability to properly configure > kdump. I'm fairly surprised others are giving you a free pass when you > keep asserting how broken kdump is with such hollow criticism. I rely > heavily on kdump and it works quite well (kvm i

Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning

* Linus Torvalds wrote: > On Sat, 10 Jan 2009, Ingo Molnar wrote: > > > > Well, it's not totally meaningless. To begin with, defining 'inline' to > > mean 'always inline' is a Linux kernel definition. So we already changed > > the behavio

Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning

* Linus Torvalds wrote: > On Sat, 10 Jan 2009, Ingo Molnar wrote: > > > > may_inline/inline_hint is a longer, less known and uglier keyword. > > Hey, your choice, should you decide to accept it, is to just get rid of > them entirely. > > You claim that we

Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning

* Linus Torvalds wrote: > On Fri, 9 Jan 2009, Harvey Harrison wrote: > > > > __needs_inline? That would imply that it's for correctness reasons. > > .. but the point is, we have _thousands_ of inlines, and do you know > which is which? We've historically forced them to be inlined, and every

Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning

* Linus Torvalds wrote: > On Fri, 9 Jan 2009, Ingo Molnar wrote: > > > > So, should we not remove CONFIG_OPTIMIZE_INLINING, then the correct one > > would be to mark it __always_inline [__asm_inline is senseless there], or > > the second patch below that changes th

Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning

* Linus Torvalds wrote: > On Fri, 9 Jan 2009, Ingo Molnar wrote: > > > > So, should we not remove CONFIG_OPTIMIZE_INLINING, then the correct > > one would be to mark it __always_inline [__asm_inline is senseless > > there], or the second patch below that c

Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning

* Ingo Molnar wrote: > Note that meanwhile i also figured out why gcc got the inlining wrong > there: the 'int nr' combined with the '% BITS_PER_LONG' signed > arithmetics was too much for it to figure out at the inlining stage - it > generated IDIV instruc

Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning

* Linus Torvalds wrote: > On Fri, 9 Jan 2009, Ingo Molnar wrote: > > > > -static inline int constant_test_bit(int nr, const volatile unsigned long > > *addr) > > +static __asm_inline int > > +constant_test_bit(int nr, const volatile unsigned long *addr) &

Re: [patch] measurements, numbers about CONFIG_OPTIMIZE_INLINING=y impact

* jim owens wrote: > Ingo Molnar wrote: >> >> One interpretation of the numbers would be that core kernel hackers are >> more inline-happy, maybe because they think that their functions are >> more important to inline. >> >> Which is generally a fair i

Re: [patch] measurements, numbers about CONFIG_OPTIMIZE_INLINING=y impact

* Ingo Molnar wrote: > > I suspect gcc has some pre-inlining heuristics that don't take > > constant folding and simplifiation into account - if you look at just > > the raw tree of the function without taking the optimization into > > account, it will look bi

Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning

* H. Peter Anvin wrote: > Andi Kleen wrote: > >> I'll try to annotate the inline asms (there's not _that_ many of them), > >> and measure what the size impact is. > > > > You can just use the patch I submitted and that you rejected for > > most of them :) > > I just ran a sample build for x86

[patch] measurements, numbers about CONFIG_OPTIMIZE_INLINING=y impact

either mark CONFIG_OPTIMIZE_INLINING as CONFIG_BROKEN, or limit CONFIG_OPTIMIZE_INLINING to GCC 4.3.x and later versions only. I'm no fan of the GCC inliner, but the latter seems to be the more rational choice to me - the size win from inline-optimization is significant: 1% for defconfig,

Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning

* Linus Torvalds wrote: > Unrelated: > > On Thu, 8 Jan 2009, Chris Mason wrote: > > > > RIP: 0010:[] [] __cmpxchg+0x36/0x3f > > Ouch. HOW THE HELL DID THAT NOT GET INLINED? > > cmpxchg() is a _single_ instruction if it's inlined, but it's a horrible > mess of dynamic conditionals on the (co

Re: [PATCH -v6][RFC]: mutex: implement adaptive spinning

* Peter Zijlstra wrote: > On Wed, 2009-01-07 at 15:10 -0800, Linus Torvalds wrote: > > > Please take all my patches to be pseudo-code. They've neither been > > compiled nor tested, and I'm just posting them in the hope that somebody > > else will then do things in the direction I think is the

Re: [PATCH -v5][RFC]: mutex: implement adaptive spinning

* Gregory Haskins wrote: > Can I ask a simple question in light of all this discussion? > > "Is get_task_struct() really that bad?" it dirties a cacheline and it also involves atomics. Also, it's a small design cleanliness issue to me: get_task_struct() impacts the lifetime of an object - an

Re: [PATCH -v5][RFC]: mutex: implement adaptive spinning

* Andrew Morton wrote: > On Wed, 7 Jan 2009 22:32:22 +0100 > Ingo Molnar wrote: > > > > We could do the whole "oldfs = get_fs(); set_fs(KERNEL_DS); .. > > > set_fs(oldfs);" crud, but it would probably be better to just add an > > > archit

Re: [PATCH -v5][RFC]: mutex: implement adaptive spinning

* Linus Torvalds wrote: > > > On Wed, 7 Jan 2009, Matthew Wilcox wrote: > > > > I appreciate this is sample code, but using __get_user() on > > non-userspace pointers messes up architectures which have separate > > user/kernel spaces (eg the old 4G/4G split for x86-32). Do we have an > > app

Re: [PATCH -v5][RFC]: mutex: implement adaptive spinning

* Linus Torvalds wrote: > /* >* Even if the access succeeded (likely case), >* the cpu field may no longer be valid. FIXME: >* this needs to validate that we can do a >* get_cpu(

Re: Btrfs for mainline

* Matthew Wilcox wrote: > On Wed, Jan 07, 2009 at 02:07:42PM +0100, Ingo Molnar wrote: > > * Chris Mason wrote: > > > All of this is a long way of saying the btrfs locking scheme is far from > > > perfect. I'll look harder at the loop and ways to get rid of

Re: Btrfs for mainline

* Chris Mason wrote: > On Tue, 2009-01-06 at 01:47 +1100, Nick Piggin wrote: > > [ adaptive locking in btrfs ] > > > adaptive locks have traditionally (read: Linus says) indicated the locking > > is suboptimal from a performance perspective and should be reworked. This > > is definitely the ca

Re: [PATCH][RFC]: mutex: adaptive spin

* Linus Torvalds wrote: > On Tue, 6 Jan 2009, Linus Torvalds wrote: > > > > Right now, if some process deadlocks on a mutex, we get hung process, > > but with a nice backtrace and hopefully other things (that don't need > > that lock) still continue to work. > > Clarification: the "nice back

Re: [PATCH][RFC]: mutex: adaptive spin

* Ingo Molnar wrote: > One thought: > > BUG_ON()'s do_exit() shows a slightly misleading failure pattern to > users: instead of a 'hanging' task, we'd get a misbehaving app due to > one of its tasks exiting spuriously. It can even go completely unnoticed

Re: [PATCH][RFC]: mutex: adaptive spin

* Linus Torvalds wrote: > On Tue, 6 Jan 2009, Linus Torvalds wrote: > > > > So it should be renamed. Something like "task_is_oncpu()" or whatever. > > Another complaint, which is tangentially related in that it actually > concerns "current". > > Right now, if some process deadlocks on a mute

Re: [PATCH][RFC]: mutex: adaptive spin

* Gregory Haskins wrote: > Ingo Molnar wrote: > > There's no time or spin-rate based heuristics in this at all (i.e. these > > mutexes are not 'adaptive' at all!), > > FYI: The original "adaptive" name was chosen in the -rt implementation >

Re: [PATCH][RFC]: mutex: adaptive spin

* Peter Zijlstra wrote: > +++ linux-2.6/kernel/mutex.c > @@ -46,6 +46,7 @@ __mutex_init(struct mutex *lock, const c > atomic_set(&lock->count, 1); > spin_lock_init(&lock->wait_lock); > INIT_LIST_HEAD(&lock->wait_list); > + lock->owner = NULL; > > debug_mutex_init(lo