RE: 2.6.9 chrdev_open: serial_core: uart_open
Successful resolution!! The red-hat engineers monitoring their bugzilla list posted a fix for tty_io.c Friday that works. Thanks again for your help. karl m > -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: 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 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 straight to Red Hat's bugzilla! Do not collect 200$. Do > > > not pass go. > > > > > > Seriously though, this bug is not present in mainline kernels, so I > > > can't resolve this issue for you. Mainline kernels appear to work > > > properly. > > > > Could tty_io.c be all that changed by a small set of red-hat patches to > > 2.6.9? Why would they need to go in there to make so many > changes in the > > first place? Which 2.6 release changed tty_io.c's use of tty_sem so > > heavily? > > These are questions to ask of Red Hat, and can only be answered by > their representatives. > > Thanks anyway, and I'm sorry that this hasn't been resolved given > the amount of time put into it by both of us. > > -- > Russell King > Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ > maintainer of: 2.6 Serial core - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.9 chrdev_open: serial_core: uart_open
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 baz(x,y); }
into something like
overwrite 'a' with 'x', and 'b' with 'y'
pop local stack frame, if present
jump to baz
which saves some stack space and is faster, but makes you wonder
how in hell the
baz
foo
stack dump you're seeing in your crash dump came about.
(2.6.13 will turn that off when debugging.)
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
There is a vast difference between putting your nose in other people's
business and putting your heart in other people's problems.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.9 chrdev_open: serial_core: uart_open
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 you know if this would be Roland at Red Hat, or a Roland at lkml? Roland at Red Hat. See the kernel list but 2.6.9 had an interesting hole where you could crash the system by playing games with setsid and threaded applications. RHEL bugs really are best in the RHEL bugzilla, or through your support contact as a customer. That ensures that the bug is processed promptly and chased up for you while bugzilla is just for bug collection. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.9 chrdev_open: serial_core: uart_open
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 things including deferring stack cleanup so that it can turn push, push, call, adjust stack, push, push call .. etc into a sequence with less stack pointer adjustment for performance reasons. That sometimes fools the traceback code. 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. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.9 chrdev_open: serial_core: uart_open
> -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: 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 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 straight to Red Hat's bugzilla! Do not collect 200$. Do > > > not pass go. > > > > > > Seriously though, this bug is not present in mainline kernels, so I > > > can't resolve this issue for you. Mainline kernels appear to work > > > properly. > > > > Could tty_io.c be all that changed by a small set of red-hat patches to > > 2.6.9? Why would they need to go in there to make so many > changes in the > > first place? Which 2.6 release changed tty_io.c's use of tty_sem so > > heavily? > > These are questions to ask of Red Hat, and can only be answered by > their representatives. 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 you know if this would be Roland at Red Hat, or a Roland at lkml? Thanks, karl m - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 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 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 straight to Red Hat's bugzilla! Do not collect 200$. Do > > not pass go. > > > > Seriously though, this bug is not present in mainline kernels, so I > > can't resolve this issue for you. Mainline kernels appear to work > > properly. > > Could tty_io.c be all that changed by a small set of red-hat patches to > 2.6.9? Why would they need to go in there to make so many changes in the > first place? Which 2.6 release changed tty_io.c's use of tty_sem so > heavily? These are questions to ask of Red Hat, and can only be answered by their representatives. Thanks anyway, and I'm sorry that this hasn't been resolved given the amount of time put into it by both of us. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.9 chrdev_open: serial_core: uart_open
> -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 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 straight to Red Hat's bugzilla! Do not collect 200$. Do > not pass go. > > Seriously though, this bug is not present in mainline kernels, so I > can't resolve this issue for you. Mainline kernels appear to work > properly. Could tty_io.c be all that changed by a small set of red-hat patches to 2.6.9? Why would they need to go in there to make so many changes in the first place? Which 2.6 release changed tty_io.c's use of tty_sem so heavily? This conflict between main-line/redhat looks much worse than the unix sysV r4.0 divergence after 3.2. Ouch. Thanks for your help, though. karl m - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 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 straight to Red Hat's bugzilla! Do not collect 200$. Do not pass go. Seriously though, this bug is not present in mainline kernels, so I can't resolve this issue for you. Mainline kernels appear to work properly. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.9 chrdev_open: serial_core: uart_open
> -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: 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() 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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: [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() 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. > 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 The stack traces on x86 are very hap-hazard - the code just scans the stack for anything which looks like it may be in kernel text and dumps the result. This means that stale words on the stack which may have been return addresses at one time may still look like return addresses. Don't believe everything you see in an x86 stacktrace! -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.9 chrdev_open: serial_core: uart_open
> -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() 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. This would appear to be the problem!! Is this a new semaphore in 2.6? How could this have ever worked with tty blocking mode? It would appear that tty_sem is going to have to be released before sleeping in uart_open. What a mess. 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.9 chrdev_open: serial_core: uart_open
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 "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
