Permalink
Commits on Nov 27, 2012
  1. Merge branch 'configs-3.6' into pf-3.6

    Oleksandr Natalenko committed Nov 27, 2012
  2. configs-3.6: update dell-vostro-3360.config

    Oleksandr Natalenko committed Nov 27, 2012
  3. Merge branch 'distro-3.6' into pf-3.6

    Oleksandr Natalenko committed Nov 27, 2012
  4. Merge branch 'version-3.6' into pf-3.6

    Oleksandr Natalenko committed Nov 27, 2012
  5. distro-3.6: bump to v3.6.10-pf

    Oleksandr Natalenko committed Nov 27, 2012
  6. version-3.6: bump to v3.6.10-pf

    Oleksandr Natalenko committed Nov 27, 2012
  7. fix merge conflict

    Oleksandr Natalenko committed Nov 27, 2012
  8. Revert "cifs: Do not lookup hashed negative dentry in cifs_atomic_open"

    Oleksandr Natalenko committed Nov 27, 2012
    This reverts commit 88dbf6e.
  9. Merge branch 'upstream-3.6' into tuxonice-3.6

    Nigel committed Nov 27, 2012
Commits on Nov 26, 2012
  1. Linux 3.6.8

    gregkh committed Nov 26, 2012
  2. ext4: fix metadata checksum calculation for the superblock

    tytso committed with gregkh Oct 10, 2012
    commit 06db49e upstream.
    
    The function ext4_handle_dirty_super() was calculating the superblock
    on the wrong block data.  As a result, when the superblock is modified
    while it is mounted (most commonly, when inodes are added or removed
    from the orphan list), the superblock checksum would be wrong.  We
    didn't notice because the superblock *was* being correctly calculated
    in ext4_commit_super(), and this would get called when the file system
    was unmounted.  So the problem only became obvious if the system
    crashed while the file system was mounted.
    
    Fix this by removing the poorly designed function signature for
    ext4_superblock_csum_set(); if it only took a single argument, the
    pointer to a struct superblock, the ambiguity which caused this
    mistake would have been impossible.
    
    Reported-by: George Spelvin <linux@horizon.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Tested-by: George Spelvin <linux@horizon.com>
  3. Revert "serial: omap: fix software flow control"

    Felipe Balbi committed with gregkh Oct 16, 2012
    commit a4f7438 upstream.
    
    This reverts commit 957ee72
    (serial: omap: fix software flow control).
    
    As Russell has pointed out, that commit isn't fixing
    Software Flow Control at all, and it actually makes
    it even more broken.
    
    It was agreed to revert this commit and use Russell's
    latest UART patches instead.
    
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Cc: Russell King <linux@arm.linux.org.uk>
    Acked-by: Tony Lindgren <tony@atomide.com>
    Cc: Andreas Bießmann <andreas.devel@googlemail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  4. ACPI video: Ignore errors after _DOD evaluation.

    GArik committed with gregkh Oct 13, 2012
    commit fba4e08 upstream.
    
    There are systems where video module known to work fine regardless
    of broken _DOD and ignoring returned value here doesn't cause
    any issues later. This should fix brightness controls on some laptops.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47861
    
    Signed-off-by: Igor Murzov <e-mail@date.by>
    Reviewed-by: Sergey V <sftp.mtuci@gmail.com>
    Signed-off-by: Zhang Rui <rui.zhang@intel.com>
    Signed-off-by: Abdallah Chatila <abdallah.chatila@ericsson.com>
  5. selinux: fix sel_netnode_insert() suspicious rcu dereference

    Dave Jones committed with gregkh Nov 9, 2012
    commit 88a693b upstream.
    
    ===============================
    [ INFO: suspicious RCU usage. ]
    3.5.0-rc1+ #63 Not tainted
    -------------------------------
    security/selinux/netnode.c:178 suspicious rcu_dereference_check() usage!
    
    other info that might help us debug this:
    
    rcu_scheduler_active = 1, debug_locks = 0
    1 lock held by trinity-child1/8750:
     #0:  (sel_netnode_lock){+.....}, at: [<ffffffff812d8f8a>] sel_netnode_sid+0x16a/0x3e0
    
    stack backtrace:
    Pid: 8750, comm: trinity-child1 Not tainted 3.5.0-rc1+ #63
    Call Trace:
     [<ffffffff810cec2d>] lockdep_rcu_suspicious+0xfd/0x130
     [<ffffffff812d91d1>] sel_netnode_sid+0x3b1/0x3e0
     [<ffffffff812d8e20>] ? sel_netnode_find+0x1a0/0x1a0
     [<ffffffff812d24a6>] selinux_socket_bind+0xf6/0x2c0
     [<ffffffff810cd1dd>] ? trace_hardirqs_off+0xd/0x10
     [<ffffffff810cdb55>] ? lock_release_holdtime.part.9+0x15/0x1a0
     [<ffffffff81093841>] ? lock_hrtimer_base+0x31/0x60
     [<ffffffff812c9536>] security_socket_bind+0x16/0x20
     [<ffffffff815550ca>] sys_bind+0x7a/0x100
     [<ffffffff816c03d5>] ? sysret_check+0x22/0x5d
     [<ffffffff810d392d>] ? trace_hardirqs_on_caller+0x10d/0x1a0
     [<ffffffff8133b09e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
     [<ffffffff816c03a9>] system_call_fastpath+0x16/0x1b
    
    This patch below does what Paul McKenney suggested in the previous thread.
    
    Signed-off-by: Dave Jones <davej@redhat.com>
    Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Acked-by: Paul Moore <paul@paul-moore.com>
    Cc: Eric Paris <eparis@parisplace.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: James Morris <james.l.morris@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  6. intel-iommu: Fix lookup in add device

    awilliam committed with gregkh Nov 13, 2012
    commit 3da4af0 upstream.
    
    We can't assume this device exists, fall back to the bridge itself.
    
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Tested-by: Matthew Thode <prometheanfire@gentoo.org>
    Signed-off-by: Joerg Roedel <joro@8bytes.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  7. reiserfs: Protect reiserfs_quota_write() with write lock

    jankara committed with gregkh Nov 13, 2012
    commit 361d94a upstream.
    
    Calls into reiserfs journalling code and reiserfs_get_block() need to
    be protected with write lock. We remove write lock around calls to high
    level quota code in the next patch so these paths would suddently become
    unprotected.
    
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  8. reiserfs: Move quota calls out of write lock

    jankara committed with gregkh Nov 13, 2012
    commit 7af1168 upstream.
    
    Calls into highlevel quota code cannot happen under the write lock. These
    calls take dqio_mutex which ranks above write lock. So drop write lock
    before calling back into quota code.
    
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  9. reiserfs: Protect reiserfs_quota_on() with write lock

    jankara committed with gregkh Nov 13, 2012
    commit b9e06ef upstream.
    
    In reiserfs_quota_on() we do quite some work - for example unpacking
    tail of a quota file. Thus we have to hold write lock until a moment
    we call back into the quota code.
    
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  10. reiserfs: Fix lock ordering during remount

    jankara committed with gregkh Nov 13, 2012
    commit 3bb3e1f upstream.
    
    When remounting reiserfs dquot_suspend() or dquot_resume() can be called.
    These functions take dqonoff_mutex which ranks above write lock so we have
    to drop it before calling into quota code.
    
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  11. NFC: Use dynamic initialization for rwlocks

    Szymon Janc committed with gregkh Sep 25, 2012
    commit fe235b5 upstream.
    
    If rwlock is dynamically allocated but statically initialized it is
    missing proper lockdep annotation.
    
    INFO: trying to register non-static key.
    the code is fine but needs lockdep annotation.
    turning off the locking correctness validator.
    Pid: 3352, comm: neard Not tainted 3.5.0-999-nfc+ #2
    Call Trace:
    [<ffffffff810c8526>] __lock_acquire+0x8f6/0x1bf0
    [<ffffffff81739045>] ? printk+0x4d/0x4f
    [<ffffffff810c9eed>] lock_acquire+0x9d/0x220
    [<ffffffff81702bfe>] ? nfc_llcp_sock_from_sn+0x4e/0x160
    [<ffffffff81746724>] _raw_read_lock+0x44/0x60
    [<ffffffff81702bfe>] ? nfc_llcp_sock_from_sn+0x4e/0x160
    [<ffffffff81702bfe>] nfc_llcp_sock_from_sn+0x4e/0x160
    [<ffffffff817034a7>] nfc_llcp_get_sdp_ssap+0xa7/0x1b0
    [<ffffffff81706353>] llcp_sock_bind+0x173/0x210
    [<ffffffff815d9c94>] sys_bind+0xe4/0x100
    [<ffffffff8139209e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
    [<ffffffff8174ea69>] system_call_fastpath+0x16/0x1b
    
    Signed-off-by: Szymon Janc <szymon.janc@tieto.com>
    Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  12. s390/signal: set correct address space control

    Martin Schwidefsky committed with gregkh Nov 7, 2012
    commit fa968ee upstream.
    
    If user space is running in primary mode it can switch to secondary
    or access register mode, this is used e.g. in the clock_gettime code
    of the vdso. If a signal is delivered to the user space process while
    it has been running in access register mode the signal handler is
    executed in access register mode as well which will result in a crash
    most of the time.
    
    Set the address space control bits in the PSW to the default for the
    execution of the signal handler and make sure that the previous
    address space control is restored on signal return. Take care
    that user space can not switch to the kernel address space by
    modifying the registers in the signal frame.
    
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  13. netfilter: nf_conntrack: fix rt_gateway checks for H.323 helper

    Julian Anastasov committed with gregkh Oct 9, 2012
    commit bbb5823 upstream.
    
    After the change "Adjust semantics of rt->rt_gateway"
    (commit f8126f1) we should properly match the nexthop when
    destinations are directly connected because rt_gateway can be 0.
    
    The rt_gateway checks in H.323 helper try to avoid the creation
    of an unnecessary expectation in this call-forwarding case:
    
    http://people.netfilter.org/zhaojingmin/h323_conntrack_nat_helper/#_Toc133598073
    
    However, the existing code fails to avoid that in many cases,
    see this thread:
    
    http://marc.info/?l=linux-netdev&m=135043175028620&w=2
    
    It seems it is not trivial to know from the kernel if two hosts
    have to go through the firewall to communicate each other, which
    is the main point of the call-forwarding filter code to avoid
    creating unnecessary expectations.
    
    So this patch just gets things the way they were as before
    commit f8126f1.
    
    Signed-off-by: Julian Anastasov <ja@ssi.bg>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  14. netfilter: xt_TEE: don't use destination address found in header

    Eric Dumazet committed with gregkh Oct 16, 2012
    commit 2ad5b9e upstream.
    
    Torsten Luettgert bisected TEE regression starting with commit
    f8126f1 (ipv4: Adjust semantics of rt->rt_gateway.)
    
    The problem is that it tries to ARP-lookup the original destination
    address of the forwarded packet, not the address of the gateway.
    
    Fix this using FLOWI_FLAG_KNOWN_NH Julian added in commit
    c92b965 (ipv4: Add FLOWI_FLAG_KNOWN_NH), so that known
    nexthop (info->gw.ip) has preference on resolving.
    
    Reported-by: Torsten Luettgert <ml-netfilter@enda.eu>
    Bisected-by: Torsten Luettgert <ml-netfilter@enda.eu>
    Tested-by: Torsten Luettgert <ml-netfilter@enda.eu>
    Cc: Julian Anastasov <ja@ssi.bg>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  15. netfilter: nf_nat: don't check for port change on ICMP tuples

    Ulrich Weber committed with gregkh Oct 25, 2012
    commit 38fe36a upstream.
    
    ICMP tuples have id in src and type/code in dst.
    So comparing src.u.all with dst.u.all will always fail here
    and ip_xfrm_me_harder() is called for every ICMP packet,
    even if there was no NAT.
    
    Signed-off-by: Ulrich Weber <ulrich.weber@sophos.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  16. r8169: allow multicast packets on sub-8168f chipset.

    faceprint committed with gregkh Nov 1, 2012
    commit 0481776 upstream.
    
    RTL_GIGA_MAC_VER_35 includes no multicast hardware filter.
    
    Signed-off-by: Nathan Walp <faceprint@faceprint.com>
    Suggested-by: Hayes Wang <hayeswang@realtek.com>
    Acked-by: Francois Romieu <romieu@fr.zoreil.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  17. r8169: Fix WoL on RTL8168d/8111d.

    Cyril Brulebois committed with gregkh Oct 31, 2012
    commit b00e69d upstream.
    
    This regression was spotted between Debian squeeze and Debian wheezy
    kernels (respectively based on 2.6.32 and 3.2). More info about
    Wake-on-LAN issues with Realtek's 816x chipsets can be found in the
    following thread: http://marc.info/?t=132079219400004
    
    Probable regression from d4ed95d;
    more chipsets are likely affected.
    
    Tested on top of a 3.2.23 kernel.
    
    Reported-by: Florent Fourcot <florent.fourcot@enst-bretagne.fr>
    Tested-by: Florent Fourcot <florent.fourcot@enst-bretagne.fr>
    Hinted-by: Francois Romieu <romieu@fr.zoreil.com>
    Signed-off-by: Cyril Brulebois <kibi@debian.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  18. tg3: unconditionally select HWMON support when tg3 is enabled.

    paulgortmaker committed with gregkh Oct 1, 2012
    commit de0a414 upstream.
    
    There is the seldom used corner case where HWMON=m at the same
    time as TIGON3=y (typically randconfigs) which will cause a link
    fail like:
    
    drivers/built-in.o: In function `tg3_close':
    tg3.c:(.text+0x16bd86): undefined reference to `hwmon_device_unregister'
    drivers/built-in.o: In function `tg3_hwmon_open':
    tg3.c:(.text+0x16fc4b): undefined reference to `hwmon_device_register'
    make[1]: *** [vmlinux] Error 1
    
    Fix it as suggested by DaveM[1] by having the Kconfig logic simply
    select HWMON when TIGON3 is selected.  This gets rid of all the
    extra IS_ENABLED ifdeffery in tg3.c as a side benefit.
    
    [1] http://marc.info/?l=linux-netdev&m=134250573718151&w=2
    
    Reported-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: Michael Chan <mchan@broadcom.com>
    Reported-by: Anisse Astier <anisse@astier.eu>
    Suggested-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  19. SCSI: isci: Allow SSP tasks into the task management path.

    Jeff Skirvin committed with gregkh Sep 6, 2012
    commit 54b4667 upstream.
    
    This commit fixes a driver bug for SSP tasks that require task management
    in the target after they complete in the SCU hardware.  The problem was
    manifested in the function "isci_task_abort_task", which tests
    to see if the sas_task.lldd_task is non-NULL before allowing task
    management; this bug would always NULL lldd_task in the SCU I/O completion
    path even if target management was required, which would prevent
    task / target manangement from happening.
    
    Note that in the case of SATA/STP targets, error recovery is provided by
    the libata error handler which is why SATA/STP device recovery worked
    correctly even though SSP handling did not.
    
    Signed-off-by: Jeff Skirvin <jeffrey.d.skirvin@intel.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Cc: "Dorau, Lukasz" <lukasz.dorau@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  20. xen/events: fix RCU warning, or Call idle notifier after irq_enter()

    Mojiong Qiu committed with gregkh Nov 6, 2012
    commit 772aebc upstream.
    
    exit_idle() should be called after irq_enter(), otherwise it throws:
    
    [ INFO: suspicious RCU usage. ]
    3.6.5 #1 Not tainted
    -------------------------------
    include/linux/rcupdate.h:725 rcu_read_lock() used illegally while idle!
    
    other info that might help us debug this:
    
    RCU used illegally from idle CPU!
    rcu_scheduler_active = 1, debug_locks = 1
    RCU used illegally from extended quiescent state!
    1 lock held by swapper/0/0:
     #0:  (rcu_read_lock){......}, at: [<ffffffff810e9fe0>] __atomic_notifier_call_chain+0x0/0x140
    
    stack backtrace:
    Pid: 0, comm: swapper/0 Not tainted 3.6.5 #1
    Call Trace:
     <IRQ>  [<ffffffff811259a2>] lockdep_rcu_suspicious+0xe2/0x130
     [<ffffffff810ea10c>] __atomic_notifier_call_chain+0x12c/0x140
     [<ffffffff810e9fe0>] ? atomic_notifier_chain_unregister+0x90/0x90
     [<ffffffff811216cd>] ? trace_hardirqs_off+0xd/0x10
     [<ffffffff810ea136>] atomic_notifier_call_chain+0x16/0x20
     [<ffffffff810777c3>] exit_idle+0x43/0x50
     [<ffffffff81568865>] xen_evtchn_do_upcall+0x25/0x50
     [<ffffffff81aa690e>] xen_do_hypervisor_callback+0x1e/0x30
     <EOI>  [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
     [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
     [<ffffffff81061540>] ? xen_safe_halt+0x10/0x20
     [<ffffffff81075cfa>] ? default_idle+0xba/0x570
     [<ffffffff810778af>] ? cpu_idle+0xdf/0x140
     [<ffffffff81a4d881>] ? rest_init+0x135/0x144
     [<ffffffff81a4d74c>] ? csum_partial_copy_generic+0x16c/0x16c
     [<ffffffff82520c45>] ? start_kernel+0x3db/0x3e8
     [<ffffffff8252066a>] ? repair_env_string+0x5a/0x5a
     [<ffffffff82520356>] ? x86_64_start_reservations+0x131/0x135
     [<ffffffff82524aca>] ? xen_start_kernel+0x465/0x46
    
    Git commit 98ad1cc
    Author: Frederic Weisbecker <fweisbec@gmail.com>
    Date:   Fri Oct 7 18:22:09 2011 +0200
    
        x86: Call idle notifier after irq_enter()
    
    did this, but it missed the Xen code.
    
    Signed-off-by: Mojiong Qiu <mjqiu@tencent.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  21. r8169: use unlimited DMA burst for TX

    michich committed with gregkh Sep 9, 2012
    commit aee77e4 upstream.
    
    The r8169 driver currently limits the DMA burst for TX to 1024 bytes. I have
    a box where this prevents the interface from using the gigabit line to its full
    potential. This patch solves the problem by setting TX_DMA_BURST to unlimited.
    
    The box has an ASRock B75M motherboard with on-board RTL8168evl/8111evl
    (XID 0c900880). TSO is enabled.
    
    I used netperf (TCP_STREAM test) to measure the dependency of TX throughput
    on MTU. I did it for three different values of TX_DMA_BURST ('5'=512, '6'=1024,
    '7'=unlimited). This chart shows the results:
    http://michich.fedorapeople.org/r8169/r8169-effects-of-TX_DMA_BURST.png
    
    Interesting points:
     - With the current DMA burst limit (1024):
       - at the default MTU=1500 I get only 842 Mbit/s.
       - when going from small MTU, the performance rises monotonically with
         increasing MTU only up to a peak at MTU=1076 (908 MBit/s). Then there's
         a sudden drop to 762 MBit/s from which the throughput rises monotonically
         again with further MTU increases.
     - With a smaller DMA burst limit (512):
       - there's a similar peak at MTU=1076 and another one at MTU=564.
     - With unlimited DMA burst:
       - at the default MTU=1500 I get nice 940 Mbit/s.
       - the throughput rises monotonically with increasing MTU with no strange
         peaks.
    
    Notice that the peaks occur at MTU sizes that are multiples of the DMA burst
    limit plus 52. Why 52? Because:
      20 (IP header) + 20 (TCP header) + 12 (TCP options) = 52
    
    The Realtek-provided r8168 driver (v8.032.00) uses unlimited TX DMA burst too,
    except for CFG_METHOD_1 where the TX DMA burst is set to 512 bytes.
    CFG_METHOD_1 appears to be the oldest MAC version of "RTL8168B/8111B",
    i.e. RTL_GIGA_MAC_VER_11 in r8169. Not sure if this MAC version really needs
    the smaller burst limit, or if any other versions have similar requirements.
    
    Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
    Acked-by: Francois Romieu <romieu@fr.zoreil.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  22. GFS2: Don't call file_accessed() with a shared glock

    bmarzins committed with gregkh Nov 6, 2012
    commit 3d16268 upstream.
    
    file_accessed() was being called by gfs2_mmap() with a shared glock. If it
    needed to update the atime, it was crashing because it dirtied the inode in
    gfs2_dirty_inode() without holding an exclusive lock. gfs2_dirty_inode()
    checked if the caller was already holding a glock, but it didn't make sure that
    the glock was in the exclusive state. Now, instead of calling file_accessed()
    while holding the shared lock in gfs2_mmap(), file_accessed() is called after
    grabbing and releasing the glock to update the inode.  If file_accessed() needs
    to update the atime, it will grab an exclusive lock in gfs2_dirty_inode().
    
    gfs2_dirty_inode() now also checks to make sure that if the calling process has
    already locked the glock, it has an exclusive lock.
    
    Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
    Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  23. ALSA: usb-audio: Fix crash at re-preparing the PCM stream

    tiwai committed with gregkh Nov 20, 2012
    commit f58161b upstream.
    
    There are bug reports of a crash with USB-audio devices when PCM
    prepare is performed immediately after the stream is stopped via
    trigger callback.  It turned out that the problem is that we don't
    wait until all URBs are killed.
    
    This patch adds a new function to synchronize the pending stop
    operation on an endpoint, and calls in the prepare callback for
    avoiding the crash above.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=49181
    
    Reported-and-tested-by: Artem S. Tashkinov <t.artem@lycos.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  24. tmpfs: change final i_blocks BUG to WARNING

    Hugh Dickins committed with gregkh Nov 16, 2012
    commit 0f3c42f upstream.
    
    Under a particular load on one machine, I have hit shmem_evict_inode()'s
    BUG_ON(inode->i_blocks), enough times to narrow it down to a particular
    race between swapout and eviction.
    
    It comes from the "if (freed > 0)" asymmetry in shmem_recalc_inode(),
    and the lack of coherent locking between mapping's nrpages and shmem's
    swapped count.  There's a window in shmem_writepage(), between lowering
    nrpages in shmem_delete_from_page_cache() and then raising swapped
    count, when the freed count appears to be +1 when it should be 0, and
    then the asymmetry stops it from being corrected with -1 before hitting
    the BUG.
    
    One answer is coherent locking: using tree_lock throughout, without
    info->lock; reasonable, but the raw_spin_lock in percpu_counter_add() on
    used_blocks makes that messier than expected.  Another answer may be a
    further effort to eliminate the weird shmem_recalc_inode() altogether,
    but previous attempts at that failed.
    
    So far undecided, but for now change the BUG_ON to WARN_ON: in usual
    circumstances it remains a useful consistency check.
    
    Signed-off-by: Hugh Dickins <hughd@google.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@linuxfoundation.org>
  25. tcp: handle tcp_net_metrics_init() order-5 memory allocation failures

    Eric Dumazet committed with gregkh Nov 16, 2012
    [ Upstream commit 976a702 ]
    
    order-5 allocations can fail with current kernels, we should
    try vmalloc() as well.
    
    Reported-by: Julien Tinnes <jln@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>