Permalink
Commits on Aug 26, 2010
  1. Linux 2.6.32.21

    gregkh committed Aug 26, 2010
  2. x86, apic: ack all pending irqs when crashed/on kexec

    commit 8c3ba8d upstream.
    
    When the SMP kernel decides to crash_kexec() the local APICs may have
    pending interrupts in their vector tables.
    
    The setup routine for the local APIC has a deficient mechanism for
    clearing these interrupts, it only handles interrupts that has already
    been dispatched to the local core for servicing (the ISR register) safely,
    it doesn't consider lower prioritized queued interrupts stored in the IRR
    register.
    
    If you have more than one pending interrupt within the same 32 bit word in
    the LAPIC vector table registers you may find yourself entering the IO
    APIC setup with pending interrupts left in the LAPIC.  This is a situation
    for wich the IO APIC setup is not prepared.  Depending of what/which
    interrupt vector/vectors are stuck in the APIC tables your system may show
    various degrees of malfunctioning.  That was the reason why the
    check_timer() failed in our system, the timer interrupts was blocked by
    pending interrupts from the old kernel when routed trough the IO APIC.
    
    Additional comment from Jiri Bohac:
    ==============
    If this should go into stable release,
    I'd add some kind of limit on the number of iterations, just to be safe from
    hard to debug lock-ups:
    
    +if (loops++  > MAX_LOOPS) {
    +        printk("LAPIC pending clean-up")
    +        break;
    +}
     while (queued);
    
    with MAX_LOOPS something like 1E9 this would leave plenty of time for the
    pending IRQs to be cleared and would and still cause at most a second of delay
    if the loop were to lock-up for whatever reason.
    
    [trenn@suse.de:
    
    V2: Use tsc if avail to bail out after 1 sec due to possible virtual
        apic_read calls which may take rather long (suggested by: Avi Kivity
        <avi@redhat.com>) If no tsc is available bail out quickly after
        cpu_khz, if we broke out too early and still have irqs pending (which
        should never happen?) we still get a WARN_ON...
    
    V3: - Fixed indentation -> checkpatch clean
        - max_loops must be signed
    
    V4: - Fix typo, mixed up tsc and ntsc in first rdtscll() call
    
    V5: Adjust WARN_ON() condition to also catch error in cpu_has_tsc case]
    
    Cc: <jbohac@novell.com>
    Cc: Yinghai Lu <yinghai@kernel.org>
    Cc: Kerstin Jonsson <kerstin.jonsson@ericsson.com>
    Cc: Avi Kivity <avi@redhat.com>
    Cc: Suresh Siddha <suresh.b.siddha@intel.com>
    Tested-by: Eric W. Biederman <ebiederm@xmission.com>
    Signed-off-by: Thomas Renninger <trenn@suse.de>
    LKML-Reference: <201005241913.o4OJDGWM010865@imap1.linux-foundation.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Cc: Thomas Renninger <trenn@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    etxkers committed with gregkh May 24, 2010
  3. USB: ftdi_sio: add product ID for Lenz LI-USB

    commit ea233f8 upstream.
    
    Add ftdi product ID for Lenz LI-USB, a model train interface.  This
    was NOT tested against 2.6.35, but a similar patch was tested with the
    CentOS 2.6.18-194.11.1.el5 kernel.  It wasn't clear to me what
    ordering is being used in ftdi_sio.c, so I inserted the ID after another
    model train entry(SPROG_II).
    
    Signed-off-by: Galen Seitz <galens@seitzassoc.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    galenseitz committed with gregkh Aug 19, 2010
  4. USB: ftdi_sio: Add ID for Ionics PlugComputer

    commit 666cc07 upstream.
    
    Add the ID for the Ionics PlugComputer (<http://ionicsplug.com/>).
    
    Signed-off-by: Martin Michlmayr <tbm@cyrius.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    tbm committed with gregkh Aug 10, 2010
  5. USB: xhci: Remove buggy assignment in next_trb()

    commit a1669b2 upstream.
    
    The code to increment the TRB pointer has a slight ambiguity that could
    lead to a bug on different compilers.  The ANSI C specification does not
    specify the precedence of the assignment operator over the postfix
    operator.  gcc 4.4 produced the correct code (increment the pointer and
    assign the value), but a MIPS compiler that one of John's clients used
    assigned the old (unincremented) value.
    
    Remove the unnecessary assignment to make all compilers produce the
    correct assembly.
    
    Signed-off-by: John Youn <johnyoun@synopsys.com>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    John Youn committed with gregkh Aug 9, 2010
  6. USB: io_ti: check firmware version before updating

    commit 0827a9f upstream.
    
    If we can't read the firmware for a device from the disk, and yet the
    device already has a valid firmware image in it, we don't want to
    replace the firmware with something invalid.  So check the version
    number to be less than the current one to verify this is the correct
    thing to do.
    
    
    Reported-by: Chris Beauchamp <chris@chillibean.tv>
    Tested-by: Chris Beauchamp <chris@chillibean.tv>
    Cc: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    gregkh committed Aug 17, 2010
  7. USB: ftdi_sio: fix endianess of max packet size

    commit d1ab903 upstream.
    
    The USB max packet size (always little-endian) was not being byte
    swapped on big-endian systems.
    
    Applicable since [USB: ftdi_sio: fix hi-speed device packet size calculation] approx 2.6.31
    
    Signed-off-by: Michael Wileczka <mikewileczka@yahoo.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Michael Wileczka committed with gregkh Aug 18, 2010
  8. USB: CP210x Fix Break On/Off

    commit 7291679 upstream.
    
    The definitions for BREAK_ON and BREAK_OFF are inverted, causing break
    requests to fail. This patch sets BREAK_ON and BREAK_OFF to the correct
    values.
    
    Signed-off-by: Craig Shelley <craig@microtron.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    craigshelley committed with gregkh Aug 18, 2010
  9. USB: pl2303: New vendor and product id

    commit f36ecd5 upstream.
    
    Add support for the Zeagle N2iTiON3 dive computer interface. Since
    Zeagle devices are actually manufactured by Seiko, this patch will
    support other Seiko based models as well.
    
    Signed-off-by: Jef Driesen <jefdriesen@telenet.be>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Jef Driesen committed with gregkh Aug 9, 2010
  10. USB: add device IDs for igotu to navman

    commit 0eee6a2 upstream.
    
    I recently bought a i-gotU USB GPS, and whilst hunting around for linux
    support discovered this post by you back in 2009:
    
    http://kerneltrap.org/mailarchive/linux-usb/2009/3/12/5148644
    
    >Try the navman driver instead.  You can either add the device id to the
    > driver and rebuild it, or do this before you plug the device in:
    > 	modprobe navman
    > 	echo -n "0x0df7 0x0900" > /sys/bus/usb-serial/drivers/navman/new_id
    >
    > and then plug your device in and see if that works.
    
    I can confirm that the navman driver works with the right device IDs on
    my i-gotU GT-600, which has the same device IDs.  Attached is a patch
    adding the IDs.
    
    From: Ross Burton <ross@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    rossburton committed with gregkh Aug 6, 2010
  11. USB: option: add Celot CT-650

    commit 76078dc upstream.
    
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Michael Tokarev committed with gregkh Aug 6, 2010
  12. powerpc: Fix typo in uImage target

    commit c686ecf upstream.
    
    Commit e32e78c
    (powerpc: fix build with make 3.82) introduced a
    typo in uImage target and broke building uImage:
    
    make: *** No rule to make target `uImage'.  Stop.
    
    Signed-off-by: Anatolij Gustschin <agust@denx.de>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Anatolij Gustschin committed with gregkh Aug 15, 2010
  13. drm: stop information leak of old kernel stack.

    commit b9f0aee upstream.
    
    non-critical issue, CVE-2010-2803
    
    Userspace controls the amount of memory to be allocate, so it can
    get the ioctl to allocate more memory than the kernel uses, and get
    access to kernel stack. This can only be done for processes authenticated
    to the X server for DRI access, and if the user has DRI access.
    
    Fix is to just memset the data to 0 if the user doesn't copy into
    it in the first place.
    
    Reported-by: Kees Cook <kees@ubuntu.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Dave Airlie committed with gregkh Aug 17, 2010
  14. drm/radeon/kms: fix typo in radeon_compute_pll_gain

    commit 0537398 upstream.
    
    Looks like this got copied from the ddx wrong.
    
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Alex Deucher committed with gregkh Aug 17, 2010
  15. netlink: fix compat recvmsg

    commit 68d6ac6 upstream.
    
    Since
    commit 1dacc76
    Author: Johannes Berg <johannes@sipsolutions.net>
    Date:   Wed Jul 1 11:26:02 2009 +0000
    
        net/compat/wext: send different messages to compat tasks
    
    we had a race condition when setting and then
    restoring frag_list. Eric attempted to fix it,
    but the fix created even worse problems.
    
    However, the original motivation I had when I
    added the code that turned out to be racy is
    no longer clear to me, since we only copy up
    to skb->len to userspace, which doesn't include
    the frag_list length. As a result, not doing
    any frag_list clearing and restoring avoids
    the race condition, while not introducing any
    other problems.
    
    Additionally, while preparing this patch I found
    that since none of the remaining netlink code is
    really aware of the frag_list, we need to use the
    original skb's information for packet information
    and credentials. This fixes, for example, the
    group information received by compat tasks.
    
    Cc: Eric Dumazet <eric.dumazet@gmail.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    jmberg committed with gregkh Aug 15, 2010
  16. ALSA: intel8x0: Mute External Amplifier by default for ThinkPad X31

    commit 9c77b84 upstream.
    
    BugLink: https://bugs.launchpad.net/bugs/619439
    
    This ThinkPad model needs External Amplifier muted for audible playback,
    so set the inv_eapd quirk for it.
    
    Reported-and-tested-by: Dennis Bell <dennis.bell@parkerg.co.uk>
    Signed-off-by: Daniel T Chen <crimsun@ubuntu.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    crimsun committed with gregkh Aug 18, 2010
  17. fixes for using make 3.82

    commit 3c955b4 upstream.
    
    It doesn't like pattern and explicit rules to be on the same line,
    and it seems to be more picky when matching file (or really directory)
    names with different numbers of trailing slashes.
    
    Signed-off-by: Jan Beulich <jbeulich@novell.com>
    Acked-by: Sam Ravnborg <sam@ravnborg.org>
    Andrew Benton <b3nton@gmail.com>
    Signed-off-by: Michal Marek <mmarek@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Jan Beulich committed with gregkh Aug 16, 2010
  18. oprofile: add support for Intel processor model 30

    commit a7c55cb upstream.
    
    Newer Intel processors identifying themselves as model 30 are not recognized by
    oprofile.
    
    <cpuinfo snippet>
    model           : 30
    model name      : Intel(R) Xeon(R) CPU           X3470  @ 2.93GHz
    </cpuinfo snippet>
    
    Running oprofile on these machines gives the following:
    + opcontrol --init
    + opcontrol --list-events
    oprofile: available events for CPU type "Intel Architectural Perfmon"
    
    See Intel 64 and IA-32 Architectures Software Developer's Manual
    Volume 3B (Document 253669) Chapter 18 for architectural perfmon events
    This is a limited set of fallback events because oprofile doesn't know your CPU
    CPU_CLK_UNHALTED: (counter: all)
            Clock cycles when not halted (min count: 6000)
    INST_RETIRED: (counter: all)
            number of instructions retired (min count: 6000)
    LLC_MISSES: (counter: all)
            Last level cache demand requests from this core that missed the LLC
    (min count: 6000)
            Unit masks (default 0x41)
            ----------
            0x41: No unit mask
    LLC_REFS: (counter: all)
            Last level cache demand requests from this core (min count: 6000)
            Unit masks (default 0x4f)
            ----------
            0x4f: No unit mask
    BR_MISS_PRED_RETIRED: (counter: all)
            number of mispredicted branches retired (precise) (min count: 500)
    + opcontrol --shutdown
    
    Tested using oprofile 0.9.6.
    
    Signed-off-by: Josh Hunt <johunt@akamai.com>
    Reviewed-by: Andi Kleen <ak@linux.intel.com>
    Signed-off-by: Robert Richter <robert.richter@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Josh Hunt committed with gregkh Aug 5, 2010
  19. Oprofile: Change CPUIDS from decimal to hex, and add some comments

    commit 45c34e0 upstream.
    
    Back when the patch was submitted for "Add Xeon 7500 series support to
    oprofile", Robert Richter had asked for a followon patch that
    converted all the CPU ID values to hex.
    
    I have done that here for the "i386/core_i7" and "i386/atom" class
    processors in the ppro_init() function and also added some comments on
    where to find documentation on the Intel processors.
    
    Signed-off-by: John L. Villalovos <john.l.villalovos@intel.com>
    Signed-off-by: Robert Richter <robert.richter@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    John Villalovos committed with gregkh May 7, 2010
  20. ext4: consolidate in_range() definitions

    commit 731eb1a upstream.
    
    There are duplicate macro definitions of in_range() in mballoc.h and
    balloc.c.  This consolidates these two definitions into ext4.h, and
    changes extents.c to use in_range() as well.
    
    Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Cc: Andreas Dilger <adilger@sun.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    mita committed with gregkh Mar 4, 2010
  21. pcmcia: avoid buffer overflow in pcmcia_setup_isa_irq

    commit 127c03c upstream.
    
    NR_IRQS may be as low as 16, causing a (harmless?) buffer overflow in
    pcmcia_setup_isa_irq():
    
    static u8 pcmcia_used_irq[NR_IRQS];
    
    ...
    
    		if ((try < 32) && pcmcia_used_irq[irq])
    			continue;
    
    This is read-only, so if this address would be non-zero, it would just
    mean we would not attempt an IRQ >= NR_IRQS -- which would fail anyway!
    And as request_irq() fails for an irq >= NR_IRQS, the setting code path:
    
    			pcmcia_used_irq[irq]++;
    
    is never reached as well.
    
    Reported-by: Christoph Fritz <chf.fritz@googlemail.com>
    Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Dominik Brodowski committed with gregkh Aug 3, 2010
  22. vmscan: raise the bar to PAGEOUT_IO_SYNC stalls

    commit e31f369 upstream.
    
    Fix "system goes unresponsive under memory pressure and lots of
    dirty/writeback pages" bug.
    
    	http://lkml.org/lkml/2010/4/4/86
    
    In the above thread, Andreas Mohr described that
    
    	Invoking any command locked up for minutes (note that I'm
    	talking about attempted additional I/O to the _other_,
    	_unaffected_ main system HDD - such as loading some shell
    	binaries -, NOT the external SSD18M!!).
    
    This happens when the two conditions are both meet:
    - under memory pressure
    - writing heavily to a slow device
    
    OOM also happens in Andreas' system.  The OOM trace shows that 3 processes
    are stuck in wait_on_page_writeback() in the direct reclaim path.  One in
    do_fork() and the other two in unix_stream_sendmsg().  They are blocked on
    this condition:
    
    	(sc->order && priority < DEF_PRIORITY - 2)
    
    which was introduced in commit 78dc583 (vmscan: low order lumpy reclaim
    also should use PAGEOUT_IO_SYNC) one year ago.  That condition may be too
    permissive.  In Andreas' case, 512MB/1024 = 512KB.  If the direct reclaim
    for the order-1 fork() allocation runs into a range of 512KB
    hard-to-reclaim LRU pages, it will be stalled.
    
    It's a severe problem in three ways.
    
    Firstly, it can easily happen in daily desktop usage.  vmscan priority can
    easily go below (DEF_PRIORITY - 2) on _local_ memory pressure.  Even if
    the system has 50% globally reclaimable pages, it still has good
    opportunity to have 0.1% sized hard-to-reclaim ranges.  For example, a
    simple dd can easily create a big range (up to 20%) of dirty pages in the
    LRU lists.  And order-1 to order-3 allocations are more than common with
    SLUB.  Try "grep -v '1 :' /proc/slabinfo" to get the list of high order
    slab caches.  For example, the order-1 radix_tree_node slab cache may
    stall applications at swap-in time; the order-3 inode cache on most
    filesystems may stall applications when trying to read some file; the
    order-2 proc_inode_cache may stall applications when trying to open a
    /proc file.
    
    Secondly, once triggered, it will stall unrelated processes (not doing IO
    at all) in the system.  This "one slow USB device stalls the whole system"
    avalanching effect is very bad.
    
    Thirdly, once stalled, the stall time could be intolerable long for the
    users.  When there are 20MB queued writeback pages and USB 1.1 is writing
    them in 1MB/s, wait_on_page_writeback() will stuck for up to 20 seconds.
    Not to mention it may be called multiple times.
    
    So raise the bar to only enable PAGEOUT_IO_SYNC when priority goes below
    DEF_PRIORITY/3, or 6.25% LRU size.  As the default dirty throttle ratio is
    20%, it will hardly be triggered by pure dirty pages.  We'd better treat
    PAGEOUT_IO_SYNC as some last resort workaround -- its stall time is so
    uncomfortably long (easily goes beyond 1s).
    
    The bar is only raised for (order < PAGE_ALLOC_COSTLY_ORDER) allocations,
    which are easy to satisfy in 1TB memory boxes.  So, although 6.25% of
    memory could be an awful lot of pages to scan on a system with 1TB of
    memory, it won't really have to busy scan that much.
    
    Andreas tested an older version of this patch and reported that it mostly
    fixed his problem.  Mel Gorman helped improve it and KOSAKI Motohiro will
    fix it further in the next patch.
    
    Reported-by: Andreas Mohr <andi@lisas.de>
    Reviewed-by: Minchan Kim <minchan.kim@gmail.com>
    Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Signed-off-by: Mel Gorman <mel@csn.ul.ie>
    Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
    Cc: Rik van Riel <riel@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    fengguang committed with gregkh Aug 10, 2010
  23. act_nat: the checksum of ICMP doesn't have pseudo header

    [ Upstream commit 3a3dfb0 ]
    
    after updating the value of the ICMP payload, inet_proto_csum_replace4() should
    be called with zero pseudohdr.
    
    Signed-off-by: Changli Gao <xiaosuo@gmail.com>
    Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    xiaosuo committed with gregkh Jul 29, 2010
  24. isdn: fix information leak

    [ Upstream commit 4b030d4 ]
    
    The main motivation of this patch changing strcpy() to strlcpy().
    We strcpy() to copy a 48 byte buffers into a 49 byte buffers.  So at
    best the last byte has leaked information, or maybe there is an
    overflow?  Anyway, this patch closes the information leaks by zeroing
    the memory and the calls to strlcpy() prevent overflows.
    
    Signed-off-by: Dan Carpenter <error27@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    error27 committed with gregkh Aug 4, 2010
  25. can: add limit for nframes and clean up signed/unsigned variables

    [ Upstream commit 5b75c49 ]
    
    This patch adds a limit for nframes as the number of frames in TX_SETUP and
    RX_SETUP are derived from a single byte multiplex value by default.
    Use-cases that would require to send/filter more than 256 CAN frames should
    be implemented in userspace for complexity reasons anyway.
    
    Additionally the assignments of unsigned values from userspace to signed
    values in kernelspace and vice versa are fixed by using unsigned values in
    kernelspace consistently.
    
    Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
    Reported-by: Ben Hawkes <hawkes@google.com>
    Acked-by: Urs Thuermann <urs.thuermann@volkswagen.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    hartkopp committed with gregkh Aug 11, 2010
  26. net: Fix a memmove bug in dev_gro_receive()

    [ Upstream commit e5093ae ]
    
    >Xin Xiaohui wrote:
    > I looked into the code dev_gro_receive(), found the code here:
    > if the frags[0] is pulled to 0, then the page will be released,
    > and memmove() frags left.
    > Is that right? I'm not sure if memmove do right or not, but
    > frags[0].size is never set after memove at least. what I think
    > a simple way is not to do anything if we found frags[0].size == 0.
    > The patch is as followed.
    ...
    
    This version of the patch fixes the bug directly in memmove.
    
    Reported-by: "Xin, Xiaohui" <xiaohui.xin@intel.com>
    Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Jarek Poplawski committed with gregkh Aug 11, 2010
  27. sparc64: Fix atomic64_t routine return values.

    [ Upstream commits 86fa04b
      and b10f997 ]
    
    Should return 'long' instead of 'int'.
    
    Thanks to Dimitris Michailidis and Tony Luck.
    
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    davem330 committed with gregkh Aug 18, 2010
  28. sparc64: Fix rwsem constant bug leading to hangs.

    [ Upstream commit ef201be ]
    
    As noticed by Linus, it is critical that some of the
    rwsem constants be signed.  Yet, hex constants are
    unsigned unless explicitly casted or negated.
    
    The most critical one is RWSEM_WAITING_BIAS.
    
    This bug was exacerbated by commit
    424acaa ("rwsem: wake queued readers
    when writer blocks on active read lock")
    
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    davem330 committed with gregkh Aug 18, 2010
  29. sparc64: Add missing ID to parport probing code.

    [ Upstream commit bf8253bf5e7cfe17dd53e3f6340a45b11d9fb51c ]
    
    SunBlade-2500 has 'parallel' device node with compatible
    property "pnpALI,1533,3" so add that to the ID table.
    
    Reported-by: Mikael Pettersson <mikpe@it.uu.se>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    davem330 committed with gregkh Aug 5, 2010
  30. sunxvr500: Ignore secondary output PCI devices.

    [ Upstream commit bdd32ce ]
    
    These just represent the secondary and further heads attached to the
    card, and they have different sets of PCI bar registers to map.
    
    So don't try to drive them in the main driver.
    
    Reported-by: Frans van Berckel <fberckel@xs4all.nl>
    Tested-by: Frans van Berckel <fberckel@xs4all.nl>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    davem330 committed with gregkh Apr 4, 2010
  31. slab: fix object alignment

    commit 1ab335d upstream.
    
    This patch fixes alignment of slab objects in case CONFIG_DEBUG_PAGEALLOC is
    active.
    Before this spot in kmem_cache_create, we have this situation:
    - align contains the required alignment of the object
    - cachep->obj_offset is 0 or equals align in case of CONFIG_DEBUG_SLAB
    - size equals the size of the object, or object plus trailing redzone in case
      of CONFIG_DEBUG_SLAB
    
    This spot tries to fill one page per object if the object is in certain size
    limits, however setting obj_offset to PAGE_SIZE - size does break the object
    alignment since size may not be aligned with the required alignment.
    This patch simply adds an ALIGN(size, align) to the equation and fixes the
    object size detection accordingly.
    
    This code in drivers/s390/cio/qdio_setup_init has lead to incorrectly aligned
    slab objects (sizeof(struct qdio_q) equals 1792):
    	qdio_q_cache = kmem_cache_create("qdio_q", sizeof(struct qdio_q),
    					 256, 0, NULL);
    
    Acked-by: Christoph Lameter <cl@linux.com>
    Signed-off-by: Carsten Otte <cotte@de.ibm.com>
    Signed-off-by: Pekka Enberg <penberg@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Carsten Otte committed with gregkh Aug 6, 2010
  32. drm/i915: add 'reclaimable' to i915 self-reclaimable page allocations

    commit cd9f040 upstream.
    
    The hibernate issues that got fixed in commit 985b823 ("drm/i915:
    fix hibernation since i915 self-reclaim fixes") turn out to have been
    incomplete.  Vefa Bicakci tested lots of hibernate cycles, and without
    the __GFP_RECLAIMABLE flag the system eventually fails to resume.
    
    With the flag added, Vefa can apparently hibernate forever (or until he
    gets bored running his automated scripts, whichever comes first).
    
    The reclaimable flag was there originally, and was one of the flags that
    were dropped (unintentionally) by commit 4bdadb9 ("drm/i915:
    Selectively enable self-reclaim") that introduced all these problems,
    but I didn't want to just blindly add back all the flags in commit
    985b823, and it looked like __GFP_RECLAIM wasn't necessary.  It
    clearly was.
    
    I still suspect that there is some subtle reason we're missing that
    causes the problems, but __GFP_RECLAIMABLE is certainly not wrong to use
    in this context, and is what the code historically used.  And we have no
    idea what the causes the corruption without it.
    
    Reported-and-tested-by: M. Vefa Bicakci <bicave@superonline.com>
    Cc: Dave Airlie <airlied@gmail.com>
    Cc: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Cc: Hugh Dickins <hugh.dickins@tiscali.co.uk>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    torvalds committed with gregkh Jul 18, 2010
  33. drm/i915: fix hibernation since i915 self-reclaim fixes

    commit 985b823 upstream.
    
    Since commit 4bdadb9 ("drm/i915:
    Selectively enable self-reclaim"), we've been passing GFP_MOVABLE to the
    i915 page allocator where we weren't before due to some over-eager
    removal of the page mapping gfp_flags games the code used to play.
    
    This caused hibernate on Intel hardware to result in a lot of memory
    corruptions on resume.  See for example
    
      http://bugzilla.kernel.org/show_bug.cgi?id=13811
    
    Reported-by: Evengi Golov (in bugzilla)
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Tested-by: M. Vefa Bicakci <bicave@superonline.com>
    Cc: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Cc: Hugh Dickins <hugh.dickins@tiscali.co.uk>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    torvalds committed with gregkh Jul 2, 2010
  34. mm: make stack guard page logic use vm_prev pointer

    commit 0e8e50e upstream.
    
    Like the mlock() change previously, this makes the stack guard check
    code use vma->vm_prev to see what the mapping below the current stack
    is, rather than have to look it up with find_vma().
    
    Also, accept an abutting stack segment, since that happens naturally if
    you split the stack with mlock or mprotect.
    
    Tested-by: Ian Campbell <ijc@hellion.org.uk>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    torvalds committed with gregkh Aug 20, 2010
  35. mm: make the mlock() stack guard page checks stricter

    commit 7798330 upstream.
    
    If we've split the stack vma, only the lowest one has the guard page.
    Now that we have a doubly linked list of vma's, checking this is trivial.
    
    Tested-by: Ian Campbell <ijc@hellion.org.uk>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    torvalds committed with gregkh Aug 20, 2010