Eric Lee / smarc-fsl-linux-kernel

15 Sep, 2005

1 commit

10 Sep, 2005

1 commit

  • 3b41dc1a3   [PATCH] console: Fix buffer copy on vc resize ... Browse Code »

    On a vc resize, the contents of the old screen buffer are transferred to the
    new screenbuffer. If the new screenbuffer is smaller than the old one, only
    the contents from the bottom are copied to new. If the contents of the old
    buffer are located at the top, then the contents will not be copied to the new
    buffer resulting in a blank screen.

    This bug will happen only if the vc in question is not in the foreground.
    Doing an fbset -a or con2fbmap will trigger this bug.

    To fix this problem, base the start of the copy from the location of the
    current cursor. If the cursor is near the top of the buffer, copy the
    contents at the top, and if the cursor is near the bottom of the buffer, then
    copy the contents at the bottom. In the unlikely case where the new row size
    is greater than 2x smaller than the old one, and the cursor is in the middle,
    copy 1/2 screenful from the top and bottom of the cursor position.

    Signed-off-by: Antonino Daplas
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Antonino A. Daplas
     

08 Sep, 2005

2 commits

  • 414edcd32   [PATCH] vt: fix possible memory corruption in complement_pos ... Browse Code »

    Based on a patch from Andr Pereira de Almeida

    It might be possible for the saved pointer (*p) to become invalid in
    between vc_resizes, so saving the screen offset instead of the screen
    pointer is saner.

    This bug is very hard to trigger though, but Andre probably did, if he's
    submitting this patch. Anyway, with Andre's patch, it's still possible for
    the offsets to be still illegal, if the new screen size is smaller than the
    old one. So I've also added checks if the offsets are still within the
    screenbuffer size.

    Signed-off-by: Antonino Daplas
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Antonino A. Daplas
     
  • 2d237c636   [PATCH] Console blanking locking fix ... Browse Code »

    I've had WARN_CONSOLE_UNLOCKED warnings when calling TIOCLINUX
    TIOCL_BLANKSCREEN and TIOCL_UNBLANKSCREEN.

    (I'm blind and I use a braille display. I use those functions to blank my
    laptop's screen so people don't read it, and hopefully to conserve power.)

    The warnings are from these places:
    do_blank_screen at drivers/char/vt.c:2754 (Not tainted)
    save_screen at drivers/char/vt.c:575 (Not tainted)
    do_unblank_screen at drivers/char/vt.c:2822 (Not tainted)
    set_palette at drivers/char/vt.c:2908 (Not tainted)

    At a glance I would think the following patch ought to fix that. Tested on
    one machine. Could you please tell me if this is correct and/or forward
    the patch where appropriate...

    Signed-off-by: Stephane Doyon
    Signed-off-by: Benjamin Herrenschmidt
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Stephane Doyon
     

28 Aug, 2005

1 commit

  • f786648b8   [PATCH] Remove race between con_open and con_close ... Browse Code »

    [ Same race and same patch also by Steven Rostedt ]

    I have a laptop (G3 powerbook) which will pretty reliably hit a race
    between con_open and con_close late in the boot process and oops in
    vt_ioctl due to tty->driver_data being NULL.

    What happens is this: process A opens /dev/tty6; it comes into
    con_open() (drivers/char/vt.c) and assign a non-NULL value to
    tty->driver_data. Then process A closes that and concurrently process
    B opens /dev/tty6. Process A gets through con_close() and clears
    tty->driver_data, since tty->count == 1. However, before process A
    can decrement tty->count, we switch to process B (e.g. at the
    down(&tty_sem) call at drivers/char/tty_io.c line 1626).

    So process B gets to run and comes into con_open with tty->count == 2,
    as tty->count is incremented (in init_dev) before con_open is called.
    Because tty->count != 1, we don't set tty->driver_data. Then when the
    process tries to do anything with that fd, it oopses.

    The simple and effective fix for this is to test tty->driver_data
    rather than tty->count in con_open. The testing and setting of
    tty->driver_data is serialized with respect to the clearing of
    tty->driver_data in con_close by the console_sem. We can't get a
    situation where con_open sees tty->driver_data != NULL and then
    con_close on a different fd clears tty->driver_data, because
    tty->count is incremented before con_open is called. Thus this patch
    eliminates the race, and in fact with this patch my laptop doesn't
    oops.

    Signed-off-by: Paul Mackerras
    [ Same patch
    Signed-off-by: Steven Rostedt
    in http://marc.theaimsgroup.com/?l=linux-kernel&m=112450820432121&w=2 ]
    Signed-off-by: Linus Torvalds

    Paul Mackerras
     

16 Jul, 2005

1 commit

19 Jun, 2005

1 commit

  • cc63b1e12   [PATCH] console blanking oops fix ... Browse Code »

    When significant delays happen during boot (e.g. with a kernel debugger,
    but the problem has also seen in other cases) the timeout for blanking the
    console may trigger, but the work scheduler may not have been initialized,
    yet. schedule_work() will oops over the null keventd_wq.

    Signed-off-by: Jan Beulich
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jan Beulich
     

17 Apr, 2005

1 commit

  • 1da177e4c   Linux-2.6.12-rc2 ... Browse Code »

    Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds