OTECTED] Kernel. Org
> Subject: Re: 2.6.9 chrdev_open: serial_core: uart_open
>
>
> On Fri, Jul 15, 2005 at 02:17:01PM -0700, karl malbrain wrote:
> > > -Original Message-
> > > From: Russell King
> > > Sent: Friday, July 15, 2005 1:59 PM
> >
Hi, Alan Cox wrote:
> A good rule of thumb
> is to trace the sequence of calls and assume that the last sane sequence
> is the one that occurred before the failure.
Note also that gcc does sibling optimization, i.e. it will happily
reduce the code at the end of
int bar(a,b) { [...] return
On Gwe, 2005-07-15 at 15:02 -0700, karl malbrain wrote:
> I've since answered part of my question. Red Hat pulled some code-changes
> from 2.6.10 tty_io.c with the somewhat cryptic comment "fix the trivial
> exploits caused by Rolands controlling tty changes (part 1)" and moved the
> tty_sem ops.
On Gwe, 2005-07-15 at 13:11 -0700, karl malbrain wrote:
> N.b. I don't pretend to understand how uart_change_pm, uart_startup, and
> uart_block_til_ready could ALL be on the call stack. Uart_open calls them
> sequentially. Perhaps you might explain how this works? Thanks, karl m
gcc does smart
> -Original Message-
> From: Russell King
> Sent: Friday, July 15, 2005 2:54 PM
> To: karl malbrain
> Cc: [EMAIL PROTECTED] Kernel. Org
> Subject: Re: 2.6.9 chrdev_open: serial_core: uart_open
>
>
> On Fri, Jul 15, 2005 at 02:17:01PM -0700, karl malbrain wrote:
On Fri, Jul 15, 2005 at 02:17:01PM -0700, karl malbrain wrote:
> > -Original Message-
> > From: Russell King
> > Sent: Friday, July 15, 2005 1:59 PM
> > To: karl malbrain
> > Cc: [EMAIL PROTECTED] Kernel. Org
> > Subject: Re: 2.6.9 chrdev_open: seria
> -Original Message-
> From: Russell King
> Sent: Friday, July 15, 2005 1:59 PM
> To: karl malbrain
> Cc: [EMAIL PROTECTED] Kernel. Org
> Subject: Re: 2.6.9 chrdev_open: serial_core: uart_open
>
>
> On Fri, Jul 15, 2005 at 01:52:15PM -0700, karl malbrain wrote:
On Fri, Jul 15, 2005 at 01:52:15PM -0700, karl malbrain wrote:
> 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.
In which case, I have to say...
Congratulations! You've found a bug with Red Hat's Enterprise Linux
kernel! G
> -Original Message-
> From: Russell King
> Sent: Friday, July 15, 2005 1:31 PM
> To: karl malbrain
> Cc: [EMAIL PROTECTED] 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:
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: [EMAIL PROTECTED] Kernel. Org
> > Subject: Re: 2.6.9 chrdev_open: seria
> -Original Message-
> From: Russell King
> Sent: Friday, July 15, 2005 12:23 AM
> To: karl malbrain
> Cc: [EMAIL PROTECTED] 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 wrot
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/tt
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"???
karl m
-
To unsubscribe from this list: send the line "unsubscr
13 matches
Mail list logo
