linux-kernel - Re: [PATCH 3/3] do_exit(): do not panic if exiting thread is not serving an interrupt

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.02.1203221139190.2542@ionos>
Date:	Thu, 22 Mar 2012 12:56:55 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Alexander Gordeev <agordeev@...hat.com>
cc:	LKML <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...nel.org>
Subject: Re: [PATCH 3/3] do_exit(): do not panic if exiting thread is not
 serving an interrupt

On Mon, 19 Mar 2012, Alexander Gordeev wrote:

> Currently a crashed and killed forced oneshot threaded handler hits
> in_interrupt() check in do_exit() and panics. As result, the code that
> cleans up IRQ descriptor never not get called and IRQ line stays masked.
> 
> Similarly non-forced oneshot threaded handlers that crashed while holding
> bh lock leave a IRQ line masked.
> 
> Regular threaded handlers that crashed while holding bh simply panic,
> although they could have just terminate loudly.
> 
> This fix allows IRQ threaded handlers get killed gracefully instead of
> panicking.
> 
> Since introduction of SOFTIRQ_DISABLE_OFFSET in 75e1056 we can differ
> between bh being serviced and bh being disabled. Use this ability to
> avoid unnecessary crashes when a exiting thread explicitly disabled bh
> and is not serving any softirq. Still we will get the regular warning
> that exiting thread is in atomic context.

Hmm, this applies for all threads which exit with bh disabled. We risk
data corruption this way as the crash of a task might happen within a
data set manipulation protected by bh_disable.

Not sure whether the chance to get debug information from the machine
is worth the risk of data corruption causes follow up problems.
 
Thanks,

	tglx


> Signed-off-by: Alexander Gordeev <agordeev@...hat.com>
> ---
>  include/linux/hardirq.h |    4 ++++
>  kernel/exit.c           |    2 +-
>  2 files changed, 5 insertions(+), 1 deletions(-)
> 
> diff --git a/include/linux/hardirq.h b/include/linux/hardirq.h
> index bb7f309..93aca12 100644
> --- a/include/linux/hardirq.h
> +++ b/include/linux/hardirq.h
> @@ -82,11 +82,15 @@
>   * Are we in a softirq context? Interrupt context?
>   * in_softirq - Are we currently processing softirq or have bh disabled?
>   * in_serving_softirq - Are we currently processing softirq?
> + * in_serving_interrupt - Are we currently processing softirq, nmi or
> + *                        hardware interrupt?
>   */
>  #define in_irq()		(hardirq_count())
>  #define in_softirq()		(softirq_count())
>  #define in_interrupt()		(irq_count())
>  #define in_serving_softirq()	(softirq_count() & SOFTIRQ_OFFSET)
> +#define in_serving_interrupt()	(preempt_count() & (HARDIRQ_MASK \
> +					 | SOFTIRQ_OFFSET | NMI_MASK))
>  
>  /*
>   * Are we in NMI context?
> diff --git a/kernel/exit.c b/kernel/exit.c
> index 752d2c0..0c78ae6 100644
> --- a/kernel/exit.c
> +++ b/kernel/exit.c
> @@ -896,7 +896,7 @@ void do_exit(long code)
>  
>  	WARN_ON(blk_needs_flush_plug(tsk));
>  
> -	if (unlikely(in_interrupt()))
> +	if (unlikely(in_serving_interrupt()))
>  		panic("Aiee, killing interrupt handler!");
>  	if (unlikely(!tsk->pid))
>  		panic("Attempted to kill the idle task!");
> -- 
> 1.7.7.6
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/