On Tue, May 19, 2015 at 03:51:55PM +0800, Herbert Xu wrote: > On Tue, May 19, 2015 at 09:35:15AM +0200, Stephan Mueller wrote: > > > > Thank you for the hints. I will follow your guidance. > > > > Just for my edification: why is this (rather complex sounding) approach > > preferred over a simple cancel API? Other async APIs (e.g. the AIO syscalls > > with io_cancel) have such cancel operations. > > > > Such cancel function would be as simple as: > > You're right. The cancel function is indeed simpler. I can > certainly live with that. I'm not at all convinced it's simpler. I see it add a huge amount of hair to drivers/char/random.c that is only used by a single caller. I'm also not sure I understand herbert's suggstion of adding a struct module to the /dev/random code. Why is this helpful, and what is the race that you are trying to protect against? Finally, this is only going to block *once*, when the system is initially botting up. Why is it so important that we get the asynchronous nature of this right, and why can't we solve it simply by just simply doing the work in a workqueue, with a completion barrier getting triggered once /dev/random initializes itself, and just simply blocking the module unload until /dev/random is initialized? - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
