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
| ||
|
Date: Sat, 23 Jun 2007 22:32:55 +0530 From: "Satyam Sharma" <satyam.sharma@...il.com> To: "Oliver Neukum" <oliver@...kum.org> Cc: "Arnd Bergmann" <arnd@...db.de>, "Robert P. J. Day" <rpjday@...dspring.com>, "Florin Iucha" <florin@...ha.net>, "Linux Kernel Mailing List" <linux-kernel@...r.kernel.org> Subject: Re: "upping" a semaphore from interrupt context? On 6/23/07, Oliver Neukum <oliver@...kum.org> wrote: > Am Samstag, 23. Juni 2007 schrieb Satyam Sharma: > > * 3. set up a timer and schedule another function to service the > > * interrupt / do what needs to be done then, hopefully the mutex > > * would be uncontended then => *gargh* > > You could use schedule_work(). However then why not use it always. > This would make sense if what you want to do is outright trivial. If you use schedule_work() to pass off work from interrupt context to process context, then you wouldn't be calling down_trylock() from interrupt context in the first place (which is what is being discussed here). You would simply pass off the entire code that uses the shared data (and wraps a *proper* down() or mutex_lock() around it, not the _trylock() variant) to the workqueue. Also, that is precisely my point too. What I'm saying is that it is generally poor design to be wanting to use the _trylock() variant of semaphore / mutex in interrupt context. Workqueues _are_ the preferred mechanism to use for (most) such cases where you need to do something that may require you to sleep. Satyam - 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