Linux 3.0.75

commit b47833937231eebab2fe46502426ea8158fae8d9
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Apr 25 21:24:11 2013 -0700

    Linux 3.0.75

commit 7a860c4dfb8ebaf777a7df185df4436ea343189a
Author: Josef Bacik <jbacik@fusionio.com>
Date:   Fri Apr 5 20:50:09 2013 +0000

    Btrfs: make sure nbytes are right after log replay

    commit 4bc4bee4595662d8bff92180d5c32e3313a704b0 upstream.

    While trying to track down a tree log replay bug I noticed that fsck was always
    complaining about nbytes not being right for our fsynced file.  That is because
    the new fsync stuff doesn't wait for ordered extents to complete, so the inodes
    nbytes are not necessarily updated properly when we log it.  So to fix this we
    need to set nbytes to whatever it is on the inode that is on disk, so when we
    replay the extents we can just add the bytes that are being added as we replay
    the extent.  This makes it work for the case that we have the wrong nbytes or
    the case that we logged everything and nbytes is actually correct.  With this
    I'm no longer getting nbytes errors out of btrfsck.

    Signed-off-by: Josef Bacik <jbacik@fusionio.com>
    Signed-off-by: Chris Mason <chris.mason@fusionio.com>
    Signed-off-by: Lingzhu Xiang <lxiang@redhat.com>
    Reviewed-by: CAI Qian <caiqian@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 856398d852436111d5cdbf30374f576671903998
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri Apr 19 09:53:07 2013 -0700

    vm: convert mtdchar mmap to vm_iomap_memory() helper

    commit 8558e4a26b00225efeb085725bc319f91201b239 upstream.

    This is my example conversion of a few existing mmap users.  The mtdchar
    case is actually disabled right now (and stays disabled), but I did it
    because it showed up on my "git grep", and I was familiar with the code
    due to fixing an overflow problem in the code in commit 9c603e53d380
    ("mtdchar: fix offset overflow detection").

    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 102fe50d961cf56eb764959783485193884ab1e6
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri Apr 19 09:46:39 2013 -0700

    vm: convert HPET mmap to vm_iomap_memory() helper

    commit 2323036dfec8ce3ce6e1c86a49a31b039f3300d1 upstream.

    This is my example conversion of a few existing mmap users.  The HPET
    case is simple, widely available, and easy to test (Clemens Ladisch sent
    a trivial test-program for it).

    Test-program-by: Clemens Ladisch <clemens@ladisch.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 03a850de03bfed25270d20918ee02d9f0dbb1f21
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri Apr 19 09:57:35 2013 -0700

    vm: convert fb_mmap to vm_iomap_memory() helper

    commit fc9bbca8f650e5f738af8806317c0a041a48ae4a upstream.

    This is my example conversion of a few existing mmap users.  The
    fb_mmap() case is a good example because it is a bit more complicated
    than some: fb_mmap() mmaps one of two different memory areas depending
    on the page offset of the mmap (but happily there is never any mixing of
    the two, so the helper function still works).

    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 69c8dbb74ce747df83ad81ba73db965d7a716726
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri Apr 19 10:01:04 2013 -0700

    vm: convert snd_pcm_lib_mmap_iomem() to vm_iomap_memory() helper

    commit 0fe09a45c4848b5b5607b968d959fdc1821c161d upstream.

    This is my example conversion of a few existing mmap users.  The pcm
    mmap case is one of the more straightforward ones.

    Acked-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d1a01d18320e37367e23f006f0dfbd74ff32de68
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Tue Apr 16 13:45:37 2013 -0700

    vm: add vm_iomap_memory() helper function

    commit b4cbb197c7e7a68dbad0d491242e3ca67420c13e upstream.

    Various drivers end up replicating the code to mmap() their memory
    buffers into user space, and our core memory remapping function may be
    very flexible but it is unnecessarily complicated for the common cases
    to use.

    Our internal VM uses pfn's ("page frame numbers") which simplifies
    things for the VM, and allows us to pass physical addresses around in a
    denser and more efficient format than passing a "phys_addr_t" around,
    and having to shift it up and down by the page size.  But it just means
    that drivers end up doing that shifting instead at the interface level.

    It also means that drivers end up mucking around with internal VM things
    like the vma details (vm_pgoff, vm_start/end) way more than they really
    need to.

    So this just exports a function to map a certain physical memory range
    into user space (using a phys_addr_t based interface that is much more
    natural for a driver) and hides all the complexity from the driver.
    Some drivers will still end up tweaking the vm_page_prot details for
    things like prefetching or cacheability etc, but that's actually
    relevant to the driver, rather than caring about what the page offset of
    the mapping is into the particular IO memory region.

    Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 22fd0f0bb5e791b7cd5b5e0c7d4c2172c722844d
Author: Dave Airlie <airlied@gmail.com>
Date:   Fri Jan 25 11:38:56 2013 +1000

    fbcon: fix locking harder

    commit 054430e773c9a1e26f38e30156eff02dedfffc17 upstream.

    Okay so Alan's patch handled the case where there was no registered fbcon,
    however the other path entered in set_con2fb_map pit.

    In there we called fbcon_takeover, but we also took the console lock in a couple
    of places. So push the console lock out to the callers of set_con2fb_map,

    this means fbmem and switcheroo needed to take the lock around the fb notifier
    entry points that lead to this.

    This should fix the efifb regression seen by Maarten.

    Tested-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
    Tested-by: Lu Hua <huax.lu@intel.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 456edf57d7a6fe1b238ec708b19063d78cf4b250
