Re: [Intel-gfx] [PATCH] rtc: cmos: Don't enable interrupts in the middle of the interrupt handler

2016-10-20 Thread Alexandre Belloni 
On 19/10/2016 at 21:02:04 +0300, ville.syrj...@linux.intel.com wrote :
> From: Ville Syrjälä 
> 
> Using spin_lock_irq()/spin_unlock_irq() from within the interrupt
> handler is a no-no. Let's save/restore the flags to avoid turning on
> interrupts prematurely.
> 
> We hit this in a bunch of our CI systems, but for whatever reason I
> wasn't able to reproduce on my own machine, so this fix is just
> based on the backtrace.
> 
> [  202.634918] WARNING: CPU: 0 PID: 0 at kernel/locking/lockdep.c:2729 
> trace_hardirqs_on_caller+0x113/0x1b0
> [  202.634919] DEBUG_LOCKS_WARN_ON(current->hardirq_context)
> [  202.634929] Modules linked in: snd_hda_intel i915 x86_pkg_temp_thermal 
> intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel 
> lpc_ich snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi 
> snd_hda_codec snd_hwdep i2c_designware_platform i2c_designware_core 
> snd_hda_core mei_me mei snd_pcm r8169 mii sdhci_acpi sdhci mmc_core i2c_hid 
> [last unloaded: i915]
> [  202.634930] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G U  
> 4.9.0-rc1-CI-CI_DRM_1734+ #1
> [  202.634931] Hardware name: GIGABYTE M4HM87P-00/M4HM87P-00, BIOS F6 
> 12/10/2014
> [  202.634933]  88011ea03d68 8142dce5 88011ea03db8 
> 
> [  202.634934]  88011ea03da8 8107e496 0aa90002 
> 81e249a0
> [  202.634935]  81815637 82e7c280  
> 0004
> [  202.634936] Call Trace:
> [  202.634939]  
> [  202.634939]  [] dump_stack+0x67/0x92
> [  202.634941]  [] __warn+0xc6/0xe0
> [  202.634944]  [] ? _raw_spin_unlock_irq+0x27/0x50
> [  202.634945]  [] warn_slowpath_fmt+0x4a/0x50
> [  202.634946]  [] trace_hardirqs_on_caller+0x113/0x1b0
> [  202.634948]  [] trace_hardirqs_on+0xd/0x10
> [  202.634949]  [] _raw_spin_unlock_irq+0x27/0x50
> [  202.634951]  [] rtc_handler+0x32/0xa0
> [  202.634954]  [] acpi_ev_fixed_event_detect+0xd4/0xfb
> [  202.634956]  [] acpi_ev_sci_xrupt_handler+0xf/0x2d
> [  202.634957]  [] acpi_irq+0x11/0x2c
> [  202.634960]  [] __handle_irq_event_percpu+0x58/0x370
> [  202.634961]  [] handle_irq_event_percpu+0x1e/0x50
> [  202.634962]  [] handle_irq_event+0x34/0x60
> [  202.634963]  [] handle_fasteoi_irq+0xa6/0x170
> [  202.634966]  [] handle_irq+0x15/0x20
> [  202.634967]  [] do_IRQ+0x68/0x130
> [  202.634968]  [] common_interrupt+0x89/0x89
> [  202.634970]  
> [  202.634970]  [] ? mwait_idle+0x93/0x210
> [  202.634971]  [] ? mwait_idle+0x8a/0x210
> [  202.634972]  [] arch_cpu_idle+0xa/0x10
> [  202.634973]  [] default_idle_call+0x1e/0x30
> [  202.634974]  [] cpu_startup_entry+0x17c/0x1f0
> [  202.634976]  [] rest_init+0x127/0x130
> [  202.634978]  [] start_kernel+0x3f6/0x403
> [  202.634980]  [] x86_64_start_reservations+0x2a/0x2c
> [  202.634981]  [] x86_64_start_kernel+0x173/0x186
> [  202.634982] ---[ end trace 293c99618fa08d34 ]---
> 
> Cc: Gabriele Mazzotta 
> Cc: Alexandre Belloni 
> Fixes: 983bf1256edb ("rtc: cmos: Clear ACPI-driven alarms upon resume")
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/rtc/rtc-cmos.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
Applied, thanks.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] rtc: cmos: Don't enable interrupts in the middle of the interrupt handler

2016-10-19 Thread Ville Syrjälä 
On Wed, Oct 19, 2016 at 07:16:39PM +0100, Chris Wilson wrote:
> On Wed, Oct 19, 2016 at 09:02:04PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > Using spin_lock_irq()/spin_unlock_irq() from within the interrupt
> > handler is a no-no. Let's save/restore the flags to avoid turning on
> > interrupts prematurely.
> > 
> > We hit this in a bunch of our CI systems, but for whatever reason I
> > wasn't able to reproduce on my own machine, so this fix is just
> > based on the backtrace.
> > 
> > [  202.634918] WARNING: CPU: 0 PID: 0 at kernel/locking/lockdep.c:2729 
> > trace_hardirqs_on_caller+0x113/0x1b0
> > [  202.634919] DEBUG_LOCKS_WARN_ON(current->hardirq_context)
> > [  202.634929] Modules linked in: snd_hda_intel i915 x86_pkg_temp_thermal 
> > intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel 
> > lpc_ich snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi 
> > snd_hda_codec snd_hwdep i2c_designware_platform i2c_designware_core 
> > snd_hda_core mei_me mei snd_pcm r8169 mii sdhci_acpi sdhci mmc_core i2c_hid 
> > [last unloaded: i915]
> > [  202.634930] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G U  
> > 4.9.0-rc1-CI-CI_DRM_1734+ #1
> > [  202.634931] Hardware name: GIGABYTE M4HM87P-00/M4HM87P-00, BIOS F6 
> > 12/10/2014
> > [  202.634933]  88011ea03d68 8142dce5 88011ea03db8 
> > 
> > [  202.634934]  88011ea03da8 8107e496 0aa90002 
> > 81e249a0
> > [  202.634935]  81815637 82e7c280  
> > 0004
> > [  202.634936] Call Trace:
> > [  202.634939]  
> > [  202.634939]  [] dump_stack+0x67/0x92
> > [  202.634941]  [] __warn+0xc6/0xe0
> > [  202.634944]  [] ? _raw_spin_unlock_irq+0x27/0x50
> > [  202.634945]  [] warn_slowpath_fmt+0x4a/0x50
> > [  202.634946]  [] trace_hardirqs_on_caller+0x113/0x1b0
> > [  202.634948]  [] trace_hardirqs_on+0xd/0x10
> > [  202.634949]  [] _raw_spin_unlock_irq+0x27/0x50
> > [  202.634951]  [] rtc_handler+0x32/0xa0
> > [  202.634954]  [] acpi_ev_fixed_event_detect+0xd4/0xfb
> > [  202.634956]  [] acpi_ev_sci_xrupt_handler+0xf/0x2d
> > [  202.634957]  [] acpi_irq+0x11/0x2c
> > [  202.634960]  [] __handle_irq_event_percpu+0x58/0x370
> > [  202.634961]  [] handle_irq_event_percpu+0x1e/0x50
> > [  202.634962]  [] handle_irq_event+0x34/0x60
> > [  202.634963]  [] handle_fasteoi_irq+0xa6/0x170
> > [  202.634966]  [] handle_irq+0x15/0x20
> > [  202.634967]  [] do_IRQ+0x68/0x130
> > [  202.634968]  [] common_interrupt+0x89/0x89
> > [  202.634970]  
> > [  202.634970]  [] ? mwait_idle+0x93/0x210
> > [  202.634971]  [] ? mwait_idle+0x8a/0x210
> > [  202.634972]  [] arch_cpu_idle+0xa/0x10
> > [  202.634973]  [] default_idle_call+0x1e/0x30
> > [  202.634974]  [] cpu_startup_entry+0x17c/0x1f0
> > [  202.634976]  [] rest_init+0x127/0x130
> > [  202.634978]  [] start_kernel+0x3f6/0x403
> > [  202.634980]  [] x86_64_start_reservations+0x2a/0x2c
> > [  202.634981]  [] x86_64_start_kernel+0x173/0x186
> > [  202.634982] ---[ end trace 293c99618fa08d34 ]---
> > 
> > Cc: Gabriele Mazzotta 
> > Cc: Alexandre Belloni 
> > Fixes: 983bf1256edb ("rtc: cmos: Clear ACPI-driven alarms upon resume")
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/rtc/rtc-cmos.c | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
> > index dd3d59806ffa..19cd49ad92dc 100644
> > --- a/drivers/rtc/rtc-cmos.c
> > +++ b/drivers/rtc/rtc-cmos.c
> > @@ -996,8 +996,9 @@ static u32 rtc_handler(void *context)
> > struct cmos_rtc *cmos = dev_get_drvdata(dev);
> > unsigned char rtc_control = 0;
> > unsigned char rtc_intr;
> > +   unsigned long flags;
> >  
> > -   spin_lock_irq(_lock);
> > +   spin_lock_irqsave(_lock, flags);
> 
> My reading of the acpi fixed event handlers suggests that this can only
> be called from interrupt context.

