Date:	Mon, 2 Mar 2009 14:10:25 -0800
From:	David Brownell <david-b@...bell.net>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Andrew Morton <akpm@...ux-foundation.org>, me@...ipebalbi.com,
	linux-kernel@...r.kernel.org, linux-input@...r.kernel.org,
	felipe.balbi@...ia.com, dmitry.torokhov@...il.com,
	sameo@...nedhand.com, tglx@...utronix.de
Subject: Re: lockdep and threaded IRQs (was: ...)

On Monday 02 March 2009, Peter Zijlstra wrote:
> On Fri, 2009-02-27 at 15:18 -0800, David Brownell wrote:
> > 
> > This stuff just pokes at some annoying current gaps in the
> > IRQ framework.  I'll be glad when eventually there's no
> > need to work around those weaknesses ... that is, when
> > real threaded IRQ support is available.
> 
> Its unfortunate that you prefer these dinky little hacks over
> helping out providing whatever infrastructure you need.

That's an unfair and unreasonable criticism.  You don't
know what I "prefer", or how much time I have to "help"
with.  Plus, you discount the work involved in actually
tracking down root causes ... and your evaluation of at
least this issue is biased.

What's unfortunate is that you prefer not to fix that
IRQF_DISABLED bug in lockdep, which you co-"maintain".
When running with lockdep, that bug (a) introduces bugs
in some drivers and (b) hides bugs in others.  You've
rejected even a minimal warning fix, to help minimize
the amount of time developers waste on (a) and (b).

Attacking folk for having to cope with such bugs escalates
things beyond "unfortunate".  If lockdep is "maintained",
your response should be fixing that lockdep bug.  Once
that's done, all workarounds for that bug can be removed.


> There's plenty good reasons for mandating that irq handlers run with
> irqs disabled, if you need threaded handlers -- that's fine, but then
> teach the generic code about them.

There are many ways to "teach" such things, of course,
and the learning goes both ways ... the initial set of
perceived requirements changes when 

And since there have been folk at work on such issues for
some time, I'm not sure why you think I shouldn't give
them a fair chance to deliver, and help improve those
(long anticipated) solutions.  There's a saying that
"too many cooks spoil the broth"; and in software, it's
well known that extra developers aren't necessarily any
kind of help.


> What you do _NOT_ do is hack your way around things, that's not how
> Linux works, and by doing that you make the world a slightly worse place
> for everyone.

Linux has lots of bug workarounds and odd constraints, like
any other large system does.  The "world" is full of them;
DNA-coded machinery is felt to consist *mostly* of them.
(And many folk argue that monoculture is dangerous...)

The sign of a bad workaround is that it sits in core code
and impacts everything using it.  Like, oh, that lockdep
bug, preventing various systems from ever using it because
they rely on mechanisms broken by that bug.


On the other hand, the main valid complaint about one-line
workarounds is needing them at all.  Boiling down a system
misbehavior to a one-line workaround *IS* a way to help
make the (kernel) world a better place, by fingerpointing
a real issue ... setting trail markers for a better way.

In this case there's a real bug in the lockdep code.

The recent threaded IRQ proposal moves some support down
a layer (into genirq) and generalizes it a bit, but some
drivers (e.g. I2C ones) have threaded IRQs for a long time
now -- out of necessity, not just performance tweaking.

- Dave

--
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