All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcin Jabrzyk <m.jabrzyk@samsung.com>
To: Damian Eppel <d.eppel@samsung.com>,
	daniel.lezcano@linaro.org, tglx@linutronix.de, kgene@kernel.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-samsung-soc@vger.kernel.org
Cc: kyungmin.park@samsung.com, b.zolnierkie@samsung.com,
	stable@vger.kernel.org
Subject: Re: [PATCH] clocksource: exynos_mct: fix for sleeping in atomic ctx handling cpu hotplug notif.
Date: Mon, 02 Feb 2015 09:42:33 +0100	[thread overview]
Message-ID: <54CF3879.7080908@samsung.com> (raw)
In-Reply-To: <1422627691-10774-1-git-send-email-d.eppel@samsung.com>



On 30/01/15 15:21, Damian Eppel wrote:
> This is to fix an issue of sleeping in atomic context when processing
> hotplug notifications in Exynos MCT(Multi-Core Timer).
> The issue was reproducible on Exynos 3250 (Rinato board) and Exynos 5420
> (Arndale Octa board).
>
> Whilst testing cpu hotplug events on kernel configured with DEBUG_PREEMPT
> and DEBUG_ATOMIC_SLEEP we get following BUG message, caused by calling
> request_irq() and free_irq() in the context of hotplug notification
> (which is in this case atomic context).
>
> root@target:~# echo 0 > /sys/devices/system/cpu/cpu1/online
>
> [   25.157867] IRQ18 no longer affine to CPU1
> ...
> [   25.158445] CPU1: shutdown
>
> root@target:~# echo 1 > /sys/devices/system/cpu/cpu1/online
>
> [   40.785859] CPU1: Software reset
> [   40.786660] BUG: sleeping function called from invalid context at mm/slub.c:1241
> [   40.786668] in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/1
> [   40.786678] Preemption disabled at:[<  (null)>]   (null)
> [   40.786681]
> [   40.786692] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.19.0-rc4-00024-g7dca860 #36
> [   40.786698] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> [   40.786728] [<c0014a00>] (unwind_backtrace) from [<c0011980>] (show_stack+0x10/0x14)
> [   40.786747] [<c0011980>] (show_stack) from [<c0449ba0>] (dump_stack+0x70/0xbc)
> [   40.786767] [<c0449ba0>] (dump_stack) from [<c00c6124>] (kmem_cache_alloc+0xd8/0x170)
> [   40.786785] [<c00c6124>] (kmem_cache_alloc) from [<c005d6f8>] (request_threaded_irq+0x64/0x128)
> [   40.786804] [<c005d6f8>] (request_threaded_irq) from [<c0350b8c>] (exynos4_local_timer_setup+0xc0/0x13c)
> [   40.786820] [<c0350b8c>] (exynos4_local_timer_setup) from [<c0350ca8>] (exynos4_mct_cpu_notify+0x30/0xa8)
> [   40.786838] [<c0350ca8>] (exynos4_mct_cpu_notify) from [<c003b330>] (notifier_call_chain+0x44/0x84)
> [   40.786857] [<c003b330>] (notifier_call_chain) from [<c0022fd4>] (__cpu_notify+0x28/0x44)
> [   40.786873] [<c0022fd4>] (__cpu_notify) from [<c0013714>] (secondary_start_kernel+0xec/0x150)
> [   40.786886] [<c0013714>] (secondary_start_kernel) from [<40008764>] (0x40008764)
>
> Solution:
> Clockevent irqs cannot be requested/freed every time cpu is
> hot-plugged/unplugged as CPU_STARTING/CPU_DYING notifications
> that signals hotplug or unplug events are sent with both preemption
> and local interrupts disabled. Since request_irq() may sleep it is
> moved to the initialization stage and performed for all possible
> cpus prior putting them online. Then, in the case of hotplug event
> the irq asociated with the given cpu will simply be enabled.
> Similarly on cpu unplug event the interrupt is not freed but just
> disabled.
>
> Note that after successful request_irq() call for a clockevent device
> associated to given cpu the requested irq is disabled (via disable_irq()).
> That is to make things symmetric as we expect hotplug event as a next
> thing (which will enable irq again). This should not pose any problems
> because at the time of requesting irq the clockevent device is not
> fully initialized yet, therefore should not produce interrupts at that point.
>
> For disabling an irq at cpu unplug notification disable_irq_nosync() is
> chosen which is a non-blocking function. This again shouldn't be a problem as
> prior sending CPU_DYING notification interrupts are migrated away
> from the cpu.
>
> Fixes: 7114cd749a12 ("clocksource: exynos_mct: use (request/free)_irq calls for local timer registration")
> Signed-off-by: Damian Eppel <d.eppel@samsung.com>
> Cc: <stable@vger.kernel.org>
> Reported-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> ---
>   drivers/clocksource/exynos_mct.c | 45 ++++++++++++++++++++++++++++------------
>   1 file changed, 32 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
> index 83564c9..9beca58 100644
> --- a/drivers/clocksource/exynos_mct.c
> +++ b/drivers/clocksource/exynos_mct.c
> @@ -466,15 +466,12 @@ static int exynos4_local_timer_setup(struct clock_event_device *evt)
>   	exynos4_mct_write(TICK_BASE_CNT, mevt->base + MCT_L_TCNTB_OFFSET);
>
>   	if (mct_int_type == MCT_INT_SPI) {
> -		evt->irq = mct_irqs[MCT_L0_IRQ + cpu];
> -		if (request_irq(evt->irq, exynos4_mct_tick_isr,
> -				IRQF_TIMER | IRQF_NOBALANCING,
> -				evt->name, mevt)) {
> -			pr_err("exynos-mct: cannot register IRQ %d\n",
> -				evt->irq);
> +
> +		if (evt->irq == -1)
>   			return -EIO;
> -		}
> -		irq_force_affinity(mct_irqs[MCT_L0_IRQ + cpu], cpumask_of(cpu));
> +
> +		irq_force_affinity(evt->irq, cpumask_of(cpu));
> +		enable_irq(evt->irq);
>   	} else {
>   		enable_percpu_irq(mct_irqs[MCT_L0_IRQ], 0);
>   	}
> @@ -487,10 +484,12 @@ static int exynos4_local_timer_setup(struct clock_event_device *evt)
>   static void exynos4_local_timer_stop(struct clock_event_device *evt)
>   {
>   	evt->set_mode(CLOCK_EVT_MODE_UNUSED, evt);
> -	if (mct_int_type == MCT_INT_SPI)
> -		free_irq(evt->irq, this_cpu_ptr(&percpu_mct_tick));
> -	else
> +	if (mct_int_type == MCT_INT_SPI) {
> +		if (evt->irq != -1)
> +			disable_irq_nosync(evt->irq);
> +	} else {
>   		disable_percpu_irq(mct_irqs[MCT_L0_IRQ]);
> +	}
>   }
>
>   static int exynos4_mct_cpu_notify(struct notifier_block *self,
> @@ -522,7 +521,7 @@ static struct notifier_block exynos4_mct_cpu_nb = {
>
>   static void __init exynos4_timer_resources(struct device_node *np, void __iomem *base)
>   {
> -	int err;
> +	int err, cpu;
>   	struct mct_clock_event_device *mevt = this_cpu_ptr(&percpu_mct_tick);
>   	struct clk *mct_clk, *tick_clk;
>
> @@ -549,7 +548,27 @@ static void __init exynos4_timer_resources(struct device_node *np, void __iomem
>   		WARN(err, "MCT: can't request IRQ %d (%d)\n",
>   		     mct_irqs[MCT_L0_IRQ], err);
>   	} else {
> -		irq_set_affinity(mct_irqs[MCT_L0_IRQ], cpumask_of(0));
> +		for_each_possible_cpu(cpu) {
> +			int mct_irq = mct_irqs[MCT_L0_IRQ + cpu];
> +			struct mct_clock_event_device *pcpu_mevt =
> +				per_cpu_ptr(&percpu_mct_tick, cpu);
> +
> +			pcpu_mevt->evt.irq = -1;
> +
> +			if (request_irq(mct_irq,
> +					exynos4_mct_tick_isr,
> +					IRQF_TIMER | IRQF_NOBALANCING,
> +					pcpu_mevt->name, pcpu_mevt)) {
> +				pr_err("exynos-mct: cannot register IRQ (cpu%d)\n",
> +									cpu);
> +
> +				continue;
> +			}
> +			pcpu_mevt->evt.irq = mct_irq;
> +			irq_force_affinity(mct_irq, cpumask_of(cpu));
> +
> +			disable_irq(mct_irq);
> +		}
>   	}
>
>   	err = register_cpu_notifier(&exynos4_mct_cpu_nb);
>

Tested-by: Marcin Jabrzyk <m.jabrzyk@samsung.com>

Test hardware: Rinato B2 (Exynos 3250) board

I can confirm that this fixes bug reported here [1] "BUG appearing when 
trying to allocate interrupt on Exynos MCT after CPU hotplug".


[1] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/296500.html

Best regards,
Marcin Jabrzyk

Samsung R&D Institute Poland
Samsung Electronics

WARNING: multiple messages have this Message-ID (diff)
From: m.jabrzyk@samsung.com (Marcin Jabrzyk)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] clocksource: exynos_mct: fix for sleeping in atomic ctx handling cpu hotplug notif.
Date: Mon, 02 Feb 2015 09:42:33 +0100	[thread overview]
Message-ID: <54CF3879.7080908@samsung.com> (raw)
In-Reply-To: <1422627691-10774-1-git-send-email-d.eppel@samsung.com>



On 30/01/15 15:21, Damian Eppel wrote:
> This is to fix an issue of sleeping in atomic context when processing
> hotplug notifications in Exynos MCT(Multi-Core Timer).
> The issue was reproducible on Exynos 3250 (Rinato board) and Exynos 5420
> (Arndale Octa board).
>
> Whilst testing cpu hotplug events on kernel configured with DEBUG_PREEMPT
> and DEBUG_ATOMIC_SLEEP we get following BUG message, caused by calling
> request_irq() and free_irq() in the context of hotplug notification
> (which is in this case atomic context).
>
> root at target:~# echo 0 > /sys/devices/system/cpu/cpu1/online
>
> [   25.157867] IRQ18 no longer affine to CPU1
> ...
> [   25.158445] CPU1: shutdown
>
> root at target:~# echo 1 > /sys/devices/system/cpu/cpu1/online
>
> [   40.785859] CPU1: Software reset
> [   40.786660] BUG: sleeping function called from invalid context at mm/slub.c:1241
> [   40.786668] in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/1
> [   40.786678] Preemption disabled at:[<  (null)>]   (null)
> [   40.786681]
> [   40.786692] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.19.0-rc4-00024-g7dca860 #36
> [   40.786698] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> [   40.786728] [<c0014a00>] (unwind_backtrace) from [<c0011980>] (show_stack+0x10/0x14)
> [   40.786747] [<c0011980>] (show_stack) from [<c0449ba0>] (dump_stack+0x70/0xbc)
> [   40.786767] [<c0449ba0>] (dump_stack) from [<c00c6124>] (kmem_cache_alloc+0xd8/0x170)
> [   40.786785] [<c00c6124>] (kmem_cache_alloc) from [<c005d6f8>] (request_threaded_irq+0x64/0x128)
> [   40.786804] [<c005d6f8>] (request_threaded_irq) from [<c0350b8c>] (exynos4_local_timer_setup+0xc0/0x13c)
> [   40.786820] [<c0350b8c>] (exynos4_local_timer_setup) from [<c0350ca8>] (exynos4_mct_cpu_notify+0x30/0xa8)
> [   40.786838] [<c0350ca8>] (exynos4_mct_cpu_notify) from [<c003b330>] (notifier_call_chain+0x44/0x84)
> [   40.786857] [<c003b330>] (notifier_call_chain) from [<c0022fd4>] (__cpu_notify+0x28/0x44)
> [   40.786873] [<c0022fd4>] (__cpu_notify) from [<c0013714>] (secondary_start_kernel+0xec/0x150)
> [   40.786886] [<c0013714>] (secondary_start_kernel) from [<40008764>] (0x40008764)
>
> Solution:
> Clockevent irqs cannot be requested/freed every time cpu is
> hot-plugged/unplugged as CPU_STARTING/CPU_DYING notifications
> that signals hotplug or unplug events are sent with both preemption
> and local interrupts disabled. Since request_irq() may sleep it is
> moved to the initialization stage and performed for all possible
> cpus prior putting them online. Then, in the case of hotplug event
> the irq asociated with the given cpu will simply be enabled.
> Similarly on cpu unplug event the interrupt is not freed but just
> disabled.
>
> Note that after successful request_irq() call for a clockevent device
> associated to given cpu the requested irq is disabled (via disable_irq()).
> That is to make things symmetric as we expect hotplug event as a next
> thing (which will enable irq again). This should not pose any problems
> because at the time of requesting irq the clockevent device is not
> fully initialized yet, therefore should not produce interrupts at that point.
>
> For disabling an irq at cpu unplug notification disable_irq_nosync() is
> chosen which is a non-blocking function. This again shouldn't be a problem as
> prior sending CPU_DYING notification interrupts are migrated away
> from the cpu.
>
> Fixes: 7114cd749a12 ("clocksource: exynos_mct: use (request/free)_irq calls for local timer registration")
> Signed-off-by: Damian Eppel <d.eppel@samsung.com>
> Cc: <stable@vger.kernel.org>
> Reported-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> ---
>   drivers/clocksource/exynos_mct.c | 45 ++++++++++++++++++++++++++++------------
>   1 file changed, 32 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
> index 83564c9..9beca58 100644
> --- a/drivers/clocksource/exynos_mct.c
> +++ b/drivers/clocksource/exynos_mct.c
> @@ -466,15 +466,12 @@ static int exynos4_local_timer_setup(struct clock_event_device *evt)
>   	exynos4_mct_write(TICK_BASE_CNT, mevt->base + MCT_L_TCNTB_OFFSET);
>
>   	if (mct_int_type == MCT_INT_SPI) {
> -		evt->irq = mct_irqs[MCT_L0_IRQ + cpu];
> -		if (request_irq(evt->irq, exynos4_mct_tick_isr,
> -				IRQF_TIMER | IRQF_NOBALANCING,
> -				evt->name, mevt)) {
> -			pr_err("exynos-mct: cannot register IRQ %d\n",
> -				evt->irq);
> +
> +		if (evt->irq == -1)
>   			return -EIO;
> -		}
> -		irq_force_affinity(mct_irqs[MCT_L0_IRQ + cpu], cpumask_of(cpu));
> +
> +		irq_force_affinity(evt->irq, cpumask_of(cpu));
> +		enable_irq(evt->irq);
>   	} else {
>   		enable_percpu_irq(mct_irqs[MCT_L0_IRQ], 0);
>   	}
> @@ -487,10 +484,12 @@ static int exynos4_local_timer_setup(struct clock_event_device *evt)
>   static void exynos4_local_timer_stop(struct clock_event_device *evt)
>   {
>   	evt->set_mode(CLOCK_EVT_MODE_UNUSED, evt);
> -	if (mct_int_type == MCT_INT_SPI)
> -		free_irq(evt->irq, this_cpu_ptr(&percpu_mct_tick));
> -	else
> +	if (mct_int_type == MCT_INT_SPI) {
> +		if (evt->irq != -1)
> +			disable_irq_nosync(evt->irq);
> +	} else {
>   		disable_percpu_irq(mct_irqs[MCT_L0_IRQ]);
> +	}
>   }
>
>   static int exynos4_mct_cpu_notify(struct notifier_block *self,
> @@ -522,7 +521,7 @@ static struct notifier_block exynos4_mct_cpu_nb = {
>
>   static void __init exynos4_timer_resources(struct device_node *np, void __iomem *base)
>   {
> -	int err;
> +	int err, cpu;
>   	struct mct_clock_event_device *mevt = this_cpu_ptr(&percpu_mct_tick);
>   	struct clk *mct_clk, *tick_clk;
>
> @@ -549,7 +548,27 @@ static void __init exynos4_timer_resources(struct device_node *np, void __iomem
>   		WARN(err, "MCT: can't request IRQ %d (%d)\n",
>   		     mct_irqs[MCT_L0_IRQ], err);
>   	} else {
> -		irq_set_affinity(mct_irqs[MCT_L0_IRQ], cpumask_of(0));
> +		for_each_possible_cpu(cpu) {
> +			int mct_irq = mct_irqs[MCT_L0_IRQ + cpu];
> +			struct mct_clock_event_device *pcpu_mevt =
> +				per_cpu_ptr(&percpu_mct_tick, cpu);
> +
> +			pcpu_mevt->evt.irq = -1;
> +
> +			if (request_irq(mct_irq,
> +					exynos4_mct_tick_isr,
> +					IRQF_TIMER | IRQF_NOBALANCING,
> +					pcpu_mevt->name, pcpu_mevt)) {
> +				pr_err("exynos-mct: cannot register IRQ (cpu%d)\n",
> +									cpu);
> +
> +				continue;
> +			}
> +			pcpu_mevt->evt.irq = mct_irq;
> +			irq_force_affinity(mct_irq, cpumask_of(cpu));
> +
> +			disable_irq(mct_irq);
> +		}
>   	}
>
>   	err = register_cpu_notifier(&exynos4_mct_cpu_nb);
>

Tested-by: Marcin Jabrzyk <m.jabrzyk@samsung.com>

Test hardware: Rinato B2 (Exynos 3250) board

I can confirm that this fixes bug reported here [1] "BUG appearing when 
trying to allocate interrupt on Exynos MCT after CPU hotplug".


[1] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/296500.html

Best regards,
Marcin Jabrzyk

Samsung R&D Institute Poland
Samsung Electronics

  parent reply	other threads:[~2015-02-02  8:42 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-30 14:21 [PATCH] clocksource: exynos_mct: fix for sleeping in atomic ctx handling cpu hotplug notif Damian Eppel
2015-01-30 14:21 ` Damian Eppel
2015-02-02  8:24 ` Krzysztof Kozłowski
2015-02-02  8:24   ` Krzysztof Kozłowski
2015-02-02  8:42 ` Marcin Jabrzyk [this message]
2015-02-02  8:42   ` Marcin Jabrzyk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54CF3879.7080908@samsung.com \
    --to=m.jabrzyk@samsung.com \
    --cc=b.zolnierkie@samsung.com \
    --cc=d.eppel@samsung.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=kgene@kernel.org \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.