Linux 3.0.88

commit 7d4d5a89e9a6226e0958fd1dd06e03f4916c8203
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Jul 28 16:22:04 2013 -0700

    Linux 3.0.88

commit 2d4fe72b277dde96b6cb765b13689d98ee759a5f
Author: Eldad Zack <eldad@fogrefinery.com>
Date:   Fri Jul 19 18:26:53 2013 +0200

    ALSA: usb-audio: 6fire: return correct XRUN indication

    commit be2f93a4c4981b3646b6f98f477154411b8516cb upstream.

    Return SNDRV_PCM_POS_XRUN (snd_pcm_uframes_t) instead of
    SNDRV_PCM_STATE_XRUN (snd_pcm_state_t) from the pointer
    function of 6fire, as expected by snd_pcm_update_hw_ptr0().

    Caught by sparse.

    Signed-off-by: Eldad Zack <eldad@fogrefinery.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9cfe5af116d3c10595733f11681399f5d80980f6
Author: Steffen Maier <maier@linux.vnet.ibm.com>
Date:   Fri Apr 26 17:34:54 2013 +0200

    zfcp: status read buffers on first adapter open with link down

    commit 9edf7d75ee5f21663a0183d21f702682d0ef132f upstream.

    Commit 64deb6efdc5504ce97b5c1c6f281fffbc150bd93
    "[SCSI] zfcp: Use status_read_buf_num provided by FCP channel"
    started using a value returned by the channel but only evaluated the value
    if the fabric link is up.
    Commit 8d88cf3f3b9af4713642caeb221b6d6a42019001
    "[SCSI] zfcp: Update status read mempool"
    introduced mempool resizings based on the above value.
    On setting an FCP device online for the very first time since boot, a new
    zeroed adapter object is allocated. If the link is down, the number of
    status read requests remains zero. Since just the config data exchange is
    incomplete, we proceed with adapter open recovery. However, we
    unconditionally call mempool_resize with adapter->stat_read_buf_num == 0 in
    this case.

    This causes a kernel message "kernel BUG at mm/mempool.c:131!" in process
    "zfcperp<FCP-device-bus-ID>" with last function mempool_resize in Krnl PSW
    and zfcp_erp_thread in the Call Trace.

    Don't evaluate channel values which are invalid on link down. The number of
    status read requests is always valid, evaluated, and set to a positive
    minimum greater than zero. The adapter open recovery can proceed and the
    channel has status read buffers to inform us on a future link up event.
    While we are not aware of any other code path that could result in mempool
    resize attempts of size zero, we still also initialize the number of status
    read buffers to be posted to a static minimum number on adapter object
    allocation.

    Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
    [sm: Backported to 3.0:
     - Copyright notice changed slightly
     - Don't use zfcp_fsf_convert_portspeed()]
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e5056425dd86e1e8cc8411014daec42a408483d8
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Fri Jul 5 12:09:18 2013 +0200

    hrtimers: Move SMP function call to thread context

    commit 5ec2481b7b47a4005bb446d176e5d0257400c77d upstream.

    smp_call_function_* must not be called from softirq context.

    But clock_was_set() which calls on_each_cpu() is called from softirq
    context to implement a delayed clock_was_set() for the timer interrupt
    handler. Though that almost never gets invoked. A recent change in the
    resume code uses the softirq based delayed clock_was_set to support
    Xens resume mechanism.

    linux-next contains a new warning which warns if smp_call_function_*
    is called from softirq context which gets triggered by that Xen
    change.

    Fix this by moving the delayed clock_was_set() call to a work context.

    Reported-and-tested-by: Artem Savkov <artem.savkov@gmail.com>
    Reported-by: Sasha Levin <sasha.levin@oracle.com>
    Cc: David Vrabel <david.vrabel@citrix.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: H. Peter Anvin <hpa@zytor.com>,
    Cc: Konrad Wilk <konrad.wilk@oracle.com>
    Cc: John Stultz <john.stultz@linaro.org>
    Cc: xen-devel@lists.xen.org
    Cc: stable@vger.kernel.org
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 06b15223cae9d65c7c353adbcb354bbe2d0feddd
Author: zhangwei(Jovi) <jovi.zhangwei@huawei.com>
Date:   Wed Apr 10 11:26:23 2013 +0800

    tracing: Fix irqs-off tag display in syscall tracing

    commit 11034ae9c20f4057a6127fc965906417978e69b2 upstream.

    All syscall tracing irqs-off tags are wrong, the syscall enter entry doesn't
    disable irqs.

     [root@jovi tracing]#echo "syscalls:sys_enter_open" > set_event
     [root@jovi tracing]# cat trace
     # tracer: nop
     #
     # entries-in-buffer/entries-written: 13/13   #P:2
     #
     #                              _-----=> irqs-off
     #                             / _----=> need-resched
     #                            | / _---=> hardirq/softirq
     #                            || / _--=> preempt-depth
     #                            ||| /     delay
     #           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
     #              | |       |   ||||       |         |
           irqbalance-513   [000] d... 56115.496766: sys_open(filename: 804e1a6, flags: 0, mode: 1b6)
           irqbalance-513   [000] d... 56115.497008: sys_open(filename: 804e1bb, flags: 0, mode: 1b6)
             sendmail-771   [000] d... 56115.827982: sys_open(filename: b770e6d1, flags: 0, mode: 1b6)

    The reason is syscall tracing doesn't record irq_flags into buffer.
    The proper display is:

     [root@jovi tracing]#echo "syscalls:sys_enter_open" > set_event
     [root@jovi tracing]# cat trace
     # tracer: nop
     #
     # entries-in-buffer/entries-written: 14/14   #P:2
     #
     #                              _-----=> irqs-off
     #                             / _----=> need-resched
     #                            | / _---=> hardirq/softirq
     #                            || / _--=> preempt-depth
     #                            ||| /     delay
     #           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
     #              | |       |   ||||       |         |
           irqbalance-514   [001] ....    46.213921: sys_open(filename: 804e1a6, flags: 0, mode: 1b6)
           irqbalance-514   [001] ....    46.214160: sys_open(filename: 804e1bb, flags: 0, mode: 1b6)
                <...>-920   [001] ....    47.307260: sys_open(filename: 4e82a0c5, flags: 80000, mode: 0)

    Link: http://lkml.kernel.org/r/1365564393-10972-3-git-send-email-jovi.zhangwei@huawei.com

    Cc: stable@vger.kernel.org # 2.6.35
    Signed-off-by: zhangwei(Jovi) <jovi.zhangwei@huawei.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a00c4c9f176094d7b71acd410f871b609f5e7c84
Author: David Jeffery <djeffery@redhat.com>
Date:   Wed Jul 10 13:19:50 2013 -0400

    lockd: protect nlm_blocked access in nlmsvc_retry_blocked

    commit 1c327d962fc420aea046c16215a552710bde8231 upstream.

    In nlmsvc_retry_blocked, the check that the list is non-empty and acquiring
    the pointer of the first entry is unprotected by any lock.  This allows a rare
    race condition when there is only one entry on the list.  A function such as
    nlmsvc_grant_callback() can be called, which will temporarily remove the entry
    from the list.  Between the list_empty() and list_entry(),the list may become
    empty, causing an invalid pointer to be used as an nlm_block, leading to a
    possible crash.

    This patch adds the nlm_block_lock around these calls to prevent concurrent
    use of the nlm_blocked list.

    This was a regression introduced by
    f904be9cc77f361d37d71468b13ff3d1a1823dea  "lockd: Mostly remove BKL from
    the server".

    Signed-off-by: David Jeffery <djeffery@redhat.com>
    Cc: Bryan Schumaker <bjschuma@netapp.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 101e49a9ce6fadd876ae68bddf6f155bbd02a776
Author: Barry Grussling <barry@grussling.com>
Date:   Fri Jul 19 14:46:12 2013 -0700

    usb: cp210x support SEL C662 Vendor/Device

    commit b579fa52f6be0b4157ca9cc5e94d44a2c89a7e95 upstream.

    This patch adds support for the Schweitzer Engineering Laboratories
    C662 USB cable based off the CP210x driver.

    Signed-off-by: Barry Grussling <barry@grussling.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 838adcbfb9d711a56c0137cc10307fe3dce30771
Author: Sami Rahman <sami.rahman@mmbresearch.com>
Date:   Mon Jul 8 14:28:55 2013 -0400

    USB: cp210x: add MMB and PI ZigBee USB Device Support

    commit 7681156982026ebf7eafd7301eb0374d7648d068 upstream.

    Added support for MMB Networks and Planet Innovation Ingeni ZigBee USB
    devices using customized Silicon Labs' CP210x.c USB to UART bridge
    drivers with PIDs: 88A4, 88A5.

    Signed-off-by: Sami Rahman <sami.rahman@mmbresearch.com>
    Tested-by: Sami Rahman <sami.rahman@mmbresearch.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a18112769fdfa24345bc8d0cec6cb6b590d87325
Author: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Date:   Mon Jul 1 23:56:25 2013 -0300

    usb: serial: cp210x: Add USB ID for Netgear Switches embedded serial adapter

    commit 90625070c4253377025878c4e82feed8b35c7116 upstream.

    This adds NetGear Managed Switch M4100 series, M5300 series, M7100 series
    USB ID (0846:0110) to the cp210x driver. Without this, the serial
    adapter is not recognized in Linux. Description was obtained from
    an Netgear Eng.

    Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6280fb6d01c8e3fd3b2e4467e5e5cecce2e3b41d
Author: Enrico Mioso <mrkiko.rs@gmail.com>
Date:   Thu Jul 25 02:01:39 2013 +0200

    usb: serial: option: Add ONYX 3G device support

    commit 63b5df963f52ccbab6fabedf05b7ac6b465789a4 upstream.

    This patch adds support for the ONYX 3G device (version 1) from ALFA
    NETWORK.

    Signed-off-by: Enrico Mioso <mrkiko.rs@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ce2a4856d35f96196200e28a6ee34a836a4b3b2f
Author: Alexandr \\\"Sky\\\" Ivanov <alexandr.sky@gmail.com>
Date:   Tue Jul 23 17:46:40 2013 +0400

    USB: option: add D-Link DWM-152/C1 and DWM-156/C1

    commit ca24763588844b14f019ffc45c7df6d9e8f932c5 upstream.

    Adding support for D-Link DWM-152/C1 and DWM-156/C1 devices.

    DWM-152/C1:
    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  6 Spd=480 MxCh= 0
    D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=07d1 ProdID=3e01 Rev= 0.00
    S:  Product=USB Configuration
    S:  SerialNumber=1234567890ABCDEF
    C:* #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
    I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
    I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
    I:* If#= 4 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms

    DWM-156/C1:
    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  8 Spd=480 MxCh= 0
    D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=07d1 ProdID=3e02 Rev= 0.00
    S:  Product=DataCard Device
    S:  SerialNumber=1234567890ABCDEF
    C:* #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
    I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
    I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
    I:* If#= 4 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms

    Signed-off-by: Alexandr Ivanov <alexandr.sky@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c3a11656cc97d64855423ba438828c85a8e54ee5
Author: Daniil Bolsun <dan.bolsun@gmail.com>
Date:   Fri Jul 19 10:21:23 2013 +0300

    USB: option: append Petatel NP10T device to GSM modems list

    commit c38e83b6cc2adf80e3f091fd92cfbeacc9748347 upstream.

    This patch was tested on 3.10.1 kernel.

    Same models of Petatel NP10T modems have different device IDs.
    Unfortunately they have no additional revision information on a board
    which may treat them as different devices. Currently I've seen only
    two NP10T devices with various IDs. Possibly Petatel NP10T list will
    be appended upon devices with new IDs will appear.

    Signed-off-by: Daniil Bolsun <dan.bolsun@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 95087796786486aed495ef1bcbd90293457a95f4
Author: Enrico Mioso <mrkiko.rs@gmail.com>
Date:   Sat Jul 13 18:54:14 2013 +0200

    usb: serial: option.c: remove ONDA MT825UP product ID fromdriver

    commit 878c69aae986ae97084458c0183a8c0a059865b1 upstream.

    Some (very few) early devices like mine, where not exposting a proper CDC
    descriptor. This was fixed with an immediate firmware update from the vendor,
    and pre-installed on newer devices.
    So actual devices can be driven by cdc_acm.c + cdc_ether.c.

    Signed-off-by: Enrico Mioso <mrkiko.rs@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f560b0a91504905b45a86d6aab741596f8918de9
Author: Dan Williams <dcbw@redhat.com>
Date:   Wed Jul 10 12:25:02 2013 -0500

    usb: serial: option: add Olivetti Olicard 200

    commit 4cf76df06ecc852633ed927d91e01c83c33bc331 upstream.

    Speaks AT on interfaces 5 (command & PPP) and 3 (secondary), other
    interface protocols are unknown.

    Signed-off-by: Dan Williams <dcbw@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit db3b3fb7e0beb4f1c0aecbf4b701b550b1378e97
Author: Bjørn Mork <bjorn@mork.no>
Date:   Fri Jun 28 17:15:25 2013 +0200

    usb: option: add TP-LINK MA260

    commit 94190301ffa059c2d127b3a67ec5d161d5c62681 upstream.

    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 086d6ce19be48369ede4cf32a4983f70618caea5
Author: Enrico Mioso <mrkiko.rs@gmail.com>
Date:   Sat Jun 29 15:33:35 2013 +0200

    usb: serial: option: blacklist ONDA MT689DC QMI interface

    commit 3d1a69e726406ab662ab88fa30a3a05ed404334d upstream.

    Prevent the option driver from binding itself to the QMI/WWAN interface, making
    it unusable by the proper driver.

    Signed-off-by: enrico Mioso <mrkiko.rs@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ad4beaccb0882af065befc18665f461d9711a2d4
Author: Andi Kleen <andi@firstfloor.org>
Date:   Mon Sep 3 20:50:30 2012 +0200

    SCSI: Fix incorrect memset in bnx2fc_parse_fcp_rsp

    commit 16da05b1158d1bcb31656e636a8736a663b1cf1f upstream.

    gcc 4.8 warns because the memset only clears sizeof(char *) bytes, not
    the whole buffer. Use the correct buffer size and clear the whole sense
    buffer.

    /backup/lsrc/git/linux-lto-2.6/drivers/scsi/bnx2fc/bnx2fc_io.c: In
    function 'bnx2fc_parse_fcp_rsp':
    /backup/lsrc/git/linux-lto-2.6/drivers/scsi/bnx2fc/bnx2fc_io.c:1810:41:
    warning: argument to 'sizeof' in 'memset' call is the same expression as
    the destination; did you mean to provide an explicit length?
    [-Wsizeof-pointer-memaccess]
       memset(sc_cmd->sense_buffer, 0, sizeof(sc_cmd->sense_buffer));
                                             ^

    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    Acked-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d45ff5f89c087a667290048c24deaeb27fa43ba0
Author: Bjørn Mork <bjorn@mork.no>
Date:   Wed Nov 21 09:54:48 2012 +0100

    SCSI: megaraid_sas: fix memory leak if SGL has zero length entries

    commit 7a6a731bd00ca90d0e250867c3b9c05b5ff0fa49 upstream.

    commit 98cb7e44 ([SCSI] megaraid_sas: Sanity check user
    supplied length before passing it to dma_alloc_coherent())
    introduced a memory leak.  Memory allocated for entries
    following zero length SGL entries will not be freed.

    Reference: http://bugs.debian.org/688198

    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Acked-by: Adam Radford <aradford@gmail.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a4c38fde90666a77d461fd352914f954232361ab
Author: Jan Kara <jack@suse.cz>
Date:   Fri Jun 28 16:04:02 2013 +0200

    writeback: Fix periodic writeback after fs mount

    commit a5faeaf9109578e65e1a32e2a3e76c8b47e7dcb6 upstream.

    Code in blkdev.c moves a device inode to default_backing_dev_info when
    the last reference to the device is put and moves the device inode back
    to its bdi when the first reference is acquired. This includes moving to
    wb.b_dirty list if the device inode is dirty. The code however doesn't
    setup timer to wake corresponding flusher thread and while wb.b_dirty
    list is non-empty __mark_inode_dirty() will not set it up either. Thus
    periodic writeback is effectively disabled until a sync(2) call which can
    lead to unexpected data loss in case of crash or power failure.

    Fix the problem by setting up a timer for periodic writeback in case we
    add the first dirty inode to wb.b_dirty list in bdev_inode_switch_bdi().

    Reported-by: Bert De Jonghe <Bert.DeJonghe@amplidata.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f45a0233de990dc788371b54f23a8986a23bfa4a
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Jul 18 09:35:10 2013 -0700

    vlan: fix a race in egress prio management

    [ Upstream commit 3e3aac497513c669e1c62c71e1d552ea85c1d974 ]

    egress_priority_map[] hash table updates are protected by rtnl,
    and we never remove elements until device is dismantled.

    We have to make sure that before inserting an new element in hash table,
    all its fields are committed to memory or else another cpu could
    find corrupt values and crash.

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

commit 8956c3efefa2a61df16a47ba4f159e3d49717858
Author: dingtianhong <dingtianhong@huawei.com>
Date:   Thu Jul 11 19:04:06 2013 +0800

    ifb: fix oops when loading the ifb failed

    [ Upstream commit f2966cd5691058b8674a20766525bedeaea9cbcf ]

    If __rtnl_link_register() return faild when loading the ifb, it will
    take the wrong path and get oops, so fix it just like dummy.

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

commit 7474f8cdc7a60fe7c5d2579f99ec04232f76a208
Author: dingtianhong <dingtianhong@huawei.com>
Date:   Thu Jul 11 19:04:02 2013 +0800

    dummy: fix oops when loading the dummy failed

    [ Upstream commit 2c8a01894a12665d8059fad8f0a293c98a264121 ]

    We rename the dummy in modprobe.conf like this:

    install dummy0 /sbin/modprobe -o dummy0 --ignore-install dummy
    install dummy1 /sbin/modprobe -o dummy1 --ignore-install dummy

    We got oops when we run the command:

    modprobe dummy0
    modprobe dummy1

    ------------[ cut here ]------------

    [ 3302.187584] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
    [ 3302.195411] IP: [<ffffffff813fe62a>] __rtnl_link_unregister+0x9a/0xd0
    [ 3302.201844] PGD 85c94a067 PUD 8517bd067 PMD 0
    [ 3302.206305] Oops: 0002 [#1] SMP
    [ 3302.299737] task: ffff88105ccea300 ti: ffff880eba4a0000 task.ti: ffff880eba4a0000
    [ 3302.307186] RIP: 0010:[<ffffffff813fe62a>]  [<ffffffff813fe62a>] __rtnl_link_unregister+0x9a/0xd0
    [ 3302.316044] RSP: 0018:ffff880eba4a1dd8  EFLAGS: 00010246
    [ 3302.321332] RAX: 0000000000000000 RBX: ffffffff81a9d738 RCX: 0000000000000002
    [ 3302.328436] RDX: 0000000000000000 RSI: ffffffffa04d602c RDI: ffff880eba4a1dd8
    [ 3302.335541] RBP: ffff880eba4a1e18 R08: dead000000200200 R09: dead000000100100
    [ 3302.342644] R10: 0000000000000080 R11: 0000000000000003 R12: ffffffff81a9d788
    [ 3302.349748] R13: ffffffffa04d7020 R14: ffffffff81a9d670 R15: ffff880eba4a1dd8
    [ 3302.364910] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [ 3302.370630] CR2: 0000000000000008 CR3: 000000085e15e000 CR4: 00000000000427e0
    [ 3302.377734] DR0: 0000000000000003 DR1: 00000000000000b0 DR2: 0000000000000001
    [ 3302.384838] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    [ 3302.391940] Stack:
    [ 3302.393944]  ffff880eba4a1dd8 ffff880eba4a1dd8 ffff880eba4a1e18 ffffffffa04d70c0
    [ 3302.401350]  00000000ffffffef ffffffffa01a8000 0000000000000000 ffffffff816111c8
    [ 3302.408758]  ffff880eba4a1e48 ffffffffa01a80be ffff880eba4a1e48 ffffffffa04d70c0
    [ 3302.416164] Call Trace:
    [ 3302.418605]  [<ffffffffa01a8000>] ? 0xffffffffa01a7fff
    [ 3302.423727]  [<ffffffffa01a80be>] dummy_init_module+0xbe/0x1000 [dummy0]
    [ 3302.430405]  [<ffffffffa01a8000>] ? 0xffffffffa01a7fff
    [ 3302.435535]  [<ffffffff81000322>] do_one_initcall+0x152/0x1b0
    [ 3302.441263]  [<ffffffff810ab24b>] do_init_module+0x7b/0x200
    [ 3302.446824]  [<ffffffff810ad3d2>] load_module+0x4e2/0x530
    [ 3302.452215]  [<ffffffff8127ae40>] ? ddebug_dyndbg_boot_param_cb+0x60/0x60
    [ 3302.458979]  [<ffffffff810ad5f1>] SyS_init_module+0xd1/0x130
    [ 3302.464627]  [<ffffffff814b9652>] system_call_fastpath+0x16/0x1b
    [ 3302.490090] RIP  [<ffffffff813fe62a>] __rtnl_link_unregister+0x9a/0xd0
    [ 3302.496607]  RSP <ffff880eba4a1dd8>
    [ 3302.500084] CR2: 0000000000000008
    [ 3302.503466] ---[ end trace 8342d49cd49f78ed ]---

    The reason is that when loading dummy, if __rtnl_link_register() return failed,
    the init_module should return and avoid take the wrong path.

    Signed-off-by: Tan Xiaojun <tanxiaojun@huawei.com>
    Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 14dfbe18c960e9367a6a25f6d7933e293fae1d20
Author: dingtianhong <dingtianhong@huawei.com>
Date:   Wed Jul 10 12:04:02 2013 +0800

    ifb: fix rcu_sched self-detected stalls

    [ Upstream commit 440d57bc5ff55ec1efb3efc9cbe9420b4bbdfefa ]

    According to the commit 16b0dc29c1af9df341428f4c49ada4f626258082
    (dummy: fix rcu_sched self-detected stalls)

    Eric Dumazet fix the problem in dummy, but the ifb will occur the
    same problem like the dummy modules.

    Trying to "modprobe ifb numifbs=30000" triggers :

    INFO: rcu_sched self-detected stall on CPU

    After this splat, RTNL is locked and reboot is needed.

    We must call cond_resched() to avoid this, even holding RTNL.

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

commit 83e460923c7640fe6af1a1b386513dcc26fe7251
Author: Dave Kleikamp <dave.kleikamp@oracle.com>
Date:   Mon Jul 1 16:49:22 2013 -0500

    sunvnet: vnet_port_remove must call unregister_netdev

    [ Upstream commit aabb9875d02559ab9b928cd6f259a5cc4c21a589 ]

    The missing call to unregister_netdev() leaves the interface active
    after the driver is unloaded by rmmod.

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

commit 639e5920a9ae14b1eefc44a8740f5d0f816adb9a
Author: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date:   Mon Jul 1 20:21:30 2013 +0200

    ipv6: call udp_push_pending_frames when uncorking a socket with AF_INET pending data

    [ Upstream commit 8822b64a0fa64a5dd1dfcf837c5b0be83f8c05d1 ]

    We accidentally call down to ip6_push_pending_frames when uncorking
    pending AF_INET data on a ipv6 socket. This results in the following
    splat (from Dave Jones):

    skbuff: skb_under_panic: text:ffffffff816765f6 len:48 put:40 head:ffff88013deb6df0 data:ffff88013deb6dec tail:0x2c end:0xc0 dev:<NULL>
    ------------[ cut here ]------------
    kernel BUG at net/core/skbuff.c:126!
    invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
    Modules linked in: dccp_ipv4 dccp 8021q garp bridge stp dlci mpoa snd_seq_dummy sctp fuse hidp tun bnep nfnetlink scsi_transport_iscsi rfcomm can_raw can_bcm af_802154 appletalk caif_socket can caif ipt_ULOG x25 rose af_key pppoe pppox ipx phonet irda llc2 ppp_generic slhc p8023 psnap p8022 llc crc_ccitt atm bluetooth
    +netrom ax25 nfc rfkill rds af_rxrpc coretemp hwmon kvm_intel kvm crc32c_intel snd_hda_codec_realtek ghash_clmulni_intel microcode pcspkr snd_hda_codec_hdmi snd_hda_intel snd_hda_codec snd_hwdep usb_debug snd_seq snd_seq_device snd_pcm e1000e snd_page_alloc snd_timer ptp snd pps_core soundcore xfs libcrc32c
    CPU: 2 PID: 8095 Comm: trinity-child2 Not tainted 3.10.0-rc7+ #37
    task: ffff8801f52c2520 ti: ffff8801e6430000 task.ti: ffff8801e6430000
    RIP: 0010:[<ffffffff816e759c>]  [<ffffffff816e759c>] skb_panic+0x63/0x65
    RSP: 0018:ffff8801e6431de8  EFLAGS: 00010282
    RAX: 0000000000000086 RBX: ffff8802353d3cc0 RCX: 0000000000000006
    RDX: 0000000000003b90 RSI: ffff8801f52c2ca0 RDI: ffff8801f52c2520
    RBP: ffff8801e6431e08 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000001 R11: 0000000000000001 R12: ffff88022ea0c800
    R13: ffff88022ea0cdf8 R14: ffff8802353ecb40 R15: ffffffff81cc7800
    FS:  00007f5720a10740(0000) GS:ffff880244c00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000005862000 CR3: 000000022843c000 CR4: 00000000001407e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600
    Stack:
     ffff88013deb6dec 000000000000002c 00000000000000c0 ffffffff81a3f6e4
     ffff8801e6431e18 ffffffff8159a9aa ffff8801e6431e90 ffffffff816765f6
     ffffffff810b756b 0000000700000002 ffff8801e6431e40 0000fea9292aa8c0
    Call Trace:
     [<ffffffff8159a9aa>] skb_push+0x3a/0x40
     [<ffffffff816765f6>] ip6_push_pending_frames+0x1f6/0x4d0
     [<ffffffff810b756b>] ? mark_held_locks+0xbb/0x140
     [<ffffffff81694919>] udp_v6_push_pending_frames+0x2b9/0x3d0
     [<ffffffff81694660>] ? udplite_getfrag+0x20/0x20
     [<ffffffff8162092a>] udp_lib_setsockopt+0x1aa/0x1f0
     [<ffffffff811cc5e7>] ? fget_light+0x387/0x4f0
     [<ffffffff816958a4>] udpv6_setsockopt+0x34/0x40
     [<ffffffff815949f4>] sock_common_setsockopt+0x14/0x20
     [<ffffffff81593c31>] SyS_setsockopt+0x71/0xd0
     [<ffffffff816f5d54>] tracesys+0xdd/0xe2
    Code: 00 00 48 89 44 24 10 8b 87 d8 00 00 00 48 89 44 24 08 48 8b 87 e8 00 00 00 48 c7 c7 c0 04 aa 81 48 89 04 24 31 c0 e8 e1 7e ff ff <0f> 0b 55 48 89 e5 0f 0b 55 48 89 e5 0f 0b 55 48 89 e5 0f 0b 55
    RIP  [<ffffffff816e759c>] skb_panic+0x63/0x65
     RSP <ffff8801e6431de8>

    This patch adds a check if the pending data is of address family AF_INET
    and directly calls udp_push_ending_frames from udp_v6_push_pending_frames
    if that is the case.

    This bug was found by Dave Jones with trinity.

    (Also move the initialization of fl6 below the AF_INET check, even if
    not strictly necessary.)

    Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Cc: Dave Jones <davej@redhat.com>
    Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3b482bb76dfd1389e4406c27c1005addf1dea08b
Author: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Date:   Tue Jul 2 09:02:07 2013 +0800

    l2tp: add missing .owner to struct pppox_proto

    [ Upstream commit e1558a93b61962710733dc8c11a2bc765607f1cd ]

    Add missing .owner of struct pppox_proto. This prevents the
    module from being removed from underneath its users.

    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 52ef39eeff06aecc56266902bba6bf28891cabd3
Author: Amerigo Wang <amwang@redhat.com>
Date:   Sat Jun 29 21:30:49 2013 +0800

    ipv6,mcast: always hold idev->lock before mca_lock

    [ Upstream commit 8965779d2c0e6ab246c82a405236b1fb2adae6b2, with
      some bits from commit b7b1bfce0bb68bd8f6e62a28295922785cc63781
      ("ipv6: split duplicate address detection and router solicitation timer")
      to get the __ipv6_get_lladdr() used by this patch. ]

    dingtianhong reported the following deadlock detected by lockdep:

     ======================================================
     [ INFO: possible circular locking dependency detected ]
     3.4.24.05-0.1-default #1 Not tainted
     -------------------------------------------------------
     ksoftirqd/0/3 is trying to acquire lock:
      (&ndev->lock){+.+...}, at: [<ffffffff8147f804>] ipv6_get_lladdr+0x74/0x120

     but task is already holding lock:
      (&mc->mca_lock){+.+...}, at: [<ffffffff8149d130>] mld_send_report+0x40/0x150

     which lock already depends on the new lock.

     the existing dependency chain (in reverse order) is:

     -> #1 (&mc->mca_lock){+.+...}:
            [<ffffffff810a8027>] validate_chain+0x637/0x730
            [<ffffffff810a8417>] __lock_acquire+0x2f7/0x500
            [<ffffffff810a8734>] lock_acquire+0x114/0x150
            [<ffffffff814f691a>] rt_spin_lock+0x4a/0x60
            [<ffffffff8149e4bb>] igmp6_group_added+0x3b/0x120
            [<ffffffff8149e5d8>] ipv6_mc_up+0x38/0x60
            [<ffffffff81480a4d>] ipv6_find_idev+0x3d/0x80
            [<ffffffff81483175>] addrconf_notify+0x3d5/0x4b0
            [<ffffffff814fae3f>] notifier_call_chain+0x3f/0x80
            [<ffffffff81073471>] raw_notifier_call_chain+0x11/0x20
            [<ffffffff813d8722>] call_netdevice_notifiers+0x32/0x60
            [<ffffffff813d92d4>] __dev_notify_flags+0x34/0x80
            [<ffffffff813d9360>] dev_change_flags+0x40/0x70
            [<ffffffff813ea627>] do_setlink+0x237/0x8a0
            [<ffffffff813ebb6c>] rtnl_newlink+0x3ec/0x600
            [<ffffffff813eb4d0>] rtnetlink_rcv_msg+0x160/0x310
            [<ffffffff814040b9>] netlink_rcv_skb+0x89/0xb0
            [<ffffffff813eb357>] rtnetlink_rcv+0x27/0x40
            [<ffffffff81403e20>] netlink_unicast+0x140/0x180
            [<ffffffff81404a9e>] netlink_sendmsg+0x33e/0x380
            [<ffffffff813c4252>] sock_sendmsg+0x112/0x130
            [<ffffffff813c537e>] __sys_sendmsg+0x44e/0x460
            [<ffffffff813c5544>] sys_sendmsg+0x44/0x70
            [<ffffffff814feab9>] system_call_fastpath+0x16/0x1b

     -> #0 (&ndev->lock){+.+...}:
            [<ffffffff810a798e>] check_prev_add+0x3de/0x440
            [<ffffffff810a8027>] validate_chain+0x637/0x730
            [<ffffffff810a8417>] __lock_acquire+0x2f7/0x500
            [<ffffffff810a8734>] lock_acquire+0x114/0x150
            [<ffffffff814f6c82>] rt_read_lock+0x42/0x60
            [<ffffffff8147f804>] ipv6_get_lladdr+0x74/0x120
            [<ffffffff8149b036>] mld_newpack+0xb6/0x160
            [<ffffffff8149b18b>] add_grhead+0xab/0xc0
            [<ffffffff8149d03b>] add_grec+0x3ab/0x460
            [<ffffffff8149d14a>] mld_send_report+0x5a/0x150
            [<ffffffff8149f99e>] igmp6_timer_handler+0x4e/0xb0
            [<ffffffff8105705a>] call_timer_fn+0xca/0x1d0
            [<ffffffff81057b9f>] run_timer_softirq+0x1df/0x2e0
            [<ffffffff8104e8c7>] handle_pending_softirqs+0xf7/0x1f0
            [<ffffffff8104ea3b>] __do_softirq_common+0x7b/0xf0
            [<ffffffff8104f07f>] __thread_do_softirq+0x1af/0x210
            [<ffffffff8104f1c1>] run_ksoftirqd+0xe1/0x1f0
            [<ffffffff8106c7de>] kthread+0xae/0xc0
            [<ffffffff814fff74>] kernel_thread_helper+0x4/0x10

    actually we can just hold idev->lock before taking pmc->mca_lock,
    and avoid taking idev->lock again when iterating idev->addr_list,
    since the upper callers of mld_newpack() already take
    read_lock_bh(&idev->lock).

    Reported-by: dingtianhong <dingtianhong@huawei.com>
    Cc: dingtianhong <dingtianhong@huawei.com>
    Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
    Cc: David S. Miller <davem@davemloft.net>
    Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Tested-by: Ding Tianhong <dingtianhong@huawei.com>
    Tested-by: Chen Weilong <chenweilong@huawei.com>
    Signed-off-by: Cong Wang <amwang@redhat.com>
    Acked-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 e533fb01a23b2c572b11f5357c330daba10039a9
Author: Changli Gao <xiaosuo@gmail.com>
Date:   Sat Jun 29 00:15:51 2013 +0800

    net: Swap ver and type in pppoe_hdr

    [ Upstream commit b1a5a34bd0b8767ea689e68f8ea513e9710b671e ]

    Ver and type in pppoe_hdr should be swapped as defined by RFC2516
    section-4.

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

commit 3f9059aea8ac27ea66c868121e0ecd31b3afaff6
Author: Dave Jones <davej@redhat.com>
Date:   Fri Jun 28 12:13:52 2013 -0400

    x25: Fix broken locking in ioctl error paths.

    [ Upstream commit 4ccb93ce7439b63c31bc7597bfffd13567fa483d ]

    Two of the x25 ioctl cases have error paths that break out of the function without
    unlocking the socket, leading to this warning:

    ================================================
    [ BUG: lock held when returning to user space! ]
    3.10.0-rc7+ #36 Not tainted
    ------------------------------------------------
    trinity-child2/31407 is leaving the kernel with locks still held!
    1 lock held by trinity-child2/31407:
     #0:  (sk_lock-AF_X25){+.+.+.}, at: [<ffffffffa024b6da>] x25_ioctl+0x8a/0x740 [x25]

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

commit f4ded0dfedaa8cab85c67fd5db5b9eef9f981c15
Author: Eric Dumazet <eric.dumazet@gmail.com>
Date:   Fri Jun 28 02:37:42 2013 -0700

    neighbour: fix a race in neigh_destroy()

    [ Upstream commit c9ab4d85de222f3390c67aedc9c18a50e767531e ]

    There is a race in neighbour code, because neigh_destroy() uses
    skb_queue_purge(&neigh->arp_queue) without holding neighbour lock,
    while other parts of the code assume neighbour rwlock is what
    protects arp_queue

    Convert all skb_queue_purge() calls to the __skb_queue_purge() variant

    Use __skb_queue_head_init() instead of skb_queue_head_init()
    to make clear we do not use arp_queue.lock

    And hold neigh->lock in neigh_destroy() to close the race.

    Reported-by: Joe Jin <joe.jin@oracle.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 3a35ccb6009ad66aa21f821a3c99ca0374b59a28
Author: Mathias Krause <minipli@googlemail.com>
Date:   Wed Jun 26 23:52:30 2013 +0200

    af_key: fix info leaks in notify messages

    [ Upstream commit a5cc68f3d63306d0d288f31edfc2ae6ef8ecd887 ]

    key_notify_sa_flush() and key_notify_policy_flush() miss to initialize
    the sadb_msg_reserved member of the broadcasted message and thereby
    leak 2 bytes of heap memory to listeners. Fix that.

    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Steffen Klassert <steffen.klassert@secunet.com>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7a4957b92965755a246b52c4721a6c9a47f5bf31
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Jun 26 04:15:07 2013 -0700

    ipv6: ip6_sk_dst_check() must not assume ipv6 dst

    [ Upstream commit a963a37d384d71ad43b3e9e79d68d42fbe0901f3 ]

    It's possible to use AF_INET6 sockets and to connect to an IPv4
    destination. After this, socket dst cache is a pointer to a rtable,
    not rt6_info.

    ip6_sk_dst_check() should check the socket dst cache is IPv6, or else
    various corruptions/crashes can happen.

    Dave Jones can reproduce immediate crash with
    trinity -q -l off -n -c sendmsg -c connect

    With help from Hannes Frederic Sowa

    Reported-by: Dave Jones <davej@redhat.com>
    Reported-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Acked-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 f9ebf8ce570a993023dd8bb20a7378f710bba4ac
Author: Gao feng <gaofeng@cn.fujitsu.com>
Date:   Sun Jun 16 11:14:30 2013 +0800

    ipv6: don't call addrconf_dst_alloc again when enable lo

    [ Upstream commit a881ae1f625c599b460cc8f8a7fcb1c438f699ad ]

    If we disable all of the net interfaces, and enable
    un-lo interface before lo interface, we already allocated
    the addrconf dst in ipv6_add_addr. So we shouldn't allocate
    it again when we enable lo interface.

    Otherwise the message below will be triggered.
    unregister_netdevice: waiting for sit1 to become free. Usage count = 1

    This problem is introduced by commit 25fb6ca4ed9cad72f14f61629b68dc03c0d9713f
    "net IPv6 : Fix broken IPv6 routing table after loopback down-up"

    Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 86fa4bff222f45bc33cc8b720f805b5b28edd19e
Author: Linus Lüssing <linus.luessing@web.de>
Date:   Sun Jun 16 23:20:34 2013 +0200

    bridge: fix switched interval for MLD Query types

    [ Upstream commit 32de868cbc6bee010d2cee95b5071b25ecbec8c3 ]

    General Queries (the one with the Multicast Address field
    set to zero / '::') are supposed to have a Maximum Response Delay
    of [Query Response Interval], while for Multicast-Address-Specific
    Queries it is [Last Listener Query Interval] - not the other way
    round. (see RFC2710, section 7.3+7.8)

    Signed-off-by: Linus Lüssing <linus.luessing@web.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 519d018ae15412bd501598872300d4c883197b44
Author: Dave Kleikamp <dave.kleikamp@oracle.com>
Date:   Tue Jun 18 09:05:36 2013 -0500

    sparc: tsb must be flushed before tlb

    upstream commit 23a01138efe216f8084cfaa74b0b90dd4b097441

    This fixes a race where a cpu may re-load a tlb from a stale tsb right
    after it has been flushed by a remote function call.

    I still see some instability when stressing the system with parallel
    kernel builds while creating memory pressure by writing to
    /proc/sys/vm/nr_hugepages, but this patch improves the stability
    significantly.

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

commit b37c61632db280b4e831dc2431a73ca045bc7e42
Author: bob picco <bpicco@meloft.net>
Date:   Tue Jun 11 14:54:51 2013 -0400

    sparc64 address-congruence property

    Upstream commit 771a37ff4d80b80db3b0df3e7696f14b298c67b7

    The Machine Description (MD) property "address-congruence-offset" is
    optional. According to the MD specification the value is assumed 0UL when
    not present. This caused early boot failure on T5.

    Signed-off-by: Bob Picco <bob.picco@oracle.com>
    CC: sparclinux@vger.kernel.org
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 00c218981b362e8dbfd624ebf0c874bb1bc9df04
Author: Olivier DANET <odanet@caramail.com>
Date:   Wed Jul 10 13:56:10 2013 -0700

    sparc32: vm_area_struct access for old Sun SPARCs.

    upstream commit 961246b4ed8da3bcf4ee1eb9147f341013553e3c

    Commit e4c6bfd2d79d063017ab19a18915f0bc759f32d9 ("mm: rearrange
    vm_area_struct for fewer cache misses") changed the layout of the
    vm_area_struct structure, it broke several SPARC32 assembly routines
    which used numerical constants for accessing the vm_mm field.

    This patch defines the VMA_VM_MM constant to replace the immediate values.

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

commit 795c3e68abaa0daa388ff2eb8bc577db955d8f7e
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Fri Jul 12 11:08:33 2013 +0200

    perf: Fix perf_lock_task_context() vs RCU

    commit 058ebd0eba3aff16b144eabf4510ed9510e1416e upstream.

    Jiri managed to trigger this warning:

     [] ======================================================
     [] [ INFO: possible circular locking dependency detected ]
     [] 3.10.0+ #228 Tainted: G        W
     [] -------------------------------------------------------
     [] p/6613 is trying to acquire lock:
     []  (rcu_node_0){..-...}, at: [<ffffffff810ca797>] rcu_read_unlock_special+0xa7/0x250
     []
     [] but task is already holding lock:
     []  (&ctx->lock){-.-...}, at: [<ffffffff810f2879>] perf_lock_task_context+0xd9/0x2c0
     []
     [] which lock already depends on the new lock.
     []
     [] the existing dependency chain (in reverse order) is:
     []
     [] -> #4 (&ctx->lock){-.-...}:
     [] -> #3 (&rq->lock){-.-.-.}:
     [] -> #2 (&p->pi_lock){-.-.-.}:
     [] -> #1 (&rnp->nocb_gp_wq[1]){......}:
     [] -> #0 (rcu_node_0){..-...}:

    Paul was quick to explain that due to preemptible RCU we cannot call
    rcu_read_unlock() while holding scheduler (or nested) locks when part
    of the read side critical section was preemptible.

    Therefore solve it by making the entire RCU read side non-preemptible.

    Also pull out the retry from under the non-preempt to play nice with RT.

    Reported-by: Jiri Olsa <jolsa@redhat.com>
    Helped-out-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Signed-off-by: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dfee0631d8373dc18ddc6bceed1ff0b76f22d911
Author: Jiri Olsa <jolsa@redhat.com>
Date:   Tue Jul 9 17:44:11 2013 +0200

    perf: Remove WARN_ON_ONCE() check in __perf_event_enable() for valid scenario

    commit 06f417968beac6e6b614e17b37d347aa6a6b1d30 upstream.

    The '!ctx->is_active' check has a valid scenario, so
    there's no need for the warning.

    The reason is that there's a time window between the
    'ctx->is_active' check in the perf_event_enable() function
    and the __perf_event_enable() function having:

      - IRQs on
      - ctx->lock unlocked

    where the task could be killed and 'ctx' deactivated by
    perf_event_exit_task(), ending up with the warning below.

    So remove the WARN_ON_ONCE() check and add comments to
    explain it all.

    This addresses the following warning reported by Vince Weaver:

    [  324.983534] ------------[ cut here ]------------
    [  324.984420] WARNING: at kernel/events/core.c:1953 __perf_event_enable+0x187/0x190()
    [  324.984420] Modules linked in:
    [  324.984420] CPU: 19 PID: 2715 Comm: nmi_bug_snb Not tainted 3.10.0+ #246
    [  324.984420] Hardware name: Supermicro X8DTN/X8DTN, BIOS 4.6.3 01/08/2010
    [  324.984420]  0000000000000009 ffff88043fce3ec8 ffffffff8160ea0b ffff88043fce3f00
    [  324.984420]  ffffffff81080ff0 ffff8802314fdc00 ffff880231a8f800 ffff88043fcf7860
    [  324.984420]  0000000000000286 ffff880231a8f800 ffff88043fce3f10 ffffffff8108103a
    [  324.984420] Call Trace:
    [  324.984420]  <IRQ>  [<ffffffff8160ea0b>] dump_stack+0x19/0x1b
    [  324.984420]  [<ffffffff81080ff0>] warn_slowpath_common+0x70/0xa0
    [  324.984420]  [<ffffffff8108103a>] warn_slowpath_null+0x1a/0x20
    [  324.984420]  [<ffffffff81134437>] __perf_event_enable+0x187/0x190
    [  324.984420]  [<ffffffff81130030>] remote_function+0x40/0x50
    [  324.984420]  [<ffffffff810e51de>] generic_smp_call_function_single_interrupt+0xbe/0x130
    [  324.984420]  [<ffffffff81066a47>] smp_call_function_single_interrupt+0x27/0x40
    [  324.984420]  [<ffffffff8161fd2f>] call_function_single_interrupt+0x6f/0x80
    [  324.984420]  <EOI>  [<ffffffff816161a1>] ? _raw_spin_unlock_irqrestore+0x41/0x70
    [  324.984420]  [<ffffffff8113799d>] perf_event_exit_task+0x14d/0x210
    [  324.984420]  [<ffffffff810acd04>] ? switch_task_namespaces+0x24/0x60
    [  324.984420]  [<ffffffff81086946>] do_exit+0x2b6/0xa40
    [  324.984420]  [<ffffffff8161615c>] ? _raw_spin_unlock_irq+0x2c/0x30
    [  324.984420]  [<ffffffff81087279>] do_group_exit+0x49/0xc0
    [  324.984420]  [<ffffffff81096854>] get_signal_to_deliver+0x254/0x620
    [  324.984420]  [<ffffffff81043057>] do_signal+0x57/0x5a0
    [  324.984420]  [<ffffffff8161a164>] ? __do_page_fault+0x2a4/0x4e0
    [  324.984420]  [<ffffffff8161665c>] ? retint_restore_args+0xe/0xe
    [  324.984420]  [<ffffffff816166cd>] ? retint_signal+0x11/0x84
    [  324.984420]  [<ffffffff81043605>] do_notify_resume+0x65/0x80
    [  324.984420]  [<ffffffff81616702>] retint_signal+0x46/0x84
    [  324.984420] ---[ end trace 442ec2f04db3771a ]---

    Reported-by: Vince Weaver <vincent.weaver@maine.edu>
    Signed-off-by: Jiri Olsa <jolsa@redhat.com>
    Suggested-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    Cc: Ingo Molnar <mingo@elte.hu>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/1373384651-6109-2-git-send-email-jolsa@redhat.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a1861db6e611efe38b0754e3ba0d48d3613983f5
Author: Jiri Olsa <jolsa@redhat.com>
Date:   Tue Jul 9 17:44:10 2013 +0200

    perf: Clone child context from parent context pmu

    commit 734df5ab549ca44f40de0f07af1c8803856dfb18 upstream.

    Currently when the child context for inherited events is
    created, it's based on the pmu object of the first event
    of the parent context.

    This is wrong for the following scenario:

      - HW context having HW and SW event
      - HW event got removed (closed)
      - SW event stays in HW context as the only event
        and its pmu is used to clone the child context

    The issue starts when the cpu context object is touched
    based on the pmu context object (__get_cpu_context). In
    this case the HW context will work with SW cpu context
    ending up with following WARN below.

    Fixing this by using parent context pmu object to clone
    from child context.

    Addresses the following warning reported by Vince Weaver:

    [ 2716.472065] ------------[ cut here ]------------
    [ 2716.476035] WARNING: at kernel/events/core.c:2122 task_ctx_sched_out+0x3c/0x)
    [ 2716.476035] Modules linked in: nfsd auth_rpcgss oid_registry nfs_acl nfs locn
    [ 2716.476035] CPU: 0 PID: 3164 Comm: perf_fuzzer Not tainted 3.10.0-rc4 #2
    [ 2716.476035] Hardware name: AOpen   DE7000/nMCP7ALPx-DE R1.06 Oct.19.2012, BI2
    [ 2716.476035]  0000000000000000 ffffffff8102e215 0000000000000000 ffff88011fc18
    [ 2716.476035]  ffff8801175557f0 0000000000000000 ffff880119fda88c ffffffff810ad
    [ 2716.476035]  ffff880119fda880 ffffffff810af02a 0000000000000009 ffff880117550
    [ 2716.476035] Call Trace:
    [ 2716.476035]  [<ffffffff8102e215>] ? warn_slowpath_common+0x5b/0x70
    [ 2716.476035]  [<ffffffff810ab2bd>] ? task_ctx_sched_out+0x3c/0x5f
    [ 2716.476035]  [<ffffffff810af02a>] ? perf_event_exit_task+0xbf/0x194
    [ 2716.476035]  [<ffffffff81032a37>] ? do_exit+0x3e7/0x90c
    [ 2716.476035]  [<ffffffff810cd5ab>] ? __do_fault+0x359/0x394
    [ 2716.476035]  [<ffffffff81032fe6>] ? do_group_exit+0x66/0x98
    [ 2716.476035]  [<ffffffff8103dbcd>] ? get_signal_to_deliver+0x479/0x4ad
    [ 2716.476035]  [<ffffffff810ac05c>] ? __perf_event_task_sched_out+0x230/0x2d1
    [ 2716.476035]  [<ffffffff8100205d>] ? do_signal+0x3c/0x432
    [ 2716.476035]  [<ffffffff810abbf9>] ? ctx_sched_in+0x43/0x141
    [ 2716.476035]  [<ffffffff810ac2ca>] ? perf_event_context_sched_in+0x7a/0x90
    [ 2716.476035]  [<ffffffff810ac311>] ? __perf_event_task_sched_in+0x31/0x118
    [ 2716.476035]  [<ffffffff81050dd9>] ? mmdrop+0xd/0x1c
    [ 2716.476035]  [<ffffffff81051a39>] ? finish_task_switch+0x7d/0xa6
    [ 2716.476035]  [<ffffffff81002473>] ? do_notify_resume+0x20/0x5d
    [ 2716.476035]  [<ffffffff813654f5>] ? retint_signal+0x3d/0x78
    [ 2716.476035] ---[ end trace 827178d8a5966c3d ]---

    Reported-by: Vince Weaver <vincent.weaver@maine.edu>
    Signed-off-by: Jiri Olsa <jolsa@redhat.com>
    Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    Cc: Ingo Molnar <mingo@elte.hu>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/1373384651-6109-1-git-send-email-jolsa@redhat.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 41a42852682c730a3693f1ef8855aa76f4b117fd
Author: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
Date:   Thu May 30 21:10:37 2013 -0400

    tracing: Use current_uid() for critical time tracing

    commit f17a5194859a82afe4164e938b92035b86c55794 upstream.

    The irqsoff tracer records the max time that interrupts are disabled.
    There are hooks in the assembly code that calls back into the tracer when
    interrupts are disabled or enabled.

    When they are enabled, the tracer checks if the amount of time they
    were disabled is larger than the previous recorded max interrupts off
    time. If it is, it creates a snapshot of the currently running trace
    to store where the last largest interrupts off time was held and how
    it happened.

    During testing, this RCU lockdep dump appeared:

    [ 1257.829021] ===============================
    [ 1257.829021] [ INFO: suspicious RCU usage. ]
    [ 1257.829021] 3.10.0-rc1-test+ #171 Tainted: G        W
    [ 1257.829021] -------------------------------
    [ 1257.829021] /home/rostedt/work/git/linux-trace.git/include/linux/rcupdate.h:780 rcu_read_lock() used illegally while idle!
    [ 1257.829021]
    [ 1257.829021] other info that might help us debug this:
    [ 1257.829021]
    [ 1257.829021]
    [ 1257.829021] RCU used illegally from idle CPU!
    [ 1257.829021] rcu_scheduler_active = 1, debug_locks = 0
    [ 1257.829021] RCU used illegally from extended quiescent state!
    [ 1257.829021] 2 locks held by trace-cmd/4831:
    [ 1257.829021]  #0:  (max_trace_lock){......}, at: [<ffffffff810e2b77>] stop_critical_timing+0x1a3/0x209
    [ 1257.829021]  #1:  (rcu_read_lock){.+.+..}, at: [<ffffffff810dae5a>] __update_max_tr+0x88/0x1ee
    [ 1257.829021]
    [ 1257.829021] stack backtrace:
    [ 1257.829021] CPU: 3 PID: 4831 Comm: trace-cmd Tainted: G        W    3.10.0-rc1-test+ #171
    [ 1257.829021] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS SDBLI944.86P 05/08/2007
    [ 1257.829021]  0000000000000001 ffff880065f49da8 ffffffff8153dd2b ffff880065f49dd8
    [ 1257.829021]  ffffffff81092a00 ffff88006bd78680 ffff88007add7500 0000000000000003
    [ 1257.829021]  ffff88006bd78680 ffff880065f49e18 ffffffff810daebf ffffffff810dae5a
    [ 1257.829021] Call Trace:
    [ 1257.829021]  [<ffffffff8153dd2b>] dump_stack+0x19/0x1b
    [ 1257.829021]  [<ffffffff81092a00>] lockdep_rcu_suspicious+0x109/0x112
    [ 1257.829021]  [<ffffffff810daebf>] __update_max_tr+0xed/0x1ee
    [ 1257.829021]  [<ffffffff810dae5a>] ? __update_max_tr+0x88/0x1ee
    [ 1257.829021]  [<ffffffff811002b9>] ? user_enter+0xfd/0x107
    [ 1257.829021]  [<ffffffff810dbf85>] update_max_tr_single+0x11d/0x12d
    [ 1257.829021]  [<ffffffff811002b9>] ? user_enter+0xfd/0x107
    [ 1257.829021]  [<ffffffff810e2b15>] stop_critical_timing+0x141/0x209
    [ 1257.829021]  [<ffffffff8109569a>] ? trace_hardirqs_on+0xd/0xf
    [ 1257.829021]  [<ffffffff811002b9>] ? user_enter+0xfd/0x107
    [ 1257.829021]  [<ffffffff810e3057>] time_hardirqs_on+0x2a/0x2f
    [ 1257.829021]  [<ffffffff811002b9>] ? user_enter+0xfd/0x107
    [ 1257.829021]  [<ffffffff8109550c>] trace_hardirqs_on_caller+0x16/0x197
    [ 1257.829021]  [<ffffffff8109569a>] trace_hardirqs_on+0xd/0xf
    [ 1257.829021]  [<ffffffff811002b9>] user_enter+0xfd/0x107
    [ 1257.829021]  [<ffffffff810029b4>] do_notify_resume+0x92/0x97
    [ 1257.829021]  [<ffffffff8154bdca>] int_signal+0x12/0x17

    What happened was entering into the user code, the interrupts were enabled
    and a max interrupts off was recorded. The trace buffer was saved along with
    various information about the task: comm, pid, uid, priority, etc.

    The uid is recorded with task_uid(tsk). But this is a macro that uses rcu_read_lock()
    to retrieve the data, and this happened to happen where RCU is blind (user_enter).

    As only the preempt and irqs off tracers can have this happen, and they both
    only have the tsk == current, if tsk == current, use current_uid() instead of
    task_uid(), as current_uid() does not use RCU as only current can change its uid.

    This fixes the RCU suspicious splat.

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

commit 9fdc84e56b76450d0d252893aa0ca87f69ba65df
Author: Sreekanth Reddy <Sreekanth.Reddy@lsi.com>
Date:   Sat Feb 2 00:58:20 2013 +0530

    SCSI: mpt2sas: fix firmware failure with wrong task attribute

    commit 48ba2efc382f94fae16ca8ca011e5961a81ad1ea upstream.

    When SCSI command is received with task attribute not set, set it to SIMPLE.
    Previously it is set to untagged. This causes the firmware to fail the commands.

    Signed-off-by: Sreekanth Reddy <Sreekanth.Reddy@lsi.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ddaf85745502f71e6a873c5cb6c975a3b0993bbc
Author: Daniel Hansel <daniel.hansel@linux.vnet.ibm.com>
Date:   Fri Apr 26 17:32:14 2013 +0200

    SCSI: zfcp: fix adapter (re)open recovery while link to SAN is down

    commit f76ccaac4f82c463a037aa4a1e4ccb85c7011814 upstream.

    FCP device remains in status ERP_FAILED when device is switched online
    or adapter recovery is triggered  while link to SAN is down.

    When Exchange Configuration Data command returns the FSF status
    FSF_EXCHANGE_CONFIG_DATA_INCOMPLETE it aborts the exchange process.
    The only retries are done during the common error recovery procedure
    (i.e. max. 3 retries with 8sec sleep between) and remains in status
    ERP_FAILED with QDIO down.

    This commit reverts the commit 0df138476c8306478d6e726f044868b4bccf411c
    (zfcp: Fix adapter activation on link down).
    When FSF status FSF_EXCHANGE_CONFIG_DATA_INCOMPLETE is received the
    adapter recovery will be finished without any retries. QDIO will be
    up now and status changes such as LINK UP will be received now.

    Signed-off-by: Daniel Hansel <daniel.hansel@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 1d912e701574a3327199d20d280f010b479a41af
Author: Gabor Juhos <juhosg@openwrt.org>
Date:   Sat Jun 22 13:13:25 2013 +0200

    rt2x00: read 5GHz TX power values from the correct offset

    commit 0a6f3a8ebaf13407523c2c7d575b4ca2debd23ba upstream.

    The current code uses the same index value both
    for the channel information array and for the TX
    power table. The index starts from 14, however the
    index of the TX power table must start from zero.

    Fix it, in order to get the correct TX power value
    for a given channel.

    The changes in rt61pci.c and rt73usb.c are compile
    tested only.

    Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
    Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
    Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ed8aac0dcdc333c2e3d1b49c098284be3d6d3421
Author: Fabio Estevam <fabio.estevam@freescale.com>
Date:   Thu Jul 4 20:01:03 2013 -0300

    ASoC: sglt5000: Fix SGTL5000_PLL_FRAC_DIV_MASK

    commit 5c78dfe87ea04b501ee000a7f03b9432ac9d008c upstream.

    SGTL5000_PLL_FRAC_DIV_MASK is used to mask bits 0-10 (11 bits in total) of
    register CHIP_PLL_CTRL, so fix the mask to accomodate all this bit range.

    Reported-by: Oskar Schirmer <oskar@scara.com>
    Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
    Signed-off-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9ffff08f8af9f5a1773693f9bd05f9053aaab23d
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Mon Jul 1 22:14:10 2013 +0200

    tick: Prevent uncontrolled switch to oneshot mode

    commit 1f73a9806bdd07a5106409bbcab3884078bd34fe upstream.

    When the system switches from periodic to oneshot mode, the broadcast
    logic causes a possibility that a CPU which has not yet switched to
    oneshot mode puts its own clock event device into oneshot mode without
    updating the state and the timer handler.

    CPU0                CPU1
                    per cpu tickdev is in periodic mode
                    and switched to broadcast

    Switch to oneshot mode
     tick_broadcast_switch_to_oneshot()
      cpumask_copy(tick_oneshot_broacast_mask,
               tick_broadcast_mask);

      broadcast device mode = oneshot

                    Timer interrupt

                    irq_enter()
                     tick_check_oneshot_broadcast()
                      dev->set_mode(ONESHOT);

                    tick_handle_periodic()
                     if (dev->mode == ONESHOT)
                       dev->next_event += period;
                       FAIL.

    We fail, because dev->next_event contains KTIME_MAX, if the device was
    in periodic mode before the uncontrolled switch to oneshot happened.

    We must copy the broadcast bits over to the oneshot mask, because
    otherwise a CPU which relies on the broadcast would not been woken up
    anymore after the broadcast device switched to oneshot mode.

    So we need to verify in tick_check_oneshot_broadcast() whether the CPU
    has already switched to oneshot mode. If not, leave the device
    untouched and let the CPU switch controlled into oneshot mode.

    This is a long standing bug, which was never noticed, because the main
    user of the broadcast x86 cannot run into that scenario, AFAICT. The
    nonarchitected timer mess of ARM creates a gazillion of differently
    broken abominations which trigger the shortcomings of that broadcast
    code, which better had never been necessary in the first place.

    Reported-and-tested-by: Stehle Vincent-B46079 <B46079@freescale.com>
    Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
    Cc: John Stultz <john.stultz@linaro.org>,
    Cc: Mark Rutland <mark.rutland@arm.com>
    Link: http://lkml.kernel.org/r/alpine.DEB.2.02.1307012153060.4013@ionos.tec.linutronix.de
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>