1. 19 Feb, 2017 1 commit
    • Sergey Senozhatsky's avatar
      printk: use rcuidle console tracepoint · fc98c3c8
      Sergey Senozhatsky authored
      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: default avatarSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Reported-by: default avatarTony Lindgren <tony@atomide.com>
      Tested-by: default avatarTony Lindgren <tony@atomide.com>
      Acked-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Acked-by: default avatarSteven 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: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      fc98c3c8
  2. 17 Feb, 2017 12 commits
  3. 16 Feb, 2017 12 commits
  4. 15 Feb, 2017 11 commits
    • Thomas Falcon's avatar
      ibmvnic: Fix endian errors in error reporting output · 75224c93
      Thomas Falcon authored
      Error reports received from firmware were not being converted from
      big endian values, leading to bogus error codes reported on little
      endian systems.
      Signed-off-by: default avatarThomas Falcon <tlfalcon@linux.vnet.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      75224c93
    • Thomas Falcon's avatar
      ibmvnic: Fix endian error when requesting device capabilities · 28f4d165
      Thomas Falcon authored
      When a vNIC client driver requests a faulty device setting, the
      server returns an acceptable value for the client to request.
      This 64 bit value was incorrectly being swapped as a 32 bit value,
      resulting in loss of data. This patch corrects that by using
      the 64 bit swap function.
      Signed-off-by: default avatarThomas Falcon <tlfalcon@linux.vnet.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      28f4d165
    • Marcus Huewe's avatar
      net: neigh: Fix netevent NETEVENT_DELAY_PROBE_TIME_UPDATE notification · 7627ae60
      Marcus Huewe authored
      When setting a neigh related sysctl parameter, we always send a
      NETEVENT_DELAY_PROBE_TIME_UPDATE netevent. For instance, when
      executing
      
      	sysctl net.ipv6.neigh.wlp3s0.retrans_time_ms=2000
      
      a NETEVENT_DELAY_PROBE_TIME_UPDATE netevent is generated.
      
      This is caused by commit 2a4501ae ("neigh: Send a
      notification when DELAY_PROBE_TIME changes"). According to the
      commit's description, it was intended to generate such an event
      when setting the "delay_first_probe_time" sysctl parameter.
      
      In order to fix this, only generate this event when actually
      setting the "delay_first_probe_time" sysctl parameter. This fix
      should not have any unintended side-effects, because all but one
      registered netevent callbacks check for other netevent event
      types (the registered callbacks were obtained by grepping for
      "register_netevent_notifier"). The only callback that uses the
      NETEVENT_DELAY_PROBE_TIME_UPDATE event is
      mlxsw_sp_router_netevent_event() (in
      drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c): in case
      of this event, it only accesses the DELAY_PROBE_TIME of the
      passed neigh_parms.
      
      Fixes: 2a4501ae ("neigh: Send a notification when DELAY_PROBE_TIME changes")
      Signed-off-by: default avatarMarcus Huewe <suse-tux@gmx.de>
      Reviewed-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7627ae60
    • Anssi Hannula's avatar
      net: xilinx_emaclite: fix freezes due to unordered I/O · acf138f1
      Anssi Hannula authored
      The xilinx_emaclite uses __raw_writel and __raw_readl for register
      accesses. Those functions do not imply any kind of memory barriers and
      they may be reordered.
      
      The driver does not seem to take that into account, though, and the
      driver does not satisfy the ordering requirements of the hardware.
      For clear examples, see xemaclite_mdio_write() and xemaclite_mdio_read()
      which try to set MDIO address before initiating the transaction.
      
      I'm seeing system freezes with the driver with GCC 5.4 and current
      Linux kernels on Zynq-7000 SoC immediately when trying to use the
      interface.
      
      In commit 123c1407 ("net: emaclite: Do not use microblaze and ppc
      IO functions") the driver was switched from non-generic
      in_be32/out_be32 (memory barriers, big endian) to
      __raw_readl/__raw_writel (no memory barriers, native endian), so
      apparently the device follows system endianness and the driver was
      originally written with the assumption of memory barriers.
      
      Rather than try to hunt for each case of missing barrier, just switch
      the driver to use iowrite32/ioread32/iowrite32be/ioread32be depending
      on endianness instead.
      
      Tested on little-endian Zynq-7000 ARM SoC FPGA.
      Signed-off-by: default avatarAnssi Hannula <anssi.hannula@bitwise.fi>
      Fixes: 123c1407 ("net: emaclite: Do not use microblaze and ppc IO
      functions")
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      acf138f1
    • Anssi Hannula's avatar
      net: xilinx_emaclite: fix receive buffer overflow · cd224553
      Anssi Hannula authored
      xilinx_emaclite looks at the received data to try to determine the
      Ethernet packet length but does not properly clamp it if
      proto_type == ETH_P_IP or 1500 < proto_type <= 1518, causing a buffer
      overflow and a panic via skb_panic() as the length exceeds the allocated
      skb size.
      
      Fix those cases.
      
      Also add an additional unconditional check with WARN_ON() at the end.
      Signed-off-by: default avatarAnssi Hannula <anssi.hannula@bitwise.fi>
      Fixes: bb81b2dd ("net: add Xilinx emac lite device driver")
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cd224553
    • Yinghai Lu's avatar
      PCI/PME: Restore pcie_pme_driver.remove · afe3e4d1
      Yinghai Lu authored
      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: default avatarYinghai Lu <yinghai@kernel.org>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      CC: stable@vger.kernel.org	# v4.9+
      afe3e4d1
    • Pierre-Louis Bossart's avatar
      drm/dp/mst: fix kernel oops when turning off secondary monitor · bb08c04d
      Pierre-Louis Bossart authored
      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: default avatarNathan D Ciobanu <nathan.d.ciobanu@linux.intel.com>
      Reviewed-by: default avatarDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
      Signed-off-by: default avatarPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1487076561-2169-1-git-send-email-jani.nikula@intel.com
      bb08c04d
    • Sahitya Tummala's avatar
      fuse: fix use after free issue in fuse_dev_do_read() · 6ba4d272
      Sahitya Tummala authored
      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: default avatarSahitya Tummala <stummala@codeaurora.org>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Fixes: fd22d62e ("fuse: no fc->lock for iqueue parts")
      Cc: <stable@vger.kernel.org> # 4.2+
      6ba4d272
    • Stephen Rothwell's avatar
    • Eric Dumazet's avatar
      tcp: tcp_probe: use spin_lock_bh() · e70ac171
      Eric Dumazet authored
      tcp_rcv_established() can now run in process context.
      
      We need to disable BH while acquiring tcp probe spinlock,
      or risk a deadlock.
      
      Fixes: 5413d1ba ("net: do not block BH while processing socket backlog")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarRicardo Nabinger Sanchez <rnsanchez@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e70ac171
    • Dmitry V. Levin's avatar
      uapi: fix linux/if_pppol2tp.h userspace compilation errors · a725eb15
      Dmitry V. Levin authored
      Because of <linux/libc-compat.h> interface limitations, <netinet/in.h>
      provided by libc cannot be included after <linux/in.h>, therefore any
      header that includes <netinet/in.h> cannot be included after <linux/in.h>.
      
      Change uapi/linux/l2tp.h, the last uapi header that includes
      <netinet/in.h>, to include <linux/in.h> and <linux/in6.h> instead of
      <netinet/in.h> and use __SOCK_SIZE__ instead of sizeof(struct sockaddr)
      the same way as uapi/linux/in.h does, to fix linux/if_pppol2tp.h userspace
      compilation errors like this:
      
      In file included from /usr/include/linux/l2tp.h:12:0,
                       from /usr/include/linux/if_pppol2tp.h:21,
      /usr/include/netinet/in.h:31:8: error: redefinition of 'struct in_addr'
      
      Fixes: 47c3e778 ("net: l2tp: deprecate PPPOL2TP_MSG_* in favour of L2TP_MSG_*")
      Signed-off-by: default avatarDmitry V. Levin <ldv@altlinux.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a725eb15
  5. 14 Feb, 2017 4 commits