All of lore.kernel.org
 help / color / mirror / Atom feed
* linux-next: boot failures with next-20120411
@ 2012-04-11  6:58 Stephen Rothwell
  2012-04-12  2:44 ` Milton Miller
  2012-04-13  2:30   ` Michael Neuling
  0 siblings, 2 replies; 14+ messages in thread
From: Stephen Rothwell @ 2012-04-11  6:58 UTC (permalink / raw)
  To: LKML; +Cc: ppc-dev

[-- Attachment #1: Type: text/plain, Size: 2453 bytes --]

Hi all,

Some (not all) of my PowerPC boot tests have failed like this after
getting into user mode (this one was just after udev started, but others
are after other processes getting going):

Unable to handle kernel paging request for data at address 0xc0000003f9d550
Faulting instruction address: 0xc0000000001b7f40
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=32 NUMA pSeries
Modules linked in: ehea
NIP: c0000000001b7f40 LR: c0000000001b7f14 CTR: c0000000000e04f0
REGS: c0000003f68bf6b0 TRAP: 0300   Not tainted  (3.4.0-rc2-autokern1)
MSR: 800000000280b032 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI>  CR: 24422424  XER: 20000001
SOFTE: 1
CFAR: 000000000000562c
DAR: 00c0000003f9d550, DSISR: 40000000
TASK = c0000003f8818000[3192] 'kdump' THREAD: c0000003f68bc000 CPU: 5
GPR00: 0000000000000000 c0000003f68bf930 c000000000ce1d40 c0000003fe00ec00 
GPR04: 00000000000002d0 0000000000000038 c0000003f8f935e8 c000000000e55280 
GPR08: 0000000000000011 c000000000bcb280 c000000000bcb1e8 000000000028a000 
GPR12: 0000000024422424 c00000000f33bc80 00000fffdd90a770 0000000000081000 
GPR16: c0000003f846c000 000000000de4f7a0 f00000000de4f7a0 0000000000000000 
GPR20: c0000003f8365408 c0000003f8365480 c0000003f8e5d110 0000000000000000 
GPR24: 0000000000000100 c0000003f8365400 c0000000001e5424 00000000000002d0 
GPR28: 0000000000000800 00c0000003f9d550 c000000000c5b718 c0000003fe00ec00 
NIP [c0000000001b7f40] .__kmalloc+0x70/0x230
LR [c0000000001b7f14] .__kmalloc+0x44/0x230
Call Trace:
[c0000003f68bf930] [c0000003f68bf9b0] 0xc0000003f68bf9b0 (unreliable)
[c0000003f68bf9e0] [c0000000001e5424] .alloc_fdmem+0x24/0x70
[c0000003f68bfa60] [c0000000001e54f8] .alloc_fdtable+0x88/0x130
[c0000003f68bfaf0] [c0000000001e5924] .dup_fd+0x384/0x450
[c0000003f68bfbd0] [c00000000009a310] .copy_process+0x880/0x11d0
[c0000003f68bfcd0] [c00000000009aee0] .do_fork+0x70/0x400
[c0000003f68bfdc0] [c0000000000141c4] .sys_clone+0x54/0x70
[c0000003f68bfe30] [c000000000009aa0] .ppc_clone+0x8/0xc
Instruction dump:
4bff9281 2ba30010 7c7f1b78 40dd00f4 e96d0040 e93f0000 7ce95a14 e9070008 
7fa9582a 2fbd0000 41de0054 e81f0022 <7f3d002a> 38000000 886d01f2 980d01f2 
---[ end trace 366fe6c7ced3bfb0 ]---

This did not happen yesterday.  Just wondering if anyone can think of
anything obvious.  Full console log at
http://ozlabs.org/~sfr/next-20120411.log.bz2

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: linux-next: boot failures with next-20120411
  2012-04-11  6:58 linux-next: boot failures with next-20120411 Stephen Rothwell
@ 2012-04-12  2:44 ` Milton Miller
  2012-04-13  2:30   ` Michael Neuling
  1 sibling, 0 replies; 14+ messages in thread
From: Milton Miller @ 2012-04-12  2:44 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: ppc-dev, LKML

On Wed, 11 Apr 2012 about 16:58:35 +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Some (not all) of my PowerPC boot tests have failed like this after
> getting into user mode (this one was just after udev started, but others
> are after other processes getting going):
> 
> Unable to handle kernel paging request for data at address 0xc0000003f9d550
> Faulting instruction address: 0xc0000000001b7f40
> Oops: Kernel access of bad area, sig: 11 [#1]
> SMP NR_CPUS=32 NUMA pSeries
> Modules linked in: ehea
> NIP: c0000000001b7f40 LR: c0000000001b7f14 CTR: c0000000000e04f0
> REGS: c0000003f68bf6b0 TRAP: 0300   Not tainted  (3.4.0-rc2-autokern1)
> MSR: 800000000280b032 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI>  CR: 24422424  XER: 20000001
> SOFTE: 1
> CFAR: 000000000000562c
> DAR: 00c0000003f9d550, DSISR: 40000000
> TASK = c0000003f8818000[3192] 'kdump' THREAD: c0000003f68bc000 CPU: 5
> GPR00: 0000000000000000 c0000003f68bf930 c000000000ce1d40 c0000003fe00ec00 
> GPR04: 00000000000002d0 0000000000000038 c0000003f8f935e8 c000000000e55280 
> GPR08: 0000000000000011 c000000000bcb280 c000000000bcb1e8 000000000028a000 
> GPR12: 0000000024422424 c00000000f33bc80 00000fffdd90a770 0000000000081000 
> GPR16: c0000003f846c000 000000000de4f7a0 f00000000de4f7a0 0000000000000000 
> GPR20: c0000003f8365408 c0000003f8365480 c0000003f8e5d110 0000000000000000 
> GPR24: 0000000000000100 c0000003f8365400 c0000000001e5424 00000000000002d0 
> GPR28: 0000000000000800 00c0000003f9d550 c000000000c5b718 c0000003fe00ec00 
> NIP [c0000000001b7f40] .__kmalloc+0x70/0x230
> LR [c0000000001b7f14] .__kmalloc+0x44/0x230
> Call Trace:
> [c0000003f68bf930] [c0000003f68bf9b0] 0xc0000003f68bf9b0 (unreliable)
> [c0000003f68bf9e0] [c0000000001e5424] .alloc_fdmem+0x24/0x70
> [c0000003f68bfa60] [c0000000001e54f8] .alloc_fdtable+0x88/0x130
> [c0000003f68bfaf0] [c0000000001e5924] .dup_fd+0x384/0x450
> [c0000003f68bfbd0] [c00000000009a310] .copy_process+0x880/0x11d0
> [c0000003f68bfcd0] [c00000000009aee0] .do_fork+0x70/0x400
> [c0000003f68bfdc0] [c0000000000141c4] .sys_clone+0x54/0x70
> [c0000003f68bfe30] [c000000000009aa0] .ppc_clone+0x8/0xc
> Instruction dump:
> 4bff9281 2ba30010 7c7f1b78 40dd00f4 e96d0040 e93f0000 7ce95a14 e9070008 
> 7fa9582a 2fbd0000 41de0054 e81f0022 <7f3d002a> 38000000 886d01f2 980d01f2 
> ---[ end trace 366fe6c7ced3bfb0 ]---
> This did not happen yesterday.  Just wondering if anyone can think of
> anything obvious.  Full console log at
> http://ozlabs.org/~sfr/next-20120411.log.bz2

Hi Steven.

The DAR print of the faulting address points out that the address
appears to be shifted right 8 bits.  Or more likely the address used
to load the register was decremented by one somewhere (Big Endian).

Although all the registers are multiples of 4 in the first dump,
looking at the later oops in the log would seem to confirm the
address being decremented, eg put_files struct dar of 
c0000003f9d547ff in oops #2, and dar 00000000ffffffff in #9, #12,
#14, and #16.

No idea if this is caused by a bad save/restore somewhere or a
decrement of a 32bit number in memory.

Anyone else with a wild -1 on a int, u32 or s32?

milton

^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: linux-next: boot failures with next-20120411
  2012-04-11  6:58 linux-next: boot failures with next-20120411 Stephen Rothwell
@ 2012-04-13  2:30   ` Michael Neuling
  2012-04-13  2:30   ` Michael Neuling
  1 sibling, 0 replies; 14+ messages in thread
From: Michael Neuling @ 2012-04-13  2:30 UTC (permalink / raw)
  To: Stephen Rothwell, Jiri Slaby, Greg Kroah-Hartman
  Cc: LKML, ppc-dev, linux-next

Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> Some (not all) of my PowerPC boot tests have failed like this after
> getting into user mode (this one was just after udev started, but others
> are after other processes getting going):
> 
> Unable to handle kernel paging request for data at address 0xc0000003f9d550
> Faulting instruction address: 0xc0000000001b7f40
> Oops: Kernel access of bad area, sig: 11 [#1]
> SMP NR_CPUS=32 NUMA pSeries
> Modules linked in: ehea
> NIP: c0000000001b7f40 LR: c0000000001b7f14 CTR: c0000000000e04f0
> REGS: c0000003f68bf6b0 TRAP: 0300   Not tainted  (3.4.0-rc2-autokern1)
> MSR: 800000000280b032 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI>  CR: 24422424  XER: 20000001
> SOFTE: 1
> CFAR: 000000000000562c
> DAR: 00c0000003f9d550, DSISR: 40000000
> TASK = c0000003f8818000[3192] 'kdump' THREAD: c0000003f68bc000 CPU: 5
> GPR00: 0000000000000000 c0000003f68bf930 c000000000ce1d40 c0000003fe00ec00 
> GPR04: 00000000000002d0 0000000000000038 c0000003f8f935e8 c000000000e55280 
> GPR08: 0000000000000011 c000000000bcb280 c000000000bcb1e8 000000000028a000 
> GPR12: 0000000024422424 c00000000f33bc80 00000fffdd90a770 0000000000081000 
> GPR16: c0000003f846c000 000000000de4f7a0 f00000000de4f7a0 0000000000000000 
> GPR20: c0000003f8365408 c0000003f8365480 c0000003f8e5d110 0000000000000000 
> GPR24: 0000000000000100 c0000003f8365400 c0000000001e5424 00000000000002d0 
> GPR28: 0000000000000800 00c0000003f9d550 c000000000c5b718 c0000003fe00ec00 
> NIP [c0000000001b7f40] .__kmalloc+0x70/0x230
> LR [c0000000001b7f14] .__kmalloc+0x44/0x230
> Call Trace:
> [c0000003f68bf930] [c0000003f68bf9b0] 0xc0000003f68bf9b0 (unreliable)
> [c0000003f68bf9e0] [c0000000001e5424] .alloc_fdmem+0x24/0x70
> [c0000003f68bfa60] [c0000000001e54f8] .alloc_fdtable+0x88/0x130
> [c0000003f68bfaf0] [c0000000001e5924] .dup_fd+0x384/0x450
> [c0000003f68bfbd0] [c00000000009a310] .copy_process+0x880/0x11d0
> [c0000003f68bfcd0] [c00000000009aee0] .do_fork+0x70/0x400
> [c0000003f68bfdc0] [c0000000000141c4] .sys_clone+0x54/0x70
> [c0000003f68bfe30] [c000000000009aa0] .ppc_clone+0x8/0xc
> Instruction dump:
> 4bff9281 2ba30010 7c7f1b78 40dd00f4 e96d0040 e93f0000 7ce95a14 e9070008 
> 7fa9582a 2fbd0000 41de0054 e81f0022 <7f3d002a> 38000000 886d01f2 980d01f2 
> ---[ end trace 366fe6c7ced3bfb0 ]---
> 
> This did not happen yesterday.  Just wondering if anyone can think of
> anything obvious.  Full console log at
> http://ozlabs.org/~sfr/next-20120411.log.bz2

I managed to bisect this down using pseries_defconfig with next-20120412
to this patch:

  commit 85bbc003b24335e253a392f6a9874103b77abb36
  Author: Jiri Slaby <jslaby@suse.cz>
  Date:   Mon Apr 2 13:54:22 2012 +0200

      TTY: HVC, use tty from tty_port

      The driver already used refcounting. So we just switch it to tty_port
      helpers. And switch to tty_port->lock for tty.

      Signed-off-by: Jiri Slaby <jslaby@suse.cz>
      Cc: linuxppc-dev@lists.ozlabs.org
      Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Reverting this commit (and 0146b6939074ebe14ece3604fd00e7be128a3812
otherwise git barfs) fixes the problem on next-20120412.  

I'm assuming we got the ref count changes wrong somewhere in the patch
but the tty code is beyond me.  Jiri, can you take a look?

Mikey

^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: linux-next: boot failures with next-20120411
@ 2012-04-13  2:30   ` Michael Neuling
  0 siblings, 0 replies; 14+ messages in thread
From: Michael Neuling @ 2012-04-13  2:30 UTC (permalink / raw)
  To: Stephen Rothwell, Jiri Slaby, Greg Kroah-Hartman
  Cc: linux-next, ppc-dev, LKML

Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> Some (not all) of my PowerPC boot tests have failed like this after
> getting into user mode (this one was just after udev started, but others
> are after other processes getting going):
> 
> Unable to handle kernel paging request for data at address 0xc0000003f9d550
> Faulting instruction address: 0xc0000000001b7f40
> Oops: Kernel access of bad area, sig: 11 [#1]
> SMP NR_CPUS=32 NUMA pSeries
> Modules linked in: ehea
> NIP: c0000000001b7f40 LR: c0000000001b7f14 CTR: c0000000000e04f0
> REGS: c0000003f68bf6b0 TRAP: 0300   Not tainted  (3.4.0-rc2-autokern1)
> MSR: 800000000280b032 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI>  CR: 24422424  XER: 20000001
> SOFTE: 1
> CFAR: 000000000000562c
> DAR: 00c0000003f9d550, DSISR: 40000000
> TASK = c0000003f8818000[3192] 'kdump' THREAD: c0000003f68bc000 CPU: 5
> GPR00: 0000000000000000 c0000003f68bf930 c000000000ce1d40 c0000003fe00ec00 
> GPR04: 00000000000002d0 0000000000000038 c0000003f8f935e8 c000000000e55280 
> GPR08: 0000000000000011 c000000000bcb280 c000000000bcb1e8 000000000028a000 
> GPR12: 0000000024422424 c00000000f33bc80 00000fffdd90a770 0000000000081000 
> GPR16: c0000003f846c000 000000000de4f7a0 f00000000de4f7a0 0000000000000000 
> GPR20: c0000003f8365408 c0000003f8365480 c0000003f8e5d110 0000000000000000 
> GPR24: 0000000000000100 c0000003f8365400 c0000000001e5424 00000000000002d0 
> GPR28: 0000000000000800 00c0000003f9d550 c000000000c5b718 c0000003fe00ec00 
> NIP [c0000000001b7f40] .__kmalloc+0x70/0x230
> LR [c0000000001b7f14] .__kmalloc+0x44/0x230
> Call Trace:
> [c0000003f68bf930] [c0000003f68bf9b0] 0xc0000003f68bf9b0 (unreliable)
> [c0000003f68bf9e0] [c0000000001e5424] .alloc_fdmem+0x24/0x70
> [c0000003f68bfa60] [c0000000001e54f8] .alloc_fdtable+0x88/0x130
> [c0000003f68bfaf0] [c0000000001e5924] .dup_fd+0x384/0x450
> [c0000003f68bfbd0] [c00000000009a310] .copy_process+0x880/0x11d0
> [c0000003f68bfcd0] [c00000000009aee0] .do_fork+0x70/0x400
> [c0000003f68bfdc0] [c0000000000141c4] .sys_clone+0x54/0x70
> [c0000003f68bfe30] [c000000000009aa0] .ppc_clone+0x8/0xc
> Instruction dump:
> 4bff9281 2ba30010 7c7f1b78 40dd00f4 e96d0040 e93f0000 7ce95a14 e9070008 
> 7fa9582a 2fbd0000 41de0054 e81f0022 <7f3d002a> 38000000 886d01f2 980d01f2 
> ---[ end trace 366fe6c7ced3bfb0 ]---
> 
> This did not happen yesterday.  Just wondering if anyone can think of
> anything obvious.  Full console log at
> http://ozlabs.org/~sfr/next-20120411.log.bz2

I managed to bisect this down using pseries_defconfig with next-20120412
to this patch:

  commit 85bbc003b24335e253a392f6a9874103b77abb36
  Author: Jiri Slaby <jslaby@suse.cz>
  Date:   Mon Apr 2 13:54:22 2012 +0200

      TTY: HVC, use tty from tty_port

      The driver already used refcounting. So we just switch it to tty_port
      helpers. And switch to tty_port->lock for tty.

      Signed-off-by: Jiri Slaby <jslaby@suse.cz>
      Cc: linuxppc-dev@lists.ozlabs.org
      Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Reverting this commit (and 0146b6939074ebe14ece3604fd00e7be128a3812
otherwise git barfs) fixes the problem on next-20120412.  

I'm assuming we got the ref count changes wrong somewhere in the patch
but the tty code is beyond me.  Jiri, can you take a look?

Mikey

^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: linux-next: boot failures with next-20120411
  2012-04-13  2:30   ` Michael Neuling
@ 2012-04-13  2:57     ` Stephen Rothwell
  -1 siblings, 0 replies; 14+ messages in thread
From: Stephen Rothwell @ 2012-04-13  2:57 UTC (permalink / raw)
  To: Michael Neuling; +Cc: Jiri Slaby, Greg Kroah-Hartman, LKML, ppc-dev, linux-next

[-- Attachment #1: Type: text/plain, Size: 661 bytes --]

Hi all,

On Fri, 13 Apr 2012 12:30:11 +1000 Michael Neuling <mikey@neuling.org> wrote:
>
> I managed to bisect this down using pseries_defconfig with next-20120412
> to this patch:
> 
>   commit 85bbc003b24335e253a392f6a9874103b77abb36
>   Author: Jiri Slaby <jslaby@suse.cz>
>   Date:   Mon Apr 2 13:54:22 2012 +0200
> 
>       TTY: HVC, use tty from tty_port

Thanks for that, Mikey.

> Reverting this commit (and 0146b6939074ebe14ece3604fd00e7be128a3812
> otherwise git barfs) fixes the problem on next-20120412.

I will revert those commits form linux-next today.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: linux-next: boot failures with next-20120411
@ 2012-04-13  2:57     ` Stephen Rothwell
  0 siblings, 0 replies; 14+ messages in thread
From: Stephen Rothwell @ 2012-04-13  2:57 UTC (permalink / raw)
  To: Michael Neuling; +Cc: Greg Kroah-Hartman, linux-next, ppc-dev, Jiri Slaby, LKML

[-- Attachment #1: Type: text/plain, Size: 661 bytes --]

Hi all,

On Fri, 13 Apr 2012 12:30:11 +1000 Michael Neuling <mikey@neuling.org> wrote:
>
> I managed to bisect this down using pseries_defconfig with next-20120412
> to this patch:
> 
>   commit 85bbc003b24335e253a392f6a9874103b77abb36
>   Author: Jiri Slaby <jslaby@suse.cz>
>   Date:   Mon Apr 2 13:54:22 2012 +0200
> 
>       TTY: HVC, use tty from tty_port

Thanks for that, Mikey.

> Reverting this commit (and 0146b6939074ebe14ece3604fd00e7be128a3812
> otherwise git barfs) fixes the problem on next-20120412.

I will revert those commits form linux-next today.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: linux-next: boot failures with next-20120411
  2012-04-13  2:30   ` Michael Neuling
@ 2012-04-13  8:02     ` Jiri Slaby
  -1 siblings, 0 replies; 14+ messages in thread
From: Jiri Slaby @ 2012-04-13  8:02 UTC (permalink / raw)
  To: Michael Neuling
  Cc: Stephen Rothwell, Greg Kroah-Hartman, LKML, ppc-dev, linux-next,
	Jiri Slaby

[-- Attachment #1: Type: text/plain, Size: 3609 bytes --]

On 04/13/2012 04:30 AM, Michael Neuling wrote:
> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
>> Hi all,
>>
>> Some (not all) of my PowerPC boot tests have failed like this after
>> getting into user mode (this one was just after udev started, but others
>> are after other processes getting going):
>>
>> Unable to handle kernel paging request for data at address 0xc0000003f9d550
>> Faulting instruction address: 0xc0000000001b7f40
>> Oops: Kernel access of bad area, sig: 11 [#1]
>> SMP NR_CPUS=32 NUMA pSeries
>> Modules linked in: ehea
>> NIP: c0000000001b7f40 LR: c0000000001b7f14 CTR: c0000000000e04f0
>> REGS: c0000003f68bf6b0 TRAP: 0300   Not tainted  (3.4.0-rc2-autokern1)
>> MSR: 800000000280b032 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI>  CR: 24422424  XER: 20000001
>> SOFTE: 1
>> CFAR: 000000000000562c
>> DAR: 00c0000003f9d550, DSISR: 40000000
>> TASK = c0000003f8818000[3192] 'kdump' THREAD: c0000003f68bc000 CPU: 5
>> GPR00: 0000000000000000 c0000003f68bf930 c000000000ce1d40 c0000003fe00ec00 
>> GPR04: 00000000000002d0 0000000000000038 c0000003f8f935e8 c000000000e55280 
>> GPR08: 0000000000000011 c000000000bcb280 c000000000bcb1e8 000000000028a000 
>> GPR12: 0000000024422424 c00000000f33bc80 00000fffdd90a770 0000000000081000 
>> GPR16: c0000003f846c000 000000000de4f7a0 f00000000de4f7a0 0000000000000000 
>> GPR20: c0000003f8365408 c0000003f8365480 c0000003f8e5d110 0000000000000000 
>> GPR24: 0000000000000100 c0000003f8365400 c0000000001e5424 00000000000002d0 
>> GPR28: 0000000000000800 00c0000003f9d550 c000000000c5b718 c0000003fe00ec00 
>> NIP [c0000000001b7f40] .__kmalloc+0x70/0x230
>> LR [c0000000001b7f14] .__kmalloc+0x44/0x230
>> Call Trace:
>> [c0000003f68bf930] [c0000003f68bf9b0] 0xc0000003f68bf9b0 (unreliable)
>> [c0000003f68bf9e0] [c0000000001e5424] .alloc_fdmem+0x24/0x70
>> [c0000003f68bfa60] [c0000000001e54f8] .alloc_fdtable+0x88/0x130
>> [c0000003f68bfaf0] [c0000000001e5924] .dup_fd+0x384/0x450
>> [c0000003f68bfbd0] [c00000000009a310] .copy_process+0x880/0x11d0
>> [c0000003f68bfcd0] [c00000000009aee0] .do_fork+0x70/0x400
>> [c0000003f68bfdc0] [c0000000000141c4] .sys_clone+0x54/0x70
>> [c0000003f68bfe30] [c000000000009aa0] .ppc_clone+0x8/0xc
>> Instruction dump:
>> 4bff9281 2ba30010 7c7f1b78 40dd00f4 e96d0040 e93f0000 7ce95a14 e9070008 
>> 7fa9582a 2fbd0000 41de0054 e81f0022 <7f3d002a> 38000000 886d01f2 980d01f2 
>> ---[ end trace 366fe6c7ced3bfb0 ]---
>>
>> This did not happen yesterday.  Just wondering if anyone can think of
>> anything obvious.  Full console log at
>> http://ozlabs.org/~sfr/next-20120411.log.bz2
> 
> I managed to bisect this down using pseries_defconfig with next-20120412
> to this patch:
> 
>   commit 85bbc003b24335e253a392f6a9874103b77abb36
>   Author: Jiri Slaby <jslaby@suse.cz>
>   Date:   Mon Apr 2 13:54:22 2012 +0200
> 
>       TTY: HVC, use tty from tty_port
> 
>       The driver already used refcounting. So we just switch it to tty_port
>       helpers. And switch to tty_port->lock for tty.
> 
>       Signed-off-by: Jiri Slaby <jslaby@suse.cz>
>       Cc: linuxppc-dev@lists.ozlabs.org
>       Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> 
> Reverting this commit (and 0146b6939074ebe14ece3604fd00e7be128a3812
> otherwise git barfs) fixes the problem on next-20120412.  
> 
> I'm assuming we got the ref count changes wrong somewhere in the patch
> but the tty code is beyond me.  Jiri, can you take a look?

Yeah, I see. I forgot to remove a couple of tty reference drops. The
reference is dropped by tty_port_tty_set in open/close/hangup now. Does
the attached patch help?

thanks,
-- 
js
suse labs



[-- Attachment #2: 0001-HVC-fix-refcounting.patch --]
[-- Type: text/x-patch, Size: 1157 bytes --]

>From cc51efe721f5aa184e119c52c661a1faf865e492 Mon Sep 17 00:00:00 2001
From: Jiri Slaby <jslaby@suse.cz>
Date: Fri, 13 Apr 2012 10:00:28 +0200
Subject: [PATCH 1/1] HVC: fix refcounting

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 drivers/tty/hvc/hvc_console.c |    3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index 6c45cbf..260d4f2 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -338,7 +338,6 @@ static int hvc_open(struct tty_struct *tty, struct file * filp)
 	 */
 	if (rc) {
 		tty_port_tty_set(&hp->port, NULL);
-		tty_kref_put(tty);
 		tty->driver_data = NULL;
 		tty_port_put(&hp->port);
 		printk(KERN_ERR "hvc_open: request_irq failed with rc %d.\n", rc);
@@ -393,7 +392,6 @@ static void hvc_close(struct tty_struct *tty, struct file * filp)
 		spin_unlock_irqrestore(&hp->port.lock, flags);
 	}
 
-	tty_kref_put(tty);
 	tty_port_put(&hp->port);
 }
 
@@ -433,7 +431,6 @@ static void hvc_hangup(struct tty_struct *tty)
 
 	while(temp_open_count) {
 		--temp_open_count;
-		tty_kref_put(tty);
 		tty_port_put(&hp->port);
 	}
 }
-- 
1.7.9.2


^ permalink raw reply related	[flat|nested] 14+ messages in thread
* Re: linux-next: boot failures with next-20120411
@ 2012-04-13  8:02     ` Jiri Slaby
  0 siblings, 0 replies; 14+ messages in thread
From: Jiri Slaby @ 2012-04-13  8:02 UTC (permalink / raw)
  To: Michael Neuling
  Cc: Stephen Rothwell, Jiri Slaby, Greg Kroah-Hartman, LKML,
	linux-next, ppc-dev

[-- Attachment #1: Type: text/plain, Size: 3609 bytes --]

On 04/13/2012 04:30 AM, Michael Neuling wrote:
> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
>> Hi all,
>>
>> Some (not all) of my PowerPC boot tests have failed like this after
>> getting into user mode (this one was just after udev started, but others
>> are after other processes getting going):
>>
>> Unable to handle kernel paging request for data at address 0xc0000003f9d550
>> Faulting instruction address: 0xc0000000001b7f40
>> Oops: Kernel access of bad area, sig: 11 [#1]
>> SMP NR_CPUS=32 NUMA pSeries
>> Modules linked in: ehea
>> NIP: c0000000001b7f40 LR: c0000000001b7f14 CTR: c0000000000e04f0
>> REGS: c0000003f68bf6b0 TRAP: 0300   Not tainted  (3.4.0-rc2-autokern1)
>> MSR: 800000000280b032 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI>  CR: 24422424  XER: 20000001
>> SOFTE: 1
>> CFAR: 000000000000562c
>> DAR: 00c0000003f9d550, DSISR: 40000000
>> TASK = c0000003f8818000[3192] 'kdump' THREAD: c0000003f68bc000 CPU: 5
>> GPR00: 0000000000000000 c0000003f68bf930 c000000000ce1d40 c0000003fe00ec00 
>> GPR04: 00000000000002d0 0000000000000038 c0000003f8f935e8 c000000000e55280 
>> GPR08: 0000000000000011 c000000000bcb280 c000000000bcb1e8 000000000028a000 
>> GPR12: 0000000024422424 c00000000f33bc80 00000fffdd90a770 0000000000081000 
>> GPR16: c0000003f846c000 000000000de4f7a0 f00000000de4f7a0 0000000000000000 
>> GPR20: c0000003f8365408 c0000003f8365480 c0000003f8e5d110 0000000000000000 
>> GPR24: 0000000000000100 c0000003f8365400 c0000000001e5424 00000000000002d0 
>> GPR28: 0000000000000800 00c0000003f9d550 c000000000c5b718 c0000003fe00ec00 
>> NIP [c0000000001b7f40] .__kmalloc+0x70/0x230
>> LR [c0000000001b7f14] .__kmalloc+0x44/0x230
>> Call Trace:
>> [c0000003f68bf930] [c0000003f68bf9b0] 0xc0000003f68bf9b0 (unreliable)
>> [c0000003f68bf9e0] [c0000000001e5424] .alloc_fdmem+0x24/0x70
>> [c0000003f68bfa60] [c0000000001e54f8] .alloc_fdtable+0x88/0x130
>> [c0000003f68bfaf0] [c0000000001e5924] .dup_fd+0x384/0x450
>> [c0000003f68bfbd0] [c00000000009a310] .copy_process+0x880/0x11d0
>> [c0000003f68bfcd0] [c00000000009aee0] .do_fork+0x70/0x400
>> [c0000003f68bfdc0] [c0000000000141c4] .sys_clone+0x54/0x70
>> [c0000003f68bfe30] [c000000000009aa0] .ppc_clone+0x8/0xc
>> Instruction dump:
>> 4bff9281 2ba30010 7c7f1b78 40dd00f4 e96d0040 e93f0000 7ce95a14 e9070008 
>> 7fa9582a 2fbd0000 41de0054 e81f0022 <7f3d002a> 38000000 886d01f2 980d01f2 
>> ---[ end trace 366fe6c7ced3bfb0 ]---
>>
>> This did not happen yesterday.  Just wondering if anyone can think of
>> anything obvious.  Full console log at
>> http://ozlabs.org/~sfr/next-20120411.log.bz2
> 
> I managed to bisect this down using pseries_defconfig with next-20120412
> to this patch:
> 
>   commit 85bbc003b24335e253a392f6a9874103b77abb36
>   Author: Jiri Slaby <jslaby@suse.cz>
>   Date:   Mon Apr 2 13:54:22 2012 +0200
> 
>       TTY: HVC, use tty from tty_port
> 
>       The driver already used refcounting. So we just switch it to tty_port
>       helpers. And switch to tty_port->lock for tty.
> 
>       Signed-off-by: Jiri Slaby <jslaby@suse.cz>
>       Cc: linuxppc-dev@lists.ozlabs.org
>       Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> 
> Reverting this commit (and 0146b6939074ebe14ece3604fd00e7be128a3812
> otherwise git barfs) fixes the problem on next-20120412.  
> 
> I'm assuming we got the ref count changes wrong somewhere in the patch
> but the tty code is beyond me.  Jiri, can you take a look?

Yeah, I see. I forgot to remove a couple of tty reference drops. The
reference is dropped by tty_port_tty_set in open/close/hangup now. Does
the attached patch help?

thanks,
-- 
js
suse labs



[-- Attachment #2: 0001-HVC-fix-refcounting.patch --]
[-- Type: text/x-patch, Size: 1157 bytes --]

>From cc51efe721f5aa184e119c52c661a1faf865e492 Mon Sep 17 00:00:00 2001
From: Jiri Slaby <jslaby@suse.cz>
Date: Fri, 13 Apr 2012 10:00:28 +0200
Subject: [PATCH 1/1] HVC: fix refcounting

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 drivers/tty/hvc/hvc_console.c |    3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index 6c45cbf..260d4f2 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -338,7 +338,6 @@ static int hvc_open(struct tty_struct *tty, struct file * filp)
 	 */
 	if (rc) {
 		tty_port_tty_set(&hp->port, NULL);
-		tty_kref_put(tty);
 		tty->driver_data = NULL;
 		tty_port_put(&hp->port);
 		printk(KERN_ERR "hvc_open: request_irq failed with rc %d.\n", rc);
@@ -393,7 +392,6 @@ static void hvc_close(struct tty_struct *tty, struct file * filp)
 		spin_unlock_irqrestore(&hp->port.lock, flags);
 	}
 
-	tty_kref_put(tty);
 	tty_port_put(&hp->port);
 }
 
@@ -433,7 +431,6 @@ static void hvc_hangup(struct tty_struct *tty)
 
 	while(temp_open_count) {
 		--temp_open_count;
-		tty_kref_put(tty);
 		tty_port_put(&hp->port);
 	}
 }
-- 
1.7.9.2


^ permalink raw reply related	[flat|nested] 14+ messages in thread
* Re: linux-next: boot failures with next-20120411
  2012-04-13  8:02     ` Jiri Slaby
@ 2012-04-13  8:04       ` Jiri Slaby
  -1 siblings, 0 replies; 14+ messages in thread
From: Jiri Slaby @ 2012-04-13  8:04 UTC (permalink / raw)
  To: Jiri Slaby
  Cc: Michael Neuling, Stephen Rothwell, Greg Kroah-Hartman, LKML,
	ppc-dev, linux-next

[-- Attachment #1: Type: text/plain, Size: 3795 bytes --]

On 04/13/2012 10:02 AM, Jiri Slaby wrote:
> On 04/13/2012 04:30 AM, Michael Neuling wrote:
>> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>>> Hi all,
>>>
>>> Some (not all) of my PowerPC boot tests have failed like this after
>>> getting into user mode (this one was just after udev started, but others
>>> are after other processes getting going):
>>>
>>> Unable to handle kernel paging request for data at address 0xc0000003f9d550
>>> Faulting instruction address: 0xc0000000001b7f40
>>> Oops: Kernel access of bad area, sig: 11 [#1]
>>> SMP NR_CPUS=32 NUMA pSeries
>>> Modules linked in: ehea
>>> NIP: c0000000001b7f40 LR: c0000000001b7f14 CTR: c0000000000e04f0
>>> REGS: c0000003f68bf6b0 TRAP: 0300   Not tainted  (3.4.0-rc2-autokern1)
>>> MSR: 800000000280b032 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI>  CR: 24422424  XER: 20000001
>>> SOFTE: 1
>>> CFAR: 000000000000562c
>>> DAR: 00c0000003f9d550, DSISR: 40000000
>>> TASK = c0000003f8818000[3192] 'kdump' THREAD: c0000003f68bc000 CPU: 5
>>> GPR00: 0000000000000000 c0000003f68bf930 c000000000ce1d40 c0000003fe00ec00 
>>> GPR04: 00000000000002d0 0000000000000038 c0000003f8f935e8 c000000000e55280 
>>> GPR08: 0000000000000011 c000000000bcb280 c000000000bcb1e8 000000000028a000 
>>> GPR12: 0000000024422424 c00000000f33bc80 00000fffdd90a770 0000000000081000 
>>> GPR16: c0000003f846c000 000000000de4f7a0 f00000000de4f7a0 0000000000000000 
>>> GPR20: c0000003f8365408 c0000003f8365480 c0000003f8e5d110 0000000000000000 
>>> GPR24: 0000000000000100 c0000003f8365400 c0000000001e5424 00000000000002d0 
>>> GPR28: 0000000000000800 00c0000003f9d550 c000000000c5b718 c0000003fe00ec00 
>>> NIP [c0000000001b7f40] .__kmalloc+0x70/0x230
>>> LR [c0000000001b7f14] .__kmalloc+0x44/0x230
>>> Call Trace:
>>> [c0000003f68bf930] [c0000003f68bf9b0] 0xc0000003f68bf9b0 (unreliable)
>>> [c0000003f68bf9e0] [c0000000001e5424] .alloc_fdmem+0x24/0x70
>>> [c0000003f68bfa60] [c0000000001e54f8] .alloc_fdtable+0x88/0x130
>>> [c0000003f68bfaf0] [c0000000001e5924] .dup_fd+0x384/0x450
>>> [c0000003f68bfbd0] [c00000000009a310] .copy_process+0x880/0x11d0
>>> [c0000003f68bfcd0] [c00000000009aee0] .do_fork+0x70/0x400
>>> [c0000003f68bfdc0] [c0000000000141c4] .sys_clone+0x54/0x70
>>> [c0000003f68bfe30] [c000000000009aa0] .ppc_clone+0x8/0xc
>>> Instruction dump:
>>> 4bff9281 2ba30010 7c7f1b78 40dd00f4 e96d0040 e93f0000 7ce95a14 e9070008 
>>> 7fa9582a 2fbd0000 41de0054 e81f0022 <7f3d002a> 38000000 886d01f2 980d01f2 
>>> ---[ end trace 366fe6c7ced3bfb0 ]---
>>>
>>> This did not happen yesterday.  Just wondering if anyone can think of
>>> anything obvious.  Full console log at
>>> http://ozlabs.org/~sfr/next-20120411.log.bz2
>>
>> I managed to bisect this down using pseries_defconfig with next-20120412
>> to this patch:
>>
>>   commit 85bbc003b24335e253a392f6a9874103b77abb36
>>   Author: Jiri Slaby <jslaby@suse.cz>
>>   Date:   Mon Apr 2 13:54:22 2012 +0200
>>
>>       TTY: HVC, use tty from tty_port
>>
>>       The driver already used refcounting. So we just switch it to tty_port
>>       helpers. And switch to tty_port->lock for tty.
>>
>>       Signed-off-by: Jiri Slaby <jslaby@suse.cz>
>>       Cc: linuxppc-dev@lists.ozlabs.org
>>       Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>
>> Reverting this commit (and 0146b6939074ebe14ece3604fd00e7be128a3812
>> otherwise git barfs) fixes the problem on next-20120412.  
>>
>> I'm assuming we got the ref count changes wrong somewhere in the patch
>> but the tty code is beyond me.  Jiri, can you take a look?
> 
> Yeah, I see. I forgot to remove a couple of tty reference drops. The
> reference is dropped by tty_port_tty_set in open/close/hangup now. Does
> the attached patch help?

And the patch is incomplete. Now we have a leak. This one should work.

> thanks,
-- 
js
suse labs


[-- Attachment #2: 0001-HVC-fix-refcounting.patch --]
[-- Type: text/x-patch, Size: 1496 bytes --]

>From 7a55e2976cb5a47e499a6db335ad30ecac2e621c Mon Sep 17 00:00:00 2001
From: Jiri Slaby <jslaby@suse.cz>
Date: Fri, 13 Apr 2012 10:00:28 +0200
Subject: [PATCH 1/1] HVC: fix refcounting

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 drivers/tty/hvc/hvc_console.c |    5 -----
 1 file changed, 5 deletions(-)

diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index 6c45cbf..2d691eb 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -317,8 +317,6 @@ static int hvc_open(struct tty_struct *tty, struct file * filp)
 	/* Check and then increment for fast path open. */
 	if (hp->port.count++ > 0) {
 		spin_unlock_irqrestore(&hp->port.lock, flags);
-		/* FIXME why taking a reference here? */
-		tty_kref_get(tty);
 		hvc_kick();
 		return 0;
 	} /* else count == 0 */
@@ -338,7 +336,6 @@ static int hvc_open(struct tty_struct *tty, struct file * filp)
 	 */
 	if (rc) {
 		tty_port_tty_set(&hp->port, NULL);
-		tty_kref_put(tty);
 		tty->driver_data = NULL;
 		tty_port_put(&hp->port);
 		printk(KERN_ERR "hvc_open: request_irq failed with rc %d.\n", rc);
@@ -393,7 +390,6 @@ static void hvc_close(struct tty_struct *tty, struct file * filp)
 		spin_unlock_irqrestore(&hp->port.lock, flags);
 	}
 
-	tty_kref_put(tty);
 	tty_port_put(&hp->port);
 }
 
@@ -433,7 +429,6 @@ static void hvc_hangup(struct tty_struct *tty)
 
 	while(temp_open_count) {
 		--temp_open_count;
-		tty_kref_put(tty);
 		tty_port_put(&hp->port);
 	}
 }
-- 
1.7.9.2


^ permalink raw reply related	[flat|nested] 14+ messages in thread
* Re: linux-next: boot failures with next-20120411
@ 2012-04-13  8:04       ` Jiri Slaby
  0 siblings, 0 replies; 14+ messages in thread
From: Jiri Slaby @ 2012-04-13  8:04 UTC (permalink / raw)
  To: Jiri Slaby
  Cc: Stephen Rothwell, Michael Neuling, Greg Kroah-Hartman, LKML,
	linux-next, ppc-dev

[-- Attachment #1: Type: text/plain, Size: 3795 bytes --]

On 04/13/2012 10:02 AM, Jiri Slaby wrote:
> On 04/13/2012 04:30 AM, Michael Neuling wrote:
>> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>>> Hi all,
>>>
>>> Some (not all) of my PowerPC boot tests have failed like this after
>>> getting into user mode (this one was just after udev started, but others
>>> are after other processes getting going):
>>>
>>> Unable to handle kernel paging request for data at address 0xc0000003f9d550
>>> Faulting instruction address: 0xc0000000001b7f40
>>> Oops: Kernel access of bad area, sig: 11 [#1]
>>> SMP NR_CPUS=32 NUMA pSeries
>>> Modules linked in: ehea
>>> NIP: c0000000001b7f40 LR: c0000000001b7f14 CTR: c0000000000e04f0
>>> REGS: c0000003f68bf6b0 TRAP: 0300   Not tainted  (3.4.0-rc2-autokern1)
>>> MSR: 800000000280b032 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI>  CR: 24422424  XER: 20000001
>>> SOFTE: 1
>>> CFAR: 000000000000562c
>>> DAR: 00c0000003f9d550, DSISR: 40000000
>>> TASK = c0000003f8818000[3192] 'kdump' THREAD: c0000003f68bc000 CPU: 5
>>> GPR00: 0000000000000000 c0000003f68bf930 c000000000ce1d40 c0000003fe00ec00 
>>> GPR04: 00000000000002d0 0000000000000038 c0000003f8f935e8 c000000000e55280 
>>> GPR08: 0000000000000011 c000000000bcb280 c000000000bcb1e8 000000000028a000 
>>> GPR12: 0000000024422424 c00000000f33bc80 00000fffdd90a770 0000000000081000 
>>> GPR16: c0000003f846c000 000000000de4f7a0 f00000000de4f7a0 0000000000000000 
>>> GPR20: c0000003f8365408 c0000003f8365480 c0000003f8e5d110 0000000000000000 
>>> GPR24: 0000000000000100 c0000003f8365400 c0000000001e5424 00000000000002d0 
>>> GPR28: 0000000000000800 00c0000003f9d550 c000000000c5b718 c0000003fe00ec00 
>>> NIP [c0000000001b7f40] .__kmalloc+0x70/0x230
>>> LR [c0000000001b7f14] .__kmalloc+0x44/0x230
>>> Call Trace:
>>> [c0000003f68bf930] [c0000003f68bf9b0] 0xc0000003f68bf9b0 (unreliable)
>>> [c0000003f68bf9e0] [c0000000001e5424] .alloc_fdmem+0x24/0x70
>>> [c0000003f68bfa60] [c0000000001e54f8] .alloc_fdtable+0x88/0x130
>>> [c0000003f68bfaf0] [c0000000001e5924] .dup_fd+0x384/0x450
>>> [c0000003f68bfbd0] [c00000000009a310] .copy_process+0x880/0x11d0
>>> [c0000003f68bfcd0] [c00000000009aee0] .do_fork+0x70/0x400
>>> [c0000003f68bfdc0] [c0000000000141c4] .sys_clone+0x54/0x70
>>> [c0000003f68bfe30] [c000000000009aa0] .ppc_clone+0x8/0xc
>>> Instruction dump:
>>> 4bff9281 2ba30010 7c7f1b78 40dd00f4 e96d0040 e93f0000 7ce95a14 e9070008 
>>> 7fa9582a 2fbd0000 41de0054 e81f0022 <7f3d002a> 38000000 886d01f2 980d01f2 
>>> ---[ end trace 366fe6c7ced3bfb0 ]---
>>>
>>> This did not happen yesterday.  Just wondering if anyone can think of
>>> anything obvious.  Full console log at
>>> http://ozlabs.org/~sfr/next-20120411.log.bz2
>>
>> I managed to bisect this down using pseries_defconfig with next-20120412
>> to this patch:
>>
>>   commit 85bbc003b24335e253a392f6a9874103b77abb36
>>   Author: Jiri Slaby <jslaby@suse.cz>
>>   Date:   Mon Apr 2 13:54:22 2012 +0200
>>
>>       TTY: HVC, use tty from tty_port
>>
>>       The driver already used refcounting. So we just switch it to tty_port
>>       helpers. And switch to tty_port->lock for tty.
>>
>>       Signed-off-by: Jiri Slaby <jslaby@suse.cz>
>>       Cc: linuxppc-dev@lists.ozlabs.org
>>       Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>
>> Reverting this commit (and 0146b6939074ebe14ece3604fd00e7be128a3812
>> otherwise git barfs) fixes the problem on next-20120412.  
>>
>> I'm assuming we got the ref count changes wrong somewhere in the patch
>> but the tty code is beyond me.  Jiri, can you take a look?
> 
> Yeah, I see. I forgot to remove a couple of tty reference drops. The
> reference is dropped by tty_port_tty_set in open/close/hangup now. Does
> the attached patch help?

And the patch is incomplete. Now we have a leak. This one should work.

> thanks,
-- 
js
suse labs


[-- Attachment #2: 0001-HVC-fix-refcounting.patch --]
[-- Type: text/x-patch, Size: 1496 bytes --]

>From 7a55e2976cb5a47e499a6db335ad30ecac2e621c Mon Sep 17 00:00:00 2001
From: Jiri Slaby <jslaby@suse.cz>
Date: Fri, 13 Apr 2012 10:00:28 +0200
Subject: [PATCH 1/1] HVC: fix refcounting

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 drivers/tty/hvc/hvc_console.c |    5 -----
 1 file changed, 5 deletions(-)

diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index 6c45cbf..2d691eb 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -317,8 +317,6 @@ static int hvc_open(struct tty_struct *tty, struct file * filp)
 	/* Check and then increment for fast path open. */
 	if (hp->port.count++ > 0) {
 		spin_unlock_irqrestore(&hp->port.lock, flags);
-		/* FIXME why taking a reference here? */
-		tty_kref_get(tty);
 		hvc_kick();
 		return 0;
 	} /* else count == 0 */
@@ -338,7 +336,6 @@ static int hvc_open(struct tty_struct *tty, struct file * filp)
 	 */
 	if (rc) {
 		tty_port_tty_set(&hp->port, NULL);
-		tty_kref_put(tty);
 		tty->driver_data = NULL;
 		tty_port_put(&hp->port);
 		printk(KERN_ERR "hvc_open: request_irq failed with rc %d.\n", rc);
@@ -393,7 +390,6 @@ static void hvc_close(struct tty_struct *tty, struct file * filp)
 		spin_unlock_irqrestore(&hp->port.lock, flags);
 	}
 
-	tty_kref_put(tty);
 	tty_port_put(&hp->port);
 }
 
@@ -433,7 +429,6 @@ static void hvc_hangup(struct tty_struct *tty)
 
 	while(temp_open_count) {
 		--temp_open_count;
-		tty_kref_put(tty);
 		tty_port_put(&hp->port);
 	}
 }
-- 
1.7.9.2


^ permalink raw reply related	[flat|nested] 14+ messages in thread
* Re: linux-next: boot failures with next-20120411
  2012-04-13  8:04       ` Jiri Slaby
@ 2012-04-13  8:09         ` Michael Neuling
  -1 siblings, 0 replies; 14+ messages in thread
From: Michael Neuling @ 2012-04-13  8:09 UTC (permalink / raw)
  To: Jiri Slaby
  Cc: Jiri Slaby, Stephen Rothwell, Greg Kroah-Hartman, LKML, ppc-dev,
	linux-next

Jiri Slaby <jslaby@suse.cz> wrote:

> On 04/13/2012 10:02 AM, Jiri Slaby wrote:
> > On 04/13/2012 04:30 AM, Michael Neuling wrote:
> >> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >>
> >>> Hi all,
> >>>
> >>> Some (not all) of my PowerPC boot tests have failed like this after
> >>> getting into user mode (this one was just after udev started, but others
> >>> are after other processes getting going):
> >>>
> >>> Unable to handle kernel paging request for data at address 0xc0000003f9d550
> >>> Faulting instruction address: 0xc0000000001b7f40
> >>> Oops: Kernel access of bad area, sig: 11 [#1]
> >>> SMP NR_CPUS=32 NUMA pSeries
> >>> Modules linked in: ehea
> >>> NIP: c0000000001b7f40 LR: c0000000001b7f14 CTR: c0000000000e04f0
> >>> REGS: c0000003f68bf6b0 TRAP: 0300   Not tainted  (3.4.0-rc2-autokern1)
> >>> MSR: 800000000280b032 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI>  CR: 24422424  XER: 20000001
> >>> SOFTE: 1
> >>> CFAR: 000000000000562c
> >>> DAR: 00c0000003f9d550, DSISR: 40000000
> >>> TASK = c0000003f8818000[3192] 'kdump' THREAD: c0000003f68bc000 CPU: 5
> >>> GPR00: 0000000000000000 c0000003f68bf930 c000000000ce1d40 c0000003fe00ec00 
> >>> GPR04: 00000000000002d0 0000000000000038 c0000003f8f935e8 c000000000e55280 
> >>> GPR08: 0000000000000011 c000000000bcb280 c000000000bcb1e8 000000000028a000 
> >>> GPR12: 0000000024422424 c00000000f33bc80 00000fffdd90a770 0000000000081000 
> >>> GPR16: c0000003f846c000 000000000de4f7a0 f00000000de4f7a0 0000000000000000 
> >>> GPR20: c0000003f8365408 c0000003f8365480 c0000003f8e5d110 0000000000000000 
> >>> GPR24: 0000000000000100 c0000003f8365400 c0000000001e5424 00000000000002d0 
> >>> GPR28: 0000000000000800 00c0000003f9d550 c000000000c5b718 c0000003fe00ec00 
> >>> NIP [c0000000001b7f40] .__kmalloc+0x70/0x230
> >>> LR [c0000000001b7f14] .__kmalloc+0x44/0x230
> >>> Call Trace:
> >>> [c0000003f68bf930] [c0000003f68bf9b0] 0xc0000003f68bf9b0 (unreliable)
> >>> [c0000003f68bf9e0] [c0000000001e5424] .alloc_fdmem+0x24/0x70
> >>> [c0000003f68bfa60] [c0000000001e54f8] .alloc_fdtable+0x88/0x130
> >>> [c0000003f68bfaf0] [c0000000001e5924] .dup_fd+0x384/0x450
> >>> [c0000003f68bfbd0] [c00000000009a310] .copy_process+0x880/0x11d0
> >>> [c0000003f68bfcd0] [c00000000009aee0] .do_fork+0x70/0x400
> >>> [c0000003f68bfdc0] [c0000000000141c4] .sys_clone+0x54/0x70
> >>> [c0000003f68bfe30] [c000000000009aa0] .ppc_clone+0x8/0xc
> >>> Instruction dump:
> >>> 4bff9281 2ba30010 7c7f1b78 40dd00f4 e96d0040 e93f0000 7ce95a14 e9070008 
> >>> 7fa9582a 2fbd0000 41de0054 e81f0022 <7f3d002a> 38000000 886d01f2 980d01f2 
> >>> ---[ end trace 366fe6c7ced3bfb0 ]---
> >>>
> >>> This did not happen yesterday.  Just wondering if anyone can think of
> >>> anything obvious.  Full console log at
> >>> http://ozlabs.org/~sfr/next-20120411.log.bz2
> >>
> >> I managed to bisect this down using pseries_defconfig with next-20120412
> >> to this patch:
> >>
> >>   commit 85bbc003b24335e253a392f6a9874103b77abb36
> >>   Author: Jiri Slaby <jslaby@suse.cz>
> >>   Date:   Mon Apr 2 13:54:22 2012 +0200
> >>
> >>       TTY: HVC, use tty from tty_port
> >>
> >>       The driver already used refcounting. So we just switch it to tty_port
> >>       helpers. And switch to tty_port->lock for tty.
> >>
> >>       Signed-off-by: Jiri Slaby <jslaby@suse.cz>
> >>       Cc: linuxppc-dev@lists.ozlabs.org
> >>       Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> >>
> >> Reverting this commit (and 0146b6939074ebe14ece3604fd00e7be128a3812
> >> otherwise git barfs) fixes the problem on next-20120412.  
> >>
> >> I'm assuming we got the ref count changes wrong somewhere in the patch
> >> but the tty code is beyond me.  Jiri, can you take a look?
> > 
> > Yeah, I see. I forgot to remove a couple of tty reference drops. The
> > reference is dropped by tty_port_tty_set in open/close/hangup now. Does
> > the attached patch help?
> 
> And the patch is incomplete. Now we have a leak. This one should work.

Fixes the problem here.. Thanks.

Tested-by: Michael Neuling <mikey@neuling.org>

^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: linux-next: boot failures with next-20120411
@ 2012-04-13  8:09         ` Michael Neuling
  0 siblings, 0 replies; 14+ messages in thread
From: Michael Neuling @ 2012-04-13  8:09 UTC (permalink / raw)
  To: Jiri Slaby
  Cc: Stephen Rothwell, Jiri Slaby, Greg Kroah-Hartman, LKML,
	linux-next, ppc-dev

Jiri Slaby <jslaby@suse.cz> wrote:

> On 04/13/2012 10:02 AM, Jiri Slaby wrote:
> > On 04/13/2012 04:30 AM, Michael Neuling wrote:
> >> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >>
> >>> Hi all,
> >>>
> >>> Some (not all) of my PowerPC boot tests have failed like this after
> >>> getting into user mode (this one was just after udev started, but others
> >>> are after other processes getting going):
> >>>
> >>> Unable to handle kernel paging request for data at address 0xc0000003f9d550
> >>> Faulting instruction address: 0xc0000000001b7f40
> >>> Oops: Kernel access of bad area, sig: 11 [#1]
> >>> SMP NR_CPUS=32 NUMA pSeries
> >>> Modules linked in: ehea
> >>> NIP: c0000000001b7f40 LR: c0000000001b7f14 CTR: c0000000000e04f0
> >>> REGS: c0000003f68bf6b0 TRAP: 0300   Not tainted  (3.4.0-rc2-autokern1)
> >>> MSR: 800000000280b032 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI>  CR: 24422424  XER: 20000001
> >>> SOFTE: 1
> >>> CFAR: 000000000000562c
> >>> DAR: 00c0000003f9d550, DSISR: 40000000
> >>> TASK = c0000003f8818000[3192] 'kdump' THREAD: c0000003f68bc000 CPU: 5
> >>> GPR00: 0000000000000000 c0000003f68bf930 c000000000ce1d40 c0000003fe00ec00 
> >>> GPR04: 00000000000002d0 0000000000000038 c0000003f8f935e8 c000000000e55280 
> >>> GPR08: 0000000000000011 c000000000bcb280 c000000000bcb1e8 000000000028a000 
> >>> GPR12: 0000000024422424 c00000000f33bc80 00000fffdd90a770 0000000000081000 
> >>> GPR16: c0000003f846c000 000000000de4f7a0 f00000000de4f7a0 0000000000000000 
> >>> GPR20: c0000003f8365408 c0000003f8365480 c0000003f8e5d110 0000000000000000 
> >>> GPR24: 0000000000000100 c0000003f8365400 c0000000001e5424 00000000000002d0 
> >>> GPR28: 0000000000000800 00c0000003f9d550 c000000000c5b718 c0000003fe00ec00 
> >>> NIP [c0000000001b7f40] .__kmalloc+0x70/0x230
> >>> LR [c0000000001b7f14] .__kmalloc+0x44/0x230
> >>> Call Trace:
> >>> [c0000003f68bf930] [c0000003f68bf9b0] 0xc0000003f68bf9b0 (unreliable)
> >>> [c0000003f68bf9e0] [c0000000001e5424] .alloc_fdmem+0x24/0x70
> >>> [c0000003f68bfa60] [c0000000001e54f8] .alloc_fdtable+0x88/0x130
> >>> [c0000003f68bfaf0] [c0000000001e5924] .dup_fd+0x384/0x450
> >>> [c0000003f68bfbd0] [c00000000009a310] .copy_process+0x880/0x11d0
> >>> [c0000003f68bfcd0] [c00000000009aee0] .do_fork+0x70/0x400
> >>> [c0000003f68bfdc0] [c0000000000141c4] .sys_clone+0x54/0x70
> >>> [c0000003f68bfe30] [c000000000009aa0] .ppc_clone+0x8/0xc
> >>> Instruction dump:
> >>> 4bff9281 2ba30010 7c7f1b78 40dd00f4 e96d0040 e93f0000 7ce95a14 e9070008 
> >>> 7fa9582a 2fbd0000 41de0054 e81f0022 <7f3d002a> 38000000 886d01f2 980d01f2 
> >>> ---[ end trace 366fe6c7ced3bfb0 ]---
> >>>
> >>> This did not happen yesterday.  Just wondering if anyone can think of
> >>> anything obvious.  Full console log at
> >>> http://ozlabs.org/~sfr/next-20120411.log.bz2
> >>
> >> I managed to bisect this down using pseries_defconfig with next-20120412
> >> to this patch:
> >>
> >>   commit 85bbc003b24335e253a392f6a9874103b77abb36
> >>   Author: Jiri Slaby <jslaby@suse.cz>
> >>   Date:   Mon Apr 2 13:54:22 2012 +0200
> >>
> >>       TTY: HVC, use tty from tty_port
> >>
> >>       The driver already used refcounting. So we just switch it to tty_port
> >>       helpers. And switch to tty_port->lock for tty.
> >>
> >>       Signed-off-by: Jiri Slaby <jslaby@suse.cz>
> >>       Cc: linuxppc-dev@lists.ozlabs.org
> >>       Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> >>
> >> Reverting this commit (and 0146b6939074ebe14ece3604fd00e7be128a3812
> >> otherwise git barfs) fixes the problem on next-20120412.  
> >>
> >> I'm assuming we got the ref count changes wrong somewhere in the patch
> >> but the tty code is beyond me.  Jiri, can you take a look?
> > 
> > Yeah, I see. I forgot to remove a couple of tty reference drops. The
> > reference is dropped by tty_port_tty_set in open/close/hangup now. Does
> > the attached patch help?
> 
> And the patch is incomplete. Now we have a leak. This one should work.

Fixes the problem here.. Thanks.

Tested-by: Michael Neuling <mikey@neuling.org>

^ permalink raw reply	[flat|nested] 14+ messages in thread
* [PATCH 1/1] TTY: hvc, fix TTY refcounting
  2012-04-13  8:09         ` Michael Neuling
@ 2012-04-13  8:31           ` Jiri Slaby
  -1 siblings, 0 replies; 14+ messages in thread
From: Jiri Slaby @ 2012-04-13  8:31 UTC (permalink / raw)
  To: gregkh; +Cc: linux-kernel, jirislaby, Stephen Rothwell, ppc-dev

A -next commit "TTY: HVC, use tty from tty_port" switched the driver
to use tty_port helper for tty refcounting. But it omitted to remove
manual tty refcounting from open, close and hangup. So now we are
getting random crashes caused by use-after-free:
Unable to handle kernel paging request for data at address 0xc0000003f9d550
Faulting instruction address: 0xc0000000001b7f40
Oops: Kernel access of bad area, sig: 11 [#1]
...
NIP: c0000000001b7f40 LR: c0000000001b7f14 CTR: c0000000000e04f0
...
NIP [c0000000001b7f40] .__kmalloc+0x70/0x230
LR [c0000000001b7f14] .__kmalloc+0x44/0x230
Call Trace:
[c0000003f68bf930] [c0000003f68bf9b0] 0xc0000003f68bf9b0 (unreliable)
[c0000003f68bf9e0] [c0000000001e5424] .alloc_fdmem+0x24/0x70
[c0000003f68bfa60] [c0000000001e54f8] .alloc_fdtable+0x88/0x130
[c0000003f68bfaf0] [c0000000001e5924] .dup_fd+0x384/0x450
[c0000003f68bfbd0] [c00000000009a310] .copy_process+0x880/0x11d0
[c0000003f68bfcd0] [c00000000009aee0] .do_fork+0x70/0x400
[c0000003f68bfdc0] [c0000000000141c4] .sys_clone+0x54/0x70
[c0000003f68bfe30] [c000000000009aa0] .ppc_clone+0x8/0xc

Fix that by complete removal of tty_kref_get/put in open/close/hangup
paths.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Reported-and-tested-by: Michael Neuling <mikey@neuling.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: ppc-dev <linuxppc-dev@lists.ozlabs.org>
---
 drivers/tty/hvc/hvc_console.c |    5 -----
 1 file changed, 5 deletions(-)

diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index 6c45cbf..2d691eb 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -317,8 +317,6 @@ static int hvc_open(struct tty_struct *tty, struct file * filp)
 	/* Check and then increment for fast path open. */
 	if (hp->port.count++ > 0) {
 		spin_unlock_irqrestore(&hp->port.lock, flags);
-		/* FIXME why taking a reference here? */
-		tty_kref_get(tty);
 		hvc_kick();
 		return 0;
 	} /* else count == 0 */
@@ -338,7 +336,6 @@ static int hvc_open(struct tty_struct *tty, struct file * filp)
 	 */
 	if (rc) {
 		tty_port_tty_set(&hp->port, NULL);
-		tty_kref_put(tty);
 		tty->driver_data = NULL;
 		tty_port_put(&hp->port);
 		printk(KERN_ERR "hvc_open: request_irq failed with rc %d.\n", rc);
@@ -393,7 +390,6 @@ static void hvc_close(struct tty_struct *tty, struct file * filp)
 		spin_unlock_irqrestore(&hp->port.lock, flags);
 	}
 
-	tty_kref_put(tty);
 	tty_port_put(&hp->port);
 }
 
@@ -433,7 +429,6 @@ static void hvc_hangup(struct tty_struct *tty)
 
 	while(temp_open_count) {
 		--temp_open_count;
-		tty_kref_put(tty);
 		tty_port_put(&hp->port);
 	}
 }
-- 
1.7.9.2



^ permalink raw reply related	[flat|nested] 14+ messages in thread
* [PATCH 1/1] TTY: hvc, fix TTY refcounting
@ 2012-04-13  8:31           ` Jiri Slaby
  0 siblings, 0 replies; 14+ messages in thread
From: Jiri Slaby @ 2012-04-13  8:31 UTC (permalink / raw)
  To: gregkh; +Cc: Stephen Rothwell, ppc-dev, linux-kernel, jirislaby

A -next commit "TTY: HVC, use tty from tty_port" switched the driver
to use tty_port helper for tty refcounting. But it omitted to remove
manual tty refcounting from open, close and hangup. So now we are
getting random crashes caused by use-after-free:
Unable to handle kernel paging request for data at address 0xc0000003f9d550
Faulting instruction address: 0xc0000000001b7f40
Oops: Kernel access of bad area, sig: 11 [#1]
...
NIP: c0000000001b7f40 LR: c0000000001b7f14 CTR: c0000000000e04f0
...
NIP [c0000000001b7f40] .__kmalloc+0x70/0x230
LR [c0000000001b7f14] .__kmalloc+0x44/0x230
Call Trace:
[c0000003f68bf930] [c0000003f68bf9b0] 0xc0000003f68bf9b0 (unreliable)
[c0000003f68bf9e0] [c0000000001e5424] .alloc_fdmem+0x24/0x70
[c0000003f68bfa60] [c0000000001e54f8] .alloc_fdtable+0x88/0x130
[c0000003f68bfaf0] [c0000000001e5924] .dup_fd+0x384/0x450
[c0000003f68bfbd0] [c00000000009a310] .copy_process+0x880/0x11d0
[c0000003f68bfcd0] [c00000000009aee0] .do_fork+0x70/0x400
[c0000003f68bfdc0] [c0000000000141c4] .sys_clone+0x54/0x70
[c0000003f68bfe30] [c000000000009aa0] .ppc_clone+0x8/0xc

Fix that by complete removal of tty_kref_get/put in open/close/hangup
paths.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Reported-and-tested-by: Michael Neuling <mikey@neuling.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: ppc-dev <linuxppc-dev@lists.ozlabs.org>
---
 drivers/tty/hvc/hvc_console.c |    5 -----
 1 file changed, 5 deletions(-)

diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index 6c45cbf..2d691eb 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -317,8 +317,6 @@ static int hvc_open(struct tty_struct *tty, struct file * filp)
 	/* Check and then increment for fast path open. */
 	if (hp->port.count++ > 0) {
 		spin_unlock_irqrestore(&hp->port.lock, flags);
-		/* FIXME why taking a reference here? */
-		tty_kref_get(tty);
 		hvc_kick();
 		return 0;
 	} /* else count == 0 */
@@ -338,7 +336,6 @@ static int hvc_open(struct tty_struct *tty, struct file * filp)
 	 */
 	if (rc) {
 		tty_port_tty_set(&hp->port, NULL);
-		tty_kref_put(tty);
 		tty->driver_data = NULL;
 		tty_port_put(&hp->port);
 		printk(KERN_ERR "hvc_open: request_irq failed with rc %d.\n", rc);
@@ -393,7 +390,6 @@ static void hvc_close(struct tty_struct *tty, struct file * filp)
 		spin_unlock_irqrestore(&hp->port.lock, flags);
 	}
 
-	tty_kref_put(tty);
 	tty_port_put(&hp->port);
 }
 
@@ -433,7 +429,6 @@ static void hvc_hangup(struct tty_struct *tty)
 
 	while(temp_open_count) {
 		--temp_open_count;
-		tty_kref_put(tty);
 		tty_port_put(&hp->port);
 	}
 }
-- 
1.7.9.2

^ permalink raw reply related	[flat|nested] 14+ messages in thread
end of thread, other threads:[~2012-04-13  8:31 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-04-11  6:58 linux-next: boot failures with next-20120411 Stephen Rothwell
2012-04-12  2:44 ` Milton Miller
2012-04-13  2:30 ` Michael Neuling
2012-04-13  2:30   ` Michael Neuling
2012-04-13  2:57   ` Stephen Rothwell
2012-04-13  2:57     ` Stephen Rothwell
2012-04-13  8:02   ` Jiri Slaby
2012-04-13  8:02     ` Jiri Slaby
2012-04-13  8:04     ` Jiri Slaby
2012-04-13  8:04       ` Jiri Slaby
2012-04-13  8:09       ` Michael Neuling
2012-04-13  8:09         ` Michael Neuling
2012-04-13  8:31         ` [PATCH 1/1] TTY: hvc, fix TTY refcounting Jiri Slaby
2012-04-13  8:31           ` Jiri Slaby

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.