[patch for 2.6.29? 2/2] scsi: mpt: suppress debugobjects warning

[patch for 2.6.29? 2/2] scsi: mpt: suppress debugobjects warning

[akpm]

From: "Eric Paris" <eparis@parisplace.org>

ODEBUG: object is on stack, but not annotated
------------[ cut here ]------------
WARNING: at lib/debugobjects.c:253 __debug_object_init+0x1f3/0x276()
Hardware name: VMware Virtual Platform
Modules linked in: mptspi(+) mptscsih mptbase scsi_transport_spi ext3 jbd mbcache
Pid: 540, comm: insmod Not tainted 2.6.28-mm1 #2
Call Trace:
 [<c042c51c>] warn_slowpath+0x74/0x8a
 [<c0469600>] ? start_critical_timing+0x96/0xb7
 [<c060c8ea>] ? _spin_unlock_irqrestore+0x2f/0x3c
 [<c0446fad>] ? trace_hardirqs_off_caller+0x18/0xaf
 [<c044704f>] ? trace_hardirqs_off+0xb/0xd
 [<c060c8ea>] ? _spin_unlock_irqrestore+0x2f/0x3c
 [<c042cb84>] ? release_console_sem+0x1a5/0x1ad
 [<c05013e6>] __debug_object_init+0x1f3/0x276
 [<c0501494>] debug_object_init+0x13/0x17
 [<c0433c56>] init_timer+0x10/0x1a
 [<e08e5b54>] mpt_config+0x1c1/0x2b7 [mptbase]
 [<e08e3b82>] ? kmalloc+0x8/0xa [mptbase]
 [<e08e3b82>] ? kmalloc+0x8/0xa [mptbase]
 [<e08e6fa2>] mpt_do_ioc_recovery+0x950/0x1212 [mptbase]
 [<c04496c2>] ? __lock_acquire+0xa69/0xacc
 [<c060c8f1>] ? _spin_unlock_irqrestore+0x36/0x3c
 [<c060c3af>] ? _spin_unlock_irq+0x22/0x26
 [<c04f2d8b>] ? string+0x2b/0x76
 [<c04f310e>] ? vsnprintf+0x338/0x7b3
 [<c04496c2>] ? __lock_acquire+0xa69/0xacc
 [<c060c8ea>] ? _spin_unlock_irqrestore+0x2f/0x3c
 [<c04496c2>] ? __lock_acquire+0xa69/0xacc
 [<c044897d>] ? debug_check_no_locks_freed+0xeb/0x105
 [<c060c8f1>] ? _spin_unlock_irqrestore+0x36/0x3c
 [<c04488bc>] ? debug_check_no_locks_freed+0x2a/0x105
 [<c0446b8c>] ? lock_release_holdtime+0x43/0x48
 [<c043f742>] ? up_read+0x16/0x29
 [<c05076f8>] ? pci_get_slot+0x66/0x72
 [<e08e89ca>] mpt_attach+0x881/0x9b1 [mptbase]
 [<e091c8e5>] mptspi_probe+0x11/0x354 [mptspi]

Noticing that every caller of mpt_config has its CONFIGPARMS struct
declared on the stack and thus the &pCfg->timer is always on the stack I
changed init_timer() to init_timer_on_stack() and it seems to have shut
up.....

