Linux Kernel Mailing List <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]