Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Commits on Jun 22, 2008
  1. @gregkh

    Linux 2.6.25.8

    gregkh authored
  2. @gregkh

    x86: disable mwait for AMD family 10H/11H CPUs

    Thomas Gleixner authored gregkh committed
    back-ported from upstream commit e9623b3 by Vegard Nossum
    
    
    The previous revert of 0c07ee3 left
    out the mwait disable condition for AMD family 10H/11H CPUs.
    
    Andreas Herrman said:
    
    It depends on the CPU. For AMD CPUs that support MWAIT this is wrong.
    Family 0x10 and 0x11 CPUs will enter C1 on HLT. Powersavings then
    depend on a clock divisor and current Pstate of the core.
    
    If all cores of a processor are in halt state (C1) the processor can
    enter the C1E (C1 enhanced) state. If mwait is used this will never
    happen.
    
    Thus HLT saves more power than MWAIT here.
    
    It might be best to switch off the mwait flag for these AMD CPU
    families like it was introduced with commit
    f039b75 (x86: Don't use MWAIT on AMD
    Family 10)
    
    Re-add the AMD families 10H/11H check and disable the mwait usage for
    those.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Vegard Nossum <vegard.nossum@gmail.com>
    Cc: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  3. @gregkh

    x86: remove mwait capability C-state check

    Ingo Molnar authored gregkh committed
    back-ported from upstream commit a738d89 by Vegard Nossum
    
    Vegard Nossum reports:
    
    | powertop shows between 200-400 wakeups/second with the description
    | "<kernel IPI>: Rescheduling interrupts" when all processors have load (e.g.
    | I need to run two busy-loops on my 2-CPU system for this to show up).
    |
    | The bisect resulted in this commit:
    |
    | commit 0c07ee3
    | Date:   Wed Jan 30 13:33:16 2008 +0100
    |
    |     x86: use the correct cpuid method to detect MWAIT support for C states
    
    remove the functional effects of this patch and make mwait unconditional.
    
    A future patch will turn off mwait on specific CPUs where that causes
    power to be wasted.
    
    Bisected-by: Vegard Nossum <vegard.nossum@gmail.com>
    Tested-by: Vegard Nossum <vegard.nossum@gmail.com>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Vegard Nossum <vegard.nossum@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  4. @kaber @gregkh

    nf_conntrack_h323: fix memory leak in module initialization error path

    kaber authored gregkh committed
    netfilter: nf_conntrack_h323: fix memory leak in module initialization error path
    
    Upstream commit 8a54886
    
    Properly free h323_buffer when helper registration fails.
    
    Signed-off-by: Patrick McHardy <kaber@trash.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  5. @kaber @gregkh

    nf_conntrack_h323: fix module unload crash

    kaber authored gregkh committed
    netfilter: nf_conntrack_h323: fix module unload crash
    
    Upstream commit a56b8f8
    
    The H.245 helper is not registered/unregistered, but assigned to
    connections manually from the Q.931 helper. This means on unload
    existing expectations and connections using the helper are not
    cleaned up, leading to the following oops on module unload:
    
    CPU 0 Unable to handle kernel paging request at virtual address c00a6828, epc == 802224dc, ra == 801d4e7c
    Oops[#1]:
    Cpu 0
    $ 0   : 00000000 00000000 00000004 c00a67f0
    $ 4   : 802a5ad0 81657e00 00000000 00000000
    $ 8   : 00000008 801461c8 00000000 80570050
    $12   : 819b0280 819b04b0 00000006 00000000
    $16   : 802a5a60 80000000 80b46000 80321010
    $20   : 00000000 00000004 802a5ad0 00000001
    $24   : 00000000 802257a8
    $28   : 802a4000 802a59e8 00000004 801d4e7c
    Hi    : 0000000b
    Lo    : 00506320
    epc   : 802224dc ip_conntrack_help+0x38/0x74     Tainted: P
    ra    : 801d4e7c nf_iterate+0xbc/0x130
    Status: 1000f403    KERNEL EXL IE
    Cause : 00800008
    BadVA : c00a6828
    PrId  : 00019374
    Modules linked in: ip_nat_pptp ip_conntrack_pptp ath_pktlog wlan_acl wlan_wep wlan_tkip wlan_ccmp wlan_xauth ath_pci ath_dev ath_dfs ath_rate_atheros wlan ath_hal ip_nat_tftp ip_conntrack_tftp ip_nat_ftp ip_conntrack_ftp pppoe ppp_async ppp_deflate ppp_mppe pppox ppp_generic slhc
    Process swapper (pid: 0, threadinfo=802a4000, task=802a6000)
    Stack : 801e7d98 00000004 802a5a60 80000000 801d4e7c 801d4e7c 802a5ad0 00000004
            00000000 00000000 801e7d98 00000000 00000004 802a5ad0 00000000 00000010
            801e7d98 80b46000 802a5a60 80320000 80000000 801d4f8c 802a5b00 00000002
            80063834 00000000 80b46000 802a5a60 801e7d98 80000000 802ba854 00000000
            81a02180 80b7e260 81a021b0 819b0000 819b0000 80570056 00000000 00000001
            ...
    Call Trace:
     [<801e7d98>] ip_finish_output+0x0/0x23c
     [<801d4e7c>] nf_iterate+0xbc/0x130
     [<801d4e7c>] nf_iterate+0xbc/0x130
     [<801e7d98>] ip_finish_output+0x0/0x23c
     [<801e7d98>] ip_finish_output+0x0/0x23c
     [<801d4f8c>] nf_hook_slow+0x9c/0x1a4
    
    One way to fix this would be to split helper cleanup from the unregistration
    function and invoke it for the H.245 helper, but since ctnetlink needs to be
    able to find the helper for synchonization purposes, a better fix is to
    register it normally and make sure its not assigned to connections during
    helper lookup. The missing l3num initialization is enough for this, this
    patch changes it to use AF_UNSPEC to make it more explicit though.
    
    Reported-by: liannan <liannan@twsz.com>
    Signed-off-by: Patrick McHardy <kaber@trash.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  6. @kaber @gregkh

    nf_conntrack: fix ctnetlink related crash in nf_nat_setup_info()

    kaber authored gregkh committed
    netfilter: nf_conntrack: fix ctnetlink related crash in nf_nat_setup_info()
    
    Upstream commit ceeff75
    
    When creation of a new conntrack entry in ctnetlink fails after having
    set up the NAT mappings, the conntrack has an extension area allocated
    that is not getting properly destroyed when freeing the conntrack again.
    This means the NAT extension is still in the bysource hash, causing a
    crash when walking over the hash chain the next time:
    
    BUG: unable to handle kernel paging request at 00120fbd
    IP: [<c03d394b>] nf_nat_setup_info+0x221/0x58a
    *pde = 00000000
    Oops: 0000 [#1] PREEMPT SMP
    
    Pid: 2795, comm: conntrackd Not tainted (2.6.26-rc5 #1)
    EIP: 0060:[<c03d394b>] EFLAGS: 00010206 CPU: 1
    EIP is at nf_nat_setup_info+0x221/0x58a
    EAX: 00120fbd EBX: 00120fbd ECX: 00000001 EDX: 00000000
    ESI: 0000019e EDI: e853bbb4 EBP: e853bbc8 ESP: e853bb78
     DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
    Process conntrackd (pid: 2795, ti=e853a000 task=f7de10f0 task.ti=e853a000)
    Stack: 00000000 e853bc2c e85672ec 00000008 c0561084 63c1db4a 00000000 00000000
           00000000 0002e109 61d2b1c3 00000000 00000000 00000000 01114e22 61d2b1c3
           00000000 00000000 f7444674 e853bc04 00000008 c038e728 0000000a f7444674
    Call Trace:
     [<c038e728>] nla_parse+0x5c/0xb0
     [<c0397c1b>] ctnetlink_change_status+0x190/0x1c6
     [<c0397eec>] ctnetlink_new_conntrack+0x189/0x61f
     [<c0119aee>] update_curr+0x3d/0x52
     [<c03902d1>] nfnetlink_rcv_msg+0xc1/0xd8
     [<c0390228>] nfnetlink_rcv_msg+0x18/0xd8
     [<c0390210>] nfnetlink_rcv_msg+0x0/0xd8
     [<c038d2ce>] netlink_rcv_skb+0x2d/0x71
     [<c0390205>] nfnetlink_rcv+0x19/0x24
     [<c038d0f5>] netlink_unicast+0x1b3/0x216
     ...
    
    Move invocation of the extension destructors to nf_conntrack_free()
    to fix this problem.
    
    Fixes http://bugzilla.kernel.org/show_bug.cgi?id=10875
    
    Reported-and-Tested-by: Krzysztof Piotr Oledzki <ole@ans.pl>
    Signed-off-by: Patrick McHardy <kaber@trash.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  7. @gregkh

    SCSI: sr: fix corrupt CD data after media change and delay

    James Bottomley authored gregkh committed
    commit: d1daeab upstream
    
    Reported-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
    
    If you delay 30s or more before mounting a CD after inserting it then
    the kernel has the wrong value for the CD size.
    
    http://marc.info/?t=121276133000001
    
    The problem is in sr_test_unit_ready(): the function eats unit
    attentions without adjusting the sdev->changed status.  This means
    that when the CD signals changed media via unit attention, we can
    ignore it.  Fix by making sr_test_unit_ready() adjust the changed
    status.
    
    Reported-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
    Tested-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
    Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  8. @acpibob @gregkh

    ACPICA: Ignore ACPI table signature for Load() operator

    acpibob authored gregkh committed
    upstream bc45b1d
    
    Without this patch booting with acpi_osi="!Windows 2006" is required
    for several machines to function properly with cpufreq
    due to failure to load a Vista specific table with a bad signature.
    
    Only "SSDT" is acceptable to the ACPI spec, but tables are
    seen with OEMx and null sigs. Therefore, signature validation
    is worthless.  Apparently MS ACPI accepts such signatures, ACPICA
    must be compatible.
    
    http://bugzilla.kernel.org/show_bug.cgi?id=9919
    http://bugzilla.kernel.org/show_bug.cgi?id=10383
    http://bugzilla.kernel.org/show_bug.cgi?id=10454
    https://bugzilla.novell.com/show_bug.cgi?id=396311
    
    Signed-off-by: Bob Moore <robert.moore@intel.com>
    Signed-off-by: Lin Ming <ming.m.lin@intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  9. @mikechristie @gregkh

    scsi_host regression: fix scsi host leak

    mikechristie authored gregkh committed
    The patch is upstream as commit 3ed7897
    
    A different backport is necessary because of the class_device to device
    conversion post 2.6.25.
    
    
    commit 9c77010
    Author: Dave Young <hidave.darkstar@gmail.com>
    Date:   Tue Jan 22 14:01:34 2008 +0800
    
        scsi: use class iteration api
    
    Isn't a correct replacement for the original hand rolled host
    lookup. The problem is that class_find_child would get a reference to
    the host's class device which is never released.  Since the host class
    device holds a reference to the host gendev, the host can never be
    freed.
    
    In 2.6.25 we started using class_find_device, and this function also
    gets a reference to the device, so we end up with an extra ref
    and the host will not get released.
    
    This patch adds a class_put_device to balance the class_find_device()
    get. I kept the scsi_host_get in scsi_host_lookup, because the target
    layer is using scsi_host_lookup and it looks like it needs the SHOST_DEL
    check.
    
    Signed-off-by: Mike Christie <michaelc@cs.wisc.edu>
    Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  10. @gregkh

    b43: Fix possible NULL pointer dereference in DMA code

    Michael Buesch authored gregkh committed
    a cut-down version of commit 028118a upstream
    
    This fixes a possible NULL pointer dereference in an error path of the
    DMA allocation error checking code. In case the DMA allocation address is invalid,
    the dev pointer is dereferenced for unmapping of the buffer.
    
    Reported-by: Miles Lane <miles.lane@gmail.com>
    Signed-off-by: Michael Buesch <mb@bu3sch.de>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  11. @gregkh

    b43: Fix noise calculation WARN_ON

    Michael Buesch authored gregkh committed
    commit 98a3b2f upstream.
    
    This removes a WARN_ON that is responsible for the following koops:
    http://www.kerneloops.org/searchweek.php?search=b43_generate_noise_sample
    
    The comment in the patch describes why it's safe to simply remove
    the check.
    
    Signed-off-by: Michael Buesch <mb@bu3sch.de>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  12. @markmc @gregkh

    virtio_net: Fix skb->csum_start computation

    markmc authored gregkh committed
    commit 23cde76 upstream.
    
    hdr->csum_start is the offset from the start of the ethernet
    header to the transport layer checksum field. skb->csum_start
    is the offset from skb->head.
    
    skb_partial_csum_set() assumes that skb->data points to the
    ethernet header - i.e. it computes skb->csum_start by adding
    the headroom to hdr->csum_start.
    
    Since eth_type_trans() skb_pull()s the ethernet header,
    skb_partial_csum_set() should be called before
    eth_type_trans().
    
    (Without this patch, GSO packets from a guest to the world outside the
    host are corrupted).
    
    Signed-off-by: Mark McLoughlin <markmc@redhat.com>
    Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  13. @bzolnier @gregkh

    opti621: remove DMA support

    bzolnier authored gregkh committed
    commit f361037 upstream
    
    These controllers don't support DMA.
    
    Based on a bugreport from Juergen Kosel & inspired by pata_opti.c code.
    
    Tested-by: Juergen Kosel <juergen.kosel@gmx.de>
    Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
    Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  14. @bzolnier @gregkh

    opti621: disable read prefetch

    bzolnier authored gregkh committed
    commit 62128b2 upstream
    
    This fixes 2.6.25 regression (kernel.org bugzilla bug #10723) caused by:
    
    commit 912fb29
    Author: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
    Date:   Fri Oct 19 00:30:11 2007 +0200
    
        opti621: always tune PIO
    ...
    
    Based on a bugreport from Juergen Kosel & inspired by pata_opti.c code.
    
    Bisected-by: Juergen Kosel <juergen.kosel@gmx.de>
    Tested-by: Juergen Kosel <juergen.kosel@gmx.de>
    Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  15. @Alan-Cox @gregkh

    Fix tty speed handling on 8250

    Alan-Cox authored gregkh committed
    commit e991a2b upstream.
    
    We try and write the correct speed back but the serial midlayer already
    mangles the speed on us and that means if we request B0 we report back B9600
    when we should not.  For now we'll hack around this in the drivers and serial
    code, pending a better long term solution.
    
    Signed-off-by: Alan Cox <alan@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  16. @torvalds @gregkh

    x86-64: Fix "bytes left to copy" return value for copy_from_user()

    torvalds authored gregkh committed
    commit 42a886a upstream
    
    Most users by far do not care about the exact return value (they only
    really care about whether the copy succeeded in its entirety or not),
    but a few special core routines actually care deeply about exactly how
    many bytes were copied from user space.
    
    And the unrolled versions of the x86-64 user copy routines would
    sometimes report that it had copied more bytes than it actually had.
    
    Very few uses actually have partial copies to begin with, but to make
    this bug even harder to trigger, most x86 CPU's use the "rep string"
    instructions for normal user copies, and that version didn't have this
    issue.
    
    To make it even harder to hit, the one user of this that really cared
    about the return value (and used the uncached version of the copy that
    doesn't use the "rep string" instructions) was the generic write
    routine, which pre-populated its source, once more hiding the problem by
    avoiding the exception case that triggers the bug.
    
    In other words, very special thanks to Bron Gondwana who not only
    triggered this, but created a test-program to show it, and bisected the
    behavior down to commit 0829142 ("mm:
    fix pagecache write deadlocks") which changed the access pattern just
    enough that you can now trigger it with 'writev()' with multiple
    iovec's.
    
    That commit itself was not the cause of the bug, it just allowed all the
    stars to align just right that you could trigger the problem.
    
    [ Side note: this is just the minimal fix to make the copy routines
      (with __copy_from_user_inatomic_nocache as the particular version that
      was involved in showing this) have the right return values.
    
      We really should improve on the exceptional case further - to make the
      copy do a byte-accurate copy up to the exact page limit that causes it
      to fail.  As it is, the callers have to do extra work to handle the
      limit case gracefully. ]
    
    Reported-by: Bron Gondwana <brong@fastmail.fm>
    Cc: Nick Piggin <npiggin@suse.de>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Andi Kleen <andi@firstfloor.org>
    Cc: Al Viro <viro@ZenIV.linux.org.uk>
    Acked-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Commits on Jun 16, 2008
  1. @gregkh

    Linux 2.6.25.7

    gregkh authored
  2. @dcbw @gregkh

    mac80211: send association event on IBSS create

    dcbw authored gregkh committed
    patch 507b06d upstream
    
    Otherwise userspace has no idea the IBSS creation succeeded.
    
    Signed-off-by: Dan Williams <dcbw@redhat.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  3. @gregkh

    x86: fix recursive dependencies

    Roman Zippel authored gregkh committed
    commit 823c248 in mainline
    
    The proper dependency check uncovered a few dependency problems,
    the subarchitecture used a mixture of selects and depends on SMP
    and PCI dependency was messed up.
    
    Signed-off-by: Roman Zippel <zippel@linux-m68k.org>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Ravikiran Thirumalai <kiran@scalex86.org>
  4. @fenrus75 @gregkh

    bttv: Fix a deadlock in the bttv driver

    fenrus75 authored gregkh committed
    commit 81b2dbc in mainline.
    
    vidiocgmbuf() does this:
            mutex_lock(&fh->cap.vb_lock);
            retval = videobuf_mmap_setup(&fh->cap, gbuffers, gbufsize,
                                         V4L2_MEMORY_MMAP);
    
    and videobuf_mmap_setup() then just does
            mutex_lock(&q->vb_lock);
            ret = __videobuf_mmap_setup(q, bcount, bsize, memory);
            mutex_unlock(&q->vb_lock);
    
    which is an obvious double-take deadlock.
    
    This patch fixes this by having vidiocgmbuf() just call the
    __videobuf_mmap_setup function instead.
    
    Acked-by: Mauro Carvalho Chehab <mchehab@infradead.org>
    Reported-by: Koos Vriezen <koos.vriezen@gmail.com>
    Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  5. @gregkh

    Kconfig: introduce ARCH_DEFCONFIG to DEFCONFIG_LIST

    Sam Ravnborg authored gregkh committed
    commit 7353190 in mainline.
    
    init/Kconfig contains a list of configs that are searched
    for if 'make *config' are used with no .config present.
    Extend this list to look at the config identified by
    ARCH_DEFCONFIG.
    
    With this change we now try the defconfig targets last.
    
    This fixes a regression reported
    by: Linus Torvalds <torvalds@linux-foundation.org>
    
    Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  6. @fenrus75 @gregkh

    serial: fix enable_irq_wake/disable_irq_wake imbalance in serial_core.c

    fenrus75 authored gregkh committed
    commit 03a74dc in mainline.
    
    enable_irq_wake() and disable_irq_wake() need to be balanced.  However,
    serial_core.c calls these for different conditions during the suspend and
    resume functions...
    
    This is causing a regular WARN_ON() as found at
    http://www.kerneloops.org/search.php?search=set_irq_wake
    
    This patch makes the conditions for triggering the _wake enable/disable
    sequence identical.
    
    Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
    Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  7. @chriswright @gregkh

    CPUFREQ: Fix format string bug.

    chriswright authored gregkh committed
    commit 326f6a5 upstream
    
    Format string bug.  Not exploitable, as this is only writable by root,
    but worth fixing all the same.
    
    From: Chris Wright <chrisw@sous-sol.org>
    Spotted-by: Ilja van Sprundel <ilja@netric.org>
    Signed-off-by: Dave Jones <davej@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  8. @mslusarz @gregkh

    cifs: fix oops on mount when CONFIG_CIFS_DFS_UPCALL is enabled

    mslusarz authored gregkh committed
    simple "mount -t cifs //xxx /mnt" oopsed on strlen of options
    http://kerneloops.org/guilty.php?guilty=cifs_get_sb&version=2.6.25-release&start=16711 \
    68&end=1703935&class=oops
    
    Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
    Acked-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Steve French <sfrench@us.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  9. @kvaneesh @gregkh

    m68k: Add ext2_find_{first,next}_bit() for ext4

    kvaneesh authored gregkh committed
    commit 69c5ddf upstream
    
    Add ext2_find_{first,next}_bit(), which are needed for ext4.
    They're derived out of the ext2_find_next_zero_bit found in the same file.
    Compile tested with crosstools
    
    [Reworked to preserve all symmetry with ext2_find_{first,next}_zero_bit()]
    
    This fixes http://bugzilla.kernel.org/show_bug.cgi?id=10393
    
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  10. @gregkh

    IB/umem: Avoid sign problems when demoting npages to integer

    Roland Dreier authored gregkh committed
    commit 8079ffa upstream
    
    On a 64-bit architecture, if ib_umem_get() is called with a size value
    that is so big that npages is negative when cast to int, then the
    length of the page list passed to get_user_pages(), namely
    
    	min_t(int, npages, PAGE_SIZE / sizeof (struct page *))
    
    will be negative, and get_user_pages() will immediately return 0 (at
    least since 900cf08, "Be more robust about bad arguments in
    get_user_pages()").  This leads to an infinite loop in ib_umem_get(),
    since the code boils down to:
    
    	while (npages) {
    		ret = get_user_pages(...);
    		npages -= ret;
    	}
    
    Fix this by taking the minimum as unsigned longs, so that the value of
    npages is never truncated.
    
    The impact of this bug isn't too severe, since the value of npages is
    checked against RLIMIT_MEMLOCK, so a process would need to have an
    astronomical limit or have CAP_IPC_LOCK to be able to trigger this,
    and such a process could already cause lots of mischief.  But it does
    let buggy userspace code cause a kernel lock-up; for example I hit
    this with code that passes a negative value into a memory registartion
    function where it is promoted to a huge u64 value.
    
    Signed-off-by: Roland Dreier <rolandd@cisco.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  11. @gregkh

    tcp: Fix inconsistency source (CA_Open only when !tcp_left_out(tp))

    Ilpo Järvinen authored gregkh committed
    [ upstream commit: 8aca6cb ]
    
    It is possible that this skip path causes TCP to end up into an
    invalid state where ca_state was left to CA_Open while some
    segments already came into sacked_out. If next valid ACK doesn't
    contain new SACK information TCP fails to enter into
    tcp_fastretrans_alert(). Thus at least high_seq is set
    incorrectly to a too high seqno because some new data segments
    could be sent in between (and also, limited transmit is not
    being correctly invoked there). Reordering in both directions
    can easily cause this situation to occur.
    
    I guess we would want to use tcp_moderate_cwnd(tp) there as well
    as it may be possible to use this to trigger oversized burst to
    network by sending an old ACK with huge amount of SACK info, but
    I'm a bit unsure about its effects (mainly to FlightSize), so to
    be on the safe side I just currently fixed it minimally to keep
    TCP's state consistent (obviously, such nasty ACKs have been
    possible this far). Though it seems that FlightSize is already
    underestimated by some amount, so probably on the long term we
    might want to trigger recovery there too, if appropriate, to make
    FlightSize calculation to resemble reality at the time when the
    losses where discovered (but such change scares me too much now
    and requires some more thinking anyway how to do that as it
    likely involves some code shuffling).
    
    This bug was found by Brian Vowell while running my TCP debug
    patch to find cause of another TCP issue (fackets_out
    miscount).
    
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  12. @gregkh

    forcedeth: msi interrupts

    Ayaz Abdulla authored gregkh committed
    commit 4db0ee1 upstream
    
    Add a workaround for lost MSI interrupts.  There is a race condition in
    the HW in which future interrupts could be missed.  The workaround is to
    toggle the MSI irq mask.
    
    Added cleanup based on comments from Andrew Morton.
    
    Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>
    Cc: Manfred Spraul <manfred@colorfullife.com>
    Cc: Jeff Garzik <jeff@garzik.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  13. @gregkh

    hgafb: resource management fix

    Krzysztof Helt authored gregkh committed
    commit 630c270 upstream
    Date: Thu, 12 Jun 2008 15:21:29 -0700
    Subject: hgafb: resource management fix
    
    Release ports which are requested during detection which are not freed if
    there is no hga card.  Otherwise there is a crash during cat /proc/ioports
    command.
    
    Signed-off-by: Krzysztof Helt <krzysztof.h1@wp.pl>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  14. @mikem13 @gregkh

    cciss: add new hardware support

    mikem13 authored gregkh committed
    commit 24aac48 upstream
    Date: Thu, 12 Jun 2008 15:21:34 -0700
    Subject: cciss: add new hardware support
    
    Add support for the next generation of HP Smart Array SAS/SATA
    controllers.  Shipping date is late Fall 2008.
    
    Bump the driver version to 3.6.20 to reflect the new hardware support from
    patch 1 of this set.
    
    Signed-off-by: Mike Miller <mike.miller@hp.com>
    Cc: Jens Axboe <jens.axboe@oracle.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  15. @gregkh

    mmc: wbsd: initialize tasklets before requesting interrupt

    Chuck Ebbert authored gregkh committed
    commit cef3340 upstream
    
    With CONFIG_DEBUG_SHIRQ set we will get an interrupt as soon as we
    allocate one.  Tasklets may be scheduled in the interrupt handler but they
    will be initialized after the handler returns, causing a BUG() in
    kernel/softirq.c when they run.
    
    Should fix this Fedora bug report:
    https://bugzilla.redhat.com/show_bug.cgi?id=449817
    
    Signed-off-by: Chuck Ebbert <cebbert@redhat.com>
    Acked-by: Pierre Ossman <drzeus@drzeus.cx>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  16. @gregkh

    tcp FRTO: work-around inorder receivers

    Ilpo Järvinen authored gregkh committed
    [ upstream commit: 79d4451 ]
    
    If receiver consumes segments successfully only in-order, FRTO
    fallback to conventional recovery produces RTO loop because
    FRTO's forward transmissions will always get dropped and need to
    be resent, yet by default they're not marked as lost (which are
    the only segments we will retransmit in CA_Loss).
    
    Price to pay about this is occassionally unnecessarily
    retransmitting the forward transmission(s). SACK blocks help
    a bit to avoid this, so it's mainly a concern for NewReno case
    though SACK is not fully immune either.
    
    This change has a side-effect of fixing SACKFRTO problem where
    it didn't have snd_nxt of the RTO time available anymore when
    fallback become necessary (this problem would have only occured
    when RTO would occur for two or more segments and ECE arrives
    in step 3; no need to figure out how to fix that unless the
    TODO item of selective behavior is considered in future).
    
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
    Reported-by: Damon L. Chesser <damon@damtek.com>
    Tested-by: Damon L. Chesser <damon@damtek.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
  17. @gregkh

    tcp FRTO: SACK variant is errorneously used with NewReno

    Ilpo Järvinen authored gregkh committed
    [ upstream commit: 62ab222 ]
    
    Note: there's actually another bug in FRTO's SACK variant, which
    is the causing failure in NewReno case because of the error
    that's fixed here. I'll fix the SACK case separately (it's
    a separate bug really, though related, but in order to fix that
    I need to audit tp->snd_nxt usage a bit).
    
    There were two places where SACK variant of FRTO is getting
    incorrectly used even if SACK wasn't negotiated by the TCP flow.
    This leads to incorrect setting of frto_highmark with NewReno
    if a previous recovery was interrupted by another RTO.
    
    An eventual fallback to conventional recovery then incorrectly
    considers one or couple of segments as forward transmissions
    though they weren't, which then are not LOST marked during
    fallback making them "non-retransmittable" until the next RTO.
    In a bad case, those segments are really lost and are the only
    one left in the window. Thus TCP needs another RTO to continue.
    The next FRTO, however, could again repeat the same events
    making the progress of the TCP flow extremely slow.
    
    In order for these events to occur at all, FRTO must occur
    again in FRTOs step 3 while the key segments must be lost as
    well, which is not too likely in practice. It seems to most
    frequently with some small devices such as network printers
    that *seem* to accept TCP segments only in-order. In cases
    were key segments weren't lost, things get automatically
    resolved because those wrongly marked segments don't need to be
    retransmitted in order to continue.
    
    I found a reproducer after digging up relevant reports (few
    reports in total, none at netdev or lkml I know of), some
    cases seemed to indicate middlebox issues which seems now
    to be a false assumption some people had made. Bugzilla
    #10063 _might_ be related. Damon L. Chesser <damon@damtek.com>
    had a reproducable case and was kind enough to tcpdump it
    for me. With the tcpdump log it was quite trivial to figure
    out.
    
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
  18. @gregkh

    tcp FRTO: Fix fallback to conventional recovery

    Ilpo Järvinen authored gregkh committed
    [ upstream commit: a1c1f28 ]
    
    It seems that commit 009a2e3 ("[TCP] FRTO: Improve
    interoperability with other undo_marker users") run into
    another land-mine which caused fallback to conventional
    recovery to break:
    
    1. Cumulative ACK arrives after FRTO retransmission
    2. tcp_try_to_open sees zero retrans_out, clears retrans_stamp
       which should be kept like in CA_Loss state it would be
    3. undo_marker change allowed tcp_packet_delayed to return
       true because of the cleared retrans_stamp once FRTO is
       terminated causing LossUndo to occur, which means all loss
       markings FRTO made are reverted.
    
    This means that the conventional recovery basically recovered
    one loss per RTT, which is not that efficient. It was quite
    unobvious that the undo_marker change broken something like
    this, I had a quite long session to track it down because of
    the non-intuitiviness of the bug (luckily I had a trivial
    reproducer at hand and I was also able to learn to use kprobes
    in the process as well :-)).
    
    This together with the NewReno+FRTO fix and FRTO in-order
    workaround this fixes Damon's problems, this and the first
    mentioned are enough to fix Bugzilla #10063.
    
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
    Reported-by: Damon L. Chesser <damon@damtek.com>
    Tested-by: Damon L. Chesser <damon@damtek.com>
    Tested-by: Sebastian Hyrwall <zibbe@cisko.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
  19. @gregkh

    tcp: fix skb vs fack_count out-of-sync condition

    Ilpo Järvinen authored gregkh committed
    [ upstream commit: a660447 ]
    
    This bug is able to corrupt fackets_out in very rare cases.
    In order for this to cause corruption:
      1) DSACK in the middle of previous SACK block must be generated.
      2) In order to take that particular branch, part or all of the
         DSACKed segment must already be SACKed so that we have that
         in cache in the first place.
      3) The new info must be top enough so that fackets_out will be
         updated on this iteration.
    ...then fack_count is updated while skb wasn't, then we walk again
    that particular segment thus updating fack_count twice for
    a single skb and finally that value is assigned to fackets_out
    by tcp_sacktag_one.
    
    It is safe to call tcp_sacktag_one just once for a segment (at
    DSACK), no need to call again for plain SACK.
    
    Potential problem of the miscount are limited to premature entry
    to recovery and to inflated reordering metric (which could even
    cancel each other out in the most the luckiest scenarios :-)).
    Both are quite insignificant in worst case too and there exists
    also code to reset them (fackets_out once sacked_out becomes zero
    and reordering metric on RTO).
    
    This has been reported by a number of people, because it occurred
    quite rarely, it has been very evasive. Andy Furniss was able to
    get it to occur couple of times so that a bit more info was
    collected about the problem using a debug patch, though it still
    required lot of checking around. Thanks also to others who have
    tried to help here.
    
    This is listed as Bugzilla #10346. The bug was introduced by
    me in commit 68f8353 ([TCP]: Rewrite SACK block processing &
    sack_recv_cache use), I probably thought back then that there's
    need to scan that entry twice or didn't dare to make it go
    through it just once there. Going through twice would have
    required restoring fack_count after the walk but as noted above,
    I chose to drop the additional walk step altogether here.
    
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Something went wrong with that request. Please try again.