Linux 3.0.90

commit 91e9a7da140b336243338476341e9980d128ab72
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Aug 11 18:53:59 2013 -0700

    Linux 3.0.90

commit ae338d71b9d692c749a5a9474ee282c9ff9732ea
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Jul 30 13:23:39 2013 +0300

    net_sched: info leak in atm_tc_dump_class()

    [ Upstream commit 8cb3b9c3642c0263d48f31d525bcee7170eedc20 ]

    The "pvc" struct has a hole after pvc.sap_family which is not cleared.

    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Jiri Pirko <jiri@resnulli.us>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dc2599e3803217c2d079cee81191fbfa27cc84d3
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Sun Jul 28 23:04:45 2013 +0300

    af_key: more info leaks in pfkey messages

    [ Upstream commit ff862a4668dd6dba962b1d2d8bd344afa6375683 ]

    This is inspired by a5cc68f3d6 "af_key: fix info leaks in notify
    messages".  There are some struct members which don't get initialized
    and could disclose small amounts of private information.

    Acked-by: Mathias Krause <minipli@googlemail.com>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    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 eaaa6acce02fa975e3d67fd223132e60da31207d
Author: David S. Miller <davem@davemloft.net>
Date:   Tue Jul 30 00:16:21 2013 -0700

    net_sched: Fix stack info leak in cbq_dump_wrr().

    [ Upstream commit a0db856a95a29efb1c23db55c02d9f0ff4f0db48 ]

    Make sure the reserved fields, and padding (if any), are
    fully initialized.

    Based upon a patch by Dan Carpenter and feedback from
    Joe Perches.

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

commit 590c955eaaa18c5f1b341093baa60e0d582ba426
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Jul 23 17:15:54 2013 -0700

    usbnet: do not pretend to support SG/TSO

    [ Upstream commit 20f0170377264e8449b6987041f0bcc4d746d3ed ]

    usbnet doesn't support yet SG, so drivers should not advertise SG or TSO
    capabilities, as they allow TCP stack to build large TSO packets that
    need to be linearized and might use order-5 pages.

    This adds an extra copy overhead and possible allocation failures.

    Current code ignore skb_linearize() return code so crashes are even
    possible.

    Best is to not pretend SG/TSO is supported, and add this again when/if
    usbnet really supports SG for devices who could get a performance gain.

    Based on a prior patch from Freddy Xin <freddy@asix.com.tw>

    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 c4a6cc62e1fe24ab8d3bfe653f7e872a7a5bcd8e
Author: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date:   Mon Jul 22 23:45:53 2013 +0200

    ipv6: take rtnl_lock and mark mrt6 table as freed on namespace cleanup

    [ Upstream commit 905a6f96a1b18e490a75f810d733ced93c39b0e5 ]

    Otherwise we end up dereferencing the already freed net->ipv6.mrt pointer
    which leads to a panic (from Srivatsa S. Bhat):

    BUG: unable to handle kernel paging request at ffff882018552020
    IP: [<ffffffffa0366b02>] ip6mr_sk_done+0x32/0xb0 [ipv6]
    PGD 290a067 PUD 207ffe0067 PMD 207ff1d067 PTE 8000002018552060
    Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
    Modules linked in: ebtable_nat ebtables nfs fscache nf_conntrack_ipv4 nf_defrag_ipv4 ipt_REJECT xt_CHECKSUM iptable_mangle iptable_filter ip_tables nfsd lockd nfs_acl exportfs auth_rpcgss autofs4 sunrpc 8021q garp bridge stp llc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter
    +ip6_tables ipv6 vfat fat vhost_net macvtap macvlan vhost tun kvm_intel kvm uinput iTCO_wdt iTCO_vendor_support cdc_ether usbnet mii microcode i2c_i801 i2c_core lpc_ich mfd_core shpchp ioatdma dca mlx4_core be2net wmi acpi_cpufreq mperf ext4 jbd2 mbcache dm_mirror dm_region_hash dm_log dm_mod
    CPU: 0 PID: 7 Comm: kworker/u33:0 Not tainted 3.11.0-rc1-ea45e-a #4
    Hardware name: IBM  -[8737R2A]-/00Y2738, BIOS -[B2E120RUS-1.20]- 11/30/2012
    Workqueue: netns cleanup_net
    task: ffff8810393641c0 ti: ffff881039366000 task.ti: ffff881039366000
    RIP: 0010:[<ffffffffa0366b02>]  [<ffffffffa0366b02>] ip6mr_sk_done+0x32/0xb0 [ipv6]
    RSP: 0018:ffff881039367bd8  EFLAGS: 00010286
    RAX: ffff881039367fd8 RBX: ffff882018552000 RCX: dead000000200200
    RDX: 0000000000000000 RSI: ffff881039367b68 RDI: ffff881039367b68
    RBP: ffff881039367bf8 R08: ffff881039367b68 R09: 2222222222222222
    R10: 2222222222222222 R11: 2222222222222222 R12: ffff882015a7a040
    R13: ffff882014eb89c0 R14: ffff8820289e2800 R15: 0000000000000000
    FS:  0000000000000000(0000) GS:ffff88103fc00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: ffff882018552020 CR3: 0000000001c0b000 CR4: 00000000000407f0
    Stack:
     ffff881039367c18 ffff882014eb89c0 ffff882015e28c00 0000000000000000
     ffff881039367c18 ffffffffa034d9d1 ffff8820289e2800 ffff882014eb89c0
     ffff881039367c58 ffffffff815bdecb ffffffff815bddf2 ffff882014eb89c0
    Call Trace:
     [<ffffffffa034d9d1>] rawv6_close+0x21/0x40 [ipv6]
     [<ffffffff815bdecb>] inet_release+0xfb/0x220
     [<ffffffff815bddf2>] ? inet_release+0x22/0x220
     [<ffffffffa032686f>] inet6_release+0x3f/0x50 [ipv6]
     [<ffffffff8151c1d9>] sock_release+0x29/0xa0
     [<ffffffff81525520>] sk_release_kernel+0x30/0x70
     [<ffffffffa034f14b>] icmpv6_sk_exit+0x3b/0x80 [ipv6]
     [<ffffffff8152fff9>] ops_exit_list+0x39/0x60
     [<ffffffff815306fb>] cleanup_net+0xfb/0x1a0
     [<ffffffff81075e3a>] process_one_work+0x1da/0x610
     [<ffffffff81075dc9>] ? process_one_work+0x169/0x610
     [<ffffffff81076390>] worker_thread+0x120/0x3a0
     [<ffffffff81076270>] ? process_one_work+0x610/0x610
     [<ffffffff8107da2e>] kthread+0xee/0x100
     [<ffffffff8107d940>] ? __init_kthread_worker+0x70/0x70
     [<ffffffff8162a99c>] ret_from_fork+0x7c/0xb0
     [<ffffffff8107d940>] ? __init_kthread_worker+0x70/0x70
    Code: 20 48 89 5d e8 4c 89 65 f0 4c 89 6d f8 66 66 66 66 90 4c 8b 67 30 49 89 fd e8 db 3c 1e e1 49 8b 9c 24 90 08 00 00 48 85 db 74 06 <4c> 39 6b 20 74 20 bb f3 ff ff ff e8 8e 3c 1e e1 89 d8 4c 8b 65
    RIP  [<ffffffffa0366b02>] ip6mr_sk_done+0x32/0xb0 [ipv6]
     RSP <ffff881039367bd8>
    CR2: ffff882018552020

    Reported-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
    Tested-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.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 a3c7417da6d8cdb421f6614d7ade485ead85da03
Author: Neil Horman <nhorman@tuxdriver.com>
Date:   Wed Jun 12 14:26:44 2013 -0400

    sctp: fully initialize sctp_outq in sctp_outq_init

    [ Upstream commit c5c7774d7eb4397891edca9ebdf750ba90977a69 ]

    In commit 2f94aabd9f6c925d77aecb3ff020f1cc12ed8f86
    (refactor sctp_outq_teardown to insure proper re-initalization)
    we modified sctp_outq_teardown to use sctp_outq_init to fully re-initalize the
    outq structure.  Steve West recently asked me why I removed the q->error = 0
    initalization from sctp_outq_teardown.  I did so because I was operating under
    the impression that sctp_outq_init would properly initalize that value for us,
    but it doesn't.  sctp_outq_init operates under the assumption that the outq
    struct is all 0's (as it is when called from sctp_association_init), but using
    it in __sctp_outq_teardown violates that assumption. We should do a memset in
    sctp_outq_init to ensure that the entire structure is in a known state there
    instead.

    Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
    Reported-by: "West, Steve (NSN - US/Fort Worth)" <steve.west@nsn.com>
    CC: Vlad Yasevich <vyasevich@gmail.com>
    CC: netdev@vger.kernel.org
    CC: davem@davemloft.net
    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 abaf7787fb4339b1c903508624a6e819650626a2