Author: Tommi Rantala <tt.rantala@gmail.com>
Date:   Sat Apr 13 22:49:14 2013 +0300

    perf: Treat attr.config as u64 in perf_swevent_init()

    commit 8176cced706b5e5d15887584150764894e94e02f upstream.

    Trinity discovered that we fail to check all 64 bits of
    attr.config passed by user space, resulting to out-of-bounds
    access of the perf_swevent_enabled array in
    sw_perf_event_destroy().

    Introduced in commit b0a873ebb ("perf: Register PMU
    implementations").

    Signed-off-by: Tommi Rantala <tt.rantala@gmail.com>
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: davej@redhat.com
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
    Link: http://lkml.kernel.org/r/1365882554-30259-1-git-send-email-tt.rantala@gmail.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bb5489176fda28aff304b59e0405f7d7d4906224
Author: Jiri Kosina <jkosina@suse.cz>
Date:   Mon Apr 22 15:40:15 2013 +0200

    Revert "sysfs: fix race between readdir and lseek"

    This reverts commit 991f76f837bf22c5bb07261cfd86525a0a96650c in Linus'
    tree which is f366c8f271888f48e15cc7c0ab70f184c220c8a4 in
    linux-stable.git

    It depends on ef3d0fd27e90f ("vfs: do (nearly) lockless generic_file_llseek")
    which is available only in 3.2+.

    When applied on 3.0 codebase, it causes A-A deadlock, whenever anyone does
    seek() on sysfs, as both generic_file_llseek() and sysfs_dir_llseek() obtain
    i_mutex.

    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Cc: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0236d37edc0522f37b83eba35432815cd98789ff
Author: Mathias Krause <minipli@googlemail.com>
Date:   Sun Apr 7 14:05:39 2013 +0200

    crypto: algif - suppress sending source address information in recvmsg

    commit 72a763d805a48ac8c0bf48fdb510e84c12de51fe upstream.

    The current code does not set the msg_namelen member to 0 and therefore
    makes net/socket.c leak the local sockaddr_storage variable to userland
    -- 128 bytes of kernel stack memory. Fix that.

    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 55aa9556812fe10d71bfe82ff61058a3a03cb0f6
Author: Tejun Heo <tj@kernel.org>
Date:   Mon Mar 18 12:22:34 2013 -0700

    sched: Convert BUG_ON()s in try_to_wake_up_local() to WARN_ON_ONCE()s

    commit 383efcd00053ec40023010ce5034bd702e7ab373 upstream.

    try_to_wake_up_local() should only be invoked to wake up another
    task in the same runqueue and BUG_ON()s are used to enforce the
    rule. Missing try_to_wake_up_local() can stall workqueue
    execution but such stalls are likely to be finite either by
    another work item being queued or the one blocked getting
    unblocked.  There's no reason to trigger BUG while holding rq
    lock crashing the whole system.

    Convert BUG_ON()s in try_to_wake_up_local() to WARN_ON_ONCE()s.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Acked-by: Steven Rostedt <rostedt@goodmis.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/20130318192234.GD3042@htj.dyndns.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0a9cb8d371991dceed054aec71541653e330180f
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Sun Apr 7 21:10:48 2013 +0200

    ath9k_htc: accept 1.x firmware newer than 1.3

    commit 319e7bd96aca64a478f3aad40711c928405b8b77 upstream.

    Since the firmware has been open sourced, the minor version has been
    bumped to 1.4 and the API/ABI will stay compatible across further 1.x
    releases.

    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cef72624c31364e7020450571393a4d5a0e44b34
Author: Illia Ragozin <illia.ragozin@grapecom.com>
Date:   Wed Apr 10 19:43:34 2013 +0100

    ARM: 7696/1: Fix kexec by setting outer_cache.inv_all for Feroceon

    commit cd272d1ea71583170e95dde02c76166c7f9017e6 upstream.

    On Feroceon the L2 cache becomes non-coherent with the CPU
    when the L1 caches are disabled. Thus the L2 needs to be invalidated
    after both L1 caches are disabled.

    On kexec before the starting the code for relocation the kernel,
    the L1 caches are disabled in cpu_froc_fin (cpu_v7_proc_fin for Feroceon),
    but after L2 cache is never invalidated, because inv_all is not set
    in cache-feroceon-l2.c.
    So kernel relocation and decompression may has (and usually has) errors.
    Setting the function enables L2 invalidation and fixes the issue.

    Signed-off-by: Illia Ragozin <illia.ragozin@grapecom.com>
    Acked-by: Jason Cooper <jason@lakedaemon.net>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d715cdddb8cdf1c17bf1c5ff8fcc9852cd6ba79e
Author: Andrew Honig <ahonig@google.com>
Date:   Fri Mar 29 09:35:21 2013 -0700

    KVM: Allow cross page reads and writes from cached translations.

    commit 8f964525a121f2ff2df948dac908dcc65be21b5b upstream.

    This patch adds support for kvm_gfn_to_hva_cache_init functions for
    reads and writes that will cross a page.  If the range falls within
    the same memslot, then this will be a fast operation.  If the range
    is split between two memslots, then the slower kvm_read_guest and
    kvm_write_guest are used.

    Tested: Test against kvm_clock unit tests.

    Signed-off-by: Andrew Honig <ahonig@google.com>
    Signed-off-by: Gleb Natapov <gleb@redhat.com>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 17f13c27702d90899081bf70134132ed5f25158e
Author: Andy Honig <ahonig@google.com>
Date:   Wed Feb 20 14:49:16 2013 -0800

    KVM: Fix bounds checking in ioapic indirect register reads (CVE-2013-1798)

    commit a2c118bfab8bc6b8bb213abfc35201e441693d55 upstream.

    If the guest specifies a IOAPIC_REG_SELECT with an invalid value and follows
    that with a read of the IOAPIC_REG_WINDOW KVM does not properly validate
    that request.  ioapic_read_indirect contains an
    ASSERT(redir_index < IOAPIC_NUM_PINS), but the ASSERT has no effect in
    non-debug builds.  In recent kernels this allows a guest to cause a kernel
    oops by reading invalid memory.  In older kernels (pre-3.3) this allows a
    guest to read from large ranges of host memory.

    Tested: tested against apic unit tests.

    Signed-off-by: Andrew Honig <ahonig@google.com>
    Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit df0ed3450c217a1cd571c0d4efa4dc6c458894a9
Author: Andy Honig <ahonig@google.com>
Date:   Wed Feb 20 14:48:10 2013 -0800

    KVM: x86: Convert MSR_KVM_SYSTEM_TIME to use gfn_to_hva_cache functions (CVE-2013-1797)

    commit 0b79459b482e85cb7426aa7da683a9f2c97aeae1 upstream.

    There is a potential use after free issue with the handling of
    MSR_KVM_SYSTEM_TIME.  If the guest specifies a GPA in a movable or removable
    memory such as frame buffers then KVM might continue to write to that
    address even after it's removed via KVM_SET_USER_MEMORY_REGION.  KVM pins
    the page in memory so it's unlikely to cause an issue, but if the user
    space component re-purposes the memory previously used for the guest, then
    the guest will be able to corrupt that memory.

    Tested: Tested against kvmclock unit test

    Signed-off-by: Andrew Honig <ahonig@google.com>
    Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d7709255affba50d2ff4087d28308e03d1154afa
Author: Andy Honig <ahonig@google.com>
Date:   Mon Mar 11 09:34:52 2013 -0700

    KVM: x86: fix for buffer overflow in handling of MSR_KVM_SYSTEM_TIME (CVE-2013-1796)

    commit c300aa64ddf57d9c5d9c898a64b36877345dd4a9 upstream.

    If the guest sets the GPA of the time_page so that the request to update the
    time straddles a page then KVM will write onto an incorrect page.  The
    write is done byusing kmap atomic to get a pointer to the page for the time
    structure and then performing a memcpy to that page starting at an offset
    that the guest controls.  Well behaved guests always provide a 32-byte aligned
    address, however a malicious guest could use this to corrupt host kernel
    memory.

    Tested: Tested against kvmclock unit test.

    Signed-off-by: Andrew Honig <ahonig@google.com>
    Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7c72cbc040d7160849369d59166f7be32d1991fd
Author: Vyacheslav Dubeyko <slava@dubeyko.com>
Date:   Wed Apr 17 15:58:33 2013 -0700

    hfsplus: fix potential overflow in hfsplus_file_truncate()

    commit 12f267a20aecf8b84a2a9069b9011f1661c779b4 upstream.

    Change a u32 to loff_t hfsplus_file_truncate().

    Signed-off-by: Vyacheslav Dubeyko <slava@dubeyko.com>
    Cc: Christoph Hellwig <hch@infradead.org>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Hin-Tak Leung <htl10@users.sourceforge.net>
    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>

commit aab5c5ca241d159f81e002aebb828c3c75bf4682
Author: Emese Revfy <re.emese@gmail.com>
Date:   Wed Apr 17 15:58:36 2013 -0700

    kernel/signal.c: stop info leak via the tkill and the tgkill syscalls

    commit b9e146d8eb3b9ecae5086d373b50fa0c1f3e7f0f upstream.

    This fixes a kernel memory contents leak via the tkill and tgkill syscalls
    for compat processes.

    This is visible in the siginfo_t->_sifields._rt.si_sigval.sival_ptr field
    when handling signals delivered from tkill.

    The place of the infoleak:

    int copy_siginfo_to_user32(compat_siginfo_t __user *to, siginfo_t *from)
    {
            ...
            put_user_ex(ptr_to_compat(from->si_ptr), &to->si_ptr);
            ...
    }

    Signed-off-by: Emese Revfy <re.emese@gmail.com>
    Reviewed-by: PaX Team <pageexec@freemail.hu>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: "Eric W. Biederman" <ebiederm@xmission.com>
    Cc: Serge Hallyn <serge.hallyn@canonical.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>

commit 6cf9b8f1a9ae1640f73cf8804484530e74eb9d5d
Author: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Date:   Wed Apr 17 15:58:30 2013 -0700

    hugetlbfs: add swap entry check in follow_hugetlb_page()

    commit 9cc3a5bd40067b9a0fbd49199d0780463fc2140f upstream.

    With applying the previous patch "hugetlbfs: stop setting VM_DONTDUMP in
    initializing vma(VM_HUGETLB)" to reenable hugepage coredump, if a memory
    error happens on a hugepage and the affected processes try to access the
    error hugepage, we hit VM_BUG_ON(atomic_read(&page->_count) <= 0) in
    get_page().

    The reason for this bug is that coredump-related code doesn't recognise
    "hugepage hwpoison entry" with which a pmd entry is replaced when a memory
    error occurs on a hugepage.

    In other words, physical address information is stored in different bit
    layout between hugepage hwpoison entry and pmd entry, so
    follow_hugetlb_page() which is called in get_dump_page() returns a wrong
    page from a given address.

    The expected behavior is like this:

      absent   is_swap_pte   FOLL_DUMP   Expected behavior
      -------------------------------------------------------------------
       true     false         false       hugetlb_fault
       false    true          false       hugetlb_fault
       false    false         false       return page
       true     false         true        skip page (to avoid allocation)
       false    true          true        hugetlb_fault
       false    false         true        return page

    With this patch, we can call hugetlb_fault() and take proper actions (we
    wait for migration entries, fail with VM_FAULT_HWPOISON_LARGE for
    hwpoisoned entries,) and as the result we can dump all hugepages except
    for hwpoisoned ones.

    Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Cc: Rik van Riel <riel@redhat.com>
    Acked-by: Michal Hocko <mhocko@suse.cz>
    Cc: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
    Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Acked-by: David Rientjes <rientjes@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>

commit 55fe10a686c3a8bce7bddc149e4ebb12f5a18c25
Author: Christoph Fritz <chf.fritz@googlemail.com>
Date:   Thu Apr 11 21:32:57 2013 +0200

    can: sja1000: fix handling on dt properties on little endian systems

    commit 0443de5fbf224abf41f688d8487b0c307dc5a4b4 upstream.

    To get correct endianes on little endian cpus (like arm) while reading device
    tree properties, this patch replaces of_get_property() with
    of_property_read_u32(). While there use of_property_read_bool() for the
    handling of the boolean "nxp,no-comparator-bypass" property.

    Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 80d98a915c07e6de6c3a2c08dea843f441273081
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Apr 17 09:50:59 2013 -0700

    Revert "8021q: fix a potential use-after-free"

    This reverts commit 9829fe9806e22d7a822f4c947cc432c8d1774b54 which is
    upstream commit 4a7df340ed1bac190c124c1601bfc10cde9fb4fb

    It turns out this causes problems on the 3.0-stable release.

    Reported-by: Thomas Voegtle <tv@lio96.de>
    Acked-by: Cong Wang <amwang@redhat.com>
    Cc: Patrick McHardy <kaber@trash.net>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 27819a8a40b34b2db511181cfbfdf7f76281651d
Author: Michael Bohan <mbohan@codeaurora.org>
Date:   Tue Mar 19 19:19:25 2013 -0700

    hrtimer: Don't reinitialize a cpu_base lock on CPU_UP

    commit 84cc8fd2fe65866e49d70b38b3fdf7219dd92fe0 upstream.

    The current code makes the assumption that a cpu_base lock won't be
    held if the CPU corresponding to that cpu_base is offline, which isn't
    always true.

    If a hrtimer is not queued, then it will not be migrated by
    migrate_hrtimers() when a CPU is offlined. Therefore, the hrtimer's
    cpu_base may still point to a CPU which has subsequently gone offline
    if the timer wasn't enqueued at the time the CPU went down.

    Normally this wouldn't be a problem, but a cpu_base's lock is blindly
    reinitialized each time a CPU is brought up. If a CPU is brought
    online during the period that another thread is performing a hrtimer
    operation on a stale hrtimer, then the lock will be reinitialized
    under its feet, and a SPIN_BUG() like the following will be observed:

    <0>[   28.082085] BUG: spinlock already unlocked on CPU#0, swapper/0/0
    <0>[   28.087078]  lock: 0xc4780b40, value 0x0 .magic: dead4ead, .owner: <none>/-1, .owner_cpu: -1
    <4>[   42.451150] [<c0014398>] (unwind_backtrace+0x0/0x120) from [<c0269220>] (do_raw_spin_unlock+0x44/0xdc)
    <4>[   42.460430] [<c0269220>] (do_raw_spin_unlock+0x44/0xdc) from [<c071b5bc>] (_raw_spin_unlock+0x8/0x30)
    <4>[   42.469632] [<c071b5bc>] (_raw_spin_unlock+0x8/0x30) from [<c00a9ce0>] (__hrtimer_start_range_ns+0x1e4/0x4f8)
    <4>[   42.479521] [<c00a9ce0>] (__hrtimer_start_range_ns+0x1e4/0x4f8) from [<c00aa014>] (hrtimer_start+0x20/0x28)
    <4>[   42.489247] [<c00aa014>] (hrtimer_start+0x20/0x28) from [<c00e6190>] (rcu_idle_enter_common+0x1ac/0x320)
    <4>[   42.498709] [<c00e6190>] (rcu_idle_enter_common+0x1ac/0x320) from [<c00e6440>] (rcu_idle_enter+0xa0/0xb8)
    <4>[   42.508259] [<c00e6440>] (rcu_idle_enter+0xa0/0xb8) from [<c000f268>] (cpu_idle+0x24/0xf0)
    <4>[   42.516503] [<c000f268>] (cpu_idle+0x24/0xf0) from [<c06ed3c0>] (rest_init+0x88/0xa0)
    <4>[   42.524319] [<c06ed3c0>] (rest_init+0x88/0xa0) from [<c0c00978>] (start_kernel+0x3d0/0x434)

    As an example, this particular crash occurred when hrtimer_start() was
    executed on CPU #0. The code locked the hrtimer's current cpu_base
    corresponding to CPU #1. CPU #0 then tried to switch the hrtimer's
    cpu_base to an optimal CPU which was online. In this case, it selected
    the cpu_base corresponding to CPU #3.

    Before it could proceed, CPU #1 came online and reinitialized the
    spinlock corresponding to its cpu_base. Thus now CPU #0 held a lock
    which was reinitialized. When CPU #0 finally ended up unlocking the
    old cpu_base corresponding to CPU #1 so that it could switch to CPU
    #3, we hit this SPIN_BUG() above while in switch_hrtimer_base().

    CPU #0                            CPU #1
    ----                              ----
    ...                               <offline>
    hrtimer_start()
    lock_hrtimer_base(base #1)
    ...                               init_hrtimers_cpu()
    switch_hrtimer_base()             ...
    ...                               raw_spin_lock_init(&cpu_base->lock)
    raw_spin_unlock(&cpu_base->lock)  ...
    <spin_bug>

    Solve this by statically initializing the lock.

    Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
    Link: http://lkml.kernel.org/r/1363745965-23475-1-git-send-email-mbohan@codeaurora.org
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
input: touchscreen: implement 'sweep2wake' feature
For Atmel i2c touchscreen and Synaptics 3k serious i2c  touchscreen.
defconfig: enable sweep2wake
Merge branch 'cm-10.1-wip' into cm-10.1
Linux 3.0.76

commit 27a2f7c50c87691fa4b6a0a8a77f779b8bbe648c
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed May 1 08:57:55 2013 -0700

    Linux 3.0.76

commit 7a0db699f49f9045484cf256316689cd6668f949
Author: Sam Ravnborg <sam@ravnborg.org>
Date:   Tue Dec 27 21:46:53 2011 +0100

    sparc32: support atomic64_t

    commit aea1181b0bd0a09c54546399768f359d1e198e45 upstream, Needed to
    compile ext4 for sparc32 since commit
    503f4bdcc078e7abee273a85ce322de81b18a224

    There is no-one that really require atomic64_t support on sparc32.
    But several drivers fails to build without proper atomic64 support.
    And for an allyesconfig build for sparc32 this is annoying.

    Include the generic atomic64_t support for sparc32.
    This has a text footprint cost:

    $size vmlinux (before atomic64_t support)
       text    data     bss     dec     hex filename
    3578860  134260  108781 3821901  3a514d vmlinux

    $size vmlinux (after atomic64_t support)
       text    data     bss     dec     hex filename
    3579892  130684  108781 3819357  3a475d vmlinux

    text increase (3579892 - 3578860) = 1032 bytes

    data decreases - but I fail to explain why!
    I have rebuild twice to check my numbers.

    Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Andreas Larsson <andreas@gaisler.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8a53479a31bed3ef13f55c6752cb1a3962affcff
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Apr 16 12:55:41 2013 +0000

    net: drop dst before queueing fragments

    [ Upstream commit 97599dc792b45b1669c3cdb9a4b365aad0232f65 ]

    Commit 4a94445c9a5c (net: Use ip_route_input_noref() in input path)
    added a bug in IP defragmentation handling, as non refcounted
    dst could escape an RCU protected section.

    Commit 64f3b9e203bd068 (net: ip_expire() must revalidate route) fixed
    the case of timeouts, but not the general problem.

    Tom Parkin noticed crashes in UDP stack and provided a patch,
    but further analysis permitted us to pinpoint the root cause.

    Before queueing a packet into a frag list, we must drop its dst,
    as this dst has limited lifetime (RCU protected)

    When/if a packet is finally reassembled, we use the dst of the very
    last skb, still protected by RCU and valid, as the dst of the
    reassembled packet.

    Use same logic in IPv6, as there is no need to hold dst references.

    Reported-by: Tom Parkin <tparkin@katalix.com>
    Tested-by: Tom Parkin <tparkin@katalix.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>

commit aad877b259293436b2bdfb1005c9bb29bb17cce5
Author: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Date:   Tue Apr 9 10:07:19 2013 +0800

    netrom: fix invalid use of sizeof in nr_recvmsg()

    [ Upstream commit c802d759623acbd6e1ee9fbdabae89159a513913 ]

    sizeof() when applied to a pointer typed expression gives the size of the
    pointer, not that of the pointed data.
    Introduced by commit 3ce5ef(netrom: fix info leak via msg_name in nr_recvmsg)

    Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dc85f620e827440f520551b2ff6222bc92b00fa9
Author: Mathias Krause <minipli@googlemail.com>
Date:   Sun Apr 7 01:52:00 2013 +0000

    tipc: fix info leaks via msg_name in recv_msg/recv_stream

    [ Upstream commit 60085c3d009b0df252547adb336d1ccca5ce52ec ]

    The code in set_orig_addr() does not initialize all of the members of
    struct sockaddr_tipc when filling the sockaddr info -- namely the union
    is only partly filled. This will make recv_msg() and recv_stream() --
    the only users of this function -- leak kernel stack memory as the
    msg_name member is a local variable in net/socket.c.

    Additionally to that both recv_msg() and recv_stream() fail to update
    the msg_namelen member to 0 while otherwise returning with 0, i.e.
    "success". This is the case for, e.g., non-blocking sockets. This will
    lead to a 128 byte kernel stack leak in net/socket.c.

    Fix the first issue by initializing the memory of the union with
    memset(0). Fix the second one by setting msg_namelen to 0 early as it
    will be updated later if we're going to fill the msg_name member.

    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Jon Maloy <jon.maloy@ericsson.com>
    Cc: Allan Stephens <allan.stephens@windriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8576a59ab9134440a889b6728c49aeea105bacdf
Author: Mathias Krause <minipli@googlemail.com>
Date:   Sun Apr 7 01:51:59 2013 +0000

    rose: fix info leak via msg_name in rose_recvmsg()

    [ Upstream commit 4a184233f21645cf0b719366210ed445d1024d72 ]

    The code in rose_recvmsg() does not initialize all of the members of
    struct sockaddr_rose/full_sockaddr_rose when filling the sockaddr info.
    Nor does it initialize the padding bytes of the structure inserted by
    the compiler for alignment. This will lead to leaking uninitialized
    kernel stack bytes in net/socket.c.

    Fix the issue by initializing the memory used for sockaddr info with
    memset(0).

    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6ccd06ead508da8351bae3aab57a2efba954cb2d
Author: Mathias Krause <minipli@googlemail.com>
Date:   Sun Apr 7 01:51:57 2013 +0000

    netrom: fix info leak via msg_name in nr_recvmsg()

    [ Upstream commits 3ce5efad47b62c57a4f5c54248347085a750ce0e and
      c802d759623acbd6e1ee9fbdabae89159a513913 ]

    In case msg_name is set the sockaddr info gets filled out, as
    requested, but the code fails to initialize the padding bytes of
    struct sockaddr_ax25 inserted by the compiler for alignment. Also
    the sax25_ndigis member does not get assigned, leaking four more
    bytes.

    Both issues lead to the fact that the code will leak uninitialized
    kernel stack bytes in net/socket.c.

    Fix both issues by initializing the memory with memset(0).

    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit af9659917d0547ebb4233635d2dc496d29fd5d7c
Author: Mathias Krause <minipli@googlemail.com>
Date:   Sun Apr 7 01:51:56 2013 +0000

    llc: Fix missing msg_namelen update in llc_ui_recvmsg()

    [ Upstream commit c77a4b9cffb6215a15196ec499490d116dfad181 ]

    For stream sockets the code misses to update the msg_namelen member
    to 0 and therefore makes net/socket.c leak the local, uninitialized
    sockaddr_storage variable to userland -- 128 bytes of kernel stack
    memory. The msg_namelen update is also missing for datagram sockets
    in case the socket is shutting down during receive.

    Fix both issues by setting msg_namelen to 0 early. It will be
    updated later if we're going to fill the msg_name member.

    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cbafa8a778286c4bd59bd0b9c028b416e0e6ac29
Author: Mathias Krause <minipli@googlemail.com>
Date:   Sun Apr 7 01:51:54 2013 +0000

    iucv: Fix missing msg_namelen update in iucv_sock_recvmsg()

    [ Upstream commit a5598bd9c087dc0efc250a5221e5d0e6f584ee88 ]

    The current code does not fill the msg_name member in case it is set.
    It also does not set the msg_namelen member to 0 and therefore makes
    net/socket.c leak the local, uninitialized sockaddr_storage variable
    to userland -- 128 bytes of kernel stack memory.

    Fix that by simply setting msg_namelen to 0 as obviously nobody cared
    about iucv_sock_recvmsg() not filling the msg_name in case it was set.

    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Ursula Braun <ursula.braun@de.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 65f4ea22548ffdd868d9d98cf91f50bc9978fb69
Author: Mathias Krause <minipli@googlemail.com>
Date:   Sun Apr 7 01:51:53 2013 +0000

    irda: Fix missing msg_namelen update in irda_recvmsg_dgram()

    [ Upstream commit 5ae94c0d2f0bed41d6718be743985d61b7f5c47d ]

    The current code does not fill the msg_name member in case it is set.
    It also does not set the msg_namelen member to 0 and therefore makes
    net/socket.c leak the local, uninitialized sockaddr_storage variable
    to userland -- 128 bytes of kernel stack memory.

    Fix that by simply setting msg_namelen to 0 as obviously nobody cared
    about irda_recvmsg_dgram() not filling the msg_name in case it was
    set.

    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Samuel Ortiz <samuel@sortiz.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3aa981cd3ed0ebaecde34fda510602f43180b37e
Author: Mathias Krause <minipli@googlemail.com>
Date:   Sun Apr 7 01:51:52 2013 +0000

    caif: Fix missing msg_namelen update in caif_seqpkt_recvmsg()

    [ Upstream commit 2d6fbfe733f35c6b355c216644e08e149c61b271 ]

    The current code does not fill the msg_name member in case it is set.
    It also does not set the msg_namelen member to 0 and therefore makes
    net/socket.c leak the local, uninitialized sockaddr_storage variable
    to userland -- 128 bytes of kernel stack memory.

    Fix that by simply setting msg_namelen to 0 as obviously nobody cared
    about caif_seqpkt_recvmsg() not filling the msg_name in case it was
    set.

    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Sjur Braendeland <sjur.brandeland@stericsson.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ebffd4ef7c48ec51176e5214d344eddf7283fa35
Author: Mathias Krause <minipli@googlemail.com>
Date:   Sun Apr 7 01:51:50 2013 +0000

    Bluetooth: RFCOMM - Fix missing msg_namelen update in rfcomm_sock_recvmsg()

    [ Upstream commit e11e0455c0d7d3d62276a0c55d9dfbc16779d691 ]

    If RFCOMM_DEFER_SETUP is set in the flags, rfcomm_sock_recvmsg() returns
    early with 0 without updating the possibly set msg_namelen member. This,
    in turn, leads to a 128 byte kernel stack leak in net/socket.c.

    Fix this by updating msg_namelen in this case. For all other cases it
    will be handled in bt_sock_stream_recvmsg().

    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Marcel Holtmann <marcel@holtmann.org>
    Cc: Gustavo Padovan <gustavo@padovan.org>
    Cc: Johan Hedberg <johan.hedberg@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0a740ea0de6c84544fe8e68d235da75341f30edd
Author: Mathias Krause <minipli@googlemail.com>
Date:   Sun Apr 7 01:51:49 2013 +0000

    Bluetooth: fix possible info leak in bt_sock_recvmsg()

    [ Upstream commit 4683f42fde3977bdb4e8a09622788cc8b5313778 ]

    In case the socket is already shutting down, bt_sock_recvmsg() returns
    with 0 without updating msg_namelen leading to net/socket.c leaking the
    local, uninitialized sockaddr_storage variable to userland -- 128 bytes
    of kernel stack memory.

    Fix this by moving the msg_namelen assignment in front of the shutdown
    test.

    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Marcel Holtmann <marcel@holtmann.org>
    Cc: Gustavo Padovan <gustavo@padovan.org>
    Cc: Johan Hedberg <johan.hedberg@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9a627f671963d81b5fdf910ddcba905328215b1f
Author: Mathias Krause <minipli@googlemail.com>
Date:   Sun Apr 7 01:51:48 2013 +0000

    ax25: fix info leak via msg_name in ax25_recvmsg()

    [ Upstream commit ef3313e84acbf349caecae942ab3ab731471f1a1 ]

    When msg_namelen is non-zero the sockaddr info gets filled out, as
    requested, but the code fails to initialize the padding bytes of struct
    sockaddr_ax25 inserted by the compiler for alignment. Additionally the
    msg_namelen value is updated to sizeof(struct full_sockaddr_ax25) but is
    not always filled up to this size.

    Both issues lead to the fact that the code will leak uninitialized
    kernel stack bytes in net/socket.c.

    Fix both issues by initializing the memory with memset(0).

    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8d5746899e9a140317c229401bfcf844a11a0247
Author: Mathias Krause <minipli@googlemail.com>
Date:   Sun Apr 7 01:51:47 2013 +0000

    atm: update msg_namelen in vcc_recvmsg()

    [ Upstream commit 9b3e617f3df53822345a8573b6d358f6b9e5ed87 ]

    The current code does not fill the msg_name member in case it is set.
    It also does not set the msg_namelen member to 0 and therefore makes
    net/socket.c leak the local, uninitialized sockaddr_storage variable
    to userland -- 128 bytes of kernel stack memory.

    Fix that by simply setting msg_namelen to 0 as obviously nobody cared
    about vcc_recvmsg() not filling the msg_name in case it was set.

    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 73d2de1ad017f674ec21e57405e47028dbc884bf
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri Apr 19 15:32:32 2013 +0000

    net: fix incorrect credentials passing

    [ Upstream commit 83f1b4ba917db5dc5a061a44b3403ddb6e783494 ]

    Commit 257b5358b32f ("scm: Capture the full credentials of the scm
    sender") changed the credentials passing code to pass in the effective
    uid/gid instead of the real uid/gid.

    Obviously this doesn't matter most of the time (since normally they are
    the same), but it results in differences for suid binaries when the wrong
    uid/gid ends up being used.

    This just undoes that (presumably unintentional) part of the commit.

    Reported-by: Andy Lutomirski <luto@amacapital.net>
    Cc: Eric W. Biederman <ebiederm@xmission.com>
    Cc: Serge E. Hallyn <serge@hallyn.com>
    Cc: David S. Miller <davem@davemloft.net>
    Cc: stable@vger.kernel.org
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7c79dac82743cab718a07520617810eb5fb8eb56
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Apr 19 07:19:48 2013 +0000

    tcp: call tcp_replace_ts_recent() from tcp_ack()

    [ Upstream commit 12fb3dd9dc3c64ba7d64cec977cca9b5fb7b1d4e ]

    commit bd090dfc634d (tcp: tcp_replace_ts_recent() should not be called
    from tcp_validate_incoming()) introduced a TS ecr bug in slow path
    processing.

    1 A > B P. 1:10001(10000) ack 1 <nop,nop,TS val 1001 ecr 200>
    2 B < A . 1:1(0) ack 1 win 257 <sack 9001:10001,TS val 300 ecr 1001>
    3 A > B . 1:1001(1000) ack 1 win 227 <nop,nop,TS val 1002 ecr 200>
    4 A > B . 1001:2001(1000) ack 1 win 227 <nop,nop,TS val 1002 ecr 200>

    (ecr 200 should be ecr 300 in packets 3 & 4)

    Problem is tcp_ack() can trigger send of new packets (retransmits),
    reflecting the prior TSval, instead of the TSval contained in the
    currently processed incoming packet.

    Fix this by calling tcp_replace_ts_recent() from tcp_ack() after the
    checks, but before the actions.

    Reported-by: Yuchung Cheng <ycheng@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Neal Cardwell <ncardwell@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>

commit eaaeae50ea0230be49e4aca5ec48f6978537a242
Author: Daniel Borkmann <dborkman@redhat.com>
Date:   Thu Feb 7 00:55:37 2013 +0000

    net: sctp: sctp_auth_key_put: use kzfree instead of kfree

    [ Upstream commit 586c31f3bf04c290dc0a0de7fc91d20aa9a5ee53 ]

    For sensitive data like keying material, it is common practice to zero
    out keys before returning the memory back to the allocator. Thus, use
    kzfree instead of kfree.

    Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Acked-by: Vlad Yasevich <vyasevich@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fe18256f3e2410e574cc48dbf033a706d000b0ff
Author: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Date:   Sat Apr 13 15:49:03 2013 +0000

    esp4: fix error return code in esp_output()

    [ Upstream commit 06848c10f720cbc20e3b784c0df24930b7304b93 ]

    Fix to return a negative error code from the error handling
    case instead of 0, as returned elsewhere in this function.

    Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
    Acked-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7b14772957275672b360e5ebd5604623561e0f30
Author: Dmitry Popov <dp@highloadlab.com>
Date:   Thu Apr 11 08:55:07 2013 +0000

    tcp: incoming connections might use wrong route under synflood

    [ Upstream commit d66954a066158781ccf9c13c91d0316970fe57b6 ]

    There is a bug in cookie_v4_check (net/ipv4/syncookies.c):
    	flowi4_init_output(&fl4, 0, sk->sk_mark, RT_CONN_FLAGS(sk),
    			   RT_SCOPE_UNIVERSE, IPPROTO_TCP,
    			   inet_sk_flowi_flags(sk),
    			   (opt && opt->srr) ? opt->faddr : ireq->rmt_addr,
    			   ireq->loc_addr, th->source, th->dest);

    Here we do not respect sk->sk_bound_dev_if, therefore wrong dst_entry may be
    taken. This dst_entry is used by new socket (get_cookie_sock ->
    tcp_v4_syn_recv_sock), so its packets may take the wrong path.

    Signed-off-by: Dmitry Popov <dp@highloadlab.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f5045d1c27676a8714142cd082e6b0e0e3e10138
Author: Michael Riesch <michael.riesch@omicron.at>
Date:   Mon Apr 8 05:45:26 2013 +0000

    rtnetlink: Call nlmsg_parse() with correct header length

    [ Upstream commit 88c5b5ce5cb57af6ca2a7cf4d5715fa320448ff9 ]

    Signed-off-by: Michael Riesch <michael.riesch@omicron.at>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Jiri Benc <jbenc@redhat.com>
    Cc: "Theodore Ts'o" <tytso@mit.edu>
    Cc: linux-kernel@vger.kernel.org
    Acked-by: Mark Rustad <mark.d.rustad@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a57d91ae48c1bca556dcde0d0a6273f7d8fabe1e
Author: Patrick McHardy <kaber@trash.net>
Date:   Fri Apr 5 20:42:05 2013 +0200

    netfilter: don't reset nf_trace in nf_reset()

    [ Upstream commit 124dff01afbdbff251f0385beca84ba1b9adda68 ]

    Commit 130549fe ("netfilter: reset nf_trace in nf_reset") added code
    to reset nf_trace in nf_reset(). This is wrong and unnecessary.

    nf_reset() is used in the following cases:

    - when passing packets up the the socket layer, at which point we want to
      release all netfilter references that might keep modules pinned while
      the packet is queued. nf_trace doesn't matter anymore at this point.

    - when encapsulating or decapsulating IPsec packets. We want to continue
      tracing these packets after IPsec processing.

    - when passing packets through virtual network devices. Only devices on
      that encapsulate in IPv4/v6 matter since otherwise nf_trace is not
      used anymore. Its not entirely clear whether those packets should
      be traced after that, however we've always done that.

    - when passing packets through virtual network devices that make the
      packet cross network namespace boundaries. This is the only cases
      where we clearly want to reset nf_trace and is also what the
      original patch intended to fix.

    Add a new function nf_reset_trace() and use it in dev_forward_skb() to
    fix this properly.

    Signed-off-by: Patrick McHardy <kaber@trash.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d0625c06de1e0a10d00e207ad97ebcb9e337534d
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Wed Apr 3 16:14:47 2013 +0000

    af_unix: If we don't care about credentials coallesce all messages

    [ Upstream commit 0e82e7f6dfeec1013339612f74abc2cdd29d43d2 ]

    It was reported that the following LSB test case failed
    https://lsbbugs.linuxfoundation.org/attachment.cgi?id=2144 because we
    were not coallescing unix stream messages when the application was
    expecting us to.

    The problem was that the first send was before the socket was accepted
    and thus sock->sk_socket was NULL in maybe_add_creds, and the second
    send after the socket was accepted had a non-NULL value for sk->socket
    and thus we could tell the credentials were not needed so we did not
    bother.

    The unnecessary credentials on the first message cause
    unix_stream_recvmsg to start verifying that all messages had the same
    credentials before coallescing and then the coallescing failed because
    the second message had no credentials.

    Ignoring credentials when we don't care in unix_stream_recvmsg fixes a
    long standing pessimization which would fail to coallesce messages when
    reading from a unix stream socket if the senders were different even if
    we did not care about their credentials.

    I have tested this and verified that the in the LSB test case mentioned
    above that the messages do coallesce now, while the were failing to
    coallesce without this change.

    Reported-by: Karel Srot <ksrot@redhat.com>
    Reported-by: Ding Tianhong <dingtianhong@huawei.com>
    Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3c53e8d24e96e85acf028dc4ccb1e60a5486f47d
Author: nikolay@redhat.com <nikolay@redhat.com>
Date:   Thu Apr 11 09:18:56 2013 +0000

    bonding: IFF_BONDING is not stripped on enslave failure

    [ Upstream commit b6a5a7b9a528a8b4c8bec940b607c5dd9102b8cc ]

    While enslaving a new device and after IFF_BONDING flag is set, in case
    of failure it is not stripped from the device's priv_flags while
    cleaning up, which could lead to other problems.
    Cleaning at err_close because the flag is set after dev_open().

    v2: no change

    Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit abd70dfd7e1df706a70fb9fa7d7777cf4428fe2c
Author: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date:   Tue Apr 2 14:36:46 2013 +0000

    atl1e: limit gso segment size to prevent generation of wrong ip length fields

    [ Upstream commit 31d1670e73f4911fe401273a8f576edc9c2b5fea ]

    The limit of 0x3c00 is taken from the windows driver.

    Suggested-by: Huang, Xiong <xiong@qca.qualcomm.com>
    Cc: Huang, Xiong <xiong@qca.qualcomm.com>
    Cc: Eric Dumazet <eric.dumazet@gmail.com>
    Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d569e833b770b21d29147c1ed937ab3882647252
Author: Vlad Yasevich <vyasevic@redhat.com>
Date:   Tue Apr 2 17:10:07 2013 -0400

    net: count hw_addr syncs so that unsync works properly.

    [ Upstream commit 4543fbefe6e06a9e40d9f2b28d688393a299f079 ]

    A few drivers use dev_uc_sync/unsync to synchronize the
    address lists from master down to slave/lower devices.  In
    some cases (bond/team) a single address list is synched down
    to multiple devices.  At the time of unsync, we have a leak
    in these lower devices, because "synced" is treated as a
    boolean and the address will not be unsynced for anything after
    the first device/call.

    Treat "synced" as a count (same as refcount) and allow all
    unsync calls to work.

    Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6ac784dcc8f749f83bc551684044f15a544fc5fd
Author: Balakumaran Kannan <kumaran.4353@gmail.com>
Date:   Tue Apr 2 16:15:05 2013 +0530

    net IPv6 : Fix broken IPv6 routing table after loopback down-up

    [ Upstream commit 25fb6ca4ed9cad72f14f61629b68dc03c0d9713f ]

    IPv6 Routing table becomes broken once we do ifdown, ifup of the loopback(lo)
    interface. After down-up, routes of other interface's IPv6 addresses through
    'lo' are lost.

    IPv6 addresses assigned to all interfaces are routed through 'lo' for internal
    communication. Once 'lo' is down, those routing entries are removed from routing
    table. But those removed entries are not being re-created properly when 'lo' is
    brought up. So IPv6 addresses of other interfaces becomes unreachable from the
    same machine. Also this breaks communication with other machines because of
    NDISC packet processing failure.

    This patch fixes this issue by reading all interface's IPv6 addresses and adding
    them to IPv6 routing table while bringing up 'lo'.

    ==Testing==
    Before applying the patch:
    $ route -A inet6
    Kernel IPv6 routing table
    Destination                    Next Hop                   Flag Met Ref Use If
    2000::20/128                   ::                         U    256 0     0 eth0
    fe80::/64                      ::                         U    256 0     0 eth0
    ::/0                           ::                         !n   -1  1     1 lo
    ::1/128                        ::                         Un   0   1     0 lo
    2000::20/128                   ::                         Un   0   1     0 lo
    fe80::xxxx:xxxx:xxxx:xxxx/128  ::                         Un   0   1     0 lo
    ff00::/8                       ::                         U    256 0     0 eth0
    ::/0                           ::                         !n   -1  1     1 lo
    $ sudo ifdown lo
    $ sudo ifup lo
    $ route -A inet6
    Kernel IPv6 routing table
    Destination                    Next Hop                   Flag Met Ref Use If
    2000::20/128                   ::                         U    256 0     0 eth0
    fe80::/64                      ::                         U    256 0     0 eth0
    ::/0                           ::                         !n   -1  1     1 lo
    ::1/128                        ::                         Un   0   1     0 lo
    ff00::/8                       ::                         U    256 0     0 eth0
    ::/0                           ::                         !n   -1  1     1 lo
    $

    After applying the patch:
    $ route -A inet6
    Kernel IPv6 routing
    table
    Destination                    Next Hop                   Flag Met Ref Use If
    2000::20/128                   ::                         U    256 0     0 eth0
    fe80::/64                      ::                         U    256 0     0 eth0
    ::/0                           ::                         !n   -1  1     1 lo
    ::1/128                        ::                         Un   0   1     0 lo
    2000::20/128                   ::                         Un   0   1     0 lo
    fe80::xxxx:xxxx:xxxx:xxxx/128  ::                         Un   0   1     0 lo
    ff00::/8                       ::                         U    256 0     0 eth0
    ::/0                           ::                         !n   -1  1     1 lo
    $ sudo ifdown lo
    $ sudo ifup lo
    $ route -A inet6
    Kernel IPv6 routing table
    Destination                    Next Hop                   Flag Met Ref Use If
    2000::20/128                   ::                         U    256 0     0 eth0
    fe80::/64                      ::                         U    256 0     0 eth0
    ::/0                           ::                         !n   -1  1     1 lo
    ::1/128                        ::                         Un   0   1     0 lo
    2000::20/128                   ::                         Un   0   1     0 lo
    fe80::xxxx:xxxx:xxxx:xxxx/128  ::                         Un   0   1     0 lo
    ff00::/8                       ::                         U    256 0     0 eth0
    ::/0                           ::                         !n   -1  1     1 lo
    $

    Signed-off-by: Balakumaran Kannan <Balakumaran.Kannan@ap.sony.com>
    Signed-off-by: Maruthi Thotad <Maruthi.Thotad@ap.sony.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f7b8a0f5795aca696f78042db1b8c4b3d07e04c5
Author: Vasily Averin <vvs@parallels.com>
Date:   Mon Apr 1 03:01:32 2013 +0000

    cbq: incorrect processing of high limits

    [ Upstream commit f0f6ee1f70c4eaab9d52cf7d255df4bd89f8d1c2 ]

    currently cbq works incorrectly for limits > 10% real link bandwidth,
    and practically does not work for limits > 50% real link bandwidth.
    Below are results of experiments taken on 1 Gbit link

     In shaper | Actual Result
    -----------+---------------
      100M     | 108 Mbps
      200M     | 244 Mbps
      300M     | 412 Mbps
      500M     | 893 Mbps

    This happen because of q->now changes incorrectly in cbq_dequeue():
    when it is called before real end of packet transmitting,
    L2T is greater than real time delay, q_now gets an extra boost
    but never compensate it.

    To fix this problem we prevent change of q->now until its synchronization
    with real time.

    Signed-off-by: Vasily Averin <vvs@openvz.org>
    Reviewed-by: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
    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>

commit 9758b79c56ae6dc93f660928a0d389ba45e530ed
Author: David S. Miller <davem@davemloft.net>
Date:   Fri Apr 19 17:26:26 2013 -0400

    sparc64: Fix race in TLB batch processing.

    [ Commits f36391d2790d04993f48da6a45810033a2cdf847 and
      f0af97070acbad5d6a361f485828223a4faaa0ee upstream. ]

    As reported by Dave Kleikamp, when we emit cross calls to do batched
    TLB flush processing we have a race because we do not synchronize on
    the sibling cpus completing the cross call.

    So meanwhile the TLB batch can be reset (tb->tlb_nr set to zero, etc.)
    and either flushes are missed or flushes will flush the wrong
    addresses.

    Fix this by using generic infrastructure to synchonize on the
    completion of the cross call.

    This first required getting the flush_tlb_pending() call out from
    switch_to() which operates with locks held and interrupts disabled.
    The problem is that smp_call_function_many() cannot be invoked with
    IRQs disabled and this is explicitly checked for with WARN_ON_ONCE().

    We get the batch processing outside of locked IRQ disabled sections by
    using some ideas from the powerpc port. Namely, we only batch inside
    of arch_{enter,leave}_lazy_mmu_mode() calls.  If we're not in such a
    region, we flush TLBs synchronously.

    1) Get rid of xcall_flush_tlb_pending and per-cpu type
       implementations.

    2) Do TLB batch cross calls instead via:

    	smp_call_function_many()
    		tlb_pending_func()
    			__flush_tlb_pending()

    3) Batch only in lazy mmu sequences:

    	a) Add 'active' member to struct tlb_batch
    	b) Define __HAVE_ARCH_ENTER_LAZY_MMU_MODE
    	c) Set 'active' in arch_enter_lazy_mmu_mode()
    	d) Run batch and clear 'active' in arch_leave_lazy_mmu_mode()
    	e) Check 'active' in tlb_batch_add_one() and do a synchronous
               flush if it's clear.

    4) Add infrastructure for synchronous TLB page flushes.

    	a) Implement __flush_tlb_page and per-cpu variants, patch
    	   as needed.
    	b) Likewise for xcall_flush_tlb_page.
    	c) Implement smp_flush_tlb_page() to invoke the cross-call.
    	d) Wire up global_flush_tlb_page() to the right routine based
               upon CONFIG_SMP

    5) It turns out that singleton batches are very common, 2 out of every
       3 batch flushes have only a single entry in them.

       The batch flush waiting is very expensive, both because of the poll
       on sibling cpu completeion, as well as because passing the tlb batch
       pointer to the sibling cpus invokes a shared memory dereference.

       Therefore, in flush_tlb_pending(), if there is only one entry in
       the batch perform a completely asynchronous global_flush_tlb_page()
       instead.

    Reported-by: Dave Kleikamp <dave.kleikamp@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Acked-by: Dave Kleikamp <dave.kleikamp@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 061bd83c6fd1c22fbcf0357d4b7e306ba5ea8591
