Eric Lee / smarc-fsl-linux-kernel

17 Jul, 2007

1 commit

08 Dec, 2006

1 commit

23 Jun, 2006

1 commit

  • d09042da7   [PATCH] fix incorrect SA_ONSTACK behaviour for 64-bit processes ... Browse Code »

    - When setting a sighandler using sigaction() call, if the flag
    SA_ONSTACK is set and no alternate stack is provided via sigaltstack(),
    the kernel still try to install the alternate stack. This behavior is
    the opposite of the one which is documented in Single Unix Specifications
    V3.

    - Also when setting an alternate stack using sigaltstack() with the flag
    SS_DISABLE, the kernel try to install the alternate stack on signal
    delivery.

    These two use cases makes the process crash at signal delivery.

    Signed-off-by: Laurent Meyer
    Cc: Richard Henderson
    Cc: Ivan Kokshaysky
    Cc: David Howells
    Cc: Yoshinori Sato
    Cc: Geert Uytterhoeven
    Cc: Roman Zippel
    Cc: Kyle McMartin
    Cc: Paul Mundt
    Cc: Kazumoto Kojima
    Cc: Chris Zankel
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Laurent MEYER
     

30 Aug, 2005

1 commit

  • 69be8f189   [PATCH] convert signal handling of NODEFER to act like other Unix boxes. ... Browse Code »

    It has been reported that the way Linux handles NODEFER for signals is
    not consistent with the way other Unix boxes handle it. I've written a
    program to test the behavior of how this flag affects signals and had
    several reports from people who ran this on various Unix boxes,
    confirming that Linux seems to be unique on the way this is handled.

    The way NODEFER affects signals on other Unix boxes is as follows:

    1) If NODEFER is set, other signals in sa_mask are still blocked.

    2) If NODEFER is set and the signal is in sa_mask, then the signal is
    still blocked. (Note: this is the behavior of all tested but Linux _and_
    NetBSD 2.0 *).

    The way NODEFER affects signals on Linux:

    1) If NODEFER is set, other signals are _not_ blocked regardless of
    sa_mask (Even NetBSD doesn't do this).

    2) If NODEFER is set and the signal is in sa_mask, then the signal being
    handled is not blocked.

    The patch converts signal handling in all current Linux architectures to
    the way most Unix boxes work.

    Unix boxes that were tested: DU4, AIX 5.2, Irix 6.5, NetBSD 2.0, SFU
    3.5 on WinXP, AIX 5.3, Mac OSX, and of course Linux 2.6.13-rcX.

    * NetBSD was the only other Unix to behave like Linux on point #2. The
    main concern was brought up by point #1 which even NetBSD isn't like
    Linux. So with this patch, we leave NetBSD as the lonely one that
    behaves differently here with #2.

    Signed-off-by: Linus Torvalds

    Steven Rostedt
     

26 Jun, 2005

1 commit

  • 3e1d1d28d   [PATCH] Cleanup patch for process freezing ... Browse Code »

    1. Establish a simple API for process freezing defined in linux/include/sched.h:

    frozen(process) Check for frozen process
    freezing(process) Check if a process is being frozen
    freeze(process) Tell a process to freeze (go to refrigerator)
    thaw_process(process) Restart process
    frozen_process(process) Process is frozen now

    2. Remove all references to PF_FREEZE and PF_FROZEN from all
    kernel sources except sched.h

    3. Fix numerous locations where try_to_freeze is manually done by a driver

    4. Remove the argument that is no longer necessary from two function calls.

    5. Some whitespace cleanup

    6. Clear potential race in refrigerator (provides an open window of PF_FREEZE
    cleared before setting PF_FROZEN, recalc_sigpending does not check
    PF_FROZEN).

    This patch does not address the problem of freeze_processes() violating the rule
    that a task may only modify its own flags by setting PF_FREEZE. This is not clean
    in an SMP environment. freeze(process) is therefore not SMP safe!

    Signed-off-by: Christoph Lameter
    Signed-off-by: Linus Torvalds

    Christoph Lameter
     

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