lkml.org 
[lkml]   [2003]   [Jan]   [13]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateMon, 13 Jan 2003 12:11:31 +0530
FromDipankar Sarma <>
SubjectRe: Fixing the tty layer was Re: any chance of 2.6.0-test*?
On Sun, Jan 12, 2003 at 09:59:15AM +0000, Andi Kleen wrote:
> > I've looked into this, and wow, it's not a simple fix :(
Oh, yes, I have spent hours and hours trying to untangle tty locking
and it isn't simple.

> > it has to be fixed for 2.6, no argument.> > I took a look at it. I think the easiest strategy would be:
> > - Make sure all the process context code holds BKL> (most of it does, but not all - sometimes it is buggy like in 
> disassociate_tty) > I have some patches for that for tty_io.c at least

What does that BKL protect ? I can't seem to ever figure our if
all the races are plugged or not.

> > The local_irq_save in there are buggy, they need to take 
> a lock.

Also a locking model w.r.t. the serial drivers ?

> > - Audit the data structures that are touched by interrupts
> and add spinlocks.> At least for n_tty.c probably just tty->read_lock needs to be 
> extended.> Perhaps some can be just "fixed" by ignoring latency and pushing
> softirq functions into keventd
> (modern CPUs should be fast enough for that) 
> 
> - Possibly disable module unloading for ldiscs (seems to be rather broken,
> although Rusty's new unload algorithm may avoid the worst - not completely
> sure)
> 
> Probably all doable with some concentrated effort.
> 
> Anyone interested in helping ?

Yes, I would like to help out. I was hoping to help rewrite the whole
thing in 2.7, but it needs help *now*. Perhaps I can take your list
of things to do and fix them as a starting point ?

Thanks
Dipankar
-
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/

\
 
 \ /
  Last update: 2005-03-22 12:32    [from the cache]
©2003-2008