Author: Jiri Slaby <jslaby@suse.cz>
Date:   Fri Apr 26 13:48:53 2013 +0200

    TTY: fix atime/mtime regression

    commit 37b7f3c76595e23257f61bd80b223de8658617ee upstream.

    In commit b0de59b5733d ("TTY: do not update atime/mtime on read/write")
    we removed timestamps from tty inodes to fix a security issue and waited
    if something breaks.  Well, 'w', the utility to find out logged users
    and their inactivity time broke.  It shows that users are inactive since
    the time they logged in.

    To revert to the old behaviour while still preventing attackers to
    guess the password length, we update the timestamps in one-minute
    intervals by this patch.

    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6dd4ef3051173062350a4c53a2c4212d3f052e0c
Author: Jiri Slaby <jslaby@suse.cz>
Date:   Fri Feb 15 15:25:05 2013 +0100

    TTY: do not update atime/mtime on read/write

    commit b0de59b5733d18b0d1974a060860a8b5c1b36a2e upstream.

    On http://vladz.devzero.fr/013_ptmx-timing.php, we can see how to find
    out length of a password using timestamps of /dev/ptmx. It is
    documented in "Timing Analysis of Keystrokes and Timing Attacks on
    SSH". To avoid that problem, do not update time when reading
    from/writing to a TTY.

    I am afraid of regressions as this is a behavior we have since 0.97
    and apps may expect the time to be current, e.g. for monitoring
    whether there was a change on the TTY. Now, there is no change. So
    this would better have a lot of testing before it goes upstream.

    References: CVE-2013-0160

    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Merge branch 'cm-10.1-wip' into cm-10.1
Linux 3.0.76

Conflicts:
	Makefile