1. 26 11月, 2015 1 次提交
  2. 18 11月, 2015 27 次提交
  3. 16 11月, 2015 4 次提交
  4. 11 11月, 2015 5 次提交
  5. 10 11月, 2015 3 次提交
    • J
      net: mvneta: Fix memory use after free. · 8c94ddbc
      Justin Maggard 提交于
      After changing an interface's MTU, then bringing the interface down and
      back up again, I immediately saw tons of kernel messages like below.
      The reason for this bad behavior is mvneta_rxq_drop_pkts(), which calls
      dma_unmap_single() on already-freed memory.  So we need to switch the
      order of those two operations.
      
      [  152.388518] BUG: Bad page state in process ifconfig  pfn:1b518
      [  152.388526] page:dff3dbc0 count:0 mapcount:0 mapping:  (null) index:0x0
      [  152.395178] flags: 0x200(arch_1)
      [  152.398441] page dumped because: PAGE_FLAGS_CHECK_AT_PREP flag set
      [  152.398446] bad because of flags:
      [  152.398450] flags: 0x200(arch_1)
      [  152.401716] Modules linked in:
      [  152.401728] CPU: 0 PID: 1453 Comm: ifconfig Tainted: P    B      O    4.1.12.armada.1 #1
      [  152.401733] Hardware name: Marvell Armada 370/XP (Device Tree)
      [  152.401749] [<c0015b1c>] (unwind_backtrace) from [<c0011d8c>] (show_stack+0x10/0x14)
      [  152.401762] [<c0011d8c>] (show_stack) from [<c06aa68c>] (dump_stack+0x74/0x90)
      [  152.401772] [<c06aa68c>] (dump_stack) from [<c0096c08>] (bad_page+0xc4/0x124)
      [  152.401783] [<c0096c08>] (bad_page) from [<c0099378>] (get_page_from_freelist+0x4e4/0x644)
      [  152.401794] [<c0099378>] (get_page_from_freelist) from [<c0099620>] (__alloc_pages_nodemask+0x148/0x784)
      [  152.401805] [<c0099620>] (__alloc_pages_nodemask) from [<c00ac658>] (kmalloc_order+0x10/0x20)
      [  152.401818] [<c00ac658>] (kmalloc_order) from [<c04c6f44>] (mvneta_rx_refill+0xc4/0xe8)
      [  152.401830] [<c04c6f44>] (mvneta_rx_refill) from [<c04c96c0>] (mvneta_setup_rxqs+0x298/0x39c)
      [  152.401842] [<c04c96c0>] (mvneta_setup_rxqs) from [<c04c9904>] (mvneta_open+0x3c/0x150)
      [  152.401853] [<c04c9904>] (mvneta_open) from [<c0597764>] (__dev_open+0xac/0x124)
      [  152.401864] [<c0597764>] (__dev_open) from [<c05979e4>] (__dev_change_flags+0x8c/0x148)
      [  152.401875] [<c05979e4>] (__dev_change_flags) from [<c0597ac0>] (dev_change_flags+0x18/0x48)
      [  152.401886] [<c0597ac0>] (dev_change_flags) from [<c060d308>] (devinet_ioctl+0x620/0x6d0)
      [  152.401897] [<c060d308>] (devinet_ioctl) from [<c057d810>] (sock_ioctl+0x64/0x288)
      [  152.401908] [<c057d810>] (sock_ioctl) from [<c00dcb7c>] (do_vfs_ioctl+0x78/0x608)
      [  152.401918] [<c00dcb7c>] (do_vfs_ioctl) from [<c00dd170>] (SyS_ioctl+0x64/0x74)
      [  152.401930] [<c00dd170>] (SyS_ioctl) from [<c000f3a0>] (ret_fast_syscall+0x0/0x3c)
      Signed-off-by: NJustin Maggard <jmaggard@netgear.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8c94ddbc
    • A
      remove abs64() · 79211c8e
      Andrew Morton 提交于
      Switch everything to the new and more capable implementation of abs().
      Mainly to give the new abs() a bit of a workout.
      
      Cc: Michal Nazarewicz <mina86@mina86.com>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      79211c8e
    • V
      macvtap: Resolve possible __might_sleep warning in macvtap_do_read() · a499a2e9
      Vlad Yasevich 提交于
      macvtap_do_read code calls macvtap_put_user while it might be set up
      to wait for the user.  This results in the following warning:
      
      Jun 23 16:25:26 galen kernel: ------------[ cut here ]------------
      Jun 23 16:25:26 galen kernel: WARNING: CPU: 0 PID: 30433 at kernel/sched/core.c:
      7286 __might_sleep+0x7f/0x90()
      Jun 23 16:25:26 galen kernel: do not call blocking ops when !TASK_RUNNING; state
      =1 set at [<ffffffff810f1c1f>] prepare_to_wait+0x2f/0x90
      Jun 23 16:25:26 galen kernel: CPU: 0 PID: 30433 Comm: cat Not tainted 4.1.0-rc6+
       #11
      Jun 23 16:25:26 galen kernel: Call Trace:
      Jun 23 16:25:26 galen kernel: [<ffffffff817f76ba>] dump_stack+0x4c/0x65
      Jun 23 16:25:26 galen kernel: [<ffffffff810a07ca>] warn_slowpath_common+0x8a/0xc
      0
      Jun 23 16:25:26 galen kernel: [<ffffffff810a0846>] warn_slowpath_fmt+0x46/0x50
      Jun 23 16:25:26 galen kernel: [<ffffffff810f1c1f>] ?  prepare_to_wait+0x2f/0x90
      Jun 23 16:25:26 galen kernel: [<ffffffff810f1c1f>] ?  prepare_to_wait+0x2f/0x90
      Jun 23 16:25:26 galen kernel: [<ffffffff810cdc1f>] __might_sleep+0x7f/0x90
      Jun 23 16:25:26 galen kernel: [<ffffffff811f8e15>] might_fault+0x55/0xb0
      Jun 23 16:25:26 galen kernel: [<ffffffff810fab9d>] ?  trace_hardirqs_on_caller+0x fd/0x1c0
      Jun 23 16:25:26 galen kernel: [<ffffffff813f639c>] copy_to_iter+0x7c/0x360
      Jun 23 16:25:26 galen kernel: [<ffffffffa052da86>] macvtap_do_read+0x256/0x3d0 [macvtap]
      Jun 23 16:25:26 galen kernel: [<ffffffff810f20e0>] ?  prepare_to_wait_event+0x110/0x110
      Jun 23 16:25:26 galen kernel: [<ffffffffa052dcab>] macvtap_read_iter+0x2b/0x50 [macvtap]
      Jun 23 16:25:26 galen kernel: [<ffffffff81247f2e>] __vfs_read+0xae/0xe0
      Jun 23 16:25:26 galen kernel: [<ffffffff81248526>] vfs_read+0x86/0x140
      Jun 23 16:25:26 galen kernel: [<ffffffff812493b9>] SyS_read+0x49/0xb0
      Jun 23 16:25:26 galen kernel: [<ffffffff8180182e>] system_call_fastpath+0x12/0x76
      Jun 23 16:25:26 galen kernel: ---[ end trace 22e33f67e70c0c2a ]---
      
      Make sure thet we call finish_wait() if we have the skb to process
      before trying to actually process it.
      Signed-off-by: NVladislav Yasevich <vyasevic@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a499a2e9