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? -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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
