lkml.org 
[lkml]   [2012]   [Feb]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] cpumask: fix lg_lock/br_lock.

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

> On Tue, 28 Feb 2012 09:43:59 +0100
> Ingo Molnar <mingo@elte.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


\
 
 \ /
  Last update: 2012-02-29 09:33    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site