linux-kernel - linux-next: boot panic in serial init

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20090724171841.b128f8be.sfr@canb.auug.org.au>
Date:	Fri, 24 Jul 2009 17:18:41 +1000
From:	Stephen Rothwell <sfr@...b.auug.org.au>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	linux-next@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: linux-next: boot panic in serial init

Hi Alan,

Today's linux-next on a pSeries PowerPC machine panics during boot like
this:

calling  .serial8250_init+0x0/0x230 @ 1
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
------------[ cut here ]------------
kernel BUG at arch/powerpc/lib/locks.c:36!
cpu 0x0: Vector: 700 (Program Check) at [c0000000be683740]
    pc: c000000000039460: .__spin_yield+0x40/0x90
    lr: c000000000570284: ._spin_lock+0x84/0x90
    sp: c0000000be6839c0
   msr: 8000000000029032
  current = 0xc0000000be67e000
  paca    = 0xc000000000947200
    pid   = 1, comm = swapper
kernel BUG at arch/powerpc/lib/locks.c:36!
enter ? for help
[c0000000be683a30] c000000000570284 ._spin_lock+0x84/0x90
[c0000000be683ab0] c00000000056e75c .__mutex_lock_slowpath+0xec/0x2d0
[c0000000be683b90] c00000000056e274 .mutex_lock+0x54/0x60
[c0000000be683c10] c00000000032f6f8 .uart_add_one_port+0xd8/0x3f0
[c0000000be683d30] c0000000007a48c4 .serial8250_init+0x1a4/0x230
[c0000000be683de0] c00000000000947c .do_one_initcall+0x6c/0x1e0
[c0000000be683ee0] c000000000779d6c .kernel_init+0x23c/0x2c0
[c0000000be683f90] c00000000002a8e4 .kernel_thread+0x54/0x70

arch/powerpc/lib/locks.c line 36 is:

        lock_value = lock->slock;
        if (lock_value == 0)
                return;
        holder_cpu = lock_value & 0xffff;
        BUG_ON(holder_cpu >= NR_CPUS);

this last line.  Which would imply that the lock has probably not been
initialised.  Indeed, uart_add_one_port does:

	struct tty_port *port;

	mutex_lock(&port->mutex);

without assigning to port.  See "serial-move-mutex" from the ttydev tree.

-- 
Cheers,
Stephen Rothwell                    sfr@...b.auug.org.au
http://www.canb.auug.org.au/~sfr/

Content of type "application/pgp-signature" skipped