Messages in this thread | | | From | "karl malbrain" <> | Subject | RE: 2.6.9 chrdev_open: serial_core: uart_open | Date | Fri, 15 Jul 2005 13:52:15 -0700 |
| |
> -----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
- 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/
| |