Subject: Re: hvc_console: Don't access hvc_task if not initialised

From: Amit Shah <[email-masked]>
Date: Wed, 20 Apr 2011 22:36:10 +0530

On (Wed) 20 Apr 2011 [07:34:35], Greg KH wrote:
> On Wed, Apr 20, 2011 at 06:03:30PM +0530, Amit Shah wrote:
> > 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.
> 
> Care to either create this patch, or resend your original one, if you
> want it applied?

Rusty has the other one queued.  I pinged him about status.

		Amit