Doug / smarc-fsl-linux-kernel

09 Jun, 2007

1 commit

09 May, 2007

1 commit

12 Feb, 2007

1 commit

  • 8b6312f4d   [PATCH] vt: refactor console SAK processing ... Browse Code »

    This does several things.
    - It moves looking up of the current foreground console into process
    context where we can safely take the semaphore that protects this
    operation.
    - It uses the new flavor of work queue processing.
    - This generates a factor of do_SAK, __do_SAK that runs immediately.
    - This calls __do_SAK with the console semaphore held ensuring nothing
    else happens to the console while we process the SAK operation.
    - With the console SAK processing moved into process context this
    patch removes the xchg operations that I used to attempt to attomically
    update struct pid, because of the strange locking used in the SAK processing.
    With SAK using the normal console semaphore nothing special is needed.

    Cc: Oleg Nesterov
    Signed-off-by: Eric W. Biederman
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Eric W. Biederman
     

02 Oct, 2006

1 commit

  • bde0d2c98   [PATCH] vt: Make vt_pid a struct pid (making it pid wrap around safe). ... Browse Code »

    I took a good hard look at the locking and it appears the locking on vt_pid
    is the console semaphore. Every modified path is called under the console
    semaphore except reset_vc when it is called from fn_SAK or do_SAK both of
    which appear to be in interrupt context. In addition I need to be careful
    because in the presence of an oops the console_sem may be arbitrarily
    dropped.

    Which leads me to conclude the current locking is inadequate for my needs.

    Given the weird cases we could hit because of oops printing instead of
    introducing an extra spin lock to protect the data and keep the pid to
    signal and the signal to send in sync, I have opted to use xchg on just the
    struct pid * pointer instead.

    Due to console_sem we will stay in sync between vt_pid and vt_mode except
    for a small window during a SAK, or oops handling. SAK handling should
    kill any user space process that care, and oops handling we are broken
    anyway. Besides the worst that can happen is that I try to send the wrong
    signal.

    Signed-off-by: Eric W. Biederman
    Cc: Oleg Nesterov
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Eric W. Biederman
     

11 Jul, 2006

1 commit

  • a8f340e39   [PATCH] vt: Remove VT-specific declarations and definitions from tty.h ... Browse Code »

    MAX_NR_CONSOLES, fg_console, want_console and last_console are more of a
    function of the VT layer than the TTY one. Moving these to vt.h and vt_kern.h
    allows all of the framebuffer and VT console drivers to remove their
    dependency on tty.h.

    [akpm@osdl.org: fix alpha build]
    Signed-off-by: Jon Smirl
    Signed-off-by: Antonino Daplas
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jon Smirl
     

07 Nov, 2005

1 commit

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