Ah, could be. I didn't bother digging quite that deep.

> 
> Anyway using irqsave is correct (just may be optimised away to a plain
> spin_lock() if the condition that this is only called in irq context is
> satisfied).
> 
> Reviewed-by: Chris Wilson 
> -Chris
> 
> -- 
> Chris Wilson, Intel Open Source Technology Centre

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] rtc: cmos: Don't enable interrupts in the middle of the interrupt handler

2016-10-19 Thread Chris Wilson 
On Wed, Oct 19, 2016 at 09:02:04PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Using spin_lock_irq()/spin_unlock_irq() from within the interrupt
> handler is a no-no. Let's save/restore the flags to avoid turning on
> interrupts prematurely.
> 
> We hit this in a bunch of our CI systems, but for whatever reason I
> wasn't able to reproduce on my own machine, so this fix is just
> based on the backtrace.
> 
> [  202.634918] WARNING: CPU: 0 PID: 0 at kernel/locking/lockdep.c:2729 
> trace_hardirqs_on_caller+0x113/0x1b0
> [  202.634919] DEBUG_LOCKS_WARN_ON(current->hardirq_context)
> [  202.634929] Modules linked in: snd_hda_intel i915 x86_pkg_temp_thermal 
> intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel 
> lpc_ich snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi 
> snd_hda_codec snd_hwdep i2c_designware_platform i2c_designware_core 
> snd_hda_core mei_me mei snd_pcm r8169 mii sdhci_acpi sdhci mmc_core i2c_hid 
> [last unloaded: i915]
> [  202.634930] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G U  
> 4.9.0-rc1-CI-CI_DRM_1734+ #1
> [  202.634931] Hardware name: GIGABYTE M4HM87P-00/M4HM87P-00, BIOS F6 
> 12/10/2014
> [  202.634933]  88011ea03d68 8142dce5 88011ea03db8 
> 
> [  202.634934]  88011ea03da8 8107e496 0aa90002 
> 81e249a0
> [  202.634935]  81815637 82e7c280  
> 0004
> [  202.634936] Call Trace:
> [  202.634939]  
> [  202.634939]  [] dump_stack+0x67/0x92
> [  202.634941]  [] __warn+0xc6/0xe0
> [  202.634944]  [] ? _raw_spin_unlock_irq+0x27/0x50
> [  202.634945]  [] warn_slowpath_fmt+0x4a/0x50
> [  202.634946]  [] trace_hardirqs_on_caller+0x113/0x1b0
> [  202.634948]  [] trace_hardirqs_on+0xd/0x10
> [  202.634949]  [] _raw_spin_unlock_irq+0x27/0x50
> [  202.634951]  [] rtc_handler+0x32/0xa0
> [  202.634954]  [] acpi_ev_fixed_event_detect+0xd4/0xfb
> [  202.634956]  [] acpi_ev_sci_xrupt_handler+0xf/0x2d
> [  202.634957]  [] acpi_irq+0x11/0x2c
> [  202.634960]  [] __handle_irq_event_percpu+0x58/0x370
> [  202.634961]  [] handle_irq_event_percpu+0x1e/0x50
> [  202.634962]  [] handle_irq_event+0x34/0x60
> [  202.634963]  [] handle_fasteoi_irq+0xa6/0x170
> [  202.634966]  [] handle_irq+0x15/0x20
> [  202.634967]  [] do_IRQ+0x68/0x130
> [  202.634968]  [] common_interrupt+0x89/0x89
> [  202.634970]  
> [  202.634970]  [] ? mwait_idle+0x93/0x210
> [  202.634971]  [] ? mwait_idle+0x8a/0x210
> [  202.634972]  [] arch_cpu_idle+0xa/0x10
> [  202.634973]  [] default_idle_call+0x1e/0x30
> [  202.634974]  [] cpu_startup_entry+0x17c/0x1f0
> [  202.634976]  [] rest_init+0x127/0x130
> [  202.634978]  [] start_kernel+0x3f6/0x403
> [  202.634980]  [] x86_64_start_reservations+0x2a/0x2c
> [  202.634981]  [] x86_64_start_kernel+0x173/0x186
> [  202.634982] ---[ end trace 293c99618fa08d34 ]---
> 
> Cc: Gabriele Mazzotta 
> Cc: Alexandre Belloni 
> Fixes: 983bf1256edb ("rtc: cmos: Clear ACPI-driven alarms upon resume")
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/rtc/rtc-cmos.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
> index dd3d59806ffa..19cd49ad92dc 100644
> --- a/drivers/rtc/rtc-cmos.c
> +++ b/drivers/rtc/rtc-cmos.c
> @@ -996,8 +996,9 @@ static u32 rtc_handler(void *context)
>   struct cmos_rtc *cmos = dev_get_drvdata(dev);
>   unsigned char rtc_control = 0;
>   unsigned char rtc_intr;
> + unsigned long flags;
>  
> - spin_lock_irq(_lock);
> + spin_lock_irqsave(_lock, flags);

