[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110420123330.GB3519@amit-x200.redhat.com>
Date: Wed, 20 Apr 2011 18:03:30 +0530
From: Amit Shah <amit.shah@...hat.com>
To: Milton Miller <miltonm@....com>
Cc: Rusty Russell <rusty@...tcorp.com.au>,
linux-kernel@...r.kernel.org, benh@...nel.crashing.org,
greg@...ah.com, linuxppc-dev@...abs.org
Subject: Re: hvc_console: Don't access hvc_task if not initialised
On (Mon) 28 Mar 2011 [11:52:05], Milton Miller wrote:
> On Fri, 25 Mar 2011 about 14:17:14 +0530, Amit Shah wrote:
> > On (Thu) 24 Mar 2011 [08:58:04], Milton Miller wrote:
> > > On Thu, 24 Mar 2011 07:29:58 -0000, Amit Shah wrote:
> > > > hvc_open() can be called without having any backing device. This
> > > > results in a call to hvc_kick() which calls wake_up_process on a NULL
> > > > pointer.
> > >
> > > How is hvc_open called without a hvc_driver registered to the tty layer?
> >
> > This gets reproduced in a couple of scenarios, I'm trying to get more
> > information.
OK - I finally could reproduce myself, albiet it's a panic in
hvc_open, not the one mentioned earlier.
hvc_console is built into the kernel and virtio_console is a module.
This sequence triggers a panic:
- modprobe virtio_console
- agetty /dev/hvc0 9600 vt100
- rmmod virtio_console
- modprobe virtio_console
- agetty /dev/hvc0 9600 vt100
A patch that I had sent previously, to hvc_remove() a port when the
associated virtio_console port gets unplugged, fixes this panic.
Stricter checking in hvc_open(), as you mentioned, will solve the
other one as well.
Thanks!
Amit
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists