Skip to content
Commits on Sep 14, 2012
  1. @gregkh

    Linux 3.5.4

    gregkh committed Sep 14, 2012
  2. @tettamanti @gregkh

    hwmon: (asus_atk0110) Add quirk for Asus M5A78L

    commit 43ca6cb upstream.
    
    The old interface is bugged and reads the wrong sensor when retrieving
    the reading for the chassis fan (it reads the CPU sensor); the new
    interface works fine.
    
    Reported-by: Göran Uddeborg <goeran@uddeborg.se>
    Tested-by: Göran Uddeborg <goeran@uddeborg.se>
    Signed-off-by: Luca Tettamanti <kronos.it@gmail.com>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    tettamanti committed with gregkh Aug 21, 2012
  3. @minipli @gregkh

    dccp: check ccid before dereferencing

    commit 276bdb8 upstream.
    
    ccid_hc_rx_getsockopt() and ccid_hc_tx_getsockopt() might be called with
    a NULL ccid pointer leading to a NULL pointer dereference. This could
    lead to a privilege escalation if the attacker is able to map page 0 and
    prepare it with a fake ccid_ops pointer.
    
    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Gerrit Renker <gerrit@erg.abdn.ac.uk>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    minipli committed with gregkh Aug 15, 2012
  4. @gregkh

    x86, microcode, AMD: Fix broken ucode patch size check

    commit 36bf50d upstream.
    
    This issue was recently observed on an AMD C-50 CPU where a patch of
    maximum size was applied.
    
    Commit be62adb ("x86, microcode, AMD: Simplify ucode verification")
    added current_size in get_matching_microcode(). This is calculated as
    size of the ucode patch + 8 (ie. size of the header). Later this is
    compared against the maximum possible ucode patch size for a CPU family.
    And of course this fails if the patch has already maximum size.
    
    Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com>
    Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
    Link: http://lkml.kernel.org/r/1344361461-10076-1-git-send-email-bp@amd64.org
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Andreas Herrmann committed with gregkh Jul 31, 2012
  5. @utrace @gregkh

    uprobes: Fix mmap_region()'s mm->mm_rb corruption if uprobe_mmap() fails

    commit c7a3a88 upstream.
    
    This patch fixes:
    
      https://bugzilla.redhat.com/show_bug.cgi?id=843640
    
    If mmap_region()->uprobe_mmap() fails, unmap_and_free_vma path
    does unmap_region() but does not remove the soon-to-be-freed vma
    from rb tree. Actually there are more problems but this is how
    William noticed this bug.
    
    Perhaps we could do do_munmap() + return in this case, but in
    fact it is simply wrong to abort if uprobe_mmap() fails. Until
    at least we move the !UPROBE_COPY_INSN code from
    install_breakpoint() to uprobe_register().
    
    For example, uprobe_mmap()->install_breakpoint() can fail if the
    probed insn is not supported (remember, uprobe_register()
    succeeds if nobody mmaps inode/offset), mmap() should not fail
    in this case.
    
    dup_mmap()->uprobe_mmap() is wrong too by the same reason,
    fork() can race with uprobe_register() and fail for no reason if
    it wins the race and does install_breakpoint() first.
    
    And, if nothing else, both mmap_region() and dup_mmap() return
    success if uprobe_mmap() fails. Change them to ignore the error
    code from uprobe_mmap().
    
    Reported-and-tested-by: William Cohen <wcohen@redhat.com>
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Acked-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
    Cc: Anton Arapov <anton@redhat.com>
    Cc: William Cohen <wcohen@redhat.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Link: http://lkml.kernel.org/r/20120819171042.GB26957@redhat.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    utrace committed with gregkh Aug 19, 2012
  6. @gregkh

    xen/pciback: Fix proper FLR steps.

    commit 80ba77d upstream.
    
    When we do FLR and save PCI config we did it in the wrong order.
    The end result was that if a PCI device was unbind from
    its driver, then binded to xen-pciback, and then back to its
    driver we would get:
    
    > lspci -s 04:00.0
    04:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
    13:42:12 # 4 :~/
    > echo "0000:04:00.0" > /sys/bus/pci/drivers/pciback/unbind
    > modprobe e1000e
    e1000e: Intel(R) PRO/1000 Network Driver - 2.0.0-k
    e1000e: Copyright(c) 1999 - 2012 Intel Corporation.
    e1000e 0000:04:00.0: Disabling ASPM L0s L1
    e1000e 0000:04:00.0: enabling device (0000 -> 0002)
    xen: registering gsi 48 triggering 0 polarity 1
    Already setup the GSI :48
    e1000e 0000:04:00.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
    e1000e: probe of 0000:04:00.0 failed with error -2
    
    This fixes it by first saving the PCI configuration space, then
    doing the FLR.
    
    Reported-by: Ren, Yongjie <yongjie.ren@intel.com>
    Reported-and-Tested-by: Tobias Geiger <tobias.geiger@vido.info>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Konrad Rzeszutek Wilk committed with gregkh Sep 5, 2012
  7. @gregkh

    xen/p2m: Fix one-off error in checking the P2M tree directory.

    commit 50e9004 upstream.
    
    We would traverse the full P2M top directory (from 0->MAX_DOMAIN_PAGES
    inclusive) when trying to figure out whether we can re-use some of the
    P2M middle leafs.
    
    Which meant that if the kernel was compiled with MAX_DOMAIN_PAGES=512
    we would try to use the 512th entry. Fortunately for us the p2m_top_index
    has a check for this:
    
     BUG_ON(pfn >= MAX_P2M_PFN);
    
    which we hit and saw this:
    
    (XEN) domain_crash_sync called from entry.S
    (XEN) Domain 0 (vcpu#0) crashed on cpu#0:
    (XEN) ----[ Xen-4.1.2-OVM  x86_64  debug=n  Tainted:    C ]----
    (XEN) CPU:    0
    (XEN) RIP:    e033:[<ffffffff819cadeb>]
    (XEN) RFLAGS: 0000000000000212   EM: 1   CONTEXT: pv guest
    (XEN) rax: ffffffff81db5000   rbx: ffffffff81db4000   rcx: 0000000000000000
    (XEN) rdx: 0000000000480211   rsi: 0000000000000000   rdi: ffffffff81db4000
    (XEN) rbp: ffffffff81793db8   rsp: ffffffff81793d38   r8:  0000000008000000
    (XEN) r9:  4000000000000000   r10: 0000000000000000   r11: ffffffff81db7000
    (XEN) r12: 0000000000000ff8   r13: ffffffff81df1ff8   r14: ffffffff81db6000
    (XEN) r15: 0000000000000ff8   cr0: 000000008005003b   cr4: 00000000000026f0
    (XEN) cr3: 0000000661795000   cr2: 0000000000000000
    
    Fixes-Oracle-Bug: 14570662
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Konrad Rzeszutek Wilk committed with gregkh Sep 4, 2012
  8. @gregkh

    xen: Use correct masking in xen_swiotlb_alloc_coherent.

    commit b5031ed upstream.
    
    When running 32-bit pvops-dom0 and a driver tries to allocate a coherent
    DMA-memory the xen swiotlb-implementation returned memory beyond 4GB.
    
    The underlaying reason is that if the supplied driver passes in a
    DMA_BIT_MASK(64) ( hwdev->coherent_dma_mask is set to 0xffffffffffffffff)
    our dma_mask will be u64 set to 0xffffffffffffffff even if we set it to
    DMA_BIT_MASK(32) previously. Meaning we do not reset the upper bits.
    By using the dma_alloc_coherent_mask function - it does the proper casting
    and we get 0xfffffffff.
    
    This caused not working sound on a system with 4 GB and a 64-bit
    compatible sound-card with sets the DMA-mask to 64bit.
    
    On bare-metal and the forward-ported xen-dom0 patches from OpenSuse a coherent
    DMA-memory is always allocated inside the 32-bit address-range by calling
    dma_alloc_coherent_mask.
    
    This patch adds the same functionality to xen swiotlb and is a rebase of the
    original patch from Ronny Hegewald which never got upstream b/c the
    underlaying reason was not understood until now.
    
    The original email with the original patch is in:
    http://old-list-archives.xen.org/archives/html/xen-devel/2010-02/msg00038.html
    the original thread from where the discussion started is in:
    http://old-list-archives.xen.org/archives/html/xen-devel/2010-01/msg00928.html
    
    Signed-off-by: Ronny Hegewald <ronny.hegewald@online.de>
    Signed-off-by: Stefano Panella <stefano.panella@citrix.com>
    Acked-By: David Vrabel <david.vrabel@citrix.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Ronny Hegewald committed with gregkh Aug 31, 2012
  9. @gregkh

    PARISC: Redefine ATOMIC_INIT and ATOMIC64_INIT to drop the casts

    commit bba3d8c upstream.
    
    The following build error occured during a parisc build with
    swap-over-NFS patches applied.
    
    net/core/sock.c:274:36: error: initializer element is not constant
    net/core/sock.c:274:36: error: (near initialization for 'memalloc_socks')
    net/core/sock.c:274:36: error: initializer element is not constant
    
    Dave Anglin says:
    > Here is the line in sock.i:
    >
    > struct static_key memalloc_socks = ((struct static_key) { .enabled =
    > ((atomic_t) { (0) }) });
    
    The above line contains two compound literals.  It also uses a designated
    initializer to initialize the field enabled.  A compound literal is not a
    constant expression.
    
    The location of the above statement isn't fully clear, but if a compound
    literal occurs outside the body of a function, the initializer list must
    consist of constant expressions.
    
    Reported-by: Fengguang Wu <fengguang.wu@intel.com>
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Mel Gorman committed with gregkh Jul 23, 2012
  10. @bwallan @gregkh

    e1000e: DoS while TSO enabled caused by link partner with small MSS

    commit d821a4c upstream.
    
    With a low enough MSS on the link partner and TSO enabled locally, the
    networking stack can periodically send a very large (e.g.  64KB) TCP
    message for which the driver will attempt to use more Tx descriptors than
    are available by default in the Tx ring.  This is due to a workaround in
    the code that imposes a limit of only 4 MSS-sized segments per descriptor
    which appears to be a carry-over from the older e1000 driver and may be
    applicable only to some older PCI or PCIx parts which are not supported in
    e1000e.  When the driver gets a message that is too large to fit across the
    configured number of Tx descriptors, it stops the upper stack from queueing
    any more and gets stuck in this state.  After a timeout, the upper stack
    assumes the adapter is hung and calls the driver to reset it.
    
    Remove the unnecessary limitation of using up to only 4 MSS-sized segments
    per Tx descriptor, and put in a hard failure test to catch when attempting
    to check for message sizes larger than would fit in the whole Tx ring.
    Refactor the remaining logic that limits the size of data per Tx descriptor
    from a seemingly arbitrary 8KB to a limit based on the dynamic size of the
    Tx packet buffer as described in the hardware specification.
    
    Also, fix the logic in the check for space in the Tx ring for the next
    largest possible packet after the current one has been successfully queued
    for transmit, and use the appropriate defines for default ring sizes in
    e1000_probe instead of magic values.
    
    This issue goes back to the introduction of e1000e in 2.6.24 when it was
    split off from e1000.
    
    Reported-by: Ben Hutchings <bhutchings@solarflare.com>
    Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
    Tested-by: Aaron Brown <aaron.f.brown@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    bwallan committed with gregkh Aug 24, 2012
  11. @notaz @gregkh

    OMAPFB: fix framebuffer console colors

    commit c1c5284 upstream.
    
    omapfb does not currently set pseudo palette correctly for color depths
    above 16bpp, making red text invisible, command like
      echo -e '\e[0;31mRED' > /dev/tty1
    will display nothing on framebuffer console in 24bpp mode.
    This is because temporary variable is declared incorrectly, fix it.
    
    Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    notaz committed with gregkh Aug 21, 2012
  12. @gregkh

    drm/vmwgfx: add MODULE_DEVICE_TABLE so vmwgfx loads at boot

    commit c490342 upstream.
    
    This will cause udev to load vmwgfx instead of waiting for X
    to do it.
    
    Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Dave Airlie committed with gregkh Aug 28, 2012
  13. @dedekind @gregkh

    UBI: fix a horrible memory deallocation bug

    commit 78b495c upstream.
    
    UBI was mistakingly using 'kfree()' instead of 'kmem_cache_free()' when
    freeing "attach eraseblock" structures in vtbl.c. Thankfully, this happened
    only when we were doing auto-format, so many systems were unaffected. However,
    there are still many users affected.
    
    It is strange, but the system did not crash and nothing bad happened when
    the SLUB memory allocator was used. However, in case of SLOB we observed an
    crash right away.
    
    This problem was introduced in 2.6.39 by commit
    "6c1e875 UBI: add slab cache for ubi_scan_leb objects"
    
    A note for stable trees:
      Because variable were renamed, this won't cleanly apply to older kernels.
      Changing names like this should help:
    	1. ai -> si
    	2. aeb_slab_cache -> seb_slab_cache
    	3. new_aeb -> new_seb
    
    Reported-by: Richard Genoud <richard.genoud@gmail.com>
    Tested-by: Richard Genoud <richard.genoud@gmail.com>
    Tested-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    dedekind committed with gregkh Sep 3, 2012
  14. @dtor @gregkh

    Input: i8042 - add Gigabyte T1005 series netbooks to noloop table

    commit 7b125b9 upstream.
    
    They all define their chassis type as "Other" and therefore are not
    categorized as "laptops" by the driver, which tries to perform AUX IRQ
    delivery test which fails and causes touchpad not working.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42620
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    dtor committed with gregkh Aug 21, 2012
  15. @gregkh

    HID: add NOGET quirk for Eaton Ellipse MAX UPS

    commit 67ddbb3 upstream.
    
    This patch (as1603) adds a NOGET quirk for the Eaton Ellipse MAX UPS
    device.  (The USB IDs were already present in hid-ids.h, apparently
    under a different name.)
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-by: Laurent Bigonville <l.bigonville@edpnet.be>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Alan Stern committed with gregkh Aug 23, 2012
  16. @gregkh

    i2c-i801: Add Device IDs for Intel Lynx Point-LP PCH

    commit 4a8f1dd upstream.
    
    Add the SMBus Device IDs for the Intel Lynx Point-LP PCH.
    
    Signed-off-by: James Ralston <james.d.ralston@intel.com>
    Signed-off-by: Jean Delvare <khali@linux-fr.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    James Ralston committed with gregkh Sep 10, 2012
  17. @AxelLin @gregkh

    i2c-designware: Fix build error if CONFIG_I2C_DESIGNWARE_PLATFORM=y &…

    …& CONFIG_I2C_DESIGNWARE_PCI=y
    
    commit e68bb91 upstream.
    
    This patch adds config I2C_DESIGNWARE_CORE in Kconfig, and let
    I2C_DESIGNWARE_PLATFORM and I2C_DESIGNWARE_PCI select I2C_DESIGNWARE_CORE.
    
    Because both I2C_DESIGNWARE_PLATFORM and I2C_DESIGNWARE_PCI can be built as
    built-in or module, we also need to export the functions in i2c-designware-core.
    
    This fixes below build error when CONFIG_I2C_DESIGNWARE_PLATFORM=y &&
    CONFIG_I2C_DESIGNWARE_PCI=y:
    
      LD      drivers/i2c/busses/built-in.o
    drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_clear_int':
    i2c-designware-core.c:(.text+0xa10): multiple definition of `i2c_dw_clear_int'
    drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x928): first defined here
    drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_init':
    i2c-designware-core.c:(.text+0x178): multiple definition of `i2c_dw_init'
    drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x90): first defined here
    drivers/i2c/busses/i2c-designware-pci.o: In function `dw_readl':
    i2c-designware-core.c:(.text+0xe8): multiple definition of `dw_readl'
    drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x0): first defined here
    drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_isr':
    i2c-designware-core.c:(.text+0x724): multiple definition of `i2c_dw_isr'
    drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x63c): first defined here
    drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_xfer':
    i2c-designware-core.c:(.text+0x4b0): multiple definition of `i2c_dw_xfer'
    drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x3c8): first defined here
    drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_is_enabled':
    i2c-designware-core.c:(.text+0x9d4): multiple definition of `i2c_dw_is_enabled'
    drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x8ec): first defined here
    drivers/i2c/busses/i2c-designware-pci.o: In function `dw_writel':
    i2c-designware-core.c:(.text+0x124): multiple definition of `dw_writel'
    drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x3c): first defined here
    drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_xfer_msg':
    i2c-designware-core.c:(.text+0x2e8): multiple definition of `i2c_dw_xfer_msg'
    drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x200): first defined here
    drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_enable':
    i2c-designware-core.c:(.text+0x9c8): multiple definition of `i2c_dw_enable'
    drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x8e0): first defined here
    drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_read_comp_param':
    i2c-designware-core.c:(.text+0xa24): multiple definition of `i2c_dw_read_comp_param'
    drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x93c): first defined here
    drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_disable':
    i2c-designware-core.c:(.text+0x9dc): multiple definition of `i2c_dw_disable'
    drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x8f4): first defined here
    drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_func':
    i2c-designware-core.c:(.text+0x710): multiple definition of `i2c_dw_func'
    drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x628): first defined here
    drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_disable_int':
    i2c-designware-core.c:(.text+0xa18): multiple definition of `i2c_dw_disable_int'
    drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x930): first defined here
    make[3]: *** [drivers/i2c/busses/built-in.o] Error 1
    make[2]: *** [drivers/i2c/busses] Error 2
    make[1]: *** [drivers/i2c] Error 2
    make: *** [drivers] Error 2
    
    Signed-off-by: Axel Lin <axel.lin@gmail.com>
    Signed-off-by: Jean Delvare <khali@linux-fr.org>
    Tested-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    AxelLin committed with gregkh Sep 10, 2012
  18. @gregkh

    fuse: fix retrieve length

    commit c9e67d4 upstream.
    
    In some cases fuse_retrieve() would return a short byte count if offset was
    non-zero.  The data returned was correct, though.
    
    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Miklos Szeredi committed with gregkh Sep 4, 2012
  19. @jankara @gregkh

    ext3: Fix fdatasync() for files with only i_size changes

    commit 156bddd upstream.
    
    Code tracking when transaction needs to be committed on fdatasync(2) forgets
    to handle a situation when only inode's i_size is changed. Thus in such
    situations fdatasync(2) doesn't force transaction with new i_size to disk
    and that can result in wrong i_size after a crash.
    
    Fix the issue by updating inode's i_datasync_tid whenever its size is
    updated.
    
    Reported-by: Kristian Nielsen <knielsen@knielsen-hq.org>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    jankara committed with gregkh Sep 3, 2012
  20. @jankara @gregkh

    udf: Fix data corruption for files in ICB

    commit 9c2fc0d upstream.
    
    When a file is stored in ICB (inode), we overwrite part of the file, and
    the page containing file's data is not in page cache, we end up corrupting
    file's data by overwriting them with zeros. The problem is we use
    simple_write_begin() which simply zeroes parts of the page which are not
    written to. The problem has been introduced by be021ee (udf: convert to
    new aops).
    
    Fix the problem by providing a ->write_begin function which makes the page
    properly uptodate.
    
    Reported-by: Ian Abbott <abbotti@mev.co.uk>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    jankara committed with gregkh Sep 5, 2012
  21. @gregkh

    SCSI: Fix 'Device not ready' issue on mpt2sas

    commit 1421656 upstream.
    
    This is a particularly nasty SCSI ATA Translation Layer (SATL) problem.
    
    SAT-2 says (section 8.12.2)
    
            if the device is in the stopped state as the result of
            processing a START STOP UNIT command (see 9.11), then the SATL
            shall terminate the TEST UNIT READY command with CHECK CONDITION
            status with the sense key set to NOT READY and the additional
            sense code of LOGICAL UNIT NOT READY, INITIALIZING COMMAND
            REQUIRED;
    
    mpt2sas internal SATL seems to implement this.  The result is very confusing
    standby behaviour (using hdparm -y).  If you suspend a drive and then send
    another command, usually it wakes up.  However, if the next command is a TEST
    UNIT READY, the SATL sees that the drive is suspended and proceeds to follow
    the SATL rules for this, returning NOT READY to all subsequent commands.  This
    means that the ordering of TEST UNIT READY is crucial: if you send TUR and
    then a command, you get a NOT READY to both back.  If you send a command and
    then a TUR, you get GOOD status because the preceeding command woke the drive.
    
    This bit us badly because
    
    commit 85ef06d
    Author: Tejun Heo <tj@kernel.org>
    Date:   Fri Jul 1 16:17:47 2011 +0200
    
        block: flush MEDIA_CHANGE from drivers on close(2)
    
    Changed our ordering on TEST UNIT READY commands meaning that SATA drives
    connected to an mpt2sas now suspend and refuse to wake (because the mpt2sas
    SATL sees the suspend *before* the drives get awoken by the next ATA command)
    resulting in lots of failed commands.
    
    The standard is completely nuts forcing this inconsistent behaviour, but we
    have to work around it.
    
    The fix for this is twofold:
    
       1. Set the allow_restart flag so we wake the drive when we see it has been
          suspended
    
       2. Return all TEST UNIT READY status directly to the mid layer without any
          further error handling which prevents us causing error handling which
          may offline the device just because of a media check TUR.
    
    Reported-by: Matthias Prager <linux@matthiasprager.de>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    James Bottomley committed with gregkh Jul 25, 2012
  22. @gregkh

    SCSI: mpt2sas: Fix for Driver oops, when loading driver with max_queu…

    …e_depth command line option to a very small value
    
    commit 338b131 upstream.
    
    If the specified max_queue_depth setting is less than the
    expected number of internal commands, then driver will calculate
    the queue depth size to a negitive number. This negitive number
    is actually a very large number because variable is unsigned
    16bit integer. So, the driver will ask for a very large amount of
    memory for message frames and resulting into oops as memory
    allocation routines will not able to handle such a large request.
    
    So, in order to limit this kind of oops, The driver need to set
    the max_queue_depth to a scsi mid layer's can_queue value. Then
    the overall message frames required for IO is minimum of either
    (max_queue_depth plus internal commands) or the IOC global
    credits.
    
    Signed-off-by: Sreekanth Reddy <sreekanth.reddy@lsi.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    sreekanth.reddy@lsi.com committed with gregkh Jul 17, 2012
  23. @snitm @gregkh

    SCSI: scsi_lib: fix scsi_io_completion's SG_IO error propagation

    commit 27c4197 upstream.
    
    The following v3.4-rc1 commit unmasked an existing bug in scsi_io_completion's
    SG_IO error handling: 47ac56d [SCSI] scsi_error: classify some ILLEGAL_REQUEST
    sense as a permanent TARGET_ERROR
    
    Given that certain ILLEGAL_REQUEST are now properly categorized as
    TARGET_ERROR the host_byte is being set (before host_byte wasn't ever
    set for these ILLEGAL_REQUEST).
    
    In scsi_io_completion, initialize req->errors with cmd->result _after_
    the SG_IO block that calls __scsi_error_from_host_byte (which may
    modify the host_byte).
    
    Before this fix:
    
        cdb to send: 12 01 01 00 00 00
    ioctl(3, SG_IO, {'S', SG_DXFER_NONE, cmd[6]=[12, 01, 01, 00, 00, 00],
        mx_sb_len=32, iovec_count=0, dxfer_len=0, timeout=20000, flags=0,
        status=02, masked_status=01, sb[19]=[70, 00, 05, 00, 00, 00, 00, 0b,
        00, 00, 00, 00, 24, 00, 00, 00, 00, 00, 00], host_status=0x10,
        driver_status=0x8, resid=0, duration=0, info=0x1}) = 0
    SCSI Status: Check Condition
    
    Sense Information:
    sense buffer empty
    
    After:
    
        cdb to send: 12 01 01 00 00 00
    ioctl(3, SG_IO, {'S', SG_DXFER_NONE, cmd[6]=[12, 01, 01, 00, 00, 00],
        mx_sb_len=32, iovec_count=0, dxfer_len=0, timeout=20000, flags=0,
        status=02, masked_status=01, sb[19]=[70, 00, 05, 00, 00, 00, 00, 0b,
        00, 00, 00, 00, 24, 00, 00, 00, 00, 00, 00], host_status=0,
        driver_status=0x8, resid=0, duration=0, info=0x1}) = 0
    SCSI Status: Check Condition
    
    Sense Information:
     Fixed format, current;  Sense key: Illegal Request
     Additional sense: Invalid field in cdb
     Raw sense data (in hex):
            70 00 05 00 00 00 00 0b  00 00 00 00 24 00 00 00
            00 00 00
    
    Reported-by: Paolo Bonzini <pbonzini@redhat.com>
    Tested-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Reviewed-by: Babu Moger <babu.moger@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    snitm committed with gregkh May 31, 2012
  24. @gregkh

    SCSI: megaraid_sas: Move poll_aen_lock initializer

    commit bd8d6dd upstream.
    
    The following patch moves the poll_aen_lock initializer from
    megasas_probe_one() to megasas_init().  This prevents a crash when a user
    loads the driver and tries to issue a poll() system call on the ioctl
    interface with no adapters present.
    
    Signed-off-by: Kashyap Desai <Kashyap.Desai@lsi.com>
    Signed-off-by: Adam Radford <aradford@gmail.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Kashyap Desai committed with gregkh Jul 17, 2012
  25. @gregkh

    usbnet: fix deadlock in resume

    commit ab6f148 upstream.
    
    A usbnet device can share a multifunction device
    with a storage device. If the storage device is autoresumed
    the usbnet devices also needs to be autoresumed. Allocating
    memory with GFP_KERNEL can deadlock in this case.
    
    This should go back into all kernels that have
    commit 65841fd
    That is 3.5
    
    Signed-off-by: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Oliver Neukum committed with gregkh Aug 26, 2012
  26. @gregkh

    Fix order of arguments to compat_put_time[spec|val]

    commit ed6fe9d upstream.
    
    Commit 644595f ("compat: Handle COMPAT_USE_64BIT_TIME in
    net/socket.c") introduced a bug where the helper functions to take
    either a 64-bit or compat time[spec|val] got the arguments in the wrong
    order, passing the kernel stack pointer off as a user pointer (and vice
    versa).
    
    Because of the user address range check, that in turn then causes an
    EFAULT due to the user pointer range checking failing for the kernel
    address.  Incorrectly resuling in a failed system call for 32-bit
    processes with a 64-bit kernel.
    
    On odder architectures like HP-PA (with separate user/kernel address
    spaces), it can be used read kernel memory.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Mikulas Patocka committed with gregkh Sep 1, 2012
  27. @kernelslacker @gregkh

    Remove user-triggerable BUG from mpol_to_str

    commit 80de7c3 upstream.
    
    Trivially triggerable, found by trinity:
    
      kernel BUG at mm/mempolicy.c:2546!
      Process trinity-child2 (pid: 23988, threadinfo ffff88010197e000, task ffff88007821a670)
      Call Trace:
        show_numa_map+0xd5/0x450
        show_pid_numa_map+0x13/0x20
        traverse+0xf2/0x230
        seq_read+0x34b/0x3e0
        vfs_read+0xac/0x180
        sys_pread64+0xa2/0xc0
        system_call_fastpath+0x1a/0x1f
      RIP: mpol_to_str+0x156/0x360
    
    Signed-off-by: Dave Jones <davej@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    kernelslacker committed with gregkh Sep 6, 2012
  28. @paulusmack @gregkh

    powerpc: Make sure IPI handlers see data written by IPI senders

    commit 9fb1b36 upstream.
    
    We have been observing hangs, both of KVM guest vcpu tasks and more
    generally, where a process that is woken doesn't properly wake up and
    continue to run, but instead sticks in TASK_WAKING state.  This
    happens because the update of rq->wake_list in ttwu_queue_remote()
    is not ordered with the update of ipi_message in
    smp_muxed_ipi_message_pass(), and the reading of rq->wake_list in
    scheduler_ipi() is not ordered with the reading of ipi_message in
    smp_ipi_demux().  Thus it is possible for the IPI receiver not to see
    the updated rq->wake_list and therefore conclude that there is nothing
    for it to do.
    
    In order to make sure that anything done before smp_send_reschedule()
    is ordered before anything done in the resulting call to scheduler_ipi(),
    this adds barriers in smp_muxed_message_pass() and smp_ipi_demux().
    The barrier in smp_muxed_message_pass() is a full barrier to ensure that
    there is a full ordering between the smp_send_reschedule() caller and
    scheduler_ipi().  In smp_ipi_demux(), we use xchg() rather than
    xchg_local() because xchg() includes release and acquire barriers.
    Using xchg() rather than xchg_local() makes sense given that
    ipi_message is not just accessed locally.
    
    This moves the barrier between setting the message and calling the
    cause_ipi() function into the individual cause_ipi implementations.
    Most of them -- those that used outb, out_8 or similar -- already had
    a full barrier because out_8 etc. include a sync before the MMIO
    store.  This adds an explicit barrier in the two remaining cases.
    
    These changes made no measurable difference to the speed of IPIs as
    measured using a simple ping-pong latency test across two CPUs on
    different cores of a POWER7 machine.
    
    The analysis of the reason why processes were not waking up properly
    is due to Milton Miller.
    
    Reported-by: Milton Miller <miltonm@bga.com>
    Signed-off-by: Paul Mackerras <paulus@samba.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    paulusmack committed with gregkh Sep 4, 2012
  29. @antonblanchard @gregkh

    powerpc: Restore correct DSCR in context switch

    commit 7143328 upstream.
    
    During a context switch we always restore the per thread DSCR value.
    If we aren't doing explicit DSCR management
    (ie thread.dscr_inherit == 0) and the default DSCR changed while
    the process has been sleeping we end up with the wrong value.
    
    Check thread.dscr_inherit and select the default DSCR or per thread
    DSCR as required.
    
    This was found with the following test case, when running with
    more threads than CPUs (ie forcing context switching):
    
    http://ozlabs.org/~anton/junkcode/dscr_default_test.c
    
    With the four patches applied I can run a combination of all
    test cases successfully at the same time:
    
    http://ozlabs.org/~anton/junkcode/dscr_default_test.c
    http://ozlabs.org/~anton/junkcode/dscr_explicit_test.c
    http://ozlabs.org/~anton/junkcode/dscr_inherit_test.c
    
    Signed-off-by: Anton Blanchard <anton@samba.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    antonblanchard committed with gregkh Sep 3, 2012
  30. @antonblanchard @gregkh

    powerpc: Fix DSCR inheritance in copy_thread()

    commit 1021cb2 upstream.
    
    If the default DSCR is non zero we set thread.dscr_inherit in
    copy_thread() meaning the new thread and all its children will ignore
    future updates to the default DSCR. This is not intended and is
    a change in behaviour that a number of our users have hit.
    
    We just need to inherit thread.dscr and thread.dscr_inherit from
    the parent which ends up being much simpler.
    
    This was found with the following test case:
    
    http://ozlabs.org/~anton/junkcode/dscr_default_test.c
    
    Signed-off-by: Anton Blanchard <anton@samba.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    antonblanchard committed with gregkh Sep 3, 2012
  31. @antonblanchard @gregkh

    powerpc: Keep thread.dscr and thread.dscr_inherit in sync

    commit 00ca0de upstream.
    
    When we update the DSCR either via emulation of mtspr(DSCR) or via
    a change to dscr_default in sysfs we don't update thread.dscr.
    We will eventually update it at context switch time but there is
    a period where thread.dscr is incorrect.
    
    If we fork at this point we will copy the old value of thread.dscr
    into the child. To avoid this, always keep thread.dscr in sync with
    reality.
    
    This issue was found with the following testcase:
    
    http://ozlabs.org/~anton/junkcode/dscr_inherit_test.c
    
    Signed-off-by: Anton Blanchard <anton@samba.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    antonblanchard committed with gregkh Sep 3, 2012
  32. @antonblanchard @gregkh

    powerpc: Update DSCR on all CPUs when writing sysfs dscr_default

    commit 1b6ca2a upstream.
    
    Writing to dscr_default in sysfs doesn't actually change the DSCR -
    we rely on a context switch on each CPU to do the work. There is no
    guarantee we will get a context switch in a reasonable amount of time
    so fire off an IPI to force an immediate change.
    
    This issue was found with the following test case:
    
    http://ozlabs.org/~anton/junkcode/dscr_explicit_test.c
    
    Signed-off-by: Anton Blanchard <anton@samba.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    antonblanchard committed with gregkh Sep 3, 2012
  33. @zonque @gregkh

    ALSA: snd-usb: fix cross-interface streaming devices

    commit 2e4a263 upstream.
    
    Commit 68e67f4 ("ALSA: snd-usb: move calls to usb_set_interface")
    saved us some unnecessary calls to snd_usb_set_interface() but ignored
    the fact that there is at least one device out there which operates on
    two endpoint in different interfaces simultaniously.
    
    Take care for this by catching the case where data and sync endpoints
    are located on different interfaces and calling snd_usb_set_interface()
    between the start of the two endpoints.
    
    Signed-off-by: Daniel Mack <zonque@gmail.com>
    Reported-by: Robert M. Albrecht <linux@romal.de>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    zonque committed with gregkh Aug 30, 2012
  34. @zonque @gregkh

    ALSA: snd-usb: fix calls to next_packet_size

    commit 245baf9 upstream.
    
    In order to support devices with implicit feedback streaming models,
    packet sizes are now stored with each individual urb, and the PCM
    handling code which fills the buffers purely relies on the size fields
    now.
    
    However, calling snd_usb_audio_next_packet_size() for all possible
    packets in an URB at once, prior to letting the PCM code do its job
    does in fact not lead to the same behaviour than what the old code did:
    The PCM code will break its loop once a period boundary is reached,
    consequently using up less packets that it really could.
    
    As snd_usb_audio_next_packet_size() implements a feedback mechanism to
    the endpoints phase accumulator, the number of calls to that function
    matters, and when called too often, the data rate runs out of bounds.
    
    Fix this by making the next_packet function public, and call it from the
    PCM code as before if the packet data sizes are not defined.
    
    Signed-off-by: Daniel Mack <zonque@gmail.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    zonque committed with gregkh Aug 30, 2012
  35. @zonque @gregkh

    ALSA: snd-usb: restore delay information

    commit fbcfbf5 upstream.
    
    Parts of commit 294c4fb ("ALSA: usb: refine delay information with USB
    frame counter") were unfortunately lost during the refactoring of the
    snd-usb driver in 3.5.
    
    This patch adds them back, restoring the correct delay information
    behaviour.
    
    Signed-off-by: Daniel Mack <zonque@gmail.com>
    Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    zonque committed with gregkh Aug 30, 2012
Something went wrong with that request. Please try again.