Commits on Jan 18, 2010
  1. Linux

    gregkh committed Jan 18, 2010
  2. powerpc: Handle VSX alignment faults correctly in little-endian mode

    commit bb7f20b upstream.
    This patch fixes the handling of VSX alignment faults in little-endian
    mode (the current code assumes the processor is in big-endian mode).
    The patch also makes the handlers clear the top 8 bytes of the register
    when handling an 8 byte VSX load.
    This is based on 2.6.32.
    Signed-off-by: Neil Campbell <>
    Acked-by: Michael Neuling <>
    Signed-off-by: Benjamin Herrenschmidt <>
    Signed-off-by: Greg Kroah-Hartman <>
    Neil Campbell committed with gregkh Dec 14, 2009
  3. powerpc: Disable VSX or current process in giveup_fpu/altivec

    commit 7e875e9 upstream.
    When we call giveup_fpu, we need to need to turn off VSX for the
    current process.  If we don't, on return to userspace it may execute a
    VSX instruction before the next FP instruction, and not have its
    register state refreshed correctly from the thread_struct.  Ditto for
    This caused a bug where an unaligned lfs or stfs results in
    fix_alignment calling giveup_fpu so it can use the FPRs (in order to
    do a single <-> double conversion), and then returning to userspace
    with FP off but VSX on.  Then if a VSX instruction is executed, before
    another FP instruction, it will proceed without another exception and
    hence have the incorrect register state for VSX registers 0-31.
       lfs unaligned   <- alignment exception turns FP off but leaves VSX on
       VSX instruction <- no exception since VSX on, hence we get the
                          wrong VSX register values for VSX registers 0-31,
                          which overlap the FPRs.
    Signed-off-by: Michael Neuling <>
    Signed-off-by: Paul Mackerras <>
    Signed-off-by: Greg Kroah-Hartman <>
    mikey committed with gregkh Apr 1, 2009
  4. fix more leaks in audit_tree.c tag_chunk()

    commit b4c30aa upstream.
    Several leaks in audit_tree didn't get caught by commit
    318b6d3, including the leak on normal
    exit in case of multiple rules refering to the same chunk.
    Signed-off-by: Al Viro <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Greg Kroah-Hartman <>
    Al Viro committed with gregkh Dec 19, 2009
  5. fix braindamage in audit_tree.c untag_chunk()

    commit 6f5d511 upstream.
    ... aka "Al had badly fscked up when writing that thing and nobody
    noticed until Eric had fixed leaks that used to mask the breakage".
    The function essentially creates a copy of old array sans one element
    and replaces the references to elements of original (they are on cyclic
    lists) with those to corresponding elements of new one.  After that the
    old one is fair game for freeing.
    First of all, there's a dumb braino: when we get to list_replace_init we
    use indices for wrong arrays - position in new one with the old array
    and vice versa.
    Another bug is more subtle - termination condition is wrong if the
    element to be excluded happens to be the last one.  We shouldn't go
    until we fill the new array, we should go until we'd finished the old
    one.  Otherwise the element we are trying to kill will remain on the
    cyclic lists...
    That crap used to be masked by several leaks, so it was not quite
    trivial to hit.  Eric had fixed some of those leaks a while ago and the
    shit had hit the fan...
    Signed-off-by: Al Viro <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Greg Kroah-Hartman <>
    Al Viro committed with gregkh Dec 19, 2009
  6. netfilter: ebtables: enforce CAP_NET_ADMIN

    commit dce766a upstream.
    normal users are currently allowed to set/modify ebtables rules.
    Restrict it to processes with CAP_NET_ADMIN.
    Note that this cannot be reproduced with unmodified ebtables binary
    because it uses SOCK_RAW.
    Signed-off-by: Florian Westphal <>
    Signed-off-by: Patrick McHardy <>
    Signed-off-by: Greg Kroah-Hartman <>
    Florian Westphal committed with gregkh Jan 8, 2010
  7. kernel/signal.c: fix kernel information leak with print-fatal-signals=1

    commit b45c6e7 upstream.
    When print-fatal-signals is enabled it's possible to dump any memory
    reachable by the kernel to the log by simply jumping to that address from
    user space.
    Or crash the system if there's some hardware with read side effects.
    The fatal signals handler will dump 16 bytes at the execution address,
    which is fully controlled by ring 3.
    In addition when something jumps to a unmapped address there will be up to
    16 additional useless page faults, which might be potentially slow (and at
    least is not very efficient)
    Fortunately this option is off by default and only there on i386.
    But fix it by checking for kernel addresses and also stopping when there's
    a page fault.
    Signed-off-by: Andi Kleen <>
    Cc: Ingo Molnar <>
    Cc: Oleg Nesterov <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Greg Kroah-Hartman <>
    Andi Kleen committed with gregkh Jan 8, 2010
