Skip to content
Commits on May 12, 2012
  1. Merge branch 'configs-3.3' into pf-3.3

    Oleksandr Natalenko committed May 12, 2012
  2. configs-3.3: update config for Dell Inspiron 1525 laptop

    Oleksandr Natalenko committed May 12, 2012
  3. fix merge conflict

    Oleksandr Natalenko committed May 12, 2012
  4. @gregkh

    Linux 3.3.6

    gregkh committed May 12, 2012
  5. @gregkh

    usb: gadget: udc-core: fix incompatibility with dummy-hcd

    commit 320cd1e upstream.
    
    This patch (as1548) fixes a recently-introduced incompatibility
    between the UDC core and the dummy-hcd driver.  Commit
    8ae8090 (usb: gadget: udc-core: fix
    asymmetric calls in remove_driver) moved the usb_gadget_udc_stop()
    call in usb_gadget_remove_driver() below the usb_gadget_disconnect()
    call.
    
    As a result, usb_gadget_disconnect() gets called at a time when the
    gadget driver believes it has been unbound but dummy-hcd believes
    it has not.  A nasty error ensues when dummy-hcd calls the gadget
    driver's disconnect method a second time.
    
    To fix the problem, this patch moves the gadget driver's unbind
    notification after the usb_gadget_disconnect() call.  Now nothing
    happens between the two unbind notifications, so nothing goes wrong.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Tested-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Alan Stern committed with gregkh Apr 26, 2012
  6. @gregkh

    usb: gadget: udc-core: fix wrong call order

    commit 83a787a upstream.
    
    commit 6d258a4 (usb: gadget: udc-core: stop UDC on device-initiated
    disconnect) introduced another case of asymmetric calls when issuing
    a device-initiated disconnect. Fix it.
    
    Reported-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Felipe Balbi committed with gregkh Apr 27, 2012
  7. @wildea01 @gregkh

    ARM: 7398/1: l2x0: only write to debug registers on PL310

    commit ab4d536 upstream.
    
    PL310 errata #588369 and #727915 require writes to the debug registers
    of the cache controller to work around known problems. Writing these
    registers on L220 may cause deadlock, so ensure that we only perform
    this operation when we identify a PL310 at probe time.
    
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    wildea01 committed with gregkh Apr 20, 2012
  8. @wildea01 @gregkh

    ARM: 7397/1: l2x0: only apply workaround for erratum #753970 on PL310

    commit f154fe9 upstream.
    
    The workaround for PL310 erratum #753970 can lead to deadlock on systems
    with an L220 cache controller.
    
    This patch makes the workaround effective only when the cache controller
    is identified as a PL310 at probe time.
    
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    wildea01 committed with gregkh Apr 20, 2012
  9. @gregkh

    nfsd: don't fail unchecked creates of non-special files

    commit 9dc4e6c upstream.
    
    Allow a v3 unchecked open of a non-regular file succeed as if it were a
    lookup; typically a client in such a case will want to fall back on a
    local open, so succeeding and giving it the filehandle is more useful
    than failing with nfserr_exist, which makes it appear that nothing at
    all exists by that name.
    
    Similarly for v4, on an open-create, return the same errors we would on
    an attempt to open a non-regular file, instead of returning
    nfserr_exist.
    
    This fixes a problem found doing a v4 open of a symlink with
    O_RDONLY|O_CREAT, which resulted in the current client returning EEXIST.
    
    Thanks also to Trond for analysis.
    
    Reported-by: Orion Poplawski <orion@cora.nwra.com>
    Tested-by: Orion Poplawski <orion@cora.nwra.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    [bwh: Backported to 3.2 and 3.3: use &resfh, not resfh]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    J. Bruce Fields committed with gregkh Apr 9, 2012
  10. @gregkh

    block: mtip32xx: remove HOTPLUG_PCI_PCIE dependancy

    commit 6363480 upstream.
    
    This removes the HOTPLUG_PCI_PCIE dependency on the driver and makes it
    depend on PCI.
    
    Cc: Sam Bradshaw <sbradshaw@micron.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Acked-by: Asai Thambi S P <asamymuthupa@micron.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    gregkh committed Apr 12, 2012
  11. @gregkh

    mtip32xx: fix error handling in mtip_init()

    commit 6d27f09 upstream.
    
    Ensure that block device is properly unregistered, if
    pci_register_driver() fails.
    
    Signed-off-by: Ryosuke Saito <raitosyo@gmail.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Ryosuke Saito committed with gregkh Apr 5, 2012
  12. @asaithambi @gregkh

    mtip32xx: fix incorrect value set for drv_cleanup_done, and re-initia…

    …lize and start port in mtip_restart_port()
    
    commit 22be2e6 upstream.
    
    This patch includes two changes:
    	* fix incorrect value set for drv_cleanup_done
    	* re-initialize and start port in mtip_restart_port()
    
    Signed-off-by: Asai Thambi S P <asamymuthupa@micron.com>
    Signed-off-by: Sam Bradshaw <sbradshaw@micron.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    asaithambi committed with gregkh Mar 23, 2012
  13. @dgibson @gregkh

    hugepages: fix use after free bug in "quota" handling

    commit 9048162 upstream.
    
    hugetlbfs_{get,put}_quota() are badly named.  They don't interact with the
    general quota handling code, and they don't much resemble its behaviour.
    Rather than being about maintaining limits on on-disk block usage by
    particular users, they are instead about maintaining limits on in-memory
    page usage (including anonymous MAP_PRIVATE copied-on-write pages)
    associated with a particular hugetlbfs filesystem instance.
    
    Worse, they work by having callbacks to the hugetlbfs filesystem code from
    the low-level page handling code, in particular from free_huge_page().
    This is a layering violation of itself, but more importantly, if the
    kernel does a get_user_pages() on hugepages (which can happen from KVM
    amongst others), then the free_huge_page() can be delayed until after the
    associated inode has already been freed.  If an unmount occurs at the
    wrong time, even the hugetlbfs superblock where the "quota" limits are
    stored may have been freed.
    
    Andrew Barry proposed a patch to fix this by having hugepages, instead of
    storing a pointer to their address_space and reaching the superblock from
    there, had the hugepages store pointers directly to the superblock,
    bumping the reference count as appropriate to avoid it being freed.
    Andrew Morton rejected that version, however, on the grounds that it made
    the existing layering violation worse.
    
    This is a reworked version of Andrew's patch, which removes the extra, and
    some of the existing, layering violation.  It works by introducing the
    concept of a hugepage "subpool" at the lower hugepage mm layer - that is a
    finite logical pool of hugepages to allocate from.  hugetlbfs now creates
    a subpool for each filesystem instance with a page limit set, and a
    pointer to the subpool gets added to each allocated hugepage, instead of
    the address_space pointer used now.  The subpool has its own lifetime and
    is only freed once all pages in it _and_ all other references to it (i.e.
    superblocks) are gone.
    
    subpools are optional - a NULL subpool pointer is taken by the code to
    mean that no subpool limits are in effect.
    
    Previous discussion of this bug found in:  "Fix refcounting in hugetlbfs
    quota handling.". See:  https://lkml.org/lkml/2011/8/11/28 or
    http://marc.info/?l=linux-mm&m=126928970510627&w=1
    
    v2: Fixed a bug spotted by Hillf Danton, and removed the extra parameter to
    alloc_huge_page() - since it already takes the vma, it is not necessary.
    
    Signed-off-by: Andrew Barry <abarry@cray.com>
    Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Minchan Kim <minchan.kim@gmail.com>
    Cc: Hillf Danton <dhillf@gmail.com>
    Cc: Paul Mackerras <paulus@samba.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@linuxfoundation.org>
    dgibson committed with gregkh Mar 21, 2012
  14. @gregkh

    sony-laptop: Enable keyboard backlight by default

    commit 6fe6ae5 upstream.
    
    When the keyboard backlight support was originally added, the commit said
    to default it to on with a 10 second timeout.  That actually wasn't the
    case, as the default value is commented out for the kbd_backlight parameter.
    Because it is a static variable, it gets set to 0 by default without some
    other form of initialization.
    
    However, it seems the function to set the value wasn't actually called
    immediately, so whatever state the keyboard was in initially would remain.
    Then commit df410d5 was introduced during the 2.6.39 timeframe to
    immediately set whatever value was present (as well as attempt to
    restore/reset the state on module removal or resume).  That seems to have
    now forced the light off immediately when the module is loaded unless
    the option kbd_backlight=1 is specified.
    
    Let's enable it by default again (for the first time).  This should solve
    https://bugzilla.redhat.com/show_bug.cgi?id=728478
    
    Signed-off-by: Josh Boyer <jwboyer@redhat.com>
    Acked-by: Mattia Dongili <malattia@linux.it>
    Signed-off-by: Matthew Garrett <mjg@redhat.com>
    Cc: maximilian attems <max@stro.at>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Josh Boyer committed with gregkh Nov 2, 2011
  15. @awilliam @gregkh

    KVM: lock slots_lock around device assignment

    (cherry picked from commit 21a1416)
    
    As pointed out by Jason Baron, when assigning a device to a guest
    we first set the iommu domain pointer, which enables mapping
    and unmapping of memory slots to the iommu.  This leaves a window
    where this path is enabled, but we haven't synchronized the iommu
    mappings to the existing memory slots.  Thus a slot being removed
    at that point could send us down unexpected code paths removing
    non-existent pinnings and iommu mappings.  Take the slots_lock
    around creating the iommu domain and initial mappings as well as
    around iommu teardown to avoid this race.
    
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    awilliam committed with gregkh May 9, 2012
  16. @gregkh

    KVM: VMX: Fix kvm_set_shared_msr() called in preemptible context

    (cherry picked from commit 2225fd5)
    
    kvm_set_shared_msr() may not be called in preemptible context,
    but vmx_set_msr() does so:
    
      BUG: using smp_processor_id() in preemptible [00000000] code: qemu-kvm/22713
      caller is kvm_set_shared_msr+0x32/0xa0 [kvm]
      Pid: 22713, comm: qemu-kvm Not tainted 3.4.0-rc3+ #39
      Call Trace:
       [<ffffffff8131fa82>] debug_smp_processor_id+0xe2/0x100
       [<ffffffffa0328ae2>] kvm_set_shared_msr+0x32/0xa0 [kvm]
       [<ffffffffa03a103b>] vmx_set_msr+0x28b/0x2d0 [kvm_intel]
       ...
    
    Making kvm_set_shared_msr() work in preemptible is cleaner, but
    it's used in the fast path.  Making two variants is overkill, so
    this patch just disables preemption around the call.
    
    Reported-by: Dave Jones <davej@redhat.com>
    Signed-off-by: Avi Kivity <avi@redhat.com>
    Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Avi Kivity committed with gregkh May 9, 2012
  17. @gregkh

    KVM: VMX: vmx_set_cr0 expects kvm->srcu locked

    (cherry picked from commit 7a4f5ad)
    
    vmx_set_cr0 is called from vcpu run context, therefore it expects
    kvm->srcu to be held (for setting up the real-mode TSS).
    
    Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
    Signed-off-by: Avi Kivity <avi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Marcelo Tosatti committed with gregkh May 9, 2012
  18. @gregkh

    KVM: nVMX: Fix erroneous exception bitmap check

    (cherry picked from commit 9587190)
    
    The code which checks whether to inject a pagefault to L1 or L2 (in
    nested VMX) was wrong, incorrect in how it checked the PF_VECTOR bit.
    Thanks to Dan Carpenter for spotting this.
    
    Signed-off-by: Nadav Har'El <nyh@il.ibm.com>
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Avi Kivity <avi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Nadav Har'El committed with gregkh May 9, 2012
  19. @gregkh

    KVM: VMX: Fix delayed load of shared MSRs

    (cherry picked from commit 9ee7397)
    
    Shared MSRs (MSR_*STAR and related) are stored in both vmx->guest_msrs
    and in the CPU registers, but vmx_set_msr() only updated memory. Prior
    to 46199f3, this didn't matter, since we called vmx_load_host_state(),
    which scheduled a vmx_save_host_state(), which re-synchronized the CPU
    state, but now we don't, so the CPU state will not be synchronized until
    the next exit to host userspace.  This mostly affects nested vmx workloads,
    which play with these MSRs a lot.
    
    Fix by loading the MSR eagerly.
    
    Signed-off-by: Avi Kivity <avi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Avi Kivity committed with gregkh May 9, 2012
  20. @gregkh

    KVM: Ensure all vcpus are consistent with in-kernel irqchip settings

    (cherry picked from commit 3e51570)
    
    If some vcpus are created before KVM_CREATE_IRQCHIP, then
    irqchip_in_kernel() and vcpu->arch.apic will be inconsistent, leading
    to potential NULL pointer dereferences.
    
    Fix by:
    - ensuring that no vcpus are installed when KVM_CREATE_IRQCHIP is called
    - ensuring that a vcpu has an apic if it is installed after KVM_CREATE_IRQCHIP
    
    This is somewhat long winded because vcpu->arch.apic is created without
    kvm->lock held.
    
    Based on earlier patch by Michael Ellerman.
    
    Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
    Signed-off-by: Avi Kivity <avi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Avi Kivity committed with gregkh May 9, 2012
  21. @gregkh

    KVM: x86 emulator: correctly mask pmc index bits in RDPMC instruction…

    … emulation
    
    (cherry picked from commit 270c6c7)
    
    
    Signed-off-by: Gleb Natapov <gleb@redhat.com>
    Signed-off-by: Avi Kivity <avi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Gleb Natapov committed with gregkh May 9, 2012
  22. @gregkh

    KVM: mmu_notifier: Flush TLBs before releasing mmu_lock

    (cherry picked from commit 565f3be)
    
    Other threads may process the same page in that small window and skip
    TLB flush and then return before these functions do flush.
    
    Signed-off-by: Takuya Yoshikawa <yoshikawa.takuya@oss.ntt.co.jp>
    Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
    Signed-off-by: Avi Kivity <avi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Takuya Yoshikawa committed with gregkh May 9, 2012
  23. @gregkh

    KVM: Fix write protection race during dirty logging

    (cherry picked from commit 6dbf79e)
    
    This patch fixes a race introduced by:
    
      commit 95d4c16
      KVM: Optimize dirty logging by rmap_write_protect()
    
    During protecting pages for dirty logging, other threads may also try
    to protect a page in mmu_sync_children() or kvm_mmu_get_page().
    
    In such a case, because get_dirty_log releases mmu_lock before flushing
    TLB's, the following race condition can happen:
    
      A (get_dirty_log)     B (another thread)
    
      lock(mmu_lock)
      clear pte.w
      unlock(mmu_lock)
                            lock(mmu_lock)
                            pte.w is already cleared
                            unlock(mmu_lock)
                            skip TLB flush
                            return
      ...
      TLB flush
    
    Though thread B assumes the page has already been protected when it
    returns, the remaining TLB entry will break that assumption.
    
    This patch fixes this problem by making get_dirty_log hold the mmu_lock
    until it flushes the TLB's.
    
    Signed-off-by: Takuya Yoshikawa <yoshikawa.takuya@oss.ntt.co.jp>
    Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
    Signed-off-by: Avi Kivity <avi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Takuya Yoshikawa committed with gregkh May 9, 2012
  24. @borntraeger @gregkh

    KVM: s390: Sanitize fpc registers for KVM_SET_FPU

    (cherry picked from commit 8517558)
    
    commit 7eef87d (KVM: s390: fix
    register setting) added a load of the floating point control register
    to the KVM_SET_FPU path. Lets make sure that the fpc is valid.
    
    Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
    Signed-off-by: Avi Kivity <avi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    borntraeger committed with gregkh May 9, 2012
  25. @gregkh

    KVM: s390: do store status after handling STOP_ON_STOP bit

    (cherry picked from commit 9e0d547)
    
    In handle_stop() handle the stop bit before doing the store status as
    described for "Stop and Store Status" in the Principles of Operation.
    We have to give up the local_int.lock before calling kvm store status
    since it calls gmap_fault() which might sleep. Since local_int.lock
    only protects local_int.* and not guest memory we can give up the lock.
    
    Signed-off-by: Jens Freimann <jfrei@linux.vnet.ibm.com>
    Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
    Signed-off-by: Avi Kivity <avi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Jens Freimann committed with gregkh May 9, 2012
  26. @gregkh

    net: Fix issue with netdev_tx_reset_queue not resetting queue from XO…

    …FF state
    
    [ Upstream commit 5c49035 ]
    
    We are seeing dev_watchdog hangs on several drivers.  I suspect this is due
    to the __QUEUE_STATE_STACK_XOFF bit being set prior to a reset for link
    change, and then not being cleared by netdev_tx_reset_queue.  This change
    corrects that.
    
    In addition we were seeing dev_watchdog hangs on igb after running the
    ethtool tests.  We found this to be due to the fact that the ethtool test
    runs the same logic as ndo_start_xmit, but we were never clearing the XOFF
    flag since the loopback test in ethtool does not do byte queue accounting.
    
    Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
    Tested-by: Stephen Ko <stephen.s.ko@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Alexander Duyck committed with gregkh Feb 7, 2012
  27. @gregkh

    net: Add memory barriers to prevent possible race in byte queue limits

    [ Upstream commit b37c0fb ]
    
    This change adds a memory barrier to the byte queue limit code to address a
    possible race as has been seen in the past with the
    netif_stop_queue/netif_wake_queue logic.
    
    Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
    Tested-by: Stephen Ko <stephen.s.ko@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Alexander Duyck committed with gregkh Feb 7, 2012
  28. @gregkh

    tcp: change tcp_adv_win_scale and tcp_rmem[2]

    [ Upstream commit b49960a ]
    
    tcp_adv_win_scale default value is 2, meaning we expect a good citizen
    skb to have skb->len / skb->truesize ratio of 75% (3/4)
    
    In 2.6 kernels we (mis)accounted for typical MSS=1460 frame :
    1536 + 64 + 256 = 1856 'estimated truesize', and 1856 * 3/4 = 1392.
    So these skbs were considered as not bloated.
    
    With recent truesize fixes, a typical MSS=1460 frame truesize is now the
    more precise :
    2048 + 256 = 2304. But 2304 * 3/4 = 1728.
    So these skb are not good citizen anymore, because 1460 < 1728
    
    (GRO can escape this problem because it build skbs with a too low
    truesize.)
    
    This also means tcp advertises a too optimistic window for a given
    allocated rcvspace : When receiving frames, sk_rmem_alloc can hit
    sk_rcvbuf limit and we call tcp_prune_queue()/tcp_collapse() too often,
    especially when application is slow to drain its receive queue or in
    case of losses (netperf is fast, scp is slow). This is a major latency
    source.
    
    We should adjust the len/truesize ratio to 50% instead of 75%
    
    This patch :
    
    1) changes tcp_adv_win_scale default to 1 instead of 2
    
    2) increase tcp_rmem[2] limit from 4MB to 6MB to take into account
    better truesize tracking and to allow autotuning tcp receive window to
    reach same value than before. Note that same amount of kernel memory is
    consumed compared to 2.6 kernels.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Neal Cardwell <ncardwell@google.com>
    Cc: Tom Herbert <therbert@google.com>
    Cc: Yuchung Cheng <ycheng@google.com>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Eric Dumazet committed with gregkh May 2, 2012
  29. @gregkh

    tcp: fix infinite cwnd in tcp_complete_cwr()

    [ Upstream commit 1cebce3 ]
    
    When the cwnd reduction is done, ssthresh may be infinite
    if TCP enters CWR via ECN or F-RTO. If cwnd is not undone, i.e.,
    undo_marker is set, tcp_complete_cwr() falsely set cwnd to the
    infinite ssthresh value. The correct operation is to keep cwnd
    intact because it has been updated in ECN or F-RTO.
    
    Signed-off-by: Yuchung Cheng <ycheng@google.com>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Yuchung Cheng committed with gregkh Apr 30, 2012
  30. @gregkh

    tg3: Avoid panic from reserved statblk field access

    [ Upstream commit f891ea1 ]
    
    When RSS is enabled, interrupt vector 0 does not receive any rx traffic.
    The rx producer index fields for vector 0's status block should be
    considered reserved in this case.  This patch changes the code to
    respect these reserved fields, which avoids a kernel panic when these
    fields take on non-zero values.
    
    Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
    Signed-off-by: Michael Chan <mchan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Matt Carlson committed with gregkh Apr 24, 2012
  31. @gerard @gregkh

    sungem: Fix WakeOnLan

    [ Upstream commit 5a8887d ]
    
    WakeOnLan was broken in this driver because gp->asleep_wol is a 1-bit
    bitfield and it was being assigned WAKE_MAGIC, which is (1 << 5).
    gp->asleep_wol remains 0 and the machine never wakes up.  Fixed by casting
    gp->wake_on_lan to bool.  Tested on an iBook G4.
    
    Signed-off-by: Gerard Lledo <gerard.lledo@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    gerard committed with gregkh Apr 28, 2012
  32. @gregkh

    sky2: fix receive length error in mixed non-VLAN/VLAN traffic

    [ Upstream commit e072b3f ]
    
    Bug: The VLAN bit of the MAC RX Status Word is unreliable in several older
    supported chips. Sometimes the VLAN bit is not set for valid VLAN packets
    and also sometimes the VLAN bit is set for non-VLAN packets that came after
    a VLAN packet. This results in a receive length error when VLAN hardware
    tagging is enabled.
    
    Fix: Variation on original fix proposed by Mirko.
    The VLAN information is decoded in the status loop, and can be
    applied to the received SKB there. This eliminates the need for the
    separate tag field in the interface data structure. The tag has to
    be copied and cleared if packet is copied. This version checked out
    with vlan and normal traffic.
    
    Note: vlan_tx_tag_present should be renamed vlan_tag_present, but that
    is outside scope of this.
    
    Reported-by: Mirko Lindner <mlindner@marvell.com>
    Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    stephen hemminger committed with gregkh Apr 30, 2012
  33. @gregkh

    sky2: propogate rx hash when packet is copied

    [ Upstream commit 3f42941 ]
    
    When a small packet is received, the driver copies it to a new skb to allow
    reusing the full size Rx buffer. The copy was propogating the checksum offload
    but not the receive hash information. The bug is impact was mostly harmless
    and therefore not observed until reviewing this area of code.
    
    Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    stephen hemminger committed with gregkh Apr 30, 2012
  34. @sashalevin @gregkh

    net: l2tp: unlock socket lock before returning from l2tp_ip_sendmsg

    [ Upstream commit 84768ed ]
    
    l2tp_ip_sendmsg could return without releasing socket lock, making it all the
    way to userspace, and generating the following warning:
    
    [  130.891594] ================================================
    [  130.894569] [ BUG: lock held when returning to user space! ]
    [  130.897257] 3.4.0-rc5-next-20120501-sasha #104 Tainted: G        W
    [  130.900336] ------------------------------------------------
    [  130.902996] trinity/8384 is leaving the kernel with locks still held!
    [  130.906106] 1 lock held by trinity/8384:
    [  130.907924]  #0:  (sk_lock-AF_INET){+.+.+.}, at: [<ffffffff82b9503f>] l2tp_ip_sendmsg+0x2f/0x550
    
    Introduced by commit 2f16270 ("l2tp: Fix locking in l2tp_ip.c").
    
    Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    sashalevin committed with gregkh May 2, 2012
Something went wrong with that request. Please try again.