1. 03 Jul, 2013 11 commits
    • Peter Zijlstra's avatar
      perf: Fix perf mmap bugs · 535fad87
      Peter Zijlstra authored
      commit 26cb63ad upstream.
      
      Vince reported a problem found by his perf specific trinity
      fuzzer.
      
      Al noticed 2 problems with perf's mmap():
      
       - it has issues against fork() since we use vma->vm_mm for accounting.
       - it has an rb refcount leak on double mmap().
      
      We fix the issues against fork() by using VM_DONTCOPY; I don't
      think there's code out there that uses this; we didn't hear
      about weird accounting problems/crashes. If we do need this to
      work, the previously proposed VM_PINNED could make this work.
      
      Aside from the rb reference leak spotted by Al, Vince's example
      prog was indeed doing a double mmap() through the use of
      perf_event_set_output().
      
      This exposes another problem, since we now have 2 events with
      one buffer, the accounting gets screwy because we account per
      event. Fix this by making the buffer responsible for its own
      accounting.
      
      [Backporting for 3.4-stable.
      VM_RESERVED flag was replaced with pair 'VM_DONTEXPAND | VM_DONTDUMP' in
      314e51b9 since 3.7.0-rc1, and 314e51b9 comes from a big patchset, we didn't
      backport the patchset, so I restored 'VM_DNOTEXPAND | VM_DONTDUMP' as before:
      -       vma->vm_flags |= VM_DONTCOPY | VM_DONTEXPAND | VM_DONTDUMP;
      +       vma->vm_flags |= VM_DONTCOPY | VM_RESERVED;
       -- zliu]
      Reported-by: default avatarVince Weaver <vincent.weaver@maine.edu>
      Signed-off-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
      Link: http://lkml.kernel.org/r/20130528085548.GA12193@twins.programming.kicks-ass.netSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarZhouping Liu <zliu@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      535fad87
    • Liang Li's avatar
      pch_uart: fix a deadlock when pch_uart as console · 5d2a2c71
      Liang Li authored
      commit 384e301e 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: default avatarLiang Li <liang.li@windriver.com>
      Cc: Yijing Wang <wangyijing@huawei.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5d2a2c71
    • Artem Bityutskiy's avatar
      UBIFS: fix a horrid bug · 4e3010bf
      Artem Bityutskiy authored
      commit 605c912b 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: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Tested-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4e3010bf
    • Artem Bityutskiy's avatar
      UBIFS: prepare to fix a horrid bug · eafde0bc
      Artem Bityutskiy authored
      commit 33f1a63a 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: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Tested-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      eafde0bc
    • Stephane Eranian's avatar
      perf: Disable monitoring on setuid processes for regular users · f57f135a
      Stephane Eranian authored
      commit 2976b10f 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: default avatarStephane Eranian <eranian@google.com>
      Tested-by: default avatarJiri Olsa <jolsa@redhat.com>
      Acked-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f57f135a
    • Zefan Li's avatar
      dlci: validate the net device in dlci_del() · 7e693230
      Zefan Li authored
      commit 578a1310 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: default avatarLi Jinyue <lijinyue@huawei.com>
      Signed-off-by: default avatarLi Zefan <lizefan@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7e693230
    • Zefan Li's avatar
      dlci: acquire rtnl_lock before calling __dev_get_by_name() · eadc8331
      Zefan Li authored
      commit 11eb2645 upstream.
      
      Otherwise the net device returned can be freed at anytime.
      Signed-off-by: default avatarLi Zefan <lizefan@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      eadc8331
    • Oleg Nesterov's avatar
      hw_breakpoint: Use cpu_possible_mask in {reserve,release}_bp_slot() · ed0b72ac
      Oleg Nesterov authored
      commit c790b0ad 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: default avatarVince Weaver <vincent.weaver@maine.edu>
      Signed-off-by: default avatarOleg Nesterov <oleg@redhat.com>
      Acked-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Link: http://lkml.kernel.org/r/20130620155009.GA6327@redhat.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ed0b72ac
    • Anderson Lizardo's avatar
      Bluetooth: Fix crash in l2cap_build_cmd() with small MTU · 630493e2
      Anderson Lizardo authored
      commit 300b962e 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: default avatarAnderson Lizardo <anderson.lizardo@openbossa.org>
      Signed-off-by: default avatarGustavo Padovan <gustavo.padovan@collabora.co.uk>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      630493e2
    • Simon Baatz's avatar
      ARM: 7772/1: Fix missing flush_kernel_dcache_page() for noMMU · a5f9dc0a
      Simon Baatz authored
      commit 63384fd0 upstream.
      
      Commit 1bc39742 (ARM: 7755/1: handle user space mapped pages in
      flush_kernel_dcache_page) moved the implementation of
      flush_kernel_dcache_page() into mm/flush.c but did not implement it
      on noMMU ARM.
      Signed-off-by: default avatarSimon Baatz <gmbnomis@gmail.com>
      Acked-by: default avatarKevin Hilman <khilman@linaro.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a5f9dc0a
    • Simon Baatz's avatar
      ARM: 7755/1: handle user space mapped pages in flush_kernel_dcache_page · 5fca91fe
      Simon Baatz authored
      commit 1bc39742 upstream.
      
      Commit f8b63c18 made flush_kernel_dcache_page a no-op assuming that
      the pages it needs to handle are kernel mapped only.  However, for
      example when doing direct I/O, pages with user space mappings may
      occur.
      
      Thus, continue to do lazy flushing if there are no user space
      mappings.  Otherwise, flush the kernel cache lines directly.
      Signed-off-by: default avatarSimon Baatz <gmbnomis@gmail.com>
      Reviewed-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5fca91fe
  2. 27 Jun, 2013 28 commits
  3. 20 Jun, 2013 1 commit