linux-kernel - Re: [patch 2.6.24-rc2 1/3] generic gpio -- gpio

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]

Message-Id: <200711132252.15872.david-b@pacbell.net>
Date:	Tue, 13 Nov 2007 22:52:15 -0800
From:	David Brownell <david-b@...bell.net>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Ingo Molnar <mingo@...e.hu>,
	Linux Kernel list <linux-kernel@...r.kernel.org>,
	Florian Fainelli <florian.fainelli@...ecomint.eu>,
	Haavard Skinnemoen <hskinnemoen@...el.com>,
	Nick Piggin <nickpiggin@...oo.com.au>
Subject: Re: [patch 2.6.24-rc2 1/3] generic gpio -- gpio_chip support

On Tuesday 13 November 2007, Andrew Morton wrote:
> 
> > >      Why do you want to use raw_spinlock_t?
> > 
> > Already answered elsewhere in this thread ...
> 
> Can't say I really understood the answer.  I don't think we
> actually know where all of this extra time is being spent?

Reading that, one could think performance was the only factor.
But it isn't, and wasn't the one which really persuaded me.

And yes we do where that time went.  Although it seems that
repeating that info once again won't help...

> > I'll highlight the
> > point that such bitops shouldn't be preemption points.
> 
> Disagree.  *everything* should be a preemption point.

So it's wrong that <asm-generic/bitops/atomic.h> uses the
same calls to prevent *those* bitops from being prempted?

Thus, that code should switch over to normal spinlocks...

I believe that if I submitted patches to do that, there'd
be a not-so-small riot.  And the arguments would all boil
down to much the same ones applying to *these* bitops...

> For internal-implementation
> details we do need to disable preemtion sometimes 
> (to prevent deadlocks and to protect per-cpu resources).

You're certainly talking about "internal-implementation
details" in this case.  It's not like the lock is used
outside of those routines.  Or as if other implementations
would even *need* such a lock.  (Just like the IRQ table,
if the entries can't be removed and are all set up very
early, locking would be pointless.)

> But those 
> preemption-off periods should be minimised.

Like the three instructions in the "hot paths" for getting
and setting GPIO values, when using raw spinlocks ... check.

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