Re: [Bug 8473] New: Oops: 0010 [1] SMP

[Björn Steinbrink <B.Steinbrink@gmx.de>]

On 2007.05.26 21:10:15 +0200, Nicolas Mailhot wrote:
> Le jeudi 17 mai 2007 à 18:59 +0200, Nicolas Mailhot a écrit :
> > Le jeudi 17 mai 2007 à 09:45 -0700, Randy Dunlap a écrit :
> > 
> > > Can you boot with "kstack=32" so that we can see more of the stack?
> > 
> > I can try. It's not triggering quickly though
> 
> Seems I was completely wrong about the trigger, but anyway it happened
> again, this time on 2.6.22-rc2.mm1.cfs14 (and I had kept kstack=32)
> 
>  BUG: using smp_processor_id() in preemptible [00000001] code: bash/3857
>  caller is oops_begin+0xb/0x6f
>  
>  Call Trace:
>  [<ffffffff8020ab4d>] show_trace+0x34/0x4f
>  [<ffffffff8020ab7a>] dump_stack+0x12/0x17
>  [<ffffffff8030d92d>] debug_smp_processor_id+0xad/0xbc
>  [<ffffffff8042388f>] oops_begin+0xb/0x6f
>  [<ffffffff8042520b>] do_page_fault+0x66a/0x7c0
>  [<ffffffff804234bd>] error_exit+0x0/0x84
>  
>  Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP: 
>  [<0000000000000000>]
>  PGD bdd2067 PUD c133067 PMD 0 
>  Oops: 0010 [1] PREEMPT SMP 
>  CPU 1 
>  Pid: 3857, comm: bash Not tainted 2.6.22-0.8.rc2.mm1.cfs14.fc8.nim #1
>  RIP: 0010:[<0000000000000000>]  [<0000000000000000>]
>  RSP: 0018:ffff81000cb03ee0  EFLAGS: 00010296
>  RAX: ffffffff8044dbc0 RBX: ffff81000c3aa8c0 RCX: 00007fff549dcae4
>  RDX: 0000000000005410 RSI: ffff81000c3aa8c0 RDI: ffff81000ba913d8
>  RBP: 00007fff549dcae4 R08: 0000000000000000 R09: 00000000ffffffff
>  R10: 0000000000000008 R11: 0000000000000246 R12: 0000000000005410
>  R13: 00000000000000ff R14: 00000000000000ff R15: 0000000000000000
>  FS:  00002b06560d8f40(0000) GS:ffff810004017180(0000) knlGS:0000000000000000
>  CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>  CR2: 0000000000000000 CR3: 000000000bc55000 CR4: 00000000000006e0
>  Process bash (pid: 3857, threadinfo ffff81000cb02000, task ffff81000adc59a0)
>  Stack:  ffffffff8028ada9 ffff81000c3aa8c0 00007fff549dcae4 00007fff549dcae4
>  ffffffff8028b016 0000000000005410 00000000000000ff ffff81000c3aa8c0
>  0000000000000000 00007fff549dcae4 0000000000005410 00000000000000ff
>  ffffffff8028b088 0000000000000000 0000000080209571 00000000ffffffff
>  00007fff549dce87 0000000000000f11 00007fff549dcfb8 00007fff549dddb0
>  ffffffff802095dc 0000000000000246 0000000000000008 00000000ffffffff
>  0000000000000000 ffffffffffffffda ffffffffffffffff 00007fff549dcae4
>  0000000000005410 00000000000000ff 0000000000000010 0000003d340c9117
>  Call Trace:
>  Inexact backtrace:
>  [<ffffffff8028ada9>] do_ioctl+0x55/0x6b
>  [<ffffffff8028b016>] vfs_ioctl+0x257/0x270
>  [<ffffffff8028b088>] sys_ioctl+0x59/0x79
>  [<ffffffff802095dc>] tracesys+0xdc/0xe1
>  
>  INFO: lockdep is turned off.
>  
>  Code:  Bad RIP value.
>  RIP  [<0000000000000000>]
>  RSP <ffff81000cb03ee0>
>  CR2: 0000000000000000

This is do_tty_hangup() exchanging the fops while we're waiting for the
lock. The new fops (hung_up_tty_fops) only have the unlocked variant and
thus we Oops our way.

The following program reproduces it quite easily on a SMP box. I'm
running it from X as root like this:
while true; do xterm /path/to/program; done

#include <pthread.h>
#include <stdio.h>
#include <unistd.h>

#include <sys/ioctl.h>

pid_t pid;

void *thread(void *arg)
{
	while (1)
		ioctl(0, TIOCSPGRP, &pid);
}

int main()
{
	pthread_t t;

	pid = getpid();

	pthread_create(&t, NULL, thread, NULL);
	sleep(1);
	vhangup();
	perror("vhangup");
	return 0;
}

I'm not exactly sure how to solve that in a clean way, though. Moving
the call to lock_kernel() up would make the Oops go away, but could
result in the wrong error code being returned. Checking for ioctl first
and unlocked_ioctl last would cause useless locking. And retrying the
unlocked ioctl doesn't look nice either :-(

Björn
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/