Author: Michal Tesar <mtesar@redhat.com>
Date:   Fri Jul 19 14:09:01 2013 +0200

    sysctl net: Keep tcp_syn_retries inside the boundary

    [ Upstream commit 651e92716aaae60fc41b9652f54cb6803896e0da ]

    Limit the min/max value passed to the
    /proc/sys/net/ipv4/tcp_syn_retries.

    Signed-off-by: Michal Tesar <mtesar@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b04aff391ca61fb2ac4e60be602aa2850c577cdd
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Jul 19 08:48:05 2013 +0300

    arcnet: cleanup sizeof parameter

    [ Upstream commit 087d273caf4f7d3f2159256f255f1f432bc84a5b ]

    This patch doesn't change the compiled code because ARC_HDR_SIZE is 4
    and sizeof(int) is 4, but the intent was to use the header size and not
    the sizeof the header size.

    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 61c0125681895320f2d9e4c0e896b50455b23904
Author: Salman Qazi <sqazi@google.com>
Date:   Thu Jun 14 15:31:09 2012 -0700

    perf: Use css_tryget() to avoid propping up css refcount

    commit 9c5da09d266ca9b32eb16cf940f8161d949c2fe5 upstream.

    An rmdir pushes css's ref count to zero.  However, if the associated
    directory is open at the time, the dentry ref count is non-zero.  If
    the fd for this directory is then passed into perf_event_open, it
    does a css_get().  This bounces the ref count back up from zero.  This
    is a problem by itself.  But what makes it turn into a crash is the
    fact that we end up doing an extra dput, since we perform a dput
    when css_put sees the ref count go down to zero.

    css_tryget() does not fall into that trap. So, we use that instead.

    Reproduction test-case for the bug:

     #include <unistd.h>
     #include <sys/types.h>
     #include <sys/stat.h>
     #include <fcntl.h>
     #include <linux/unistd.h>
     #include <linux/perf_event.h>
     #include <string.h>
     #include <errno.h>
     #include <stdio.h>

     #define PERF_FLAG_PID_CGROUP    (1U << 2)

     int perf_event_open(struct perf_event_attr *hw_event_uptr,
                         pid_t pid, int cpu, int group_fd, unsigned long flags) {
             return syscall(__NR_perf_event_open,hw_event_uptr, pid, cpu,
                     group_fd, flags);
     }

     /*
      * Directly poke at the perf_event bug, since it's proving hard to repro
      * depending on where in the kernel tree.  what moved?
      */
     int main(int argc, char **argv)
     {
            int fd;
            struct perf_event_attr attr;
            memset(&attr, 0, sizeof(attr));
            attr.exclude_kernel = 1;
            attr.size = sizeof(attr);
            mkdir("/dev/cgroup/perf_event/blah", 0777);
            fd = open("/dev/cgroup/perf_event/blah", O_RDONLY);
            perror("open");
            rmdir("/dev/cgroup/perf_event/blah");
            sleep(2);
            perf_event_open(&attr, fd, 0, -1,  PERF_FLAG_PID_CGROUP);
            perror("perf_event_open");
            close(fd);
            return 0;
     }

    Signed-off-by: Salman Qazi <sqazi@google.com>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Acked-by: Tejun Heo <tj@kernel.org>
    Link: http://lkml.kernel.org/r/20120614223108.1025.2503.stgit@dungbeetle.mtv.corp.google.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Cc: Li Zefan <lizefan@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9f65bf026312945f8dfd76a2c6573dd0d81488ed
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Fri Jul 26 09:11:56 2013 -0700

    x86, fpu: correct the asm constraints for fxsave, unbreak mxcsr.daz

    commit eaa5a990191d204ba0f9d35dbe5505ec2cdd1460 upstream.

    GCC will optimize mxcsr_feature_mask_init in arch/x86/kernel/i387.c:

            memset(&fx_scratch, 0, sizeof(struct i387_fxsave_struct));
            asm volatile("fxsave %0" : : "m" (fx_scratch));
            mask = fx_scratch.mxcsr_mask;
            if (mask == 0)
                mask = 0x0000ffbf;

    to

            memset(&fx_scratch, 0, sizeof(struct i387_fxsave_struct));
            asm volatile("fxsave %0" : : "m" (fx_scratch));
            mask = 0x0000ffbf;

    since asm statement doesn’t say it will update fx_scratch.  As the
    result, the DAZ bit will be cleared.  This patch fixes it. This bug
    dates back to at least kernel 2.6.12.

    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e8fbebf6feda80eca5bd8b0afc4dba86ae3b2ff5
Author: Jiri Olsa <jolsa@redhat.com>
Date:   Fri Feb 1 11:23:45 2013 +0100

    perf: Fix event group context move

    commit 0231bb5336758426b44ccd798ccd3c5419c95d58 upstream.

    When we have group with mixed events (hw/sw) we want to end up
    with group leader being in hw context. So if group leader is
    initialy sw event, we move all the events under hw context.

    The move is done for each event by removing it from its context
    and adding it back into proper one. As a part of the removal the
    event is automatically disabled, which is not what we want at
    this stage of creating groups.

    The fix is to initialize event state after removal from sw
    context.

    This fix resulted from the following discussion:

      http://thread.gmane.org/gmane.linux.kernel.perf.user/1144

    Reported-by: Andreas Hollmann <hollmann@in.tum.de>
    Signed-off-by: Jiri Olsa <jolsa@redhat.com>
    Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: Stephane Eranian <eranian@google.com>
    Cc: Vince Weaver <vince@deater.net>
    Link: http://lkml.kernel.org/r/1359714225-4231-1-git-send-email-jolsa@redhat.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Cc: Li Zefan <lizefan@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 14faaa5206ce5970c877f9a8e6384b713e55feb8
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon Aug 5 12:30:29 2013 +0800

    MAINTAINERS: fix up stable_kernel_rules.txt location

    There was a mismerge of 7b175c46720f8e6b92801bb634c93d1016f80c62 for the
    3.0 kernel, so this fixes it up.

    Also mark the stable stuff "Supported", as it is.

    Reported-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0157e289c1a4bdcf3ce388dd4024bf59336e38ce
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon Jul 8 15:59:40 2013 -0700

    fanotify: info leak in copy_event_to_user()

    commit de1e0c40aceb9d5bff09c3a3b97b2f1b178af53f upstream.

    The ->reserved field isn't cleared so we leak one byte of stack
    information to userspace.

    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Cc: Eric Paris <eparis@redhat.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Luis Henriques <luis.henriques@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f34f6f080ecd0677cfc9f7ed173d250a629b045a
Author: Zhu Yanhai <gaoyang.zyh@taobao.com>
Date:   Tue Jan 8 12:56:52 2013 +0800

    sched: Fix the broken sched_rr_get_interval()

    commit a59f4e079d19464eebb9b06513a1d4f55fdae5ba upstream.

    The caller of sched_sliced() should pass se.cfs_rq and se as the
    arguments, however in sched_rr_get_interval() we gave it
    rq.cfs_rq and se, which made the following computation obviously
    wrong.

    The change was introduced by commit:

      77034937dc45 sched: fix crash in sys_sched_rr_get_interval()

    ... 5 years ago, while it had been the correct 'cfs_rq_of' before
    the commit. The change seems to be irrelevant to the commit
    msg, which was to return a 0 timeslice for tasks that are on an
    idle runqueue. So I believe that was just a plain typo.

    Signed-off-by: Zhu Yanhai <gaoyang.zyh@taobao.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Paul Turner <pjt@google.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Link: http://lkml.kernel.org/r/1357621012-15039-1-git-send-email-gaoyang.zyh@taobao.com
    [ Since this is an ABI and an old bug, we'll test this via a
      slow upstream route, to hopefully discover any app breakage. ]
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 09ff7f1fc186c7c45211c8e70761863366e6c7b6
Author: Lan Tianyu <tianyu.lan@intel.com>
Date:   Tue Jul 30 14:00:42 2013 +0200

    ACPI / battery: Fix parsing _BIX return value

    commit 016d5baad04269e8559332df05f89bd95b52d6ad upstream.

    The _BIX method returns extended battery info as a package.
    According the ACPI spec (ACPI 5, Section 10.2.2.2), the first member
    of that package should be "Revision".  However, the current ACPI
    battery driver treats the first member as "Power Unit" which should
    be the second member.  This causes the result of _BIX return data
    parsing to be incorrect.

    Fix this by adding a new member called 'revision' to struct
    acpi_battery and adding the offsetof() information on it to
    extended_info_offsets[] as the first row.

    [rjw: Changelog]
    Reported-and-tested-by: Jan Hoffmann <jan.christian.hoffmann@gmail.com>
    References: http://bugzilla.kernel.org/show_bug.cgi?id=60519
    Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 605e81c987e95f423ee97173a2002363404a1402
Author: Tomasz Moń <desowin@gmail.com>
Date:   Tue Jul 23 07:42:49 2013 +0200

    mwifiex: Add missing endian conversion.

    commit 83e612f632c3897be29ef02e0472f6d63e258378 upstream.

    Both type and pkt_len variables are in host endian and these should be in
    Little Endian in the payload.

    Signed-off-by: Tomasz Moń <desowin@gmail.com>
    Acked-by: Bing Zhao <bzhao@marvell.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0088acabd29e8060552237f4f256b476678c68c2
