lkml.org 
[lkml]   [2005]   [May]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] tty races
Jason Baron <jbaron@redhat.com> wrote:
>
> >
> > I don't see anywhere which takes lock_kernel() on the tty_open() path.
> >
>
> fs/char_dev.c:chrdev_open():
>
> if (filp->f_op->open) {
> lock_kernel();
> ret = filp->f_op->open(inode,filp);
> unlock_kernel();
> }
>

hm, we're still doing that.

> >
> > We want to move away from lock_kernel()-based locking.
> >
>
> I completely agree, but unfortunately lock_kernel() is currently used
> extensively throughout the tty layer.

Well no - it's being migrated over to use tty_sem. We shouldn't start
heading in the reverse direction. Plus your patch reverts part of
http://linux.bkbits.net:8080/linux-2.5/diffs/drivers/char/tty_io.c@1.156?nav=index.html|src/|src/drivers|src/drivers/char|hist/drivers/char/tty_io.c
in ways which might be unsafe.
> lock_kernel() is used extensively throughout the tty layer. We can
> re-write the locking for the layer, but I'd like to see this bug fix in
> 2.6.12, if that isn't done in time.

Sorry, but AFAICT all you have done is to advocate for the existing patch
without having attempted to fix this problem with tty_sem. Please try to
come up with a tty_sem-based fix.
-
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-05-04 02:54    [from the cache]
©2003-2011 Jasper Spaans