linux-kernel - Re: [PATCH] cpumask: fix lg_lock/br

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 29 Feb 2012 10:32:24 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Nick Piggin <npiggin@...nel.dk>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Andi Kleen <ak@...ux.intel.com>,
	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>,
	linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH] cpumask: fix lg_lock/br_lock.


* Peter Zijlstra <a.p.zijlstra@...llo.nl> wrote:

> On Wed, 2012-02-29 at 09:29 +0100, Ingo Molnar wrote:
>
> > As part of any cleanup they should first be converted from 
> > arch_spinlock_t to regular spinlock_t - I bet if that is 
> > done then that not only simplifies the wrappers massively, 
> > it also turns the above soft lockup report into a nice, 
> > actionable lockdep splat.
> 
> It might help if you'd actually read the code.. that will 
> simply not work.

It cannot find all bugs - such as the CPU hotplug race that is 
still present in the code.

Still there's no excuse to go outside regular spinlock debug 
primitives via arch_spinlock_t.

If lockdep blows up in br_write_lock() due to holding up to 4096 
individual locks then we should add the exceptions to this 
particular write lock when the CPU count is too high - but:

 - do not disable the checking on saner configs

 - not disable all the *OTHER* lock debugging checks such as:

     - spin-lockup detection [this works even without ->held_locks]

     - allocate/free failure detection:

         The percpu code could be extended to run the equivalent 
         of debug_check_no_locks_freed() over the percpu area 
         that is going away, to make sure no held locks are 
         freed.

etc.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/