On Fri, 2013-11-29 at 09:50 +0800, Herbert Xu wrote: > On Thu, Nov 28, 2013 at 04:39:43PM +0100, Harald Freudenberger wrote: > > > > > You can't use mutex_lock because you may be in a non-sleepable > > > context. Perhaps just fall back to doing it block-by-block, like > > > we do in aesni-intel on x86? > > > > The first attempt to lock the mutex is done with mutex_trylock() which > > should be safe for non-sleepable context. If this fails, an attempt is > > made to allocate a fresh page __get_free_page(GFP_ATOMIC). If this also > > fails, well what could be done then ? I think, it is valid to wait for > > the preallocated page to get released with an mutex_lock(). Should I > > really add code here for handling the 3rd level of the exceptional > > path ? > > If it's wrong per se, how does hiding it behind two if's make it > OK? Sorry, I got the point now. Will do a rework of the patch according to your hints. Thanks
-- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