My reading of the acpi fixed event handlers suggests that this can only
be called from interrupt context.

Anyway using irqsave is correct (just may be optimised away to a plain
spin_lock() if the condition that this is only called in irq context is
satisfied).

Reviewed-by: Chris Wilson 
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] rtc: cmos: Don't enable interrupts in the middle of the interrupt handler

2016-10-19 Thread ville . syrjala 
From: Ville Syrjälä 

Using spin_lock_irq()/spin_unlock_irq() from within the interrupt
handler is a no-no. Let's save/restore the flags to avoid turning on
interrupts prematurely.

We hit this in a bunch of our CI systems, but for whatever reason I
wasn't able to reproduce on my own machine, so this fix is just
based on the backtrace.

[  202.634918] WARNING: CPU: 0 PID: 0 at kernel/locking/lockdep.c:2729 
trace_hardirqs_on_caller+0x113/0x1b0
[  202.634919] DEBUG_LOCKS_WARN_ON(current->hardirq_context)
[  202.634929] Modules linked in: snd_hda_intel i915 x86_pkg_temp_thermal 
intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel 
lpc_ich snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi 
snd_hda_codec snd_hwdep i2c_designware_platform i2c_designware_core 
snd_hda_core mei_me mei snd_pcm r8169 mii sdhci_acpi sdhci mmc_core i2c_hid 
[last unloaded: i915]
[  202.634930] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G U  
4.9.0-rc1-CI-CI_DRM_1734+ #1
[  202.634931] Hardware name: GIGABYTE M4HM87P-00/M4HM87P-00, BIOS F6 12/10/2014
[  202.634933]  88011ea03d68 8142dce5 88011ea03db8 