Commits on Jan 6, 2010
  1. Linux

    gregkh committed Jan 6, 2010
  2. Revert: KVM: MMU: do not free active mmu pages in free_mmu_pages()

    This reverts the commit d2127c8, which was
    the commit f00be0c upstream.
    This was done based on comments saying it was causing problems.
    Cc: Gleb Natapov <>
    Cc: Avi Kivity <>
    Signed-off-by: Greg Kroah-Hartman <>
    gregkh committed Jan 6, 2010
  3. generic_permission: MAY_OPEN is not write access

    commit 7ea6600 upstream.
    generic_permission was refusing CAP_DAC_READ_SEARCH-enabled
    processes from opening DAC-protected files read-only, because
    do_filp_open adds MAY_OPEN to the open mask.
    Ignore MAY_OPEN.  After this patch, CAP_DAC_READ_SEARCH is
    again sufficient to open(fname, O_RDONLY) on a file to which
    DAC otherwise refuses us read permission.
    Reported-by: Mike Kazantsev <>
    Signed-off-by: Serge E. Hallyn <>
    Tested-by: Mike Kazantsev <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Greg Kroah-Hartman <>
    Serge E. Hallyn committed with gregkh Dec 29, 2009
  4. x86/ptrace: make genregs[32]_get/set more robust

    commit 04a1e62 upstream.
    The loop condition is fragile: we compare an unsigned value to zero, and
    then decrement it by something larger than one in the loop.  All the
    callers should be passing in appropriately aligned buffer lengths, but
    it's better to just not rely on it, and have some appropriate defensive
    loop limits.
    Acked-by: Roland McGrath <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Greg Kroah-Hartman <>
    torvalds committed with gregkh Dec 17, 2009
  5. S390: dasd: support DIAG access for read-only devices

    commit 22825ab upstream.
    When a DASD device is used with the DIAG discipline, the DIAG
    initialization will indicate success or error with a respective
    return code. So far we have interpreted a return code of 4 as error,
    but it actually means that the initialization was successful, but
    the device is read-only. To allow read-only devices to be used with
    DIAG we need to accept a return code of 4 as success.
    Re-initialization of the DIAG access is also part of the DIAG error
    recovery. If we find that the access mode of a device has been
    changed from writable to read-only while the device was in use,
    we print an error message.
    Signed-off-by: Stefan Weinhuber <>
    Signed-off-by: Martin Schwidefsky <>
    Cc: Stephen Powell <>
    Signed-off-by: Greg Kroah-Hartman <>
    Stefan Weinhuber committed with gregkh Dec 7, 2009
  6. ipv6: reassembly: use seperate reassembly queues for conntrack and lo…

    …cal delivery
    commit 0b5ccb2 upstream.
    Currently the same reassembly queue might be used for packets reassembled
    by conntrack in different positions in the stack (PREROUTING/LOCAL_OUT),
    as well as local delivery. This can cause "packet jumps" when the fragment
    completing a reassembled packet is queued from a different position in the
    stack than the previous ones.
    Add a "user" identifier to the reassembly queue key to seperate the queues
    of each caller, similar to what we do for IPv4.
    Signed-off-by: Patrick McHardy <>
    Signed-off-by: Greg Kroah-Hartman <>
    kaber committed with gregkh Dec 15, 2009
  7. i2c/tsl2550: Fix lux value in extended mode

    commit 5f5bfb0 upstream.
    According to the TAOS Application Note 'Controlling a Backlight with
    the TSL2550 Ambient Light Sensor' (page 14), the actual lux value in
    extended mode should be obtained multiplying the calculated lux value
    by 5.
    Signed-off-by: Michele Jr De Candia <>
    Signed-off-by: Jean Delvare <>
    Signed-off-by: Greg Kroah-Hartman <>
    Michele Jr De Candia committed with gregkh Nov 26, 2009
  8. sound: sgio2audio/pdaudiocf/usb-audio: initialize PCM buffer

    commit 3e85fd6 upstream.
    When allocating the PCM buffer, use vmalloc_user() instead of vmalloc().
    Otherwise, it would be possible for applications to play the previous
    contents of the kernel memory to the speakers, or to read it directly if
    the buffer is exported to userspace.
    Signed-off-by: Clemens Ladisch <>
    Signed-off-by: Takashi Iwai <>
    Signed-off-by: Greg Kroah-Hartman <>
    cladisch committed with gregkh Dec 18, 2009
  9. pata_cmd64x: fix overclocking of UDMA0-2 modes

    commit 509426b upstream.
    adev->dma_mode stores the transfer mode value not UDMA mode number
    so the condition in cmd64x_set_dmamode() is always true and the higher
    UDMA clock is always selected.  This can potentially result in data
    corruption when UDMA33 device is used, when 40-wire cable is used or
    when the error recovery code decides to lower the device speed down.
    The issue was introduced in the commit 6a40da0 ("libata cmd64x: whack
    into a shape that looks like the documentation") which goes back to
    kernel 2.6.20.
    Signed-off-by: Bartlomiej Zolnierkiewicz <>
    Signed-off-by: Jeff Garzik <>
    Signed-off-by: Greg Kroah-Hartman <>
    bzolnier committed with gregkh Dec 20, 2009
  10. Libertas: fix buffer overflow in lbs_get_essid()

    commit 45b2416 upstream.
    The libertas driver copies the SSID buffer back to the wireless core and
    appends a trailing NULL character for termination. This is
    a) unnecessary because the buffer is allocated with kzalloc and is hence
       already NULLed when this function is called, and
    b) for priv->curbssparams.ssid_len == 32, it writes back one byte too
       much which causes memory corruptions.
    Fix this by removing the extra write.
    Signed-off-by: Daniel Mack <>
    Cc: Stephen Hemminger <>
    Cc: Maithili Hinge <>
    Cc: Kiran Divekar <>
    Cc: Michael Hirsch <>
    Acked-by: Holger Schurig <>
    Acked-by: Dan Williams <>
    Signed-off-by: John W. Linville <>
    Signed-off-by: Greg Kroah-Hartman <>
    zonque committed with gregkh Dec 16, 2009
