linux-kernel - RE: [PATCH] fix hrtimer_enqueue

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 5 Feb 2013 14:36:51 +0200
From:	"Leonid Shatz" <leonid.shatz@...ellosystems.com>
To:	"'Thomas Gleixner'" <tglx@...utronix.de>
Cc:	"'Izik Eidus'" <izik.eidus@...ellosystems.com>,
	"'Andrea Arcangeli'" <aarcange@...hat.com>,
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] fix hrtimer_enqueue_reprogram race

> > There are already locks used inside hrtimer code, so why should users
> > of the hrtimer add another layer of locks and get involved in the
> > intricacy of which cases are protected by internal hrtimer lock and
> > which are not?
> 
> Groan. The hrtimer locks are there to protect the internal data structures
of
> the hrtimer code and to ensure that hrtimer functions are proper protected
> against concurrent running callbacks. But that does not give you any kind
of
> protection versus multiple users of your hrtimer resource.
> 

I was not raising the issue of protecting the logic of hrtimer use cases -
this was not the scope of the entire issue. The issue was that internal
hrtimer locks were getting screwed and it was not reasonable to add external
layer of locks to protect internal hrtimer locks (I mean before this patch).
The fix should provide protection for internal locks and I think we both
agree on that.

Leonid

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