| 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
| ||
|
Message-ID: <20070911192219.2e089493@laptopd505.fenrus.org> Date: Tue, 11 Sep 2007 19:22:19 +0100 From: Arjan van de Ven <arjan@...radead.org> To: Matti Linnanvuori <mattilinnanvuori@...oo.com> Cc: linux-kernel@...r.kernel.org Subject: Re: Do not deprecate binary semaphore or do allow mutex in software interrupt contexts On Tue, 11 Sep 2007 09:20:23 -0700 (PDT) Matti Linnanvuori <mattilinnanvuori@...oo.com> wrote: > Arjan van de Ven: > > what do you do if the trylock fails? > > Just do not read the status variable now but modify the timer to run > later. > > > to be honest, the scenario describe really smells of broken > > locking, in fact it really sounds like it wants to use spinlocks > > instead > > No, I don't think it is broken. > Spinlocks can be used, but I don't see them being obviously better in > all cases. If access takes a long time, it is better to sleep during > it. And if you sleep, you might just end up creating a new mutex > implementation with a spinlock. at this point the discussion has gone so theoretical that I think it's better to go with a real example. What actual source code do you think is a legit case for this? I still think that whatever case you have in mind is better served with something else, but until we see the actual complete drier we're both talking air. - 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