Author: Stanislaw Gruszka <stf_xl@wp.pl>
Date:   Sun Jul 28 13:17:22 2013 +0200

    rt2x00: fix stop queue

    commit e2288b66fe7ff0288382b2af671b4da558b44472 upstream.

    Since we clear QUEUE_STARTED in rt2x00queue_stop_queue(), following
    call to rt2x00queue_pause_queue() reduce to noop, i.e we do not
    stop queue in mac80211.

    To fix that introduce rt2x00queue_pause_queue_nocheck() function,
    which will stop queue in mac80211 directly.

    Note that rt2x00_start_queue() explicitly set QUEUE_PAUSED bit.

    Note also that reordering operations i.e. first call to
    rt2x00queue_pause_queue() and then clear QUEUE_STARTED bit, will race
    with rt2x00queue_unpause_queue(), so calling ieee80211_stop_queue()
    directly is the only available solution to fix the problem without
    major rework.

    Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d8605bdee3179b21d4467dc5077ffe39ae5a175c
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu Jul 11 22:33:26 2013 +0200

    mac80211: fix duplicate retransmission detection

    commit 6b0f32745dcfba01d7be33acd1b40306c7a914c6 upstream.

    The duplicate retransmission detection code in mac80211
    erroneously attempts to do the check for every frame,
    even frames that don't have a sequence control field or
    that don't use it (QoS-Null frames.)

    This is problematic because it causes the code to access
    data beyond the end of the SKB and depending on the data
    there will drop packets erroneously.

    Correct the code to not do duplicate detection for such
    frames.

    I found this error while testing AP powersave, it lead
    to retransmitted PS-Poll frames being dropped entirely
    as the data beyond the end of the SKB was always zero.

    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8c35e86a798694d5741b2b71c29053fb2b6cd56c
Author: Michal Kazior <michal.kazior@tieto.com>
Date:   Tue Jun 25 09:17:17 2013 +0200

    nl80211: fix mgmt tx status and testmode reporting for netns

    commit a0ec570f4f69c4cb700d743a915096c2c8f56a99 upstream.

    These two events were sent to the default network
    namespace.

    This caused AP mode in a non-default netns to not
    work correctly. Mgmt tx status was multicasted to
    a different (default) netns instead of the one the
    AP was in.

    Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 20d717bb0ff8cf37eedc9edb538c6f7ddc2b44cc
