1. 19 2月, 2017 2 次提交
    • L
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net · 3dd9c127
      Linus Torvalds 提交于
      Pull networking fixes from David Miller:
      
       1) Fix leak in dpaa_eth error paths, from Dan Carpenter.
      
       2) Use after free when using IPV6_RECVPKTINFO, from Andrey Konovalov.
      
       3) fanout_release() cannot be invoked from atomic contexts, from Anoob
          Soman.
      
       4) Fix bogus attempt at lockdep annotation in IRDA.
      
       5) dev_fill_metadata_dst() can OOP on a NULL dst cache pointer, from
          Paolo Abeni.
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
        irda: Fix lockdep annotations in hashbin_delete().
        vxlan: fix oops in dev_fill_metadata_dst
        dccp: fix freeing skb too early for IPV6_RECVPKTINFO
        dpaa_eth: small leak on error
        packet: Do not call fanout_release from atomic contexts
      3dd9c127
    • S
      printk: use rcuidle console tracepoint · fc98c3c8
      Sergey Senozhatsky 提交于
      Use rcuidle console tracepoint because, apparently, it may be issued
      from an idle CPU:
      
        hw-breakpoint: Failed to enable monitor mode on CPU 0.
        hw-breakpoint: CPU 0 failed to disable vector catch
      
        ===============================
        [ ERR: suspicious RCU usage.  ]
        4.10.0-rc8-next-20170215+ #119 Not tainted
        -------------------------------
        ./include/trace/events/printk.h:32 suspicious rcu_dereference_check() usage!
      
        other info that might help us debug this:
      
        RCU used illegally from idle CPU!
        rcu_scheduler_active = 2, debug_locks = 0
        RCU used illegally from extended quiescent state!
        2 locks held by swapper/0/0:
         #0:  (cpu_pm_notifier_lock){......}, at: [<c0237e2c>] cpu_pm_exit+0x10/0x54
         #1:  (console_lock){+.+.+.}, at: [<c01ab350>] vprintk_emit+0x264/0x474
      
        stack backtrace:
        CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.10.0-rc8-next-20170215+ #119
        Hardware name: Generic OMAP4 (Flattened Device Tree)
          console_unlock
          vprintk_emit
          vprintk_default
          printk
          reset_ctrl_regs
          dbg_cpu_pm_notify
          notifier_call_chain
          cpu_pm_exit
          omap_enter_idle_coupled
          cpuidle_enter_state
          cpuidle_enter_state_coupled
          do_idle
          cpu_startup_entry
          start_kernel
      
      This RCU warning, however, is suppressed by lockdep_off() in printk().
      lockdep_off() increments the ->lockdep_recursion counter and thus
      disables RCU_LOCKDEP_WARN() and debug_lockdep_rcu_enabled(), which want
      lockdep to be enabled "current->lockdep_recursion == 0".
      
      Link: http://lkml.kernel.org/r/20170217015932.11898-1-sergey.senozhatsky@gmail.comSigned-off-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Reported-by: NTony Lindgren <tony@atomide.com>
      Tested-by: NTony Lindgren <tony@atomide.com>
      Acked-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Acked-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      Cc: Petr Mladek <pmladek@suse.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Russell King <rmk@armlinux.org.uk>
      Cc: <stable@vger.kernel.org> [3.4+]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      fc98c3c8
  2. 18 2月, 2017 11 次提交
    • D
      irda: Fix lockdep annotations in hashbin_delete(). · 4c03b862
      David S. Miller 提交于
      A nested lock depth was added to the hasbin_delete() code but it
      doesn't actually work some well and results in tons of lockdep splats.
      
      Fix the code instead to properly drop the lock around the operation
      and just keep peeking the head of the hashbin queue.
      Reported-by: NDmitry Vyukov <dvyukov@google.com>
      Tested-by: NDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4c03b862
    • L
      Merge branch 'for-linus' of git://git.kernel.dk/linux-block · 6dc39c50
      Linus Torvalds 提交于
      Pull block layer fix from Jens Axboe:
       "A single fix for a lockdep splat reported by Thomas and Gabriel"
      
      * 'for-linus' of git://git.kernel.dk/linux-block:
        cfq-iosched: don't call wbt_disable_default() with IRQs disabled
      6dc39c50
    • P
      vxlan: fix oops in dev_fill_metadata_dst · 22f0708a
      Paolo Abeni 提交于
      Since the commit 0c1d70af ("net: use dst_cache for vxlan device")
      vxlan_fill_metadata_dst() calls vxlan_get_route() passing a NULL
      dst_cache pointer, so the latter should explicitly check for
      valid dst_cache ptr. Unfortunately the commit d71785ff ("net: add
      dst_cache to ovs vxlan lwtunnel") removed said check.
      
      As a result is possible to trigger a null pointer access calling
      vxlan_fill_metadata_dst(), e.g. with:
      
      ovs-vsctl add-br ovs-br0
      ovs-vsctl add-port ovs-br0 vxlan0 -- set interface vxlan0 \
      	type=vxlan options:remote_ip=192.168.1.1 \
      	options:key=1234 options:dst_port=4789 ofport_request=10
      ip address add dev ovs-br0 172.16.1.2/24
      ovs-vsctl set Bridge ovs-br0 ipfix=@i -- --id=@i create IPFIX \
      	targets=\"172.16.1.1:1234\" sampling=1
      iperf -c 172.16.1.1 -u -l 1000 -b 10M -t 1 -p 1234
      
      This commit addresses the issue passing to vxlan_get_route() the
      dst_cache already available into the lwt info processed by
      vxlan_fill_metadata_dst().
      
      Fixes: d71785ff ("net: add dst_cache to ovs vxlan lwtunnel")
      Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
      Acked-by: NJiri Benc <jbenc@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      22f0708a
    • A
      dccp: fix freeing skb too early for IPV6_RECVPKTINFO · 5edabca9
      Andrey Konovalov 提交于
      In the current DCCP implementation an skb for a DCCP_PKT_REQUEST packet
      is forcibly freed via __kfree_skb in dccp_rcv_state_process if
      dccp_v6_conn_request successfully returns.
      
      However, if IPV6_RECVPKTINFO is set on a socket, the address of the skb
      is saved to ireq->pktopts and the ref count for skb is incremented in
      dccp_v6_conn_request, so skb is still in use. Nevertheless, it gets freed
      in dccp_rcv_state_process.
      
      Fix by calling consume_skb instead of doing goto discard and therefore
      calling __kfree_skb.
      
      Similar fixes for TCP:
      
      fb7e2399 [TCP]: skb is unexpectedly freed.
      0aea76d3 tcp: SYN packets are now
      simply consumed
      Signed-off-by: NAndrey Konovalov <andreyknvl@google.com>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5edabca9
    • L
      Merge tag 'powerpc-4.10-5' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux · 2fe1e8a7
      Linus Torvalds 提交于
      Pull powerpc fix from Michael Ellerman:
       "One fix from Paul: we can not use the radix MMU under a hypervisor for
        now.
      
        Although the code checked if the processor supports radix, that is not
        sufficient"
      
      * tag 'powerpc-4.10-5' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
        powerpc/64: Disable use of radix under a hypervisor
      2fe1e8a7
    • L
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input · a0d5ef45
      Linus Torvalds 提交于
      Pull input fix from Dmitry Torokhov:
       "Just a single change to Elan touchpad driver to recognize a new ACPI
        ID"
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
        Input: elan_i2c - add ELAN0605 to the ACPI table
      a0d5ef45
    • L
      Merge branch 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux · 444a034d
      Linus Torvalds 提交于
      Pull i2c fix from Wolfram Sang:
       "I2C has a revert to fix a regression"
      
      * 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
        Revert "i2c: designware: detect when dynamic tar update is possible"
      444a034d
    • L
      Merge tag 'mmc-v4.10-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc · 6adfd6ac
      Linus Torvalds 提交于
      Pull MMC fix from Ulf Hansson:
       "Fix multi-bit bus width without high-speed mode for MMC"
      
      * tag 'mmc-v4.10-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc:
        mmc: core: fix multi-bit bus width without high-speed mode
      6adfd6ac
    • L
      Merge tag 'ntb-4.10-bugfixes' of git://github.com/jonmason/ntb · 7ed1b125
      Linus Torvalds 提交于
      Pull NTB bugfixes frfom Jon Mason:
       "NTB bug fixes to address a crash when unloading the ntb module, a DMA
        engine unmap leak, allowing the proper queue choice, and clearing the
        SKX irq bit"
      
      * tag 'ntb-4.10-bugfixes' of git://github.com/jonmason/ntb:
        ntb: ntb_hw_intel: link_poll isn't clearing the pending status properly
        ntb_transport: Pick an unused queue
        ntb: ntb_perf missing dmaengine_unmap_put
        NTB: ntb_transport: fix debugfs_remove_recursive
      7ed1b125
    • D
      dpaa_eth: small leak on error · 785f3577
      Dan Carpenter 提交于
      This should be >= instead of > here.  It means that we don't increment
      the free count enough so it becomes off by one.
      
      Fixes: 9ad1a374 ("dpaa_eth: add support for DPAA Ethernet")
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      785f3577
    • A
      packet: Do not call fanout_release from atomic contexts · 2bd624b4
      Anoob Soman 提交于
      Commit 66644982 ("packet: call fanout_release, while UNREGISTERING a
      netdev"), unfortunately, introduced the following issues.
      
      1. calling mutex_lock(&fanout_mutex) (fanout_release()) from inside
      rcu_read-side critical section. rcu_read_lock disables preemption, most often,
      which prohibits calling sleeping functions.
      
      [  ] include/linux/rcupdate.h:560 Illegal context switch in RCU read-side critical section!
      [  ]
      [  ] rcu_scheduler_active = 1, debug_locks = 0
      [  ] 4 locks held by ovs-vswitchd/1969:
      [  ]  #0:  (cb_lock){++++++}, at: [<ffffffff8158a6c9>] genl_rcv+0x19/0x40
      [  ]  #1:  (ovs_mutex){+.+.+.}, at: [<ffffffffa04878ca>] ovs_vport_cmd_del+0x4a/0x100 [openvswitch]
      [  ]  #2:  (rtnl_mutex){+.+.+.}, at: [<ffffffff81564157>] rtnl_lock+0x17/0x20
      [  ]  #3:  (rcu_read_lock){......}, at: [<ffffffff81614165>] packet_notifier+0x5/0x3f0
      [  ]
      [  ] Call Trace:
      [  ]  [<ffffffff813770c1>] dump_stack+0x85/0xc4
      [  ]  [<ffffffff810c9077>] lockdep_rcu_suspicious+0x107/0x110
      [  ]  [<ffffffff810a2da7>] ___might_sleep+0x57/0x210
      [  ]  [<ffffffff810a2fd0>] __might_sleep+0x70/0x90
      [  ]  [<ffffffff8162e80c>] mutex_lock_nested+0x3c/0x3a0
      [  ]  [<ffffffff810de93f>] ? vprintk_default+0x1f/0x30
      [  ]  [<ffffffff81186e88>] ? printk+0x4d/0x4f
      [  ]  [<ffffffff816106dd>] fanout_release+0x1d/0xe0
      [  ]  [<ffffffff81614459>] packet_notifier+0x2f9/0x3f0
      
      2. calling mutex_lock(&fanout_mutex) inside spin_lock(&po->bind_lock).
      "sleeping function called from invalid context"
      
      [  ] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:620
      [  ] in_atomic(): 1, irqs_disabled(): 0, pid: 1969, name: ovs-vswitchd
      [  ] INFO: lockdep is turned off.
      [  ] Call Trace:
      [  ]  [<ffffffff813770c1>] dump_stack+0x85/0xc4
      [  ]  [<ffffffff810a2f52>] ___might_sleep+0x202/0x210
      [  ]  [<ffffffff810a2fd0>] __might_sleep+0x70/0x90
      [  ]  [<ffffffff8162e80c>] mutex_lock_nested+0x3c/0x3a0
      [  ]  [<ffffffff816106dd>] fanout_release+0x1d/0xe0
      [  ]  [<ffffffff81614459>] packet_notifier+0x2f9/0x3f0
      
      3. calling dev_remove_pack(&fanout->prot_hook), from inside
      spin_lock(&po->bind_lock) or rcu_read-side critical-section. dev_remove_pack()
      -> synchronize_net(), which might sleep.
      
      [  ] BUG: scheduling while atomic: ovs-vswitchd/1969/0x00000002
      [  ] INFO: lockdep is turned off.
      [  ] Call Trace:
      [  ]  [<ffffffff813770c1>] dump_stack+0x85/0xc4
      [  ]  [<ffffffff81186274>] __schedule_bug+0x64/0x73
      [  ]  [<ffffffff8162b8cb>] __schedule+0x6b/0xd10
      [  ]  [<ffffffff8162c5db>] schedule+0x6b/0x80
      [  ]  [<ffffffff81630b1d>] schedule_timeout+0x38d/0x410
      [  ]  [<ffffffff810ea3fd>] synchronize_sched_expedited+0x53d/0x810
      [  ]  [<ffffffff810ea6de>] synchronize_rcu_expedited+0xe/0x10
      [  ]  [<ffffffff8154eab5>] synchronize_net+0x35/0x50
      [  ]  [<ffffffff8154eae3>] dev_remove_pack+0x13/0x20
      [  ]  [<ffffffff8161077e>] fanout_release+0xbe/0xe0
      [  ]  [<ffffffff81614459>] packet_notifier+0x2f9/0x3f0
      
      4. fanout_release() races with calls from different CPU.
      
      To fix the above problems, remove the call to fanout_release() under
      rcu_read_lock(). Instead, call __dev_remove_pack(&fanout->prot_hook) and
      netdev_run_todo will be happy that &dev->ptype_specific list is empty. In order
      to achieve this, I moved dev_{add,remove}_pack() out of fanout_{add,release} to
      __fanout_{link,unlink}. So, call to {,__}unregister_prot_hook() will make sure
      fanout->prot_hook is removed as well.
      
      Fixes: 66644982 ("packet: call fanout_release, while UNREGISTERING a netdev")
      Reported-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NAnoob Soman <anoob.soman@citrix.com>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2bd624b4
  3. 17 2月, 2017 13 次提交
  4. 16 2月, 2017 10 次提交
  5. 15 2月, 2017 4 次提交
    • Y
      PCI/PME: Restore pcie_pme_driver.remove · afe3e4d1
      Yinghai Lu 提交于
      In addition to making PME non-modular, d7def204 ("PCI/PME: Make
      explicitly non-modular") removed the pcie_pme_driver .remove() method,
      pcie_pme_remove().
      
      pcie_pme_remove() freed the PME IRQ that was requested in pci_pme_probe().
      The fact that we don't free the IRQ after d7def204 causes the following
      crash when removing a PCIe port device via /sys:
      
        ------------[ cut here ]------------
        kernel BUG at drivers/pci/msi.c:370!
        invalid opcode: 0000 [#1] SMP
        Modules linked in:
        CPU: 1 PID: 14509 Comm: sh Tainted: G    W  4.8.0-rc1-yh-00012-gd29438d6
        RIP: 0010:[<ffffffff9758bbf5>]  free_msi_irqs+0x65/0x190
        ...
        Call Trace:
         [<ffffffff9758cda4>] pci_disable_msi+0x34/0x40
         [<ffffffff97583817>] cleanup_service_irqs+0x27/0x30
         [<ffffffff97583e9a>] pcie_port_device_remove+0x2a/0x40
         [<ffffffff97584250>] pcie_portdrv_remove+0x40/0x50
         [<ffffffff97576d7b>] pci_device_remove+0x4b/0xc0
         [<ffffffff9785ebe6>] __device_release_driver+0xb6/0x150
         [<ffffffff9785eca5>] device_release_driver+0x25/0x40
         [<ffffffff975702e4>] pci_stop_bus_device+0x74/0xa0
         [<ffffffff975704ea>] pci_stop_and_remove_bus_device_locked+0x1a/0x30
         [<ffffffff97578810>] remove_store+0x50/0x70
         [<ffffffff9785a378>] dev_attr_store+0x18/0x30
         [<ffffffff97260b64>] sysfs_kf_write+0x44/0x60
         [<ffffffff9725feae>] kernfs_fop_write+0x10e/0x190
         [<ffffffff971e13f8>] __vfs_write+0x28/0x110
         [<ffffffff970b0fa4>] ? percpu_down_read+0x44/0x80
         [<ffffffff971e53a7>] ? __sb_start_write+0xa7/0xe0
         [<ffffffff971e53a7>] ? __sb_start_write+0xa7/0xe0
         [<ffffffff971e1f04>] vfs_write+0xc4/0x180
         [<ffffffff971e3089>] SyS_write+0x49/0xa0
         [<ffffffff97001a46>] do_syscall_64+0xa6/0x1b0
         [<ffffffff9819201e>] entry_SYSCALL64_slow_path+0x25/0x25
        ...
         RIP  [<ffffffff9758bbf5>] free_msi_irqs+0x65/0x190
         RSP <ffff89ad3085bc48>
        ---[ end trace f4505e1dac5b95d3 ]---
        Segmentation fault
      
      Restore pcie_pme_remove().
      
      [bhelgaas: changelog]
      Fixes: d7def204 ("PCI/PME: Make explicitly non-modular")
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      CC: stable@vger.kernel.org	# v4.9+
      afe3e4d1
    • P
      drm/dp/mst: fix kernel oops when turning off secondary monitor · bb08c04d
      Pierre-Louis Bossart 提交于
      100% reproducible issue found on SKL SkullCanyon NUC with two external
      DP daisy-chained monitors in DP/MST mode. When turning off or changing
      the input of the second monitor the machine stops with a kernel
      oops. This issue happened with 4.8.8 as well as drm/drm-intel-nightly.
      
      This issue is traced to an inconsistent control flow in
      drm_dp_update_payload_part1(): the 'port' pointer is set to NULL at the
      same time as 'req_payload.num_slots' is set to zero, but the pointer is
      dereferenced even when req_payload.num_slot is zero.
      
      The problematic dereference was introduced in commit dfda0df3
      ("drm/mst: rework payload table allocation to conform better") and may
      impact all versions since v3.18
      
      The fix suggested by Chris Wilson removes the kernel oops and was found to
      work well after 10mn of monkey-testing with the second monitor power and
      input buttons
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98990
      Fixes: dfda0df3 ("drm/mst: rework payload table allocation to conform better.")
      Cc: Dave Airlie <airlied@redhat.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Nathan D Ciobanu <nathan.d.ciobanu@linux.intel.com>
      Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
      Cc: Sean Paul <seanpaul@chromium.org>
      Cc: <stable@vger.kernel.org> # v3.18+
      Tested-by: NNathan D Ciobanu <nathan.d.ciobanu@linux.intel.com>
      Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
      Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1487076561-2169-1-git-send-email-jani.nikula@intel.com
      bb08c04d
    • S
      fuse: fix use after free issue in fuse_dev_do_read() · 6ba4d272
      Sahitya Tummala 提交于
      There is a potential race between fuse_dev_do_write()
      and request_wait_answer() contexts as shown below:
      
      TASK 1:
      __fuse_request_send():
        |--spin_lock(&fiq->waitq.lock);
        |--queue_request();
        |--spin_unlock(&fiq->waitq.lock);
        |--request_wait_answer():
             |--if (test_bit(FR_SENT, &req->flags))
             <gets pre-empted after it is validated true>
                                         TASK 2:
                                         fuse_dev_do_write():
                                           |--clears bit FR_SENT,
                                           |--request_end():
                                              |--sets bit FR_FINISHED
                                              |--spin_lock(&fiq->waitq.lock);
                                              |--list_del_init(&req->intr_entry);
                                              |--spin_unlock(&fiq->waitq.lock);
                                              |--fuse_put_request();
             |--queue_interrupt();
             <request gets queued to interrupts list>
                  |--wake_up_locked(&fiq->waitq);
             |--wait_event_freezable();
             <as FR_FINISHED is set, it returns and then
             the caller frees this request>
      
      Now, the next fuse_dev_do_read(), see interrupts list is not empty
      and then calls fuse_read_interrupt() which tries to access the request
      which is already free'd and gets the below crash:
      
      [11432.401266] Unable to handle kernel paging request at virtual address
      6b6b6b6b6b6b6b6b
      ...
      [11432.418518] Kernel BUG at ffffff80083720e0
      [11432.456168] PC is at __list_del_entry+0x6c/0xc4
      [11432.463573] LR is at fuse_dev_do_read+0x1ac/0x474
      ...
      [11432.679999] [<ffffff80083720e0>] __list_del_entry+0x6c/0xc4
      [11432.687794] [<ffffff80082c65e0>] fuse_dev_do_read+0x1ac/0x474
      [11432.693180] [<ffffff80082c6b14>] fuse_dev_read+0x6c/0x78
      [11432.699082] [<ffffff80081d5638>] __vfs_read+0xc0/0xe8
      [11432.704459] [<ffffff80081d5efc>] vfs_read+0x90/0x108
      [11432.709406] [<ffffff80081d67f0>] SyS_read+0x58/0x94
      
      As FR_FINISHED bit is set before deleting the intr_entry with input
      queue lock in request completion path, do the testing of this flag and
      queueing atomically with the same lock in queue_interrupt().
      Signed-off-by: NSahitya Tummala <stummala@codeaurora.org>
      Signed-off-by: NMiklos Szeredi <mszeredi@redhat.com>
      Fixes: fd22d62e ("fuse: no fc->lock for iqueue parts")
      Cc: <stable@vger.kernel.org> # 4.2+
      6ba4d272
    • S