Commits on Dec 18, 2009
  1. Linux

    gregkh committed Dec 18, 2009
  2. matroxfb: fix problems with display stability

    commit 8c65131 upstream.
    Regression caused in 2.6.23 and then despite repeated requests never fixed
    or dealt with (Petr promised to sort it in 2008 but seems to have
    Enough is enough - remove the problem line that was added.  If it upsets
    someone they've had two years to deal with it and at the very least it'll
    rattle their cage and wake them up.
    Signed-off-by: Alan Cox <>
    Reported-by: Damon <>
    Tested-by: Ruud van Melick <>
    Cc: Petr Vandrovec <>
    Cc: Pekka Enberg <>
    Cc: Paul A. Clarke <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Greg Kroah-Hartman <>
    Alan Cox committed with gregkh Dec 16, 2009
  3. jffs2: Fix long-standing bug with symlink garbage collection.

    commit 2e16cfc upstream.
    Ever since jffs2_garbage_collect_metadata() was first half-written in
    February 2001, it's been broken on architectures where 'char' is signed.
    When garbage collecting a symlink with target length above 127, the payload
    length would end up negative, causing interesting and bad things to happen.
    Signed-off-by: David Woodhouse <>
    Signed-off-by: Greg Kroah-Hartman <>
    dwmw2 committed with gregkh Dec 16, 2009
  4. backlight: lcd - Fix wrong sizeof

    commit 1e0fa6b upstream.
    Which is why I have always preferred sizeof(struct foo) over
    Signed-off-by: Jean Delvare <>
    Signed-off-by: Richard Purdie <>
    Signed-off-by: Greg Kroah-Hartman <>
    Jean Delvare committed with gregkh Oct 2, 2009
  5. USB: fix mos7840 problem with minor numbers

    commit 37768ad upstream
    This patch fixes a problem with any mos7840 device where the use of the
    field "minor" before it is initialised results in all the devices being
    overlaid in memory (minor = 0 for all instances)
    Contributed by: Phillip Branch
    Backported to .27 by Christoph Biedl <>
    Signed-off-by: Tony Cook <>
    Signed-off-by: Greg Kroah-Hartman <>
    Tony Cook committed with gregkh Dec 8, 2009
  6. fix csum_ipv6_magic()

    commit 5afe18d upstream.
    The 32-bit parameters (len and csum) of csum_ipv6_magic() are passed in 64-bit
    registers in2 and in4. The high order 32 bits of the registers were never
    cleared, and garbage was sometimes calculated into the checksum.
    Fix this by clearing the high order 32 bits of these registers.
    Signed-off-by: Jiri Bohac <>
    Signed-off-by: Tony Luck <>
    Cc: Dennis Schridde <>
    Signed-off-by: Greg Kroah-Hartman <>
    jiribohac committed with gregkh Sep 2, 2009
  7. x86: GART: pci-gart_64.c: Use correct length in strncmp

    commit 41855b7 upstream.
    Signed-off-by: Joe Perches <>
    LKML-Reference: <1257818330.12852.72.camel@Joe-Laptop.home>
    Signed-off-by: Ingo Molnar <>
    Signed-off-by: Greg Kroah-Hartman <>
    JoePerches committed with gregkh Nov 10, 2009
  8. x86: Fix iommu=nodac parameter handling

    commit 2ae8bb7 upstream.
    iommu=nodac should forbid dac instead of enabling it. Fix it.
    Signed-off-by: Tejun Heo <>
    Acked-by: FUJITA Tomonori <>
    Cc: Matteo Frigo <>
    LKML-Reference: <>
    Signed-off-by: Ingo Molnar <>
    Signed-off-by: Greg Kroah-Hartman <>
    htejun committed with gregkh Oct 26, 2009
  9. x86, Calgary IOMMU quirk: Find nearest matching Calgary while walking…

    … up the PCI tree
    commit 4528752 upstream.
    On a multi-node x3950M2 system, there's a slight oddity in the
    PCI device tree for all secondary nodes:
     30:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1)
      \-33:00.0 PCI bridge: IBM CalIOC2 PCI-E Root Port (rev 01)
         \-34:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS 1078 (rev 04) compared to the primary node:
     00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1)
      \-01:00.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 02)
     03:00.0 PCI bridge: IBM CalIOC2 PCI-E Root Port (rev 01)
      \-04:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS 1078 (rev 04)
    In both nodes, the LSI RAID controller hangs off a CalIOC2
    device, but on the secondary nodes, the BIOS hides the VGA
    device and substitutes the device tree ending with the disk
    It would seem that Calgary devices don't necessarily appear at
    the top of the PCI tree, which means that the current code to
    find the Calgary IOMMU that goes with a particular device is
    Rather than walk all the way to the top of the PCI
    device tree and try to match bus number with Calgary descriptor,
    the code needs to examine each parent of the particular device;
    if it encounters a Calgary with a matching bus number, simply
    use that.
    Otherwise, we BUG() when the bus number of the Calgary doesn't
    match the bus number of whatever's at the top of the device tree.
    Extra note: This patch appears to work correctly for the x3950
    that came before the x3950 M2.
    Signed-off-by: Darrick J. Wong <>
    Acked-by: Muli Ben-Yehuda <>
    Cc: FUJITA Tomonori <>
    Cc: Joerg Roedel <>
    Cc: Yinghai Lu <>
    Cc: Jon D. Mason <>
    Cc: Corinna Schultz <>
    LKML-Reference: <>
    Signed-off-by: Ingo Molnar <>
    Signed-off-by: Greg Kroah-Hartman <>
    Darrick J. Wong committed with gregkh Dec 2, 2009
  10. x86: ASUS P4S800 reboot=bios quirk

    commit 4832ddd upstream.
    Bug reporter noted their system with an ASUS P4S800 motherboard would
    hang when rebooting unless reboot=b was specified.  Their dmidecode
    didn't contain descriptive System Information for Manufacturer or
    Product Name, so I used their Base Board Information to create a
    reboot quirk patch.  The bug reporter confirmed this patch resolves
    the reboot hang.
    Handle 0x0001, DMI type 1, 25 bytes
    System Information
           Manufacturer: System Manufacturer
           Product Name: System Name
           Version: System Version
           Serial Number: SYS-1234567890
           UUID: E0BFCD8B-7948-D911-A953-E486B4EEB67F
           Wake-up Type: Power Switch
    Handle 0x0002, DMI type 2, 8 bytes
    Base Board Information
         Manufacturer: ASUSTeK Computer INC.
         Product Name: P4S800
         Version: REV 1.xx
         Serial Number: xxxxxxxxxxx
    ASUS P4S800 will hang when rebooting unless reboot=b is specified.
    Add a quirk to reboot through the bios.
    Signed-off-by: Leann Ogasawara <>
    LKML-Reference: <1259972107.4629.275.camel@emiko>
    Signed-off-by: H. Peter Anvin <>
    Signed-off-by: Greg Kroah-Hartman <>
    leannogasawara committed with gregkh Dec 4, 2009
  11. x86, apic: Enable lapic nmi watchdog on AMD Family 11h

    commit 7d1849a upstream.
    The x86 lapic nmi watchdog does not recognize AMD Family 11h,
    resulting in:
      NMI watchdog: CPU not supported
    As far as I can see from available documentation (the BKDM),
    family 11h looks identical to family 10h as far as the PMU
    is concerned.
    Extending the check to accept family 11h results in:
      Testing NMI watchdog ... OK.
    I've been running with this change on a Turion X2 Ultra ZM-82
    laptop for a couple of weeks now without problems.
    Signed-off-by: Mikael Pettersson <>
    Cc: Andreas Herrmann <>
    Cc: Joerg Roedel <>
    LKML-Reference: <>
    Signed-off-by: Ingo Molnar <>
    Signed-off-by: Greg Kroah-Hartman <>
    Mikael Pettersson committed with gregkh Dec 3, 2009
  12. V4L/DVB: Fix test in copy_reg_bits()

    commit c95a419 upstream.
    The reg_pair2[j].reg was tested twice.
    Signed-off-by: Roel Kluin <>
    Acked-by: Michael Krufky <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Mauro Carvalho Chehab <>
    Signed-off-by: Greg Kroah-Hartman <>
    RoelKluin committed with gregkh Nov 20, 2009
  13. ssb: Fix range check in sprom write

    commit e33761e upstream.
    The range check in the sprom image parser hex2sprom() is broken.
    One sprom word is 4 hex characters.
    This fixes the check and also adds much better sanity checks to the code.
    We better make sure the image is OK by doing some sanity checks to avoid
    bricking the device by accident.
    Signed-off-by: Michael Buesch <>
    Signed-off-by: John W. Linville <>
    Signed-off-by: Greg Kroah-Hartman <>
    Michael Buesch committed with gregkh Nov 23, 2009
  14. pata_hpt{37x|3x2n}: fix timing register masks (take 2)

    commit 5600c70 upstream.
    These drivers inherited from the older 'hpt366' IDE driver the buggy timing
    register masks in their set_piomode() metods. As a result, too low command
    cycle active time is programmed for slow PIO modes.  Quite fortunately, it's
    later "fixed up" by the set_dmamode() methods which also "helpfully" reprogram
    the command timings, usually to PIO mode 4; unfortunately, setting an UltraDMA
    mode #N also reprograms already set PIO data timings, usually to MWDMA mode #
    max(N, 2) timings...
    However, the drivers added some breakage of their own too:  the bit that they
    set/clear to control the FIFO is sometimes wrong -- it's actually the MSB of
    the command cycle setup time; also, setting it in DMA mode is wrong as this
    bit is only for PIO actually and clearing it for PIO modes is not needed as
    no mode in any timing table has it set...
    Fix all this, inverting the masks while at it, like in the 'hpt366' and
    'pata_hpt366' drivers; bump the drivers' versions, accounting for recent
    patches that forgot to do it...
    Signed-off-by: Sergei Shtylyov <>
    Signed-off-by: Jeff Garzik <>
    Signed-off-by: Greg Kroah-Hartman <>
    Sergei Shtylyov committed with gregkh Nov 27, 2009
  15. hfs: fix a potential buffer overflow

    commit ec81aec upstream.
    A specially-crafted Hierarchical File System (HFS) filesystem could cause
    a buffer overflow to occur in a process's kernel stack during a memcpy()
    call within the hfs_bnode_read() function (at fs/hfs/bnode.c:24).  The
    attacker can provide the source buffer and length, and the destination
    buffer is a local variable of a fixed length.  This local variable (passed
    as "&entry" from fs/hfs/dir.c:112 and allocated on line 60) is stored in
    the stack frame of hfs_bnode_read()'s caller, which is hfs_readdir().
    Because the hfs_readdir() function executes upon any attempt to read a
    directory on the filesystem, it gets called whenever a user attempts to
    inspect any filesystem contents.
    [ modify this patch and fix coding style problems]
    Signed-off-by: WANG Cong <>
    Cc: Eugene Teo <>
    Cc: Roman Zippel <>
    Cc: Al Viro <>
    Cc: Christoph Hellwig <>
    Cc: Alexey Dobriyan <>
    Cc: Dave Anderson <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Greg Kroah-Hartman <>
    Amerigo Wang committed with gregkh Dec 15, 2009
  16. firewire: ohci: handle receive packets with a data length of zero

    commit 8c0c0cc upstream.
    Queueing to receive an ISO packet with a payload length of zero
    silently does nothing in dualbuffer mode, and crashes the kernel in
    packet-per-buffer mode.  Return an error in dualbuffer mode, because
    the DMA controller won't let us do what we want, and work correctly in
    packet-per-buffer mode.
    Signed-off-by: Jay Fenlason <>
    Signed-off-by: Stefan Richter <>
    Signed-off-by: Greg Kroah-Hartman <>
    dajt committed with gregkh Dec 11, 2009
  17. debugfs: fix create mutex racy fops and private data

    commit d3a3b0a upstream.
    Setting fops and private data outside of the mutex at debugfs file
    creation introduces a race where the files can be opened with the wrong
    file operations and private data.  It is easy to trigger with a process
    waiting on file creation notification.
    Signed-off-by: Mathieu Desnoyers <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Greg Kroah-Hartman <>
    Mathieu Desnoyers committed with gregkh Nov 17, 2009
  18. signal: Fix alternate signal stack check

    commit 2a855dd upstream.
    All architectures in the kernel increment/decrement the stack pointer
    before storing values on the stack.
    On architectures which have the stack grow down sas_ss_sp == sp is not
    on the alternate signal stack while sas_ss_sp + sas_ss_size == sp is
    on the alternate signal stack.
    On architectures which have the stack grow up sas_ss_sp == sp is on
    the alternate signal stack while sas_ss_sp + sas_ss_size == sp is not
    on the alternate signal stack.
    The current implementation fails for architectures which have the
    stack grow down on the corner case where sas_ss_sp == sp.This was
    reported as Debian bug #544905 on AMD64.
    Simplified test case:
    The test case creates the following stack scenario:
       0xn0300	stack top
       0xn0200	alt stack pointer top (when switching to alt stack)
       0xn01ff	alt stack end
       0xn0100	alt stack start == stack pointer
    If the signal is sent the stack pointer is pointing to the base
    address of the alt stack and the kernel erroneously decides that it
    has already switched to the alternate stack because of the current
    check for "sp - sas_ss_sp < sas_ss_size"
    On parisc (stack grows up) the scenario would be:
       0xn0200	stack pointer
       0xn01ff	alt stack end
       0xn0100	alt stack start = alt stack pointer base
       		    	  	  (when switching to alt stack)
       0xn0000	stack base
    This is handled correctly by the current implementation.
    [ tglx: Modified for archs which have the stack grow up (parisc) which
      	would fail with the correct implementation for stack grows
      	down. Added a check for sp >= current->sas_ss_sp which is
      	strictly not necessary but makes the code symetric for both
      	variants ]
    Signed-off-by: Sebastian Andrzej Siewior <>
    Cc: Oleg Nesterov <>
    Cc: Roland McGrath <>
    Cc: Kyle McMartin <>
    LKML-Reference: <>
    Signed-off-by: Thomas Gleixner <>
    Signed-off-by: Greg Kroah-Hartman <>
    Sebastian Andrzej Siewior committed with gregkh Oct 25, 2009