Skip to content
Commits on May 2, 2009
  1. @gregkh

    Linux 2.6.27.22

    gregkh committed May 2, 2009
  2. @gregkh

    unreached code in selinux_ip_postroute_iptables_compat() (CVE-2009-1184)

    Eugene Teo committed with gregkh Apr 13, 2009
    Not upstream in 2.6.30, as the function was removed there, making this a
    non-issue.
    
    Node and port send checks can skip in the compat_net=1 case. This bug
    was introduced in commit effad8d.
    
    Signed-off-by: Eugene Teo <eugeneteo@kernel.sg>
    Reported-by: Dan Carpenter <error27@gmail.com>
    Acked-by: James Morris <jmorris@namei.org>
    Acked-by: Paul Moore <paul.moore@hp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  3. @hanneseder-net @gregkh

    ACPI: EC: fix compilation warning

    hanneseder-net committed with gregkh Nov 29, 2008
    commit 3e54048 upstream.
    
    Fix the warning introduced in commit c5279de,
    and give the dummy variable a more verbose name.
    
      drivers/acpi/ec.c: In function 'acpi_ec_ecdt_probe':
      drivers/acpi/ec.c:1015: warning: ISO C90 forbids mixed declarations and code
    
    Signed-off-by: Hannes Eder <hannes@hanneseder.net>
    Acked-by: Alexey Starikovskiy <astarikovskiy@suse.de>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  4. @gregkh

    ACPI: EC: Add some basic check for ECDT data

    Alexey Starikovskiy committed with gregkh Nov 26, 2008
    commit c5279de upstream.
    
    One more ASUS comes with empty ECDT, add a guard for it...
    
    http://bugzilla.kernel.org/show_bug.cgi?id=11880
    
    Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  5. @hmh @gregkh

    thinkpad-acpi: fix LED blinking through timer trigger

    hmh committed with gregkh Apr 14, 2009
    commit 75bd3bf upstream.
    
    The set_blink hook code in the LED subdriver would never manage to get
    a LED to blink, and instead it would just turn it on.  The consequence
    of this is that the "timer" trigger would not cause the LED to blink
    if given default parameters.
    
    This problem exists since 2.6.26-rc1.
    
    To fix it, switch the deferred LED work handling to use the
    thinkpad-acpi-specific LED status (off/on/blink) directly.
    
    This also makes the code easier to read, and to extend later.
    
    Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
    Cc: stable@kernel.org
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  6. @gregkh

    PCI: fix incorrect mask of PM No_Soft_Reset bit

    Yu Zhao committed with gregkh Feb 25, 2009
    commit 998dd7c upstream.
    
    Reviewed-by: Matthew Wilcox <matthew@wil.cx>
    Signed-off-by: Yu Zhao <yu.zhao@intel.com>
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  7. @gregkh

    fs core fixes

    Hugh Dickins committed with gregkh Apr 25, 2009
    Please add the following 4 commits to 2.6.27-stable and 2.6.28-stable.
    However, there has been a lot of change here between 2.6.28 and 2.6.29:
    in particular, fs/exec.c's unsafe_exec() grew into the more complicated
    check_unsafe_exec().  So applying the original patches gives too many
    rejects: at the bottom is the diffstat and the combined patch required.
    
    1
    Commit: 53e9309
    Author: Hugh Dickins <hugh@veritas.com>
    Date: Sat, 28 Mar 2009 23:16:03 +0000 (+0000)
    Subject: compat_do_execve should unshare_files
    
    2
    Commit: e426b64
    Author: Hugh Dickins <hugh@veritas.com>
    Date: Sat, 28 Mar 2009 23:20:19 +0000 (+0000)
    Subject: fix setuid sometimes doesn't
    
    3
    Commit: 7c2c7d9
    Author: Hugh Dickins <hugh@veritas.com>
    Date: Sat, 28 Mar 2009 23:21:27 +0000 (+0000)
    Subject: fix setuid sometimes wouldn't
    
    4
    Commit: f1191b5
    Author: Al Viro <viro@zeniv.linux.org.uk>
    Date: Mon, 30 Mar 2009 11:35:18 +0000 (-0400)
    Subject: check_unsafe_exec() doesn't care about signal handlers sharing
    
    Signed-off-by: Hugh Dickins <hugh@veritas.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  8. @gregkh

    fix ptrace slowness

    Miklos Szeredi committed with gregkh Mar 23, 2009
    commit 53da1d9 upstream.
    
    This patch fixes bug #12208:
    
      Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=12208
      Subject         : uml is very slow on 2.6.28 host
    
    This turned out to be not a scheduler regression, but an already
    existing problem in ptrace being triggered by subtle scheduler
    changes.
    
    The problem is this:
    
     - task A is ptracing task B
     - task B stops on a trace event
     - task A is woken up and preempts task B
     - task A calls ptrace on task B, which does ptrace_check_attach()
     - this calls wait_task_inactive(), which sees that task B is still on the runq
     - task A goes to sleep for a jiffy
     - ...
    
    Since UML does lots of the above sequences, those jiffies quickly add
    up to make it slow as hell.
    
    This patch solves this by not rescheduling in read_unlock() after
    ptrace_stop() has woken up the tracer.
    
    Thanks to Oleg Nesterov and Ingo Molnar for the feedback.
    
    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    CC: stable@kernel.org
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  9. @utrace @gregkh

    exit_notify: kill the wrong capable(CAP_KILL) check (CVE-2009-1337)

    utrace committed with gregkh Apr 6, 2009
    CVE-2009-1337
    
    commit 432870d upstream.
    
    The CAP_KILL check in exit_notify() looks just wrong, kill it.
    
    Whatever logic we have to reset ->exit_signal, the malicious user
    can bypass it if it execs the setuid application before exiting.
    
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Acked-by: Serge Hallyn <serue@us.ibm.com>
    Acked-by: Roland McGrath <roland@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  10. @gregkh

    crypto: ixp4xx - Fix handling of chained sg buffers

    Christian Hohnstaedt committed with gregkh Mar 27, 2009
    commit 0d44dc5 upstream.
    
     - keep dma functions away from chained scatterlists.
       Use the existing scatterlist iteration inside the driver
       to call dma_map_single() for each chunk and avoid dma_map_sg().
    
    Signed-off-by: Christian Hohnstaedt <chohnstaedt@innominate.com>
    Tested-By:  Karl Hiramoto <karl@hiramoto.org>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  11. @gregkh

    b44: Use kernel DMA addresses for the kernel DMA API

    Michael Buesch committed with gregkh Apr 6, 2009
    commit 37efa23 upstream.
    
    We must not use the device DMA addresses for the kernel DMA API, because
    device DMA addresses have an additional offset added for the SSB translation.
    
    Use the original dma_addr_t for the sync operation.
    
    Cc: stable@kernel.org
    Signed-off-by: Michael Buesch <mb@bu3sch.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  12. @gregkh

    ath9k: AR9280 PCI devices must serialize IO as well

    Luis R. Rodriguez committed with gregkh Mar 23, 2009
    This is a port of:
    commit SHA1 5ec905a
    for 2.6.27
    
    Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  13. @gregkh

    ath9k: implement IO serialization

    Luis R. Rodriguez committed with gregkh Mar 23, 2009
    This is a port of:
    commit SHA1 6158425
    for 2.6.27
    
    All 802.11n PCI devices (Cardbus, PCI, mini-PCI) require
    serialization of IO when on non-uniprocessor systems. PCI
    express devices not not require this.
    
    This should fix our only last standing open ath9k kernel.org
    bugzilla bug report:
    
    http://bugzilla.kernel.org/show_bug.cgi?id=12110
    
    Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  14. @gregkh

    powerpc: Sanitize stack pointer in signal handling code

    Josh Boyer committed with gregkh Apr 28, 2009
    This has been backported to 2.6.27.x from commit efbda86 in Linus' tree.
    
    On powerpc64 machines running 32-bit userspace, we can get garbage bits in the
    stack pointer passed into the kernel.  Most places handle this correctly, but
    the signal handling code uses the passed value directly for allocating signal
    stack frames.
    
    This fixes the issue by introducing a get_clean_sp function that returns a
    sanitized stack pointer.  For 32-bit tasks on a 64-bit kernel, the stack
    pointer is masked correctly.  In all other cases, the stack pointer is simply
    returned.
    
    Additionally, we pass an 'is_32' parameter to get_sigframe now in order to
    get the properly sanitized stack.  The callers are know to be 32 or 64-bit
    statically.
    
    Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  15. @hnaz @gregkh

    mm: check for no mmaps in exit_mmap()

    hnaz committed with gregkh Jan 6, 2009
    commit dcd4a04 upstream.
    
    When dup_mmap() ooms we can end up with mm->mmap == NULL.  The error
    path does mmput() and unmap_vmas() gets a NULL vma which it
    dereferences.
    
    In exit_mmap() there is nothing to do at all for this case, we can
    cancel the callpath right there.
    
    [akpm@linux-foundation.org: add sorely-needed comment]
    Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
    Reported-by: Akinobu Mita <akinobu.mita@gmail.com>
    Cc: Nick Piggin <nickpiggin@yahoo.com.au>
    Cc: Hugh Dickins <hugh@veritas.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Reported-by: Kir Kolyshkin <kir@openvz.org>
    Tested-by: Kir Kolyshkin <kir@openvz.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  16. @gregkh

    r8169: reset IntrStatus after chip reset

    Francois Romieu committed with gregkh Apr 16, 2009
    Upstream as d78ad8c (post 2.6.29).
    
    Original comment (Karsten):
    On a MSI MS-6702E mainboard, when in rtl8169_init_one() for the first time
    after BIOS has run, IntrStatus reads 5 after chip has been reset.
    IntrStatus should equal 0 there, so patch changes IntrStatus reset to happen
    after chip reset instead of before.
    
    Remark (Francois):
    Assuming that the loglevel of the driver is increased above NETIF_MSG_INTR,
    the bug reveals itself with a typical "interrupt 0025 in poll" message
    at startup. In retrospect, the message should had been read as an hint of
    an unexpected hardware state several months ago :o(
    
    Fixes (at least part of) https://bugzilla.redhat.com/show_bug.cgi?id=460747
    
    Signed-off-by: Karsten Wiese <fzu@wemgehoertderstaat.de>
    Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
    Tested-by: Josep <josep.puigdemont@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  17. @gregkh

    r8169: use hardware auto-padding.

    Francois Romieu committed with gregkh Apr 16, 2009
    Upstream as 97d477a (post 2.6.28).
    
    It shortens the code and fixes the current pci_unmap leak with
    padded skb reported by Dave Jones.
    
    Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  18. @gregkh

    r8169: Don't update statistics counters when interface is down

    Francois Romieu committed with gregkh Apr 16, 2009
    Upstream as 355423d (post 2.6.28).
    
    Some Realtek chips (RTL8169sb/8110sb in my case) are unable to retrieve
    ethtool statistics when the interface is down. The process stays in
    endless loop in rtl8169_get_ethtool_stats. This is because these chips
    need to have receiver enabled (CmdRxEnb bit in ChipCmd register) that is
    cleared when the interface is going down. It's better to update statistics
    only when the interface is up and otherwise return copy of statistics
    grabbed when the interface was up (in rtl8169_close).
    
    It is interesting that PCI-E NICs (like 8168b/8111b...) are not affected.
    
    Signed-off-by: Ivan Vecera <ivecera@redhat.com>
    Acked-by: Francois Romieu <romieu@fr.zoreil.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  19. @gregkh

    block: revert part of 18ce375

    Jens Axboe committed with gregkh Feb 17, 2009
    commit 78f707b upstream.
    
    The above commit added WRITE_SYNC and switched various places to using
    that for committing writes that will be waited upon immediately after
    submission. However, this causes a performance regression with AS and CFQ
    for ext3 at least, since sync_dirty_buffer() will submit some writes with
    WRITE_SYNC while ext3 has sumitted others dependent writes without the sync
    flag set. This causes excessive anticipation/idling in the IO scheduler
    because sync and async writes get interleaved, causing a big performance
    regression for the below test case (which is meant to simulate sqlite
    like behaviour).
    
    ---- test case ----
    
    int main(int argc, char **argv)
    {
    
    	int fdes, i;
    	FILE *fp;
    	struct timeval start;
    	struct timeval end;
    	struct timeval res;
    
    	gettimeofday(&start, NULL);
    	for (i=0; i<ROWS; i++) {
    		fp = fopen("test_file", "a");
    		fprintf(fp, "Some Text Data\n");
    		fdes = fileno(fp);
    		fsync(fdes);
    		fclose(fp);
    	}
    	gettimeofday(&end, NULL);
    
    	timersub(&end, &start, &res);
    	fprintf(stdout, "time to write %d lines is %ld(msec)\n", ROWS,
    			(res.tv_sec*1000000 + res.tv_usec)/1000);
    
    	return 0;
    }
    
    -------------------
    
    Thanks to Sean.White@APCC.com for tracking down this performance
    regression and providing a test case.
    
    Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  20. @gregkh

    kprobes: Fix locking imbalance in kretprobes

    Ananth N Mavinakayanahalli committed with gregkh Mar 18, 2009
    commit f02b862 upstream.
    
    Fix locking imbalance in kretprobes:
    
    =====================================
    [ BUG: bad unlock balance detected! ]
    -------------------------------------
    kthreadd/2 is trying to release lock (&rp->lock) at:
    [<c06b3080>] pre_handler_kretprobe+0xea/0xf4
    but there are no more locks to release!
    
    other info that might help us debug this:
    1 lock held by kthreadd/2:
     #0:  (rcu_read_lock){..--}, at: [<c06b2b24>] __atomic_notifier_call_chain+0x0/0x5a
    
    stack backtrace:
    Pid: 2, comm: kthreadd Not tainted 2.6.29-rc8 #1
    Call Trace:
     [<c06ae498>] ? printk+0xf/0x17
     [<c06b3080>] ? pre_handler_kretprobe+0xea/0xf4
     [<c044ce6c>] print_unlock_inbalance_bug+0xc3/0xce
     [<c0444d4b>] ? clocksource_read+0x7/0xa
     [<c04450a4>] ? getnstimeofday+0x5f/0xf6
     [<c044a9ca>] ? register_lock_class+0x17/0x293
     [<c044b72c>] ? mark_lock+0x1e/0x30b
     [<c0448956>] ? tick_dev_program_event+0x4a/0xbc
     [<c0498100>] ? __slab_alloc+0xa5/0x415
     [<c06b2fbe>] ? pre_handler_kretprobe+0x28/0xf4
     [<c06b3080>] ? pre_handler_kretprobe+0xea/0xf4
     [<c044cf1b>] lock_release_non_nested+0xa4/0x1a5
     [<c06b3080>] ? pre_handler_kretprobe+0xea/0xf4
     [<c044d15d>] lock_release+0x141/0x166
     [<c06b07dd>] _spin_unlock_irqrestore+0x19/0x50
     [<c06b3080>] pre_handler_kretprobe+0xea/0xf4
     [<c06b20b5>] kprobe_exceptions_notify+0x1c9/0x43e
     [<c06b2b02>] notifier_call_chain+0x26/0x48
     [<c06b2b5b>] __atomic_notifier_call_chain+0x37/0x5a
     [<c06b2b24>] ? __atomic_notifier_call_chain+0x0/0x5a
     [<c06b2b8a>] atomic_notifier_call_chain+0xc/0xe
     [<c0442d0d>] notify_die+0x2d/0x2f
     [<c06b0f9c>] do_int3+0x1f/0x71
     [<c06b0e84>] int3+0x2c/0x34
     [<c042d476>] ? do_fork+0x1/0x288
     [<c040221b>] ? kernel_thread+0x71/0x79
     [<c043ed1b>] ? kthread+0x0/0x60
     [<c043ed1b>] ? kthread+0x0/0x60
     [<c04040b8>] ? kernel_thread_helper+0x0/0x10
     [<c043ec7f>] kthreadd+0xac/0x148
     [<c043ebd3>] ? kthreadd+0x0/0x148
     [<c04040bf>] kernel_thread_helper+0x7/0x10
    
    Signed-off-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
    Tested-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
    Cc: Masami Hiramatsu <mhiramat@redhat.com>
    Cc: Jim Keniston <jkenisto@us.ibm.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    LKML-Reference: <20090318113621.GB4129@in.ibm.com>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  21. @mita @gregkh

    hugetlbfs: return negative error code for bad mount option

    mita committed with gregkh Apr 21, 2009
    upstream commit: c12ddba
    
    This fixes the following BUG:
    
      # mount -o size=MM -t hugetlbfs none /huge
      hugetlbfs: Bad value 'MM' for mount option 'size=MM'
      ------------[ cut here ]------------
      kernel BUG at fs/super.c:996!
    
    Due to
    
    	BUG_ON(!mnt->mnt_sb);
    
    in vfs_kern_mount().
    
    Also, remove unused #include <linux/quotaops.h>
    
    Cc: William Irwin <wli@holomorphy.com>
    Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  22. @gregkh

    agp: zero pages before sending to userspace

    Shaohua Li committed with gregkh Apr 20, 2009
    upstream commit: 59de2be
    
    CVE-2009-1192
    
    AGP pages might be mapped into userspace finally, so the pages should be
    set to zero before userspace can use it. Otherwise there is potential
    information leakage.
    
    Signed-off-by: Shaohua Li <shaohua.li@intel.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  23. @gregkh

    USB: usb-storage: augment unusual_devs entry for Simple Tech/Datafab

    Alan Stern committed with gregkh Apr 17, 2009
    upstream commit: e4813ee
    
    This patch (as1227) adds the MAX_SECTORS_64 flag to the unusual_devs
    entry for the Simple Tech/Datafab controller.  This fixes Bugzilla
    #12882.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-and-tested-by: binbin <binbinsh@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
  24. @gregkh

    USB: fix oops in cdc-wdm in case of malformed descriptors

    Oliver Neukum committed with gregkh Apr 17, 2009
    upstream commit: e13c594
    
    cdc-wdm needs to ignore extremely malformed descriptors.
    
    Signed-off-by: Oliver Neukum <oliver@neukum.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
  25. @jacmet @gregkh

    USB: ftdi_sio: add vendor/project id for JETI specbos 1201 spectrometer

    jacmet committed with gregkh Apr 17, 2009
    upstream commit: ae27d84
    
    Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
  26. @u1f35c @gregkh

    usb gadget: fix ethernet link reports to ethtool

    u1f35c committed with gregkh Apr 17, 2009
    upstream commit: 237e75b
    
    The g_ether USB gadget driver currently decides whether or not there's a
    link to report back for eth_get_link based on if the USB link speed is
    set. The USB gadget speed is however often set even before the device is
    enumerated. It seems more sensible to only report a "link" if we're
    actually connected to a host that wants to talk to us. The patch below
    does this for me - tested with the PXA27x UDC driver.
    
    Signed-off-by: Jonathan McDowell <noodles@earth.li>
    Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
  27. @gregkh

    pata_hpt37x: fix HPT370 DMA timeouts

    Sergei Shtylyov committed with gregkh Apr 14, 2009
    upstream commit: 265b721
    
    The libata driver has copied the code from the IDE driver which caused a post
    2.4.18 regression on many HPT370[A] chips -- DMA stopped to work completely,
    only causing timeouts.  Now remove hpt370_bmdma_start() for good...
    
    Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
    Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  28. @gregkh

    hpt366: fix HPT370 DMA timeouts

    Sergei Shtylyov committed with gregkh Apr 18, 2009
    upstream commit: c018f1e
    
    The big driver change in 2.4.19-rc1 introduced a regression for many HPT370[A]
    chips -- DMA stopped to work completely, only causing endless timeouts...
    
    The culprit has been identified (at last!): it turned to be the code resetting
    the DMA state machine before each transfer. Stop doing it now as this counter-
    measure has clearly caused more harm than good.
    
    This should fix the kernel.org bug #7703.
    
    Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
    Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  29. @paulusmack @gregkh

    powerpc: Fix data-corrupting bug in __futex_atomic_op

    paulusmack committed with gregkh Apr 15, 2009
    upstream commit: 306a828
    
    Richard Henderson pointed out that the powerpc __futex_atomic_op has a
    bug: it will write the wrong value if the stwcx. fails and it has to
    retry the lwarx/stwcx. loop, since 'oparg' will have been overwritten
    by the result from the first time around the loop.  This happens
    because it uses the same register for 'oparg' (an input) as it uses
    for the result.
    
    This fixes it by using separate registers for 'oparg' and 'ret'.
    
    Cc: stable@kernel.org
    Signed-off-by: Paul Mackerras <paulus@samba.org>
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  30. @gregkh

    add some long-missing capabilities to fs_mask

    Serge E. Hallyn committed with gregkh Apr 13, 2009
    upstream commit: 0ad30b8
    
    When POSIX capabilities were introduced during the 2.1 Linux
    cycle, the fs mask, which represents the capabilities which having
    fsuid==0 is supposed to grant, did not include CAP_MKNOD and
    CAP_LINUX_IMMUTABLE.  However, before capabilities the privilege
    to call these did in fact depend upon fsuid==0.
    
    This patch introduces those capabilities into the fsmask,
    restoring the old behavior.
    
    See the thread starting at http://lkml.org/lkml/2009/3/11/157 for
    reference.
    
    Note that if this fix is deemed valid, then earlier kernel versions (2.4
    and 2.2) ought to be fixed too.
    
    Changelog:
    	[Mar 23] Actually delete old CAP_FS_SET definition...
    	[Mar 20] Updated against J. Bruce Fields's patch
    
    Reported-by: Igor Zhbanov <izh1979@gmail.com>
    Signed-off-by: Serge E. Hallyn <serue@us.ibm.com>
    Cc: stable@kernel.org
    Cc: J. Bruce Fields <bfields@citi.umich.edu>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  31. @nathanlynch @gregkh

    sched: do not count frozen tasks toward load

    nathanlynch committed with gregkh Apr 9, 2009
    upstream commit: e3c8ca8
    
    Freezing tasks via the cgroup freezer causes the load average to climb
    because the freezer's current implementation puts frozen tasks in
    uninterruptible sleep (D state).
    
    Some applications which perform job-scheduling functions consult the
    load average when making decisions.  If a cgroup is frozen, the load
    average does not provide a useful measure of the system's utilization
    to such applications.  This is especially inconvenient if the job
    scheduler employs the cgroup freezer as a mechanism for preempting low
    priority jobs.  Contrast this with using SIGSTOP for the same purpose:
    the stopped tasks do not count toward system load.
    
    Change task_contributes_to_load() to return false if the task is
    frozen.  This results in /proc/loadavg behavior that better meets
    users' expectations.
    
    Signed-off-by: Nathan Lynch <ntl@pobox.com>
    Acked-by: Andrew Morton <akpm@linux-foundation.org>
    Acked-by: Nigel Cunningham <nigel@tuxonice.net>
    Tested-by: Nigel Cunningham <nigel@tuxonice.net>
    Cc: containers@lists.linux-foundation.org
    Cc: linux-pm@lists.linux-foundation.org
    Cc: Matt Helsley <matthltc@us.ibm.com>
    LKML-Reference: <20090408194512.47a99b95@manatee.lan>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  32. @jdelvare @gregkh

    SCSI: libiscsi: fix iscsi pool error path again

    jdelvare committed with gregkh Apr 1, 2009
    upstream commit: fd6e1c1
    
    Le lundi 30 mars 2009, Chris Wright a écrit :
    > q->queue could be ERR_PTR(-ENOMEM) which will break unwinding
    > on error.  Make iscsi_pool_free more defensive.
    >
    
    Making the freeing of q->queue dependent on q->pool being set looks
    really weird (although it is correct at the moment. But this seems
    to be fixable in a much simpler way.
    
    With the benefit that only the error case is slowed down. In both
    cases we have a problem if q->queue contains an error value but it's
    not -ENOMEM. Apparently this can't happen today, but it doesn't feel
    right to assume this will always be true. Maybe it's the right time
    to fix this as well.
    
    Signed-off-by: Mike Christie <michaelc@cs.wisc.edu>
    Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
    [chrisw: this is a fixlet to f474a37, also in -stable]
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  33. @jdelvare @gregkh

    SCSI: libiscsi: fix iscsi pool error path

    jdelvare committed with gregkh Mar 5, 2009
    upstream commit: f474a37
    
    Memory freeing in iscsi_pool_free() looks wrong to me. Either q->pool
    can be NULL and this should be tested before dereferencing it, or it
    can't be NULL and it shouldn't be tested at all. As far as I can see,
    the only case where q->pool is NULL is on early error in
    iscsi_pool_init(). One possible way to fix the bug is thus to not
    call iscsi_pool_free() in this case (nothing needs to be freed anyway)
    and then we can get rid of the q->pool check.
    
    Signed-off-by: Jean Delvare <jdelvare@suse.de>
    Signed-off-by: Mike Christie <michaelc@cs.wisc.edu>
    Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  34. @mita @gregkh

    ALSA: hda - add missing comma in ad1884_slave_vols

    mita committed with gregkh Apr 7, 2009
    upstream commit: bca6846
    
    Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  35. @gregkh

    splice: fix deadlock in splicing to file

    Miklos Szeredi committed with gregkh Apr 7, 2009
    upstream commit: 7bfac9e
    
    There's a possible deadlock in generic_file_splice_write(),
    splice_from_pipe() and ocfs2_file_splice_write():
    
     - task A calls generic_file_splice_write()
     - this calls inode_double_lock(), which locks i_mutex on both
       pipe->inode and target inode
     - ordering depends on inode pointers, can happen that pipe->inode is
       locked first
     - __splice_from_pipe() needs more data, calls pipe_wait()
     - this releases lock on pipe->inode, goes to interruptible sleep
     - task B calls generic_file_splice_write(), similarly to the first
     - this locks pipe->inode, then tries to lock inode, but that is
       already held by task A
     - task A is interrupted, it tries to lock pipe->inode, but fails, as
       it is already held by task B
     - ABBA deadlock
    
    Fix this by explicitly ordering locks: the outer lock must be on
    target inode and the inner lock (which is later unlocked and relocked)
    must be on pipe->inode.  This is OK, pipe inodes and target inodes
    form two nonoverlapping sets, generic_file_splice_write() and friends
    are not called with a target which is a pipe.
    
    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    Acked-by: Mark Fasheh <mfasheh@suse.com>
    Acked-by: Jens Axboe <jens.axboe@oracle.com>
    Cc: stable@kernel.org
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Something went wrong with that request. Please try again.