Cc: "Moore, Eric Dean" <Eric.Moore@lsil.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 drivers/message/fusion/mptbase.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff -puN drivers/message/fusion/mptbase.c~scsi-mpt-suppress-debugobjects-warning drivers/message/fusion/mptbase.c
--- a/drivers/message/fusion/mptbase.c~scsi-mpt-suppress-debugobjects-warning
+++ a/drivers/message/fusion/mptbase.c
@@ -5934,7 +5934,7 @@ mpt_config(MPT_ADAPTER *ioc, CONFIGPARMS
 
 	/* Initalize the timer
 	 */
-	init_timer(&pCfg->timer);
+	init_timer_on_stack(&pCfg->timer);
 	pCfg->timer.data = (unsigned long) ioc;
 	pCfg->timer.function = mpt_timer_expired;
 	pCfg->wait_done = 0;
_

Re: [patch for 2.6.29? 2/2] scsi: mpt: suppress debugobjects warning

[Andrew Morton]

On Wed, 04 Mar 2009 12:12:18 -0800
akpm@linux-foundation.org wrote:

> From: "Eric Paris" <eparis@parisplace.org>
> 
> ODEBUG: object is on stack, but not annotated
> ------------[ cut here ]------------
> WARNING: at lib/debugobjects.c:253 __debug_object_init+0x1f3/0x276()
> Hardware name: VMware Virtual Platform
> Modules linked in: mptspi(+) mptscsih mptbase scsi_transport_spi ext3 jbd mbcache
> Pid: 540, comm: insmod Not tainted 2.6.28-mm1 #2
> Call Trace:
>  [<c042c51c>] warn_slowpath+0x74/0x8a
>  [<c0469600>] ? start_critical_timing+0x96/0xb7
>  [<c060c8ea>] ? _spin_unlock_irqrestore+0x2f/0x3c
>  [<c0446fad>] ? trace_hardirqs_off_caller+0x18/0xaf
>  [<c044704f>] ? trace_hardirqs_off+0xb/0xd
>  [<c060c8ea>] ? _spin_unlock_irqrestore+0x2f/0x3c
>  [<c042cb84>] ? release_console_sem+0x1a5/0x1ad
>  [<c05013e6>] __debug_object_init+0x1f3/0x276
>  [<c0501494>] debug_object_init+0x13/0x17
>  [<c0433c56>] init_timer+0x10/0x1a
>  [<e08e5b54>] mpt_config+0x1c1/0x2b7 [mptbase]
>  [<e08e3b82>] ? kmalloc+0x8/0xa [mptbase]
>  [<e08e3b82>] ? kmalloc+0x8/0xa [mptbase]
>  [<e08e6fa2>] mpt_do_ioc_recovery+0x950/0x1212 [mptbase]
>  [<c04496c2>] ? __lock_acquire+0xa69/0xacc
>  [<c060c8f1>] ? _spin_unlock_irqrestore+0x36/0x3c
>  [<c060c3af>] ? _spin_unlock_irq+0x22/0x26
>  [<c04f2d8b>] ? string+0x2b/0x76
>  [<c04f310e>] ? vsnprintf+0x338/0x7b3
>  [<c04496c2>] ? __lock_acquire+0xa69/0xacc
>  [<c060c8ea>] ? _spin_unlock_irqrestore+0x2f/0x3c
>  [<c04496c2>] ? __lock_acquire+0xa69/0xacc
>  [<c044897d>] ? debug_check_no_locks_freed+0xeb/0x105
>  [<c060c8f1>] ? _spin_unlock_irqrestore+0x36/0x3c
>  [<c04488bc>] ? debug_check_no_locks_freed+0x2a/0x105
>  [<c0446b8c>] ? lock_release_holdtime+0x43/0x48
>  [<c043f742>] ? up_read+0x16/0x29
>  [<c05076f8>] ? pci_get_slot+0x66/0x72
>  [<e08e89ca>] mpt_attach+0x881/0x9b1 [mptbase]
>  [<e091c8e5>] mptspi_probe+0x11/0x354 [mptspi]
> 
> Noticing that every caller of mpt_config has its CONFIGPARMS struct
> declared on the stack and thus the &pCfg->timer is always on the stack I
> changed init_timer() to init_timer_on_stack() and it seems to have shut
> up.....
> 
> Cc: "Moore, Eric Dean" <Eric.Moore@lsil.com>
> Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
> 
>  drivers/message/fusion/mptbase.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff -puN drivers/message/fusion/mptbase.c~scsi-mpt-suppress-debugobjects-warning drivers/message/fusion/mptbase.c
> --- a/drivers/message/fusion/mptbase.c~scsi-mpt-suppress-debugobjects-warning
> +++ a/drivers/message/fusion/mptbase.c
> @@ -5934,7 +5934,7 @@ mpt_config(MPT_ADAPTER *ioc, CONFIGPARMS
>  
>  	/* Initalize the timer
>  	 */
> -	init_timer(&pCfg->timer);
> +	init_timer_on_stack(&pCfg->timer);
>  	pCfg->timer.data = (unsigned long) ioc;
>  	pCfg->timer.function = mpt_timer_expired;
>  	pCfg->wait_done = 0;

I sent this twice, both times marked "for 2.6.29".  Both times it was
ignored and now people (including myself) are spending time re-solving
and already-solved problem (eg:
http://bugzilla.kernel.org/show_bug.cgi?id=13133).

I'll merge this patch, tagged for a 2.6.29.x backport.

RE: [patch for 2.6.29? 2/2] scsi: mpt: suppress debugobjects warning

[Desai, Kashyap]

It is a clean patch. There is not harm to ack it, but since I have already submitted code changes to upstream which have replaced "kernel timer" by "completion queue.", I will suggest to wait for next driver version.

Init_timer() function will not be called from MPT fusion driver in next version

Next available upstream version will not have this slowpath warning.

- Kashyap

-----Original Message-----
From: linux-scsi-owner@vger.kernel.org [mailto:linux-scsi-owner@vger.kernel.org] On Behalf Of Andrew Morton
Sent: Tuesday, April 21, 2009 3:25 AM
To: James.Bottomley@HansenPartnership.com; linux-scsi@vger.kernel.org; eparis@parisplace.org; Moore, Eric; tglx@linutronix.de
Subject: Re: [patch for 2.6.29? 2/2] scsi: mpt: suppress debugobjects warning

On Wed, 04 Mar 2009 12:12:18 -0800
akpm@linux-foundation.org wrote:

> From: "Eric Paris" <eparis@parisplace.org>
> 
> ODEBUG: object is on stack, but not annotated
> ------------[ cut here ]------------
> WARNING: at lib/debugobjects.c:253 __debug_object_init+0x1f3/0x276()
> Hardware name: VMware Virtual Platform
> Modules linked in: mptspi(+) mptscsih mptbase scsi_transport_spi ext3 jbd mbcache
> Pid: 540, comm: insmod Not tainted 2.6.28-mm1 #2
> Call Trace:
>  [<c042c51c>] warn_slowpath+0x74/0x8a
>  [<c0469600>] ? start_critical_timing+0x96/0xb7
>  [<c060c8ea>] ? _spin_unlock_irqrestore+0x2f/0x3c
>  [<c0446fad>] ? trace_hardirqs_off_caller+0x18/0xaf
>  [<c044704f>] ? trace_hardirqs_off+0xb/0xd
>  [<c060c8ea>] ? _spin_unlock_irqrestore+0x2f/0x3c
>  [<c042cb84>] ? release_console_sem+0x1a5/0x1ad
>  [<c05013e6>] __debug_object_init+0x1f3/0x276
>  [<c0501494>] debug_object_init+0x13/0x17
>  [<c0433c56>] init_timer+0x10/0x1a
>  [<e08e5b54>] mpt_config+0x1c1/0x2b7 [mptbase]
>  [<e08e3b82>] ? kmalloc+0x8/0xa [mptbase]
>  [<e08e3b82>] ? kmalloc+0x8/0xa [mptbase]
>  [<e08e6fa2>] mpt_do_ioc_recovery+0x950/0x1212 [mptbase]
>  [<c04496c2>] ? __lock_acquire+0xa69/0xacc
>  [<c060c8f1>] ? _spin_unlock_irqrestore+0x36/0x3c
>  [<c060c3af>] ? _spin_unlock_irq+0x22/0x26
>  [<c04f2d8b>] ? string+0x2b/0x76
>  [<c04f310e>] ? vsnprintf+0x338/0x7b3
>  [<c04496c2>] ? __lock_acquire+0xa69/0xacc
>  [<c060c8ea>] ? _spin_unlock_irqrestore+0x2f/0x3c
>  [<c04496c2>] ? __lock_acquire+0xa69/0xacc
>  [<c044897d>] ? debug_check_no_locks_freed+0xeb/0x105
>  [<c060c8f1>] ? _spin_unlock_irqrestore+0x36/0x3c
>  [<c04488bc>] ? debug_check_no_locks_freed+0x2a/0x105
>  [<c0446b8c>] ? lock_release_holdtime+0x43/0x48
>  [<c043f742>] ? up_read+0x16/0x29
>  [<c05076f8>] ? pci_get_slot+0x66/0x72
>  [<e08e89ca>] mpt_attach+0x881/0x9b1 [mptbase]
>  [<e091c8e5>] mptspi_probe+0x11/0x354 [mptspi]
> 
> Noticing that every caller of mpt_config has its CONFIGPARMS struct
> declared on the stack and thus the &pCfg->timer is always on the stack I
> changed init_timer() to init_timer_on_stack() and it seems to have shut
> up.....
> 
> Cc: "Moore, Eric Dean" <Eric.Moore@lsil.com>
> Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
> 
>  drivers/message/fusion/mptbase.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff -puN drivers/message/fusion/mptbase.c~scsi-mpt-suppress-debugobjects-warning drivers/message/fusion/mptbase.c
> --- a/drivers/message/fusion/mptbase.c~scsi-mpt-suppress-debugobjects-warning
> +++ a/drivers/message/fusion/mptbase.c
> @@ -5934,7 +5934,7 @@ mpt_config(MPT_ADAPTER *ioc, CONFIGPARMS
>  
>  	/* Initalize the timer
>  	 */
> -	init_timer(&pCfg->timer);
> +	init_timer_on_stack(&pCfg->timer);
>  	pCfg->timer.data = (unsigned long) ioc;
>  	pCfg->timer.function = mpt_timer_expired;
>  	pCfg->wait_done = 0;

I sent this twice, both times marked "for 2.6.29".  Both times it was
ignored and now people (including myself) are spending time re-solving
and already-solved problem (eg:
http://bugzilla.kernel.org/show_bug.cgi?id=13133).

I'll merge this patch, tagged for a 2.6.29.x backport.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch for 2.6.29? 2/2] scsi: mpt: suppress debugobjects warning

[Andrew Morton]

On Tue, 21 Apr 2009 16:08:45 +0530 "Desai, Kashyap" <Kashyap.Desai@lsi.com> wrote:

> It is a clean patch. There is not harm to ack it, but since I have already submitted code changes to upstream which have replaced "kernel timer" by "completion queue.", I will suggest to wait for next driver version.
> 
> Init_timer() function will not be called from MPT fusion driver in next version

No, that doesn't work.  This means that people who use 2.6.29 and
2.6.30 will potentially see these warnings.  This potentially includes
the customers of any distributors who enable debugobjects.

It creates additional work for users, for support staff and generates
concern about the stability of the kernel.

RE: [patch for 2.6.29? 2/2] scsi: mpt: suppress debugobjects warning

[Desai, Kashyap]

It is good to consider this patch as approved; even thought timer function which is causing this problem is replaced by completion queue in future. 
Lets consider this patch as ACKED.

- Kashyap

-----Original Message-----
From: Andrew Morton [mailto:akpm@linux-foundation.org] 
Sent: Tuesday, April 21, 2009 10:29 PM
To: Desai, Kashyap
Cc: James.Bottomley@HansenPartnership.com; linux-scsi@vger.kernel.org; eparis@parisplace.org; Moore, Eric; tglx@linutronix.de
Subject: Re: [patch for 2.6.29? 2/2] scsi: mpt: suppress debugobjects warning

On Tue, 21 Apr 2009 16:08:45 +0530 "Desai, Kashyap" <Kashyap.Desai@lsi.com> wrote:

> It is a clean patch. There is not harm to ack it, but since I have already submitted code changes to upstream which have replaced "kernel timer" by "completion queue.", I will suggest to wait for next driver version.
> 
> Init_timer() function will not be called from MPT fusion driver in next version

No, that doesn't work.  This means that people who use 2.6.29 and
2.6.30 will potentially see these warnings.  This potentially includes
the customers of any distributors who enable debugobjects.

It creates additional work for users, for support staff and generates
concern about the stability of the kernel.