[  202.634934]  88011ea03da8 8107e496 0aa90002 
81e249a0
[  202.634935]  81815637 82e7c280  
0004
[  202.634936] Call Trace:
[  202.634939]  
[  202.634939]  [] dump_stack+0x67/0x92
[  202.634941]  [] __warn+0xc6/0xe0
[  202.634944]  [] ? _raw_spin_unlock_irq+0x27/0x50
[  202.634945]  [] warn_slowpath_fmt+0x4a/0x50
[  202.634946]  [] trace_hardirqs_on_caller+0x113/0x1b0
[  202.634948]  [] trace_hardirqs_on+0xd/0x10
[  202.634949]  [] _raw_spin_unlock_irq+0x27/0x50
[  202.634951]  [] rtc_handler+0x32/0xa0
[  202.634954]  [] acpi_ev_fixed_event_detect+0xd4/0xfb
[  202.634956]  [] acpi_ev_sci_xrupt_handler+0xf/0x2d
[  202.634957]  [] acpi_irq+0x11/0x2c
[  202.634960]  [] __handle_irq_event_percpu+0x58/0x370
[  202.634961]  [] handle_irq_event_percpu+0x1e/0x50
[  202.634962]  [] handle_irq_event+0x34/0x60
[  202.634963]  [] handle_fasteoi_irq+0xa6/0x170
[  202.634966]  [] handle_irq+0x15/0x20
[  202.634967]  [] do_IRQ+0x68/0x130
[  202.634968]  [] common_interrupt+0x89/0x89
[  202.634970]  
[  202.634970]  [] ? mwait_idle+0x93/0x210
[  202.634971]  [] ? mwait_idle+0x8a/0x210
[  202.634972]  [] arch_cpu_idle+0xa/0x10
[  202.634973]  [] default_idle_call+0x1e/0x30
[  202.634974]  [] cpu_startup_entry+0x17c/0x1f0
[  202.634976]  [] rest_init+0x127/0x130
[  202.634978]  [] start_kernel+0x3f6/0x403
[  202.634980]  [] x86_64_start_reservations+0x2a/0x2c
[  202.634981]  [] x86_64_start_kernel+0x173/0x186
[  202.634982] ---[ end trace 293c99618fa08d34 ]---

Cc: Gabriele Mazzotta 
Cc: Alexandre Belloni 
Fixes: 983bf1256edb ("rtc: cmos: Clear ACPI-driven alarms upon resume")
Signed-off-by: Ville Syrjälä 
---
 drivers/rtc/rtc-cmos.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
index dd3d59806ffa..19cd49ad92dc 100644
--- a/drivers/rtc/rtc-cmos.c
+++ b/drivers/rtc/rtc-cmos.c
@@ -996,8 +996,9 @@ static u32 rtc_handler(void *context)
struct cmos_rtc *cmos = dev_get_drvdata(dev);
unsigned char rtc_control = 0;
unsigned char rtc_intr;
+   unsigned long flags;
 
-   spin_lock_irq(_lock);
+   spin_lock_irqsave(_lock, flags);
if (cmos_rtc.suspend_ctrl)
rtc_control = CMOS_READ(RTC_CONTROL);
if (rtc_control & RTC_AIE) {
@@ -1006,7 +1007,7 @@ static u32 rtc_handler(void *context)
rtc_intr = CMOS_READ(RTC_INTR_FLAGS);
rtc_update_irq(cmos->rtc, 1, rtc_intr);
}
-   spin_unlock_irq(_lock);
+   spin_unlock_irqrestore(_lock, flags);
 
pm_wakeup_event(dev, 0);
acpi_clear_event(ACPI_EVENT_RTC);
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx