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 09:29:44 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	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,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [PATCH] cpumask: fix lg_lock/br_lock.


* Andrew Morton <akpm@...ux-foundation.org> wrote:

> On Tue, 28 Feb 2012 09:43:59 +0100
> Ingo Molnar <mingo@...e.hu> wrote:
> 
> > This patch should also probably go upstream through the 
> > locking/lockdep tree? Mind sending it us once you think it's 
> > ready?
> 
> Oh goody, that means you own 
> http://marc.info/?l=linux-kernel&m=131419353511653&w=2.
>
> I do think the brlock code is sick, but Nick has turned into 
> an ex-Nick and nobody works on it.

The main problem, highlighted by the above soft lockup report, 
is that lglocks and brlocks go outside the regular spinlock 
facilities and thus avoid quite a bit of generic lock debugging 
for no good reason. Those patches should never have gone 
upstream in their incomplete form via the VFS tree.

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.

Andi's deficient patch does not address that main shortcoming of 
brlocks/lglocks, it just addresses a symptom - while introducing 
a handful of new symptoms of suckage.

I'll review and process resubmitted patches from Andi if he 
wants to submit a proper, complete series - but there's a 
quality threshold and in this case I'd rather keep 1970's 
preprocessor code that sucks very visibly and possibly attracts 
someone with a clue than have a sloppy patch hiding the deeper 
design problems done by a clueless person who is also openly 
hostile towards the concept of producing quality code.

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