Author: Oleksij Rempel <linux@rempel-privat.de>
Date:   Fri Jul 19 20:16:17 2013 +0200

    ath9k_htc: do some initial hardware configuration

    commit dc2a87f519a4d8cb376ab54f22b6b98a943b51ce upstream.

    Currently we configure harwdare and clock, only after
    interface start. In this case, if we reload module or
    reboot PC without configuring adapter, firmware will freeze.
    There is no software way to reset adpter.

    This patch add initial configuration and set it in
    disabled state, to avoid this freeze. Behaviour of this patch
    should be similar to: ifconfig wlan0 up; ifconfig wlan0 down.

    Bug: https://github.com/qca/open-ath9k-htc-firmware/issues/1
    Tested-by: Bo Shi <cnshibo@gmail.com>
    Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3d709d102bd11c86eddcbf6c50407df19a4fbc34
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Fri Jun 28 11:49:41 2013 +0200

    serial/mxs-auart: increase time to wait for transmitter to become idle

    commit 079a036f4283e2b0e5c26080b8c5112bc0cc1831 upstream.

    Without this patch the driver waits ~1 ms for the UART to become idle. At
    115200n8 this time is (theoretically) enough to transfer 11.5 characters
    (= 115200 bits/s / (10 Bits/char) * 1ms). As the mxs-auart has a fifo size
    of 16 characters the clock is gated too early. The problem is worse for
    lower baud rates.

    This only happens to really shut down the transmitter in the middle of a
    transfer if /dev/ttyAPPx isn't opened in userspace (e.g. by a getty) but
    was at least once (because the bootloader doesn't disable the transmitter).

    So increase the timeout to 20 ms which should be enough for 9600n8, too.
    Moreover skip gating the clock if the timeout is elapsed.

    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8c7e5916a54affa0565428f8926008f0d175ae88
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Thu Jul 4 11:28:51 2013 +0200

    serial/mxs-auart: fix race condition in interrupt handler

    commit d970d7fe65adff5efe75b4a73c4ffc9be57089f7 upstream.

    The handler needs to ack the pending events before actually handling them.
    Otherwise a new event might come in after it it considered non-pending or
    handled and is acked then without being handled. So this event is only
    noticed when the next interrupt happens.

    Without this patch an i.MX28 based machine running an rt-patched kernel
    regularly hangs during boot.

    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linux 3.0.91

commit af4bafb430f94bc8c298a213a792137169bad077
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Aug 14 22:55:43 2013 -0700

    Linux 3.0.91

commit 0e4f7396371a839713b587c33b4a768f15dba9a6
Author: Joshua Zhu <zhu.wen-jie@hp.com>
Date:   Sat Jan 5 13:29:57 2013 +0800

    perf tools: Add anonymous huge page recognition

    commit d0528b5d71faf612014dd7672e44225c915344b2 upstream.

    Judging anonymous memory's vm_area_struct, perf_mmap_event's filename
    will be set to "//anon" indicating this vma belongs to anonymous
    memory.

    Once hugepage is used, vma's vm_file points to hugetlbfs. In this way,
    this vma will not be regarded as anonymous memory by is_anon_memory() in
    perf user space utility.

    Signed-off-by: Joshua Zhu <zhu.wen-jie@hp.com>
    Cc: Akihiro Nagai <akihiro.nagai.hw@hitachi.com>
    Cc: Andi Kleen <andi@firstfloor.org>
    Cc: David Ahern <dsahern@gmail.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Joshua Zhu <zhu.wen-jie@hp.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: Vinson Lee <vlee@freedesktop.org>
    Link: http://lkml.kernel.org/r/1357363797-3550-1-git-send-email-zhu.wen-jie@hp.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 03b9342ba877075b024e3932b43afa68e5d3f0fd
Author: NeilBrown <neilb@suse.de>
Date:   Thu Nov 8 16:09:37 2012 -0800

    vfs: d_obtain_alias() needs to use "/" as default name.

    commit b911a6bdeef5848c468597d040e3407e0aee04ce upstream.

    NFS appears to use d_obtain_alias() to create the root dentry rather than
    d_make_root.  This can cause 'prepend_path()' to complain that the root
    has a weird name if an NFS filesystem is lazily unmounted.  e.g.  if
    "/mnt" is an NFS mount then

     { cd /mnt; umount -l /mnt ; ls -l /proc/self/cwd; }

    will cause a WARN message like
       WARNING: at /home/git/linux/fs/dcache.c:2624 prepend_path+0x1d7/0x1e0()
       ...
       Root dentry has weird name <>

    to appear in kernel logs.

    So change d_obtain_alias() to use "/" rather than "" as the anonymous
    name.

    Signed-off-by: NeilBrown <neilb@suse.de>
    Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    [bwh: Backported to 3.2: use named initialisers instead of QSTR_INIT()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5fc83a91c5d973a204efc619006699da9676e37f
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Thu Mar 14 15:21:36 2013 +0100

    SCSI: nsp32: use mdelay instead of large udelay constants

    commit b497ceb964a80ebada3b9b3cea4261409039e25a upstream.

    ARM cannot handle udelay for more than 2 miliseconds, so we
    should use mdelay instead for those.

    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: GOTO Masanori <gotom@debian.or.jp>
    Cc: YOKOTA Hiroshi <yokota@netlab.is.tsukuba.ac.jp>
    Cc: "James E.J. Bottomley" <JBottomley@parallels.com>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c63eea737793f3562cc62d1395b6b1d325804d27
Author: Andrew Vagin <avagin@openvz.org>
Date:   Fri Aug 2 21:16:43 2013 +0400

    tracing: Fix fields of struct trace_iterator that are zeroed by mistake

    commit ed5467da0e369e65b247b99eb6403cb79172bcda upstream.

    tracing_read_pipe zeros all fields bellow "seq". The declaration contains
    a comment about that, but it doesn't help.

    The first field is "snapshot", it's true when current open file is
    snapshot. Looks obvious, that it should not be zeroed.

    The second field is "started". It was converted from cpumask_t to
    cpumask_var_t (v2.6.28-4983-g4462344), in other words it was
    converted from cpumask to pointer on cpumask.

    Currently the reference on "started" memory is lost after the first read
    from tracing_read_pipe and a proper object will never be freed.

    The "started" is never dereferenced for trace_pipe, because trace_pipe
    can't have the TRACE_FILE_ANNOTATE options.

    Link: http://lkml.kernel.org/r/1375463803-3085183-1-git-send-email-avagin@openvz.org

    Signed-off-by: Andrew Vagin <avagin@openvz.org>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a9d8aaedf15cc981df0aebda88b113eeee9c5cab
Author: Jeff Layton <jlayton@redhat.com>
Date:   Mon Mar 26 09:55:29 2012 -0400

    cifs: silence compiler warnings showing up with gcc-4.7.0

    commit b2a3ad9ca502169fc4c11296fa20f56059c7c031 upstream.

    gcc-4.7.0 has started throwing these warnings when building cifs.ko.

      CC [M]  fs/cifs/cifssmb.o
    fs/cifs/cifssmb.c: In function ‘CIFSSMBSetCIFSACL’:
    fs/cifs/cifssmb.c:3905:9: warning: array subscript is above array bounds [-Warray-bounds]
    fs/cifs/cifssmb.c: In function ‘CIFSSMBSetFileInfo’:
    fs/cifs/cifssmb.c:5711:8: warning: array subscript is above array bounds [-Warray-bounds]
    fs/cifs/cifssmb.c: In function ‘CIFSSMBUnixSetFileInfo’:
    fs/cifs/cifssmb.c:6001:25: warning: array subscript is above array bounds [-Warray-bounds]

    This patch cleans up the code a bit by using the offsetof macro instead
    of the funky "&pSMB->hdr.Protocol" construct.

    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Steve French <sfrench@us.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1b48f57ff205805a81c56c7b480347349bf19620
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Fri Jul 26 17:12:56 2013 +0200

    debugfs: debugfs_remove_recursive() must not rely on list_empty(d_subdirs)

    commit 776164c1faac4966ab14418bb0922e1820da1d19 upstream.

    debugfs_remove_recursive() is wrong,

    1. it wrongly assumes that !list_empty(d_subdirs) means that this
       dir should be removed.

       This is not that bad by itself, but:

    2. if d_subdirs does not becomes empty after __debugfs_remove()
       it gives up and silently fails, it doesn't even try to remove
       other entries.

       However ->d_subdirs can be non-empty because it still has the
       already deleted !debugfs_positive() entries.

    3. simple_release_fs() is called even if __debugfs_remove() fails.

    Suppose we have

        dir1/
            dir2/
                file2
            file1

    and someone opens dir1/dir2/file2.

    Now, debugfs_remove_recursive(dir1/dir2) succeeds, and dir1/dir2 goes
    away.

    But debugfs_remove_recursive(dir1) silently fails and doesn't remove
    this directory. Because it tries to delete (the already deleted)
    dir1/dir2/file2 again and then fails due to "Avoid infinite loop"
    logic.

    Test-case:

        #!/bin/sh

        cd /sys/kernel/debug/tracing
        echo 'p:probe/sigprocmask sigprocmask' >> kprobe_events
        sleep 1000 < events/probe/sigprocmask/id &
        echo -n >| kprobe_events

        [ -d events/probe ] && echo "ERR!! failed to rm probe"

    And after that it is not possible to create another probe entry.

    With this patch debugfs_remove_recursive() skips !debugfs_positive()
    files although this is not strictly needed. The most important change
    is that it does not try to make ->d_subdirs empty, it simply scans
    the whole list(s) recursively and removes as much as possible.

    Link: http://lkml.kernel.org/r/20130726151256.GC19472@redhat.com

    Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1336e0d81c7ea5128f87993907aaff3db71bf973
Author: Amit Shah <amit.shah@redhat.com>
Date:   Mon Jul 29 14:23:21 2013 +0930

    virtio: console: return -ENODEV on all read operations after unplug

    commit 96f97a83910cdb9d89d127c5ee523f8fc040a804 upstream.

    If a port gets unplugged while a user is blocked on read(), -ENODEV is
    returned.  However, subsequent read()s returned 0, indicating there's no
    host-side connection (but not indicating the device went away).

    This also happened when a port was unplugged and the user didn't have
    any blocking operation pending.  If the user didn't monitor the SIGIO
    signal, they won't have a chance to find out if the port went away.

    Fix by returning -ENODEV on all read()s after the port gets unplugged.
    write() already behaves this way.

    Signed-off-by: Amit Shah <amit.shah@redhat.com>
    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7ba6337874c92f15212065b120fa70de573c56ed
Author: Amit Shah <amit.shah@redhat.com>
Date:   Mon Jul 29 14:21:32 2013 +0930

    virtio: console: fix raising SIGIO after port unplug

    commit 92d3453815fbe74d539c86b60dab39ecdf01bb99 upstream.

    SIGIO should be sent when a port gets unplugged.  It should only be sent
    to prcesses that have the port opened, and have asked for SIGIO to be
    delivered.  We were clearing out guest_connected before calling
    send_sigio_to_port(), resulting in a sigio not getting sent to
    processes.

    Fix by setting guest_connected to false after invoking the sigio
    function.

    Signed-off-by: Amit Shah <amit.shah@redhat.com>
    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 64aafc3d30fac8bc65bb28b1bbd97528cb5ef725
Author: Amit Shah <amit.shah@redhat.com>
Date:   Mon Jul 29 14:20:29 2013 +0930

    virtio: console: clean up port data immediately at time of unplug

    commit ea3768b4386a8d1790f4cc9a35de4f55b92d6442 upstream.

    We used to keep the port's char device structs and the /sys entries
    around till the last reference to the port was dropped.  This is
    actually unnecessary, and resulted in buggy behaviour:

    1. Open port in guest
    2. Hot-unplug port
    3. Hot-plug a port with the same 'name' property as the unplugged one

    This resulted in hot-plug being unsuccessful, as a port with the same
    name already exists (even though it was unplugged).

    This behaviour resulted in a warning message like this one:

    -------------------8<---------------------------------------
    WARNING: at fs/sysfs/dir.c:512 sysfs_add_one+0xc9/0x130() (Not tainted)
    Hardware name: KVM
    sysfs: cannot create duplicate filename
    '/devices/pci0000:00/0000:00:04.0/virtio0/virtio-ports/vport0p1'

    Call Trace:
     [<ffffffff8106b607>] ? warn_slowpath_common+0x87/0xc0
     [<ffffffff8106b6f6>] ? warn_slowpath_fmt+0x46/0x50
     [<ffffffff811f2319>] ? sysfs_add_one+0xc9/0x130
     [<ffffffff811f23e8>] ? create_dir+0x68/0xb0
     [<ffffffff811f2469>] ? sysfs_create_dir+0x39/0x50
     [<ffffffff81273129>] ? kobject_add_internal+0xb9/0x260
     [<ffffffff812733d8>] ? kobject_add_varg+0x38/0x60
     [<ffffffff812734b4>] ? kobject_add+0x44/0x70
     [<ffffffff81349de4>] ? get_device_parent+0xf4/0x1d0
     [<ffffffff8134b389>] ? device_add+0xc9/0x650

    -------------------8<---------------------------------------

    Instead of relying on guest applications to release all references to
    the ports, we should go ahead and unregister the port from all the core
    layers.  Any open/read calls on the port will then just return errors,
    and an unplug/plug operation on the host will succeed as expected.

    This also caused buggy behaviour in case of the device removal (not just
    a port): when the device was removed (which means all ports on that
    device are removed automatically as well), the ports with active
    users would clean up only when the last references were dropped -- and
    it would be too late then to be referencing char device pointers,
    resulting in oopses:

    -------------------8<---------------------------------------
    PID: 6162   TASK: ffff8801147ad500  CPU: 0   COMMAND: "cat"
     #0 [ffff88011b9d5a90] machine_kexec at ffffffff8103232b
     #1 [ffff88011b9d5af0] crash_kexec at ffffffff810b9322
     #2 [ffff88011b9d5bc0] oops_end at ffffffff814f4a50
     #3 [ffff88011b9d5bf0] die at ffffffff8100f26b
     #4 [ffff88011b9d5c20] do_general_protection at ffffffff814f45e2
     #5 [ffff88011b9d5c50] general_protection at ffffffff814f3db5
        [exception RIP: strlen+2]
        RIP: ffffffff81272ae2  RSP: ffff88011b9d5d00  RFLAGS: 00010246
        RAX: 0000000000000000  RBX: ffff880118901c18  RCX: 0000000000000000
        RDX: ffff88011799982c  RSI: 00000000000000d0  RDI: 3a303030302f3030
        RBP: ffff88011b9d5d38   R8: 0000000000000006   R9: ffffffffa0134500
        R10: 0000000000001000  R11: 0000000000001000  R12: ffff880117a1cc10
        R13: 00000000000000d0  R14: 0000000000000017  R15: ffffffff81aff700
        ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
     #6 [ffff88011b9d5d00] kobject_get_path at ffffffff8126dc5d
     #7 [ffff88011b9d5d40] kobject_uevent_env at ffffffff8126e551
     #8 [ffff88011b9d5dd0] kobject_uevent at ffffffff8126e9eb
     #9 [ffff88011b9d5de0] device_del at ffffffff813440c7

    -------------------8<---------------------------------------

    So clean up when we have all the context, and all that's left to do when
    the references to the port have dropped is to free up the port struct
    itself.

    Reported-by: chayang <chayang@redhat.com>
    Reported-by: YOGANANTH SUBRAMANIAN <anantyog@in.ibm.com>
    Reported-by: FuXiangChun <xfu@redhat.com>
    Reported-by: Qunfang Zhang <qzhang@redhat.com>
    Reported-by: Sibiao Luo <sluo@redhat.com>
    Signed-off-by: Amit Shah <amit.shah@redhat.com>
    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6c17607b4149b82da3cabffca74c2cdfb8479bb1
Author: Amit Shah <amit.shah@redhat.com>
Date:   Mon Jul 29 14:17:13 2013 +0930

    virtio: console: fix race in port_fops_open() and port unplug

    commit 671bdea2b9f210566610603ecbb6584c8a201c8c upstream.

    Between open() being called and processed, the port can be unplugged.
    Check if this happened, and bail out.

    A simple test script to reproduce this is:

    while true; do for i in $(seq 1 100); do echo $i > /dev/vport0p3; done; done;

    This opens and closes the port a lot of times; unplugging the port while
    this is happening triggers the bug.

    Signed-off-by: Amit Shah <amit.shah@redhat.com>
    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e3a5a432070dcebaffee8f9af193f99471280ea9
Author: Amit Shah <amit.shah@redhat.com>
Date:   Mon Jul 29 14:16:13 2013 +0930

    virtio: console: fix race with port unplug and open/close

    commit 057b82be3ca3d066478e43b162fc082930a746c9 upstream.

    There's a window between find_port_by_devt() returning a port and us
    taking a kref on the port, where the port could get unplugged.  Fix it
    by taking the reference in find_port_by_devt() itself.

    Problem reported and analyzed by Mateusz Guzik.

    Reported-by: Mateusz Guzik <mguzik@redhat.com>
    Signed-off-by: Amit Shah <amit.shah@redhat.com>
    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2e18e5161c634aa5d7e685f348aca98d295accb8
Author: Curt Brune <curt@cumulusnetworks.com>
Date:   Thu Aug 8 12:11:03 2013 -0700

    hwmon: (adt7470) Fix incorrect return code check

    commit 93d783bcca69bfacc8dc739d8a050498402587b5 upstream.

    In adt7470_write_word_data(), which writes two bytes using
    i2c_smbus_write_byte_data(), the return codes are incorrectly AND-ed
    together when they should be OR-ed together.

    The return code of i2c_smbus_write_byte_data() is zero for success.

    The upshot is only the first byte was ever written to the hardware.
    The 2nd byte was never written out.

    I noticed that trying to set the fan speed limits was not working
    correctly on my system.  Setting the fan speed limits is the only
    code that uses adt7470_write_word_data().  After making the change
    the limit settings work and the alarms work also.

    Signed-off-by: Curt Brune <curt@cumulusnetworks.com>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fs/sync: Make sync() satisfy many requests with one invocation

Dave Jones reported RCU stalls, overly long hrtimer interrupts, and
amazingly long NMI handlers from a trinity-induced workload involving
lots of concurrent sync() calls (https://lkml.org/lkml/2013/7/23/369).
There are any number of things that one might do to make sync() behave
better under high levels of contention, but it is also the case that
multiple concurrent sync() system calls can be satisfied by a single
sys_sync() invocation.

Given that this situation is reminiscent of rcu_barrier(), this commit
applies the rcu_barrier() approach to sys_sync().  This approach uses
a global mutex and a sequence counter.  The mutex is held across the
sync() operation, which eliminates contention between concurrent sync()
operations.  The counter is incremented at the beginning and end of
each sync() operation, so that it is odd while a sync() operation is in
progress and even otherwise, just like sequence locks.

The code that used to be in sys_sync() is now in do_sync(), and sys_sync()
now handles the concurrency.  The sys_sync() function first takes a
snapshot of the counter, then acquires the mutex, and then takes another
snapshot of the counter.  If the values of the two snapshots indicate that
a full do_sync() executed during the mutex acquisition, the sys_sync()
function releases the mutex and returns ("Our work is done!").  Otherwise,
sys_sync() increments the counter, invokes do_sync(), and increments
the counter again.

This approach allows a single call to do_sync() to satisfy an arbitrarily
large number of sync() system calls, which should eliminate issues due
to large numbers of concurrent invocations of the sync() system call.

Changes since v1 (https://lkml.org/lkml/2013/7/24/683):

o	Add a pair of memory barriers to keep the increments from
	bleeding into the do_sync() code.  (The failure probability
	is insanely low, but when you have several hundred million
	devices running Linux, you can expect several hundred instances
	of one-in-a-million failures.)

o	Actually CC some people who have experience in this area.

Reported-by: Dave Jones <davej@redhat.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Jan Kara <jack@suse.cz>
Cc: Curt Wohlgemuth <curtw@google.com>
Cc: Jens Axboe <jaxboe@fusionio.com>
Cc: linux-fsdevel@vger.kernel.org

Signed-off-by: Paul Reioux <reioux@gmail.com>
decompressor: Add LZ4 decompressor module

Date	Tue, 26 Feb 2013 15:24:27 +0900

This patch adds support for LZ4 decompression in the Linux Kernel.
LZ4 Decompression APIs for kernel are based on LZ4 implementation
by Yann Collet.

LZ4 homepage : http://fastcompression.blogspot.com/p/lz4.html
LZ4 source repository : http://code.google.com/p/lz4/

Signed-off-by: Kyungsik Lee <kyungsik.lee@lge.com>

v2:
- Clean up code
- Enable unaligned access for ARM v6 and above with
  CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
- Add lz4_decompress() for faster decompression with
  uncompressed output size

Signed-off-by: Paul Reioux <reioux@gmail.com>
lib: Add support for LZ4-compressed kernel

Date	Tue, 26 Feb 2013 15:24:28 +0900

This patch adds support for extracting LZ4-compressed kernel images,
as well as LZ4-compressed ramdisk images in the kernel boot process.

This depends on the patch below
decompressor: Add LZ4 decompressor module

Signed-off-by: Kyungsik Lee <kyungsik.lee@lge.com>

v2:
- Clean up code
- Use lz4_decompress() for LZ4-compressed kernel during boot-process

Signed-off-by: Paul Reioux <reioux@gmail.com>
arm: Add support for LZ4-compressed kernel

Date	Tue, 26 Feb 2013 15:24:29 +0900

This patch integrates the LZ4 decompression code to the arm pre-boot code.
And it depends on two patchs below

lib: Add support for LZ4-compressed kernel
decompressor: Add LZ4 decompressor module

Signed-off-by: Kyungsik Lee <kyungsik.lee@lge.com>

v2:
- Apply CFLAGS, -Os to decompress.o to improve decompress
  performance during boot-up process

Signed-off-by: Paul Reioux <reioux@gmail.com>

Conflicts:
	arch/arm/boot/compressed/decompress.c
lib: Add lz4 compressor module

From	Chanho Min <>

This patch adds support for LZ4 compression in the Linux Kernel.
LZ4 Compression APIs for kernel are based on LZ4 implementation
by Yann Collet and changed with kernel coding style.

LZ4 homepage : http://fastcompression.blogspot.com/p/lz4.html
LZ4 source repository : http://code.google.com/p/lz4/
svn revision : r90

Two APIs are added:
lz4_compress() support basic lz4 compression whereas lz4hc_compress() support
high compression or CPU performance get lower but compression ratio get higher.
Also, we require the pre-allocated working memory with the defined size and
destination buffer must be allocated with the size of lz4_compressbound.

Signed-off-by: Chanho Min <chanho.min@lge.com>

Signed-off-by: Paul Reioux <reioux@gmail.com>
crypto: Add lz4 Cryptographic API

From	Chanho Min <>

This patch adds support for lz4 and lz4hc compression algorithm
using the lib/lz4/* codebase.
Signed-off-by: Chanho Min <chanho.min@lge.com>

Signed-off-by: Paul Reioux <reioux@gmail.com>
lib/lz4/lz4_compress: fix macro usage error

Signed-off-by: Paul Reioux <reioux@gmail.com>
LZ4: compression/decompression signedness mismatch (v2)

LZ4 compression and decompression functions require different
in signedness input/output parameters: unsigned char for
compression and signed char for decompression.

Change decompression API to require "(const) unsigned char *".

v2: minor coding style fix.

Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>

Signed-off-by: Paul Reioux <reioux@gmail.com>
staging: zram: add Crypto API support

Date    Tue, 30 Jul 2013 14:30:48 +0200

Current version of zram does not allow any substitution of a default
compression algorithm. Therefore, I decided to change the existing
implementation of page compression by adding Crypto API compability.

All direct calls to lzo1x compression/decompression methods are now
replaced by calls consistent with Crypto. Also, I removed "workmem"
field from struct zram_meta, as it was there for lzo1x purposes only
and is no longer needed. Finally, I added a set of functions required
by Crypto API to work properly.

In order to substitute the default algorithm (lzo), change the value
of zram.compressor module parameter to a proper name (e.g. lz4).

Signed-off-by: Piotr Sarna <p.sarna@partner.samsung.com>
Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>

backported to Linux 3.0 by faux123

Signed-off-by: Paul Reioux <reioux@gmail.com>
staging: zram: add per-cpu support to Crypto

Date	Tue, 30 Jul 2013 14:30:49 +0200

Since original zram code did not implement any per-cpu operations,
my previous patch (staging: zram: add Crypto API support) did not
include them either.

This patch complements the first one with per-cpu support for Crypto,
allocating tfms buffer separately for each online processor.
Changes are based on zswap and zcache per-cpu code.

Basic tests (concurrent writing several 10-40MB chunks to zram) performed
on an ARM-based EXYNOS4412 Quad-Core showed that per-cpu code provides
noticeable time saving, ranging between 30-40% for LZO and LZ4 compressors.
Sample data (LZO): writing 160MB, 40MB per thread took 0.60s with per-cpu
code included and approximately 0.80s without per-cpu support.

Signed-off-by: Piotr Sarna <p.sarna@partner.samsung.com>
Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>

backported to Linux 3.4 by faux123
Signed-off-by: Paul Reioux <reioux@gmail.com>
zram_drv: switch default compressor to new lz4

Signed-off-by: Paul Reioux <reioux@gmail.com>
zcache-main.c: use MACRO define instead of hardcoded default of lzo

Signed-off-by: Paul Reioux <reioux@gmail.com>
zcache-main: switch to lz4 as default

Signed-off-by: Paul Reioux <reioux@gmail.com>
defconfig: enable LZ4 (faux123)
squashed set of LZ4 reverts
Linux 3.0.92

commit 497c6eb673d94487cfde35c7077981733fe862fb
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Aug 20 08:21:23 2013 -0700

    Linux 3.0.92

commit c4e462a085dd8279af22493ad0858d73e0bcafe1
Author: Andreas Schwab <schwab@linux-m68k.org>
Date:   Fri Aug 9 15:14:08 2013 +0200

    m68k: Truncate base in do_div()

    commit ea077b1b96e073eac5c3c5590529e964767fc5f7 upstream.

    Explicitly truncate the second operand of do_div() to 32 bits to guard
    against bogus code calling it with a 64-bit divisor.

    [Thorsten]

    After upgrading from 3.2 to 3.10, mounting a btrfs volume fails with:

    btrfs: setting nodatacow, compression disabled
    btrfs: enabling auto recovery
    btrfs: disk space caching is enabled
     *** ZERO DIVIDE ***   FORMAT=2
    Current process id is 722
    BAD KERNEL TRAP: 00000000
    Modules linked in: evdev mac_hid ext4 crc16 jbd2 mbcache btrfs xor lzo_compress zlib_deflate raid6_pq crc32c libcrc32c
    PC: [<319535b2>] __btrfs_map_block+0x11c/0x119a [btrfs]
    SR: 2000  SP: 30c1fab4  a2: 30f0faf0
    d0: 00000000    d1: 00001000    d2: 00000000    d3: 00000000
    d4: 00010000    d5: 00000000    a0: 3085c72c    a1: 3085c72c
    Process mount (pid: 722, task=30f0faf0)
    Frame format=2 instr addr=319535ae
    Stack from 30c1faec:
            00000000 00000020 00000000 00001000 00000000 01401000 30253928 300ffc00
            00a843ac 3026f640 00000000 00010000 0009e250 00d106c0 00011220 00000000
            00001000 301c6830 0009e32a 000000ff 00000009 3085c72c 00000000 00000000
            30c1fd14 00000000 00000020 00000000 30c1fd14 0009e26c 00000020 00000003
            00000000 0009dd8a 300b0b6c 30253928 00a843ac 00001000 00000000 00000000
            0000a008 3194e76a 30253928 00a843ac 00001000 00000000 00000000 00000002
    Call Trace: [<00001000>] kernel_pg_dir+0x0/0x1000

        [...]

    Code: 222e ff74 2a2e ff5c 2c2e ff60 4c45 1402 <2d40> ff64 2d41 ff68 2205 4c2e 1800 ff68 4c04 0800 2041 d1c0 2206 4c2e 1400 ff68

    [Geert]

    As diagnosed by Andreas, fs/btrfs/volumes.c:__btrfs_map_block()
    calls

        do_div(stripe_nr, stripe_len);

    with stripe_len u64, while do_div() assumes the divisor is a 32-bit number.

    Due to the lack of truncation in the m68k-specific implementation of
    do_div(), the division is performed using the upper 32-bit word of
    stripe_len, which is zero.

    This was introduced by commit 53b381b3abeb86f12787a6c40fee9b2f71edc23b
    ("Btrfs: RAID5 and RAID6"), which changed the divisor from
    map->stripe_len (struct map_lookup.stripe_len is int) to a 64-bit temporary.

    Reported-by: Thorsten Glaser <tg@debian.org>
    Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
    Tested-by: Thorsten Glaser <tg@debian.org>
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2a9a85d5fb90db72d8e0618a0fafa2069be86198
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sat Apr 27 13:25:38 2013 -0700

    vm: add no-mmu vm_iomap_memory() stub

    commit 3c0b9de6d37a481673e81001c57ca0e410c72346 upstream.

    I think we could just move the full vm_iomap_memory() function into
    util.h or similar, but I didn't get any reply from anybody actually
    using nommu even to this trivial patch, so I'm not going to touch it any
    more than required.

    Here's the fairly minimal stub to make the nommu case at least
    potentially work.  It doesn't seem like anybody cares, though.

    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0e69b54fa8b48e3cdc1a78f77beab3af763a33a1
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Tue Sep 6 07:45:46 2011 +0100

    ARM: 7080/1: l2x0: make sure I&D are not locked down on init

    commit bac7e6ecf60933b68af910eb4c83a775a8b20b19 upstream.

    Fighting unfixed U-Boots and other beasts that may the cache in
    a locked-down state when starting the kernel, we make sure to
    disable all cache lock-down when initializing the l2x0 so we
    are in a known state.

    Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
    Reported-by: Jan Rinze <janrinze@gmail.com>
    Cc: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com>
    Cc: Rabin Vincent <rabin.vincent@stericsson.com>
    Cc: Adrian Bunk <adrian.bunk@movial.com>
    Cc: Rob Herring <robherring2@gmail.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Will Deacon <will.deacon@arm.com>
    Tested-by: Robert Marklund <robert.marklund@stericsson.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3fa539e24c5d7077791a1d6bd8bb28bf86bef932
Author: Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Fri Jul 26 00:08:25 2013 +0200

    m68k/atari: ARAnyM - Fix NatFeat module support

    commit e8184e10f89736a23ea6eea8e24cd524c5c513d2 upstream.

    As pointed out by Andreas Schwab, pointers passed to ARAnyM NatFeat calls
    should be physical addresses, not virtual addresses.

    Fortunately on Atari, physical and virtual kernel addresses are the same,
    as long as normal kernel memory is concerned, so this usually worked fine
    without conversion.

    But for modules, pointers to literal strings are located in vmalloc()ed
    memory. Depending on the version of ARAnyM, this causes the nf_get_id()
    call to just fail, or worse, crash ARAnyM itself with e.g.

        Gotcha! Illegal memory access. Atari PC = $968c

    This is a big issue for distro kernels, who want to have all drivers as
    loadable modules in an initrd.

    Add a wrapper for nf_get_id() that copies the literal to the stack to
    work around this issue.

    Reported-by: Thorsten Glaser <tg@debian.org>
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fc1e43e5cbee9f14ee940044d0e4e722370009d2
Author: Anton Blanchard <anton@samba.org>
Date:   Thu Jun 30 13:55:27 2011 +0000

    powerpc: Use -mtraceback=no

    commit af9719c3062dfe216a0c3de3fa52be6d22b4456c upstream.

    gcc 4.7 will be more strict about parsing the -mtraceback option:

     gcc: error: unrecognized argument in option '-mtraceback=none'
     gcc: note: valid arguments to '-mtraceback=' are: full no part

    gcc used to do a 2 char compare so both "no" and "none" would
    match. Switch to using -mtraceback=no should work everywhere.

    Signed-off-by: Anton Blanchard <anton@samba.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3a2f18948f8e7ef5b90c654c09e237027e1e0645
Author: David S. Miller <davem@davemloft.net>
Date:   Sat May 19 15:27:01 2012 -0700

    sparc32: Add ucmpdi2.o to obj-y instead of lib-y.

    commit 74c7b28953d4eaa6a479c187aeafcfc0280da5e8 upstream.

    Otherwise if no references exist in the static kernel image,
    we won't export the symbol properly to modules.

    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ec982038bd3b0620090e80075be2b5bb5dd26872
Author: Sam Ravnborg <sam@ravnborg.org>
Date:   Sat May 19 11:54:11 2012 +0200

    sparc32: add ucmpdi2

    commit de36e66d5fa52bc6e2dacd95c701a1762b5308a7 upstream.

    Based on copy from microblaze add ucmpdi2 implementation.
    This fixes build of niu driver which failed with:

    drivers/built-in.o: In function `niu_get_nfc':
    niu.c:(.text+0x91494): undefined reference to `__ucmpdi2'

    This driver will never be used on a sparc32 system,
    but patch added to fix build breakage with all*config builds.

    Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d808cb7d6aacff9e39d6d1a4e4ad54ad0a47e901
Author: Johan Hovold <jhovold@gmail.com>
Date:   Tue Aug 13 13:27:34 2013 +0200

    USB: mos7720: fix broken control requests

    commit ef6c8c1d733e244f0499035be0dabe1f4ed98c6f upstream.

    The parallel-port code of the drivers used a stack allocated
    control-request buffer for asynchronous (and possibly deferred) control
    requests. This not only violates the no-DMA-from-stack requirement but
    could also lead to corrupt control requests being submitted.

    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fc1cabf00e9fd2fbfaf4d4df246f53138ccf3a0d
Author: Oliver Neukum <oneukum@suse.de>
Date:   Wed Aug 14 11:01:46 2013 +0200

    usb: add two quirky touchscreen

    commit 304ab4ab079a8ed03ce39f1d274964a532db036b upstream.

    These devices tend to become unresponsive after S3

    Signed-off-by: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bba2a9f0d381e510ba32f2f984e5ae1e705c90d1
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Tue Aug 13 09:04:05 2013 +0200

    genetlink: fix family dump race

    commit 58ad436fcf49810aa006016107f494c9ac9013db upstream.

    When dumping generic netlink families, only the first dump call
    is locked with genl_lock(), which protects the list of families,
    and thus subsequent calls can access the data without locking,
    racing against family addition/removal. This can cause a crash.
    Fix it - the locking needs to be conditional because the first
    time around it's already locked.

    A similar bug was reported to me on an old kernel (3.4.47) but
    the exact scenario that happened there is no longer possible,
    on those kernels the first round wasn't locked either. Looking
    at the current code I found the race described above, which had
    also existed on the old kernel.

    Reported-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e00f3fdc81f21fe6de883c647aff2efcd6945de4
Author: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date:   Mon Feb 18 16:24:20 2013 +0100

    af_key: initialize satype in key_notify_policy_flush()

    commit 85dfb745ee40232876663ae206cba35f24ab2a40 upstream.

    This field was left uninitialized. Some user daemons perform check against this
    field.

    Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Cc: Luis Henriques <luis.henriques@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bd874f70e245977197782bc0e03c658f3e93573b
Author: Jesper Nilsson <jesper.nilsson@axis.com>
Date:   Mon Oct 24 11:19:25 2011 +0200

    CRIS: Add _sdata to vmlinux.lds.S

    commit 473e162eea465e60578edb93341752e7f1c1dacc upstream.

    Fixes link error:
      LD      vmlinux
    kernel/built-in.o: In function `core_kernel_data':
    (.text+0x13e44): undefined reference to `_sdata'

    Signed-off-by: Jesper Nilsson <jesper.nilsson@axis.com>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Cc: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 481101ccce3d7cb2247ff29fc7b8ae1916deeae4
Author: Zhang Yi <wetpzy@gmail.com>
Date:   Tue Jun 25 21:19:31 2013 +0800

    futex: Take hugepages into account when generating futex_key

    commit 13d60f4b6ab5b702dc8d2ee20999f98a93728aec upstream.

    The futex_keys of process shared futexes are generated from the page
    offset, the mapping host and the mapping index of the futex user space
    address. This should result in an unique identifier for each futex.

    Though this is not true when futexes are located in different subpages
    of an hugepage. The reason is, that the mapping index for all those
    futexes evaluates to the index of the base page of the hugetlbfs
    mapping. So a futex at offset 0 of the hugepage mapping and another
    one at offset PAGE_SIZE of the same hugepage mapping have identical
    futex_keys. This happens because the futex code blindly uses
    page->index.

    Steps to reproduce the bug:

    1. Map a file from hugetlbfs. Initialize pthread_mutex1 at offset 0
       and pthread_mutex2 at offset PAGE_SIZE of the hugetlbfs
       mapping.

       The mutexes must be initialized as PTHREAD_PROCESS_SHARED because
       PTHREAD_PROCESS_PRIVATE mutexes are not affected by this issue as
       their keys solely depend on the user space address.

    2. Lock mutex1 and mutex2

    3. Create thread1 and in the thread function lock mutex1, which
       results in thread1 blocking on the locked mutex1.

    4. Create thread2 and in the thread function lock mutex2, which
       results in thread2 blocking on the locked mutex2.

    5. Unlock mutex2. Despite the fact that mutex2 got unlocked, thread2
       still blocks on mutex2 because the futex_key points to mutex1.

    To solve this issue we need to take the normal page index of the page
    which contains the futex into account, if the futex is in an hugetlbfs
    mapping. In other words, we calculate the normal page mapping index of
    the subpage in the hugetlbfs mapping.

    Mappings which are not based on hugetlbfs are not affected and still
    use page->index.

    Thanks to Mel Gorman who provided a patch for adding proper evaluation
    functions to the hugetlbfs code to avoid exposing hugetlbfs specific
    details to the futex code.

    [ tglx: Massaged changelog ]

    Signed-off-by: Zhang Yi <zhang.yi20@zte.com.cn>
    Reviewed-by: Jiang Biao <jiang.biao2@zte.com.cn>
    Tested-by: Ma Chenggong <ma.chenggong@zte.com.cn>
    Reviewed-by: 'Mel Gorman' <mgorman@suse.de>
    Acked-by: 'Darren Hart' <dvhart@linux.intel.com>
    Cc: 'Peter Zijlstra' <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/000101ce71a6%24a83c5880%24f8b50980%24@com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Mike Galbraith <mgalbraith@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linux 3.0.93

commit 77a83f016ce93273734ae6a732737c0d700e8113
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Aug 20 10:23:58 2013 -0700

    Linux 3.0.93

commit f12d8c177c00695eb5c35d132eccd5ffcdaca922
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Aug 20 10:06:19 2013 -0700

    Revert "genetlink: fix family dump race"

    This reverts commit bba2a9f0d381e510ba32f2f984e5ae1e705c90d1 which is
    commit 58ad436fcf49810aa006016107f494c9ac9013db upstream, as there are
    reported problems with it.

    Cc: Johannes Berg <johannes.berg@intel.com>
    Cc: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
    Cc: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linux 3.0.94

commit cc540ceeceb321a779b1b5a4224774d83a6f1f1b
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Aug 29 09:43:15 2013 -0700

    Linux 3.0.94

commit 43bbe371b28bdcb7367e846d53bf6632a2ab2287
Author: Martin Peschke <mpeschke@linux.vnet.ibm.com>
Date:   Thu Aug 22 17:45:37 2013 +0200

    SCSI: zfcp: fix schedule-inside-lock in scsi_device list loops

    commit 924dd584b198a58aa7cb3efefd8a03326550ce8f upstream.

    BUG: sleeping function called from invalid context at kernel/workqueue.c:2752
    in_atomic(): 1, irqs_disabled(): 1, pid: 360, name: zfcperp0.0.1700
    CPU: 1 Not tainted 3.9.3+ #69
    Process zfcperp0.0.1700 (pid: 360, task: 0000000075b7e080, ksp: 000000007476bc30)
    <snip>
    Call Trace:
    ([<00000000001165de>] show_trace+0x106/0x154)
     [<00000000001166a0>] show_stack+0x74/0xf4
     [<00000000006ff646>] dump_stack+0xc6/0xd4
     [<000000000017f3a0>] __might_sleep+0x128/0x148
     [<000000000015ece8>] flush_work+0x54/0x1f8
     [<00000000001630de>] __cancel_work_timer+0xc6/0x128
     [<00000000005067ac>] scsi_device_dev_release_usercontext+0x164/0x23c
     [<0000000000161816>] execute_in_process_context+0x96/0xa8
     [<00000000004d33d8>] device_release+0x60/0xc0
     [<000000000048af48>] kobject_release+0xa8/0x1c4
     [<00000000004f4bf2>] __scsi_iterate_devices+0xfa/0x130
     [<000003ff801b307a>] zfcp_erp_strategy+0x4da/0x1014 [zfcp]
     [<000003ff801b3caa>] zfcp_erp_thread+0xf6/0x2b0 [zfcp]
     [<000000000016b75a>] kthread+0xf2/0xfc
     [<000000000070c9de>] kernel_thread_starter+0x6/0xc
     [<000000000070c9d8>] kernel_thread_starter+0x0/0xc

    Apparently, the ref_count for some scsi_device drops down to zero,
    triggering device removal through execute_in_process_context(), while
    the lldd error recovery thread iterates through a scsi device list.
    Unfortunately, execute_in_process_context() decides to immediately
    execute that device removal function, instead of scheduling asynchronous
    execution, since it detects process context and thinks it is safe to do
    so. But almost all calls to shost_for_each_device() in our lldd are
    inside spin_lock_irq, even in thread context. Obviously, schedule()
    inside spin_lock_irq sections is a bad idea.

    Change the lldd to use the proper iterator function,
    __shost_for_each_device(), in combination with required locking.

    Occurences that need to be changed include all calls in zfcp_erp.c,
    since those might be executed in zfcp error recovery thread context
    with a lock held.

    Other occurences of shost_for_each_device() in zfcp_fsf.c do not
    need to be changed (no process context, no surrounding locking).

    The problem was introduced in Linux 2.6.37 by commit
    b62a8d9b45b971a67a0f8413338c230e3117dff5
    "[SCSI] zfcp: Use SCSI device data zfcp_scsi_dev instead of zfcp_unit".

    Reported-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Signed-off-by: Martin Peschke <mpeschke@linux.vnet.ibm.com>
    Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 374172589a9c99e63c373b1c74588553237a74d3
Author: Martin Peschke <mpeschke@linux.vnet.ibm.com>
Date:   Thu Aug 22 17:45:36 2013 +0200

    SCSI: zfcp: fix lock imbalance by reworking request queue locking

    commit d79ff142624e1be080ad8d09101f7004d79c36e1 upstream.

    This patch adds wait_event_interruptible_lock_irq_timeout(), which is a
    straight-forward descendant of wait_event_interruptible_timeout() and
    wait_event_interruptible_lock_irq().

    The zfcp driver used to call wait_event_interruptible_timeout()
    in combination with some intricate and error-prone locking. Using
    wait_event_interruptible_lock_irq_timeout() as a replacement
    nicely cleans up that locking.

    This rework removes a situation that resulted in a locking imbalance
    in zfcp_qdio_sbal_get():

    BUG: workqueue leaked lock or atomic: events/1/0xffffff00/10
        last function: zfcp_fc_wka_port_offline+0x0/0xa0 [zfcp]

    It was introduced by commit c2af7545aaff3495d9bf9a7608c52f0af86fb194
    "[SCSI] zfcp: Do not wait for SBALs on stopped queue", which had a new
    code path related to ZFCP_STATUS_ADAPTER_QDIOUP that took an early exit
    without a required lock being held. The problem occured when a
    special, non-SCSI I/O request was being submitted in process context,
    when the adapter's queues had been torn down. In this case the bug
    surfaced when the Fibre Channel port connection for a well-known address
    was closed during a concurrent adapter shut-down procedure, which is a
    rare constellation.

    This patch also fixes these warnings from the sparse tool (make C=1):

    drivers/s390/scsi/zfcp_qdio.c:224:12: warning: context imbalance in
     'zfcp_qdio_sbal_check' - wrong count at exit
    drivers/s390/scsi/zfcp_qdio.c:244:5: warning: context imbalance in
     'zfcp_qdio_sbal_get' - unexpected unlock

    Last but not least, we get rid of that crappy lock-unlock-lock
    sequence at the beginning of the critical section.

    It is okay to call zfcp_erp_adapter_reopen() with req_q_lock held.

    Reported-by: Mikulas Patocka <mpatocka@redhat.com>
    Reported-by: Heiko Carstens <heiko.carstens@de.ibm.com>
    Signed-off-by: Martin Peschke <mpeschke@linux.vnet.ibm.com>
    Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 016d826cfcb22b27915149aabadf461641b7907c
Author: Terry Suereth <terry.suereth@gmail.com>
Date:   Sat Aug 17 15:53:12 2013 -0400

    libata: apply behavioral quirks to sil3826 PMP

    commit 8ffff94d20b7eb446e848e0046107d51b17a20a8 upstream.

    Fixing support for the Silicon Image 3826 port multiplier, by applying
    to it the same quirks applied to the Silicon Image 3726.  Specifically
    fixes the repeated timeout/reset process which previously afflicted
    the 3726, as described from line 290.  Slightly based on notes from:

    https://bugzilla.redhat.com/show_bug.cgi?id=890237

    Signed-off-by: Terry Suereth <terry.suereth@gmail.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8d43271717d467f6795cfc5a81fd2cd886833330
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Aug 9 12:52:31 2013 +0300

    Hostap: copying wrong data prism2_ioctl_giwaplist()

    commit 909bd5926d474e275599094acad986af79671ac9 upstream.

    We want the data stored in "addr" and "qual", but the extra ampersands
    mean we are copying stack data instead.

    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3c6766ab27147383b3a084d29cb87163342f14b0
Author: Vyacheslav Dubeyko <slava@dubeyko.com>
Date:   Thu Aug 22 16:35:45 2013 -0700

    nilfs2: fix issue with counting number of bio requests for BIO_EOPNOTSUPP error detection

    commit 4bf93b50fd04118ac7f33a3c2b8a0a1f9fa80bc9 upstream.

    Fix the issue with improper counting number of flying bio requests for
    BIO_EOPNOTSUPP error detection case.

    The sb_nbio must be incremented exactly the same number of times as
    complete() function was called (or will be called) because
    nilfs_segbuf_wait() will call wail_for_completion() for the number of
    times set to sb_nbio:

      do {
          wait_for_completion(&segbuf->sb_bio_event);
      } while (--segbuf->sb_nbio > 0);

    Two functions complete() and wait_for_completion() must be called the
    same number of times for the same sb_bio_event.  Otherwise,
    wait_for_completion() will hang or leak.

    Signed-off-by: Vyacheslav Dubeyko <slava@dubeyko.com>
    Cc: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
    Tested-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
    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 637a641c5478377849d936fa276f92a4f418bb65
Author: Vyacheslav Dubeyko <slava@dubeyko.com>
Date:   Thu Aug 22 16:35:44 2013 -0700

    nilfs2: remove double bio_put() in nilfs_end_bio_write() for BIO_EOPNOTSUPP error

    commit 2df37a19c686c2d7c4e9b4ce1505b5141e3e5552 upstream.

    Remove double call of bio_put() in nilfs_end_bio_write() for the case of
    BIO_EOPNOTSUPP error detection.  The issue was found by Dan Carpenter
    and he suggests first version of the fix too.

    Signed-off-by: Vyacheslav Dubeyko <slava@dubeyko.com>
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
    Tested-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
    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 14c3de73b19d1c758ae92ec4674482742ad54fb3
Author: Wladislav Wiebe <wladislav.kw@gmail.com>
Date:   Mon Aug 12 13:06:53 2013 +0200

    of: fdt: fix memory initialization for expanded DT

    commit 9e40127526e857fa3f29d51e83277204fbdfc6ba upstream.

    Already existing property flags are filled wrong for properties created from
    initial FDT. This could cause problems if this DYNAMIC device-tree functions
    are used later, i.e. properties are attached/detached/replaced. Simply dumping
    flags from the running system show, that some initial static (not allocated via
    kzmalloc()) nodes are marked as dynamic.

    I putted some debug extensions to property_proc_show(..) :
    ..
    +       if (OF_IS_DYNAMIC(pp))
    +               pr_err("DEBUG: xxx : OF_IS_DYNAMIC\n");
    +       if (OF_IS_DETACHED(pp))
    +               pr_err("DEBUG: xxx : OF_IS_DETACHED\n");

    when you operate on the nodes (e.g.: ~$ cat /proc/device-tree/*some_node*) you
    will see that those flags are filled wrong, basically in most cases it will dump
    a DYNAMIC or DETACHED status, which is in not true.
    (BTW. this OF_IS_DETACHED is a own define for debug purposes which which just
    make a test_bit(OF_DETACHED, &x->_flags)

    If nodes are dynamic kernel is allowed to kfree() them. But it will crash
    attempting to do so on the nodes from FDT -- they are not allocated via
    kzmalloc().

    Signed-off-by: Wladislav Wiebe <wladislav.kw@gmail.com>
    Acked-by: Alexander Sverdlin <alexander.sverdlin@nsn.com>
    Signed-off-by: Rob Herring <rob.herring@calxeda.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1b9ba06c5f4e84b8dfa402bee0daff42db045977
Author: David Vrabel <david.vrabel@citrix.com>
Date:   Thu Aug 15 13:21:06 2013 +0100

    xen/events: initialize local per-cpu mask for all possible events

    commit 84ca7a8e45dafb49cd5ca90a343ba033e2885c17 upstream.

    The sizeof() argument in init_evtchn_cpu_bindings() is incorrect
    resulting in only the first 64 (or 32 in 32-bit guests) ports having
    their bindings being initialized to VCPU 0.

    In most cases this does not cause a problem as request_irq() will set
    the irq affinity which will set the correct local per-cpu mask.
    However, if the request_irq() is called on a VCPU other than 0, there
    is a window between the unmasking of the event and the affinity being
    set were an event may be lost because it is not locally unmasked on
    any VCPU. If request_irq() is called on VCPU 0 then local irqs are
    disabled during the window and the race does not occur.

    Fix this by initializing all NR_EVENT_CHANNEL bits in the local
    per-cpu masks.

    Signed-off-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>

commit 50e27a160f6146de036e81420dc13ec9f4824564
Author: Jussi Kivilinna <jussi.kivilinna@iki.fi>
Date:   Tue Aug 6 14:28:42 2013 +0300

    zd1201: do not use stack as URB transfer_buffer

    commit 1206ff4ff9d2ef7468a355328bc58ac6ebf5be44 upstream.

    Patch fixes zd1201 not to use stack as URB transfer_buffer. URB buffers need
    to be DMA-able, which stack is not.

    Patch is only compile tested.

    Signed-off-by: Jussi Kivilinna <jussi.kivilinna@iki.fi>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>