Linux 3.0.85

commit 2d0ed86595ca3a101c710efaec7aab0ca69c76da
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Jul 3 11:03:56 2013 -0700

    Linux 3.0.85

commit db61e4ec623437237d05b5ab8ce97d9377682de2
Author: Liang Li <liang.li@windriver.com>
Date:   Sat Jan 19 17:52:10 2013 +0800

    pch_uart: fix a deadlock when pch_uart as console

    commit 384e301e3519599b000c1a2ecd938b533fc15d85 upstream.

    When we use pch_uart as system console like 'console=ttyPCH0,115200',
    then 'send break' to it. We'll encounter the deadlock on a cpu/core,
    with interrupts disabled on the core. When we happen to have all irqs
    affinity to cpu0 then the deadlock on cpu0 actually deadlock whole
    system.

    In pch_uart_interrupt, we have spin_lock_irqsave(&priv->lock, flags)
    then call pch_uart_err_ir when break is received. Then the call to
    dev_err would actually call to pch_console_write then we'll run into
    another spin_lock(&priv->lock), with interrupts disabled.

    So in the call sequence lead by pch_uart_interrupt, we should be
    carefully to call functions that will 'print message to console' only
    in case the uart port is not being used as serial console.

    Signed-off-by: Liang Li <liang.li@windriver.com>
    Cc: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c6c46477761504a89d5c68331f3b86fe31b51338
Author: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Date:   Fri Jun 28 14:15:15 2013 +0300

    UBIFS: fix a horrid bug

    commit 605c912bb843c024b1ed173dc427cd5c08e5d54d upstream.

    Al Viro pointed me to the fact that '->readdir()' and '->llseek()' have no
    mutual exclusion, which means the 'ubifs_dir_llseek()' can be run while we are
    in the middle of 'ubifs_readdir()'.

    This means that 'file->private_data' can be freed while 'ubifs_readdir()' uses
    it, and this is a very bad bug: not only 'ubifs_readdir()' can return garbage,
    but this may corrupt memory and lead to all kinds of problems like crashes an
    security holes.

    This patch fixes the problem by using the 'file->f_version' field, which
    '->llseek()' always unconditionally sets to zero. We set it to 1 in
    'ubifs_readdir()' and whenever we detect that it became 0, we know there was a
    seek and it is time to clear the state saved in 'file->private_data'.

    I tested this patch by writing a user-space program which runds readdir and
    seek in parallell. I could easily crash the kernel without these patches, but
    could not crash it with these patches.

    Reported-by: Al Viro <viro@zeniv.linux.org.uk>
    Tested-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1f4f917e5e882de1e701d7b26955884ed16604d5
Author: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Date:   Fri Jun 28 14:15:14 2013 +0300

    UBIFS: prepare to fix a horrid bug

    commit 33f1a63ae84dfd9ad298cf275b8f1887043ced36 upstream.

    Al Viro pointed me to the fact that '->readdir()' and '->llseek()' have no
    mutual exclusion, which means the 'ubifs_dir_llseek()' can be run while we are
    in the middle of 'ubifs_readdir()'.

    First of all, this means that 'file->private_data' can be freed while
    'ubifs_readdir()' uses it.  But this particular patch does not fix the problem.
    This patch is only a preparation, and the fix will follow next.

    In this patch we make 'ubifs_readdir()' stop using 'file->f_pos' directly,
    because 'file->f_pos' can be changed by '->llseek()' at any point. This may
    lead 'ubifs_readdir()' to returning inconsistent data: directory entry names
    may correspond to incorrect file positions.

    So here we introduce a local variable 'pos', read 'file->f_pose' once at very
    the beginning, and then stick to 'pos'. The result of this is that when
    'ubifs_dir_llseek()' changes 'file->f_pos' while we are in the middle of
    'ubifs_readdir()', the latter "wins".

    Reported-by: Al Viro <viro@zeniv.linux.org.uk>
    Tested-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5d28835c59b02d4389003bbfa7c4276375f39ed6
Author: Stephane Eranian <eranian@google.com>
Date:   Thu Jun 20 11:36:28 2013 +0200

    perf: Disable monitoring on setuid processes for regular users

    commit 2976b10f05bd7f6dab9f9e7524451ddfed656a89 upstream.

    There was a a bug in setup_new_exec(), whereby
    the test to disabled perf monitoring was not
    correct because the new credentials for the
    process were not yet committed and therefore
    the get_dumpable() test was never firing.

    The patch fixes the problem by moving the
    perf_event test until after the credentials
    are committed.

    Signed-off-by: Stephane Eranian <eranian@google.com>
    Tested-by: Jiri Olsa <jolsa@redhat.com>
    Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 806f529730af538c2edbb805589c48cc19ad169b
Author: Zefan Li <lizefan@huawei.com>
Date:   Wed Jun 26 15:31:58 2013 +0800

    dlci: validate the net device in dlci_del()

    commit 578a1310f2592ba90c5674bca21c1dbd1adf3f0a upstream.

    We triggered an oops while running trinity with 3.4 kernel:

    BUG: unable to handle kernel paging request at 0000000100000d07
    IP: [<ffffffffa0109738>] dlci_ioctl+0xd8/0x2d4 [dlci]
    PGD 640c0d067 PUD 0
    Oops: 0000 [#1] PREEMPT SMP
    CPU 3
    ...
    Pid: 7302, comm: trinity-child3 Not tainted 3.4.24.09+ 40 Huawei Technologies Co., Ltd. Tecal RH2285          /BC11BTSA
    RIP: 0010:[<ffffffffa0109738>]  [<ffffffffa0109738>] dlci_ioctl+0xd8/0x2d4 [dlci]
    ...
    Call Trace:
      [<ffffffff8137c5c3>] sock_ioctl+0x153/0x280
      [<ffffffff81195494>] do_vfs_ioctl+0xa4/0x5e0
      [<ffffffff8118354a>] ? fget_light+0x3ea/0x490
      [<ffffffff81195a1f>] sys_ioctl+0x4f/0x80
      [<ffffffff81478b69>] system_call_fastpath+0x16/0x1b
    ...

    It's because the net device is not a dlci device.

    Reported-by: Li Jinyue <lijinyue@huawei.com>
    Signed-off-by: Li Zefan <lizefan@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 72ad35befc4715ebb0d715b90f27572ef11a15e2
Author: Zefan Li <lizefan@huawei.com>
Date:   Wed Jun 26 15:29:54 2013 +0800

    dlci: acquire rtnl_lock before calling __dev_get_by_name()

    commit 11eb2645cbf38a08ae491bf6c602eea900ec0bb5 upstream.

    Otherwise the net device returned can be freed at anytime.

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

commit e2652ea43028e5409c2fd2b585dc8388a6e75bd0
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Thu Jun 20 17:50:09 2013 +0200

    hw_breakpoint: Use cpu_possible_mask in {reserve,release}_bp_slot()

    commit c790b0ad23f427c7522ffed264706238c57c007e upstream.

    fetch_bp_busy_slots() and toggle_bp_slot() use
    for_each_online_cpu(), this is obviously wrong wrt cpu_up() or
    cpu_down(), we can over/under account the per-cpu numbers.

    For example:

        # echo 0 >> /sys/devices/system/cpu/cpu1/online
        # perf record -e mem:0x10 -p 1 &
        # echo 1 >> /sys/devices/system/cpu/cpu1/online
        # perf record -e mem:0x10,mem:0x10,mem:0x10,mem:0x10 -C1 -a &
        # taskset -p 0x2 1

    triggers the same WARN_ONCE("Can't find any breakpoint slot") in
    arch_install_hw_breakpoint().

    Reported-by: Vince Weaver <vincent.weaver@maine.edu>
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Acked-by: Frederic Weisbecker <fweisbec@gmail.com>
    Link: http://lkml.kernel.org/r/20130620155009.GA6327@redhat.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3ddc55287a4505a5634643fec8e02f887498ffc8
Author: Anderson Lizardo <anderson.lizardo@openbossa.org>
Date:   Sun Jun 2 16:30:40 2013 -0400

    Bluetooth: Fix crash in l2cap_build_cmd() with small MTU

    commit 300b962e5244a1ea010df7e88595faa0085b461d upstream.

    If a too small MTU value is set with ioctl(HCISETACLMTU) or by a bogus
    controller, memory corruption happens due to a memcpy() call with
    negative length.

    Fix this crash on either incoming or outgoing connections with a MTU
    smaller than L2CAP_HDR_SIZE + L2CAP_CMD_HDR_SIZE:

    [   46.885433] BUG: unable to handle kernel paging request at f56ad000
    [   46.888037] IP: [<c03d94cd>] memcpy+0x1d/0x40
    [   46.888037] *pdpt = 0000000000ac3001 *pde = 00000000373f8067 *pte = 80000000356ad060
    [   46.888037] Oops: 0002 [#1] SMP DEBUG_PAGEALLOC
    [   46.888037] Modules linked in: hci_vhci bluetooth virtio_balloon i2c_piix4 uhci_hcd usbcore usb_common
    [   46.888037] CPU: 0 PID: 1044 Comm: kworker/u3:0 Not tainted 3.10.0-rc1+ #12
    [   46.888037] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
    [   46.888037] Workqueue: hci0 hci_rx_work [bluetooth]
    [   46.888037] task: f59b15b0 ti: f55c4000 task.ti: f55c4000
    [   46.888037] EIP: 0060:[<c03d94cd>] EFLAGS: 00010212 CPU: 0
    [   46.888037] EIP is at memcpy+0x1d/0x40
    [   46.888037] EAX: f56ac1c0 EBX: fffffff8 ECX: 3ffffc6e EDX: f55c5cf2
    [   46.888037] ESI: f55c6b32 EDI: f56ad000 EBP: f55c5c68 ESP: f55c5c5c
    [   46.888037]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
    [   46.888037] CR0: 8005003b CR2: f56ad000 CR3: 3557d000 CR4: 000006f0
    [   46.888037] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
    [   46.888037] DR6: ffff0ff0 DR7: 00000400
    [   46.888037] Stack:
    [   46.888037]  fffffff8 00000010 00000003 f55c5cac f8c6a54c ffffffff f8c69eb2 00000000
    [   46.888037]  f4783cdc f57f0070 f759c590 1001c580 00000003 0200000a 00000000 f5a88560
    [   46.888037]  f5ba2600 f5a88560 00000041 00000000 f55c5d90 f8c6f4c7 00000008 f55c5cf2
    [   46.888037] Call Trace:
    [   46.888037]  [<f8c6a54c>] l2cap_send_cmd+0x1cc/0x230 [bluetooth]
    [   46.888037]  [<f8c69eb2>] ? l2cap_global_chan_by_psm+0x152/0x1a0 [bluetooth]
    [   46.888037]  [<f8c6f4c7>] l2cap_connect+0x3f7/0x540 [bluetooth]
    [   46.888037]  [<c019b37b>] ? trace_hardirqs_off+0xb/0x10
    [   46.888037]  [<c01a0ff8>] ? mark_held_locks+0x68/0x110
    [   46.888037]  [<c064ad20>] ? mutex_lock_nested+0x280/0x360
    [   46.888037]  [<c064b9d9>] ? __mutex_unlock_slowpath+0xa9/0x150
    [   46.888037]  [<c01a118c>] ? trace_hardirqs_on_caller+0xec/0x1b0
    [   46.888037]  [<c064ad08>] ? mutex_lock_nested+0x268/0x360
    [   46.888037]  [<c01a125b>] ? trace_hardirqs_on+0xb/0x10
    [   46.888037]  [<f8c72f8d>] l2cap_recv_frame+0xb2d/0x1d30 [bluetooth]
    [   46.888037]  [<c01a0ff8>] ? mark_held_locks+0x68/0x110
    [   46.888037]  [<c064b9d9>] ? __mutex_unlock_slowpath+0xa9/0x150
    [   46.888037]  [<c01a118c>] ? trace_hardirqs_on_caller+0xec/0x1b0
    [   46.888037]  [<f8c754f1>] l2cap_recv_acldata+0x2a1/0x320 [bluetooth]
    [   46.888037]  [<f8c491d8>] hci_rx_work+0x518/0x810 [bluetooth]
    [   46.888037]  [<f8c48df2>] ? hci_rx_work+0x132/0x810 [bluetooth]
    [   46.888037]  [<c0158979>] process_one_work+0x1a9/0x600
    [   46.888037]  [<c01588fb>] ? process_one_work+0x12b/0x600
    [   46.888037]  [<c015922e>] ? worker_thread+0x19e/0x320
    [   46.888037]  [<c015922e>] ? worker_thread+0x19e/0x320
    [   46.888037]  [<c0159187>] worker_thread+0xf7/0x320
    [   46.888037]  [<c0159090>] ? rescuer_thread+0x290/0x290
    [   46.888037]  [<c01602f8>] kthread+0xa8/0xb0
    [   46.888037]  [<c0656777>] ret_from_kernel_thread+0x1b/0x28
    [   46.888037]  [<c0160250>] ? flush_kthread_worker+0x120/0x120
    [   46.888037] Code: c3 90 8d 74 26 00 e8 63 fc ff ff eb e8 90 55 89 e5 83 ec 0c 89 5d f4 89 75 f8 89 7d fc 3e 8d 74 26 00 89 cb 89 c7 c1 e9 02 89 d6 <f3> a5 89 d9 83 e1 03 74 02 f3 a4 8b 5d f4 8b 75 f8 8b 7d fc 89
    [   46.888037] EIP: [<c03d94cd>] memcpy+0x1d/0x40 SS:ESP 0068:f55c5c5c
    [   46.888037] CR2: 00000000f56ad000
    [   46.888037] ---[ end trace 0217c1f4d78714a9 ]---

    Signed-off-by: Anderson Lizardo <anderson.lizardo@openbossa.org>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>