RE: 2.6.9 chrdev_open: serial_core: uart_open

["karl malbrain" <karl@petzent.com>]

> -----Original Message-----
> From: Russell King
> Sent: Friday, July 15, 2005 1:31 PM
> To: karl malbrain
> Cc: Linux-Kernel@Vger. Kernel. Org
> Subject: Re: 2.6.9 chrdev_open: serial_core: uart_open
>
>
> On Fri, Jul 15, 2005 at 01:11:33PM -0700, karl malbrain wrote:
> > > -----Original Message-----
> > > From: Russell King
> > > Sent: Friday, July 15, 2005 12:23 AM
> > > To: karl malbrain
> > > Cc: Linux-Kernel@Vger. Kernel. Org
> > > Subject: Re: 2.6.9 chrdev_open: serial_core: uart_open
> > >
> > >
> > > On Thu, Jul 14, 2005 at 04:50:00PM -0700, karl malbrain wrote:
> > > > chrdev_open issues a lock_kernel() before calling uart_open.
> > > >
> > > > It would appear that servicing the blocking open request
> > > uart_open goes to
> > > > sleep with the kernel locked.  Would this shut down
> subsequent access to
> > > > opening "/dev/tty"???
> > >
> > > No.  lock_kernel() is automatically released when a process sleeps.
> >
> > Drilling down between the uart_open and chrdev_open into tty_open is a
> > semaphore tty_sem that is being held during the sleep cycle in
> uart_open.
>
> chrdev_open() calls tty_open(), which then calls init_dev().  init_dev()
> takes tty_sem, does its stuff, and then releases tty_sem.  A little
> later on, tty_open() calls the uart driver's uart_open() function.
>
> So it does this with tty_sem unlocked.

On my 2.6.9-11EL source it clearly shows the up(&tty_sem) after the call to
uart_open. Init_dev never touches tty_sem.

karl m