linux-kernel - Re: [PATCH 1/2] lockdep: implement full check without irq checking

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: <1225362995.3690.10.camel@johannes.berg>
Date:	Thu, 30 Oct 2008 11:36:35 +0100
From:	Johannes Berg <johannes@...solutions.net>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Linux Kernel list <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH 1/2] lockdep: implement full check without irq checking

On Wed, 2008-10-29 at 16:23 +0100, Peter Zijlstra wrote:

> This thing worries me, can you help my exhausted brain a long a little..
> 
> So I take it the idea is to couple the lock chains of the site calling
> del_timer_sync and the actual timer.
> 
> We do this by holding a fake lock while executing the timer, so that its
> lock chain starts with that lock.
> 
> We then acquire the fake lock on del_timer_sync so as to establish a
> relation.

Right. Same way as the workqueue code. Mind you, I'm not sure this is
even worth it, in running it I haven't found a bug and I because timer
code may not sleep you can only take spinlocks in them, and I suspect
that it's unlikely somebody will try to cancel_sync a timer under a
spinlock, though it is of course possible.

> Now you get warnings about using a lock in hardirq context that was
> previously used !irq-safe, right?
> 
> So why not simply write something like:
> 
> 
> del_timer_sync():
> 
>   local_irq_save(flags);
>   lock_aquire(my fake timer lock);
>   lock_release(...);
>   local_irq_restore(flags);
> 
> and make that conditional CONFIG_PROVE_LOCKING and or wrap it up
> somewhere..

Yeah, that is possible, but it seemed to me that would affect the
performance of del_timer_sync() quite a bit. Not sure it matters. And on
powerpc (which I care about) it won't actually affect performance much
because we lazily disable IRQs, but still. The >= 2 change also seemed
to generate smaller code?

johannes

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)