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
> >
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
To: karl malbrain
Cc: [EMAIL PROTECTED] Kernel. Org
Subject: Re: 2.6.9
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) { [...]
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(_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! Go
> -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 wr
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
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???
-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 wrote:
chrdev_open issues a lock_kernel
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: serial_core: uart_open
On Thu, Jul 14, 2005 at 04
-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:
-Original Message-
From
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! Go
-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 my 2.6.9-11EL source it clearly
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: serial_core: uart_open
On Fri, Jul 15, 2005 at 01
-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:
-Original Message-
From
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
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.
Do
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
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
26 matches
Mail list logo
