[lkml]   [2000]   [Sep]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: PROBLEM: Segmentation fault [SIGSEGV] reading from /proc/tty/driver/serial
There was a round of discussion about /proc.../serial back in May.  It
covered corruption and bad addresses. Although it didn't specifically say
"I'm fixing the segmentation fault that some people are going to report",
they did indeed discuss the bad data, smp locking, and etc precisely on

If a specific problem such as a bad address went away by upgrading, there's a
very strong chance that the bug was fixed. Such problems aren't likely to
migrate around in the kernel and be hidden, they tend to stay localized.
Instead of searching for a given author's comments, diff the two files and
see if the initializing code changed. A lot of fixes go in without specific


David Ciemiewicz wrote:

> Igmar,
> Thanks for attempting to validate that the problem is fixed in a
> later release. However, I still stand by my submission.
> If the readers will note, the problem is in 2.2.14 and
> AND in 2.3.5 as referenced by another auther. It looks like the
> info structure in drivers/char/serial.c:line_info is not sufficiently
> initialized in all cases that might be processed by serial_in()
> for instance, the CONFIG_HUB6 case. If line_info populates an
> info struct and CONFIG_HUB6 is defined and info->hub6 is
> dereferenced, there may well be garbage in info->hub6.
> I've searched the source trees and I don't see any of the fixes
> between 2.2.14 and 2.2.17 referenced by the previous author at
> the end of my original post.
> That said, the incompletely initialized "info" structure problem
> exists. The fact that you and many others may not encountered the
> problem is pure happenstance either because CONFIG_HUB6 was not
> configured or you were lucky enough not to have garbage in any
> of the data structures.
> So, if I upgraded to 2.2.17 and the problem went away, that doesn't
> mean the problem doesn't exist, it just means that the problem may
> simply be being masked or has not yet been encountered.
> --- Ciemo
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to
> Please read the FAQ at

"The difference between 'involvement' and 'commitment' is like an
eggs-and-ham breakfast: the chicken was 'involved' - the pig was

org:<img src="">
title:Blue Labs Developer
fn:David Ford
 \ /
  Last update: 2005-03-22 12:39    [W:0.061 / U:1.504 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site