lkml.org 
[lkml]   [2003]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    SubjectRe: any chance of 2.6.0-test*?
    From
    Date
    Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

    > On Fri, 2003-01-10 at 16:10, William Lee Irwin III wrote:
    > > Any specific concerns/issues/wishlist items you want taken care of
    > > before doing it or is it a "generalized comfort level" kind of thing?
    > > Let me know, I'd be much obliged for specific directions to move in.
    >
    > IDE is all broken still and will take at least another three months to
    > fix - before we get to 'improve'. The entire tty layer locking is terminally

    Can you quickly summarize what is broken with IDE ?

    Are just some low level drivers broken or are there some generic
    nasty problems.

    If it is just some broken low level drivers I guess they can
    be marked dangerous or CONFIG_EXPERIMENTAL.

    How does it differ from the code that was just merged into 2.4.21pre3
    (has the later all the problems fixed?)

    > broken and nobody has even started fixing it. Just try a mass of parallel
    > tty/pty activity . It was problematic before, pre-empt has taken it to dead,
    > defunct and buried.

    Can someone shortly describe what is the main problem with TTY?

    From what I can see the high level tty code mostly takes lock_kernel
    before doing anything.
    On reads access to file->private_data is not serialized, but it at
    least shouldn't go away because VFS takes care of struct file
    reference counting.

    The tty_drivers list does seem to need a spinlock, but I guess
    just taking lock_kernel in tty_open would fix that for now.

    [i didn't look at low level ldiscs]

    Any particular test cases that break ?

    If yes I would recommend to post them as scripts and their oopses so
    that people can start working on them.


    The appended untested patch adds some lock_kernel()s that appear to be missing
    to tty_io.c. The rest seems to already run under BKL or not access
    any global data
    (except tty_paranoia_check, but is probably ok with the reference counting
    in the VFS)

    >
    > Most of the drivers still don't build either.

    In UP most did last time I tried.
    On SMP a lot of problems are caused by the cli removal

    My personal (i386) problem list is relatively short.
    I use used 2.5.54 on my desktop without any problems (without preempt)

    - BIO still oopses when XFS tries replay a log on RAID-0

    -Andi

    --- linux-2.5.56-work/drivers/char/tty_io.c-o 2003-01-02 05:13:12.000000000 +0100
    +++ linux-2.5.56-work/drivers/char/tty_io.c 2003-01-11 13:23:15.000000000 +0100
    @@ -1329,6 +1329,8 @@
    int major, minor;
    struct tty_driver *driver;

    + lock_kernel();
    +
    /* find a device that is not in use. */
    retval = -1;
    for ( major = 0 ; major < UNIX98_NR_MAJORS ; major++ ) {
    @@ -1340,6 +1342,8 @@
    if (!init_dev(device, &tty)) goto ptmx_found; /* ok! */
    }
    }
    +
    + unlock_kernel();
    return -EIO; /* no free ptys */
    ptmx_found:
    set_bit(TTY_PTY_LOCK, &tty->flags); /* LOCK THE SLAVE */
    @@ -1357,6 +1361,8 @@
    #endif /* CONFIG_UNIX_98_PTYS */
    }

    + lock_kernel();
    +
    retval = init_dev(device, &tty);
    if (retval)
    return retval;
    @@ -1389,6 +1395,8 @@
    #endif

    release_dev(filp);
    +
    + unlock_kernel();
    if (retval != -ERESTARTSYS)
    return retval;
    if (signal_pending(current))
    @@ -1397,6 +1405,7 @@
    /*
    * Need to reset f_op in case a hangup happened.
    */
    + lock_kernel();
    filp->f_op = &tty_fops;
    goto retry_open;
    }
    @@ -1424,6 +1433,7 @@
    nr_warns++;
    }
    }
    + unlock_kernel();
    return 0;
    }

    @@ -1444,8 +1454,13 @@
    if (tty_paranoia_check(tty, filp->f_dentry->d_inode->i_rdev, "tty_poll"))
    return 0;

    - if (tty->ldisc.poll)
    - return (tty->ldisc.poll)(tty, filp, wait);
    + if (tty->ldisc.poll) {
    + int ret;
    + lock_kernel();
    + ret = (tty->ldisc.poll)(tty, filp, wait);
    + unlock_kernel();
    + return ret;
    + }
    return 0;
    }

    -
    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 13:32    [W:0.024 / U:32.716 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site