Re: [CRYPTO]: Only reschedule if !in_atomic()

[Andrew Morton]

Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx> wrote:
>
> The netlink gfp_any() problem made me double-check the uses of in_softirq()
> in crypto/*.  It seems to me that we should be checking in_atomic() instead
> of in_softirq() in crypto_yield.  Otherwise people calling the crypto ops
> with spin locks held or preemption disabled will get burnt, right?
> 

Sort-of, but the code is still wrong.

> 
>  crypto/internal.h |    2 +-
>  1 files changed, 1 insertion(+), 1 deletion(-)
> 
> Index: crypto/internal.h
> ===================================================================
> --- dade029a8df8b249d14282d8f8023a0de0f6c1e7/crypto/internal.h  (mode:100644 sha1:e68e43886d3cc23439f30210e88b517911bf395e)
> +++ c48106158bce4c7af328c486b7f33ad2133459ee/crypto/internal.h  (mode:100644 sha1:964b9a60ca24413f07b1fe8410f7ac3198642135)
> @@ -38,7 +38,7 @@ static inline void crypto_kunmap(void *v
>  
>  static inline void crypto_yield(struct crypto_tfm *tfm)
>  {
> -	if (!in_softirq())
> +	if (!in_atomic())
>  		cond_resched();
>  }

This code can cause deadlocks on CONFIG_SMP && !CONFIG_PREEMPT kernels.

Please see http://lkml.org/lkml/2005/3/10/358

You (the programmer) *have* to know what context you're running in before
doing a voluntary yield.  There is simply no way to work this out at
runtime.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/