1. 22 6月, 2017 10 次提交
  2. 21 6月, 2017 12 次提交
  3. 20 6月, 2017 14 次提交
    • J
      Merge branch 'for-4.12/upstream-fixes' into for-linus · 900a88ef
      Jiri Kosina 提交于
      900a88ef
    • P
      livepatch: Fix stacking of patches with respect to RCU · 842c0884
      Petr Mladek 提交于
      rcu_read_(un)lock(), list_*_rcu(), and synchronize_rcu() are used for a secure
      access and manipulation of the list of patches that modify the same function.
      In particular, it is the variable func_stack that is accessible from the ftrace
      handler via struct ftrace_ops and klp_ops.
      
      Of course, it synchronizes also some states of the patch on the top of the
      stack, e.g. func->transition in klp_ftrace_handler.
      
      At the same time, this mechanism guards also the manipulation of
      task->patch_state. It is modified according to the state of the transition and
      the state of the process.
      
      Now, all this works well as long as RCU works well. Sadly livepatching might
      get into some corner cases when this is not true. For example, RCU is not
      watching when rcu_read_lock() is taken in idle threads.  It is because they
      might sleep and prevent reaching the grace period for too long.
      
      There are ways how to make RCU watching even in idle threads, see
      rcu_irq_enter(). But there is a small location inside RCU infrastructure when
      even this does not work.
      
      This small problematic location can be detected either before calling
      rcu_irq_enter() by rcu_irq_enter_disabled() or later by rcu_is_watching().
      Sadly, there is no safe way how to handle it.  Once we detect that RCU was not
      watching, we might see inconsistent state of the function stack and the related
      variables in klp_ftrace_handler(). Then we could do a wrong decision, use an
      incompatible implementation of the function and break the consistency of the
      system. We could warn but we could not avoid the damage.
      
      Fortunately, ftrace has similar problems and they seem to be solved well there.
      It uses a heavy weight implementation of some RCU operations. In particular, it
      replaces:
      
        + rcu_read_lock() with preempt_disable_notrace()
        + rcu_read_unlock() with preempt_enable_notrace()
        + synchronize_rcu() with schedule_on_each_cpu(sync_work)
      
      My understanding is that this is RCU implementation from a stone age. It meets
      the core RCU requirements but it is rather ineffective. Especially, it does not
      allow to batch or speed up the synchronize calls.
      
      On the other hand, it is very trivial. It allows to safely trace and/or
      livepatch even the RCU core infrastructure.  And the effectiveness is a not a
      big issue because using ftrace or livepatches on productive systems is a rare
      operation.  The safety is much more important than a negligible extra load.
      
      Note that the alternative implementation follows the RCU principles. Therefore,
           we could and actually must use list_*_rcu() variants when manipulating the
           func_stack.  These functions allow to access the pointers in the right
           order and with the right barriers. But they do not use any other
           information that would be set only by rcu_read_lock().
      
      Also note that there are actually two problems solved in ftrace:
      
      First, it cares about the consistency of RCU read sections.  It is being solved
      the way as described and used in this patch.
      
      Second, ftrace needs to make sure that nobody is inside the dynamic trampoline
      when it is being freed. For this, it also calls synchronize_rcu_tasks() in
      preemptive kernel in ftrace_shutdown().
      
      Livepatch has similar problem but it is solved by ftrace for free.
      klp_ftrace_handler() is a good guy and never sleeps. In addition, it is
      registered with FTRACE_OPS_FL_DYNAMIC. It causes that
      unregister_ftrace_function() calls:
      
      	* schedule_on_each_cpu(ftrace_sync) - always
      	* synchronize_rcu_tasks() - in preemptive kernel
      
      The effect is that nobody is neither inside the dynamic trampoline nor inside
      the ftrace handler after unregister_ftrace_function() returns.
      
      [jkosina@suse.cz: reformat changelog, fix comment]
      Signed-off-by: NPetr Mladek <pmladek@suse.com>
      Acked-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Acked-by: NMiroslav Benes <mbenes@suse.cz>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      842c0884
    • D
      Revert "HID: magicmouse: Set multi-touch keybits for Magic Mouse" · 53145c2e
      Daniel Stone 提交于
      Setting these bits causes libinput to fail to initialize the device;
      setting BTN_TOUCH and BTN_TOOL_FINGER causes it to treat the mouse as a
      touchpad, and it then refuses to continue when it discovers ABS_X is not
      set.
      
      This breaks all known Wayland compositors, as well as Xorg when the
      libinput driver is being used.
      
      This reverts commit f4b65b95.
      Signed-off-by: NDaniel Stone <daniels@collabora.com>
      Cc: Che-Liang Chiou <clchiou@chromium.org>
      Cc: Thierry Escande <thierry.escande@collabora.com>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
      Acked-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      53145c2e
    • L
      Merge tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux · 9705596d
      Linus Torvalds 提交于
      Pull clk fixes from Stephen Boyd:
       "One build fix for an Amlogic clk driver and a handful of Allwinner clk
        driver fixes for some DT bindings and a randconfig build error that
        all came in this merge window"
      
      * tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux:
        clk: sunxi-ng: a64: Export PLL_PERIPH0 clock for the PRCM
        clk: sunxi-ng: h3: Export PLL_PERIPH0 clock for the PRCM
        dt-bindings: clock: sunxi-ccu: Add pll-periph to PRCM's needed clocks
        clk: sunxi-ng: sun5i: Fix ahb_bist_clk definition
        clk: sunxi-ng: enable SUNXI_CCU_MP for PRCM
        clk: meson: gxbb: fix build error without RESET_CONTROLLER
        clk: sunxi-ng: v3s: Fix usb otg device reset bit
        clk: sunxi-ng: a31: Correct lcd1-ch1 clock register offset
      9705596d
    • L
      Merge tag 'ntb-4.12-bugfixes' of git://github.com/jonmason/ntb · 865be780
      Linus Torvalds 提交于
      Pull NTB fixes from Jon Mason:
       "NTB bug fixes to address the modinfo in ntb_perf, a couple of bugs in
        the NTB transport QP calculations, skx doorbells, and sleeping in
        ntb_async_tx_submit"
      
      * tag 'ntb-4.12-bugfixes' of git://github.com/jonmason/ntb:
        ntb: no sleep in ntb_async_tx_submit
        ntb: ntb_hw_intel: Skylake doorbells should be 32bits, not 64bits
        ntb_transport: fix bug calculating num_qps_mw
        ntb_transport: fix qp count bug
        NTB: ntb_test: fix bug printing ntb_perf results
        ntb: Correct modinfo usage statement for ntb_perf
      865be780
    • X
      sctp: ensure ep is not destroyed before doing the dump · 86fdb344
      Xin Long 提交于
      Now before dumping a sock in sctp_diag, it only holds the sock while
      the ep may be already destroyed. It can cause a use-after-free panic
      when accessing ep->asocs.
      
      This patch is to set sctp_sk(sk)->ep NULL in sctp_endpoint_destroy,
      and check if this ep is already destroyed before dumping this ep.
      Suggested-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Acked-by: NNeil Horman <nhorman@tuxdrver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      86fdb344
    • A
      ntb: no sleep in ntb_async_tx_submit · 88931ec3
      Allen Hubbe 提交于
      Do not sleep in ntb_async_tx_submit, which could deadlock.
      This reverts commit "8c874cc1"
      
      Fixes: 8c874cc1 ("NTB: Address out of DMA descriptor issue with NTB")
      Reported-by: NJia-Ju Bai <baijiaju1990@163.com>
      Signed-off-by: NAllen Hubbe <Allen.Hubbe@dell.com>
      Acked-by: NDave Jiang <dave.jiang@intel.com>
      Signed-off-by: NJon Mason <jdmason@kudzu.us>
      88931ec3
    • D
      ntb: ntb_hw_intel: Skylake doorbells should be 32bits, not 64bits · 5eb449e1
      Dave Jiang 提交于
      Fixing doorbell register length to 32bits per spec. On Skylake NTB, the
      doorbell registers are 32bit write only registers. The source for the
      doorbell is a 64bit register that shows the interrupt bits.
      Signed-off-by: NDave Jiang <dave.jiang@intel.com>
      Fixes: 783dfa6c ("ntb: Adding Skylake Xeon NTB support")
      Acked-by: NAllen Hubbe <Allen.Hubbe@dell.com>
      Signed-off-by: NJon Mason <jdmason@kudzu.us>
      5eb449e1
    • L
      ntb_transport: fix bug calculating num_qps_mw · 8e8496e0
      Logan Gunthorpe 提交于
      A divide by zero error occurs if qp_count is less than mw_count because
      num_qps_mw is calculated to be zero. The calculation appears to be
      incorrect.
      
      The requirement is for num_qps_mw to be set to qp_count / mw_count
      with any remainder divided among the earlier mws.
      
      For example, if mw_count is 5 and qp_count is 12 then mws 0 and 1
      will have 3 qps per window and mws 2 through 4 will have 2 qps per window.
      Thus, when mw_num < qp_count % mw_count, num_qps_mw is 1 higher
      than when mw_num >= qp_count.
      Signed-off-by: NLogan Gunthorpe <logang@deltatee.com>
      Fixes: e26a5843 ("NTB: Split ntb_hw_intel and ntb_transport drivers")
      Acked-by: NAllen Hubbe <Allen.Hubbe@dell.com>
      Signed-off-by: NJon Mason <jdmason@kudzu.us>
      8e8496e0
    • L
      ntb_transport: fix qp count bug · cb827ee6
      Logan Gunthorpe 提交于
      In cases where there are more mw's than spads/2-2, the mw count gets
      reduced to match the limitation. ntb_transport also tries to ensure that
      there are fewer qps than mws but uses the full mw count instead of
      the reduced one. When this happens, the math in
      'ntb_transport_setup_qp_mw' will get confused and result in a kernel
      paging request bug.
      
      This patch fixes the bug by reducing qp_count to the reduced mw count
      instead of the full mw count.
      Signed-off-by: NLogan Gunthorpe <logang@deltatee.com>
      Fixes: e26a5843 ("NTB: Split ntb_hw_intel and ntb_transport drivers")
      Acked-by: NAllen Hubbe <Allen.Hubbe@dell.com>
      Signed-off-by: NJon Mason <jdmason@kudzu.us>
      cb827ee6
    • L
      NTB: ntb_test: fix bug printing ntb_perf results · 07b0b22b
      Logan Gunthorpe 提交于
      The code mistakenly prints the local perf results for the remote test
      so the script reports identical results for both directions. Fix this
      by ensuring we print the remote result.
      Signed-off-by: NLogan Gunthorpe <logang@deltatee.com>
      Fixes: a9c59ef7 ("ntb_test: Add a selftest script for the NTB subsystem")
      Acked-by: NAllen Hubbe <Allen.Hubbe@dell.com>
      Signed-off-by: NJon Mason <jdmason@kudzu.us>
      07b0b22b
    • G
      ntb: Correct modinfo usage statement for ntb_perf · 94fc7954
      Gary R Hook 提交于
      The order parameters are powers of 2; adjust the usage information
      to use correct mathematical representations.
      Signed-off-by: NGary R Hook <gary.hook@amd.com>
      Fixes: 8a7b6a77 ("ntb: ntb perf tool")
      Acked-by: NDave Jiang <dave.jiang@intel.com>
      Signed-off-by: NJon Mason <jdmason@kudzu.us>
      94fc7954
    • L
      net/hns:bugfix of ethtool -t phy self_test · 7fe5b914
      Lin Yun Sheng 提交于
      This patch fixes the phy loopback self_test failed issue. when
      Marvell Phy Module is loaded, it will powerdown fiber when doing
      phy loopback self test, which cause phy loopback self_test fail.
      Signed-off-by: NLin Yun Sheng <linyunsheng@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7fe5b914
    • G
      net: 8021q: Fix one possible panic caused by BUG_ON in free_netdev · 9745e362
      Gao Feng 提交于
      The register_vlan_device would invoke free_netdev directly, when
      register_vlan_dev failed. It would trigger the BUG_ON in free_netdev
      if the dev was already registered. In this case, the netdev would be
      freed in netdev_run_todo later.
      
      So add one condition check now. Only when dev is not registered, then
      free it directly.
      
      The following is the part coredump when netdev_upper_dev_link failed
      in register_vlan_dev. I removed the lines which are too long.
      
      [  411.237457] ------------[ cut here ]------------
      [  411.237458] kernel BUG at net/core/dev.c:7998!
      [  411.237484] invalid opcode: 0000 [#1] SMP
      [  411.237705]  [last unloaded: 8021q]
      [  411.237718] CPU: 1 PID: 12845 Comm: vconfig Tainted: G            E   4.12.0-rc5+ #6
      [  411.237737] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/02/2015
      [  411.237764] task: ffff9cbeb6685580 task.stack: ffffa7d2807d8000
      [  411.237782] RIP: 0010:free_netdev+0x116/0x120
      [  411.237794] RSP: 0018:ffffa7d2807dbdb0 EFLAGS: 00010297
      [  411.237808] RAX: 0000000000000002 RBX: ffff9cbeb6ba8fd8 RCX: 0000000000001878
      [  411.237826] RDX: 0000000000000001 RSI: 0000000000000282 RDI: 0000000000000000
      [  411.237844] RBP: ffffa7d2807dbdc8 R08: 0002986100029841 R09: 0002982100029801
      [  411.237861] R10: 0004000100029980 R11: 0004000100029980 R12: ffff9cbeb6ba9000
      [  411.238761] R13: ffff9cbeb6ba9060 R14: ffff9cbe60f1a000 R15: ffff9cbeb6ba9000
      [  411.239518] FS:  00007fb690d81700(0000) GS:ffff9cbebb640000(0000) knlGS:0000000000000000
      [  411.239949] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  411.240454] CR2: 00007f7115624000 CR3: 0000000077cdf000 CR4: 00000000003406e0
      [  411.240936] Call Trace:
      [  411.241462]  vlan_ioctl_handler+0x3f1/0x400 [8021q]
      [  411.241910]  sock_ioctl+0x18b/0x2c0
      [  411.242394]  do_vfs_ioctl+0xa1/0x5d0
      [  411.242853]  ? sock_alloc_file+0xa6/0x130
      [  411.243465]  SyS_ioctl+0x79/0x90
      [  411.243900]  entry_SYSCALL_64_fastpath+0x1e/0xa9
      [  411.244425] RIP: 0033:0x7fb69089a357
      [  411.244863] RSP: 002b:00007ffcd04e0fc8 EFLAGS: 00000202 ORIG_RAX: 0000000000000010
      [  411.245445] RAX: ffffffffffffffda RBX: 00007ffcd04e2884 RCX: 00007fb69089a357
      [  411.245903] RDX: 00007ffcd04e0fd0 RSI: 0000000000008983 RDI: 0000000000000003
      [  411.246527] RBP: 00007ffcd04e0fd0 R08: 0000000000000000 R09: 1999999999999999
      [  411.246976] R10: 000000000000053f R11: 0000000000000202 R12: 0000000000000004
      [  411.247414] R13: 00007ffcd04e1128 R14: 00007ffcd04e2888 R15: 0000000000000001
      [  411.249129] RIP: free_netdev+0x116/0x120 RSP: ffffa7d2807dbdb0
      Signed-off-by: NGao Feng <gfree.wind@vip.163.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9745e362
  4. 19 6月, 2017 4 次提交
    • R
      cxgb4: notify uP to route ctrlq compl to rdma rspq · dec6b331
      Raju Rangoju 提交于
      During the module initialisation there is a possible race
      (basically race between uld and lld) where neither the uld
      nor lld notifies the uP about where to route the ctrl queue
      completions. LLD skips notifying uP as the rdma queues were
      not created by then (will leave it to ULD to notify the uP).
      As the ULD comes up, it also skips notifying the uP as the
      flag FULL_INIT_DONE is not set yet (ULD assumes that the
      interface is not up yet).
      
      Consequently, this race between uld and lld leaves uP
      unnotified about where to send the ctrl queue completions
      to, leading to iwarp RI_RES WR failure.
      
      Here is the race:
      
      CPU 0                                   CPU1
      
      - allocates nic rx queus
      - t4_sge_alloc_ctrl_txq()
      (if rdma rsp queues exists,
      tell uP to route ctrl queue
      compl to rdma rspq)
                                      - acquires the mutex_lock
                                      - allocates rdma response queues
                                      - if FULL_INIT_DONE set,
                                        tell uP to route ctrl queue compl
                                        to rdma rspq
                                      - relinquishes mutex_lock
      - acquires the mutex_lock
      - enable_rx()
      - set FULL_INIT_DONE
      - relinquishes mutex_lock
      
      This patch fixes the above issue.
      
      Fixes: e7519f99('cxgb4: avoid enabling napi twice to the same queue')
      Signed-off-by: NRaju Rangoju <rajur@chelsio.com>
      Acked-by: NSteve Wise <swise@opengridcomputing.com>
      CC: Stable <stable@vger.kernel.org> # 4.9+
      Signed-off-by: NGanesh Goudar <ganeshgr@chelsio.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      dec6b331
    • L
      Linux 4.12-rc6 · 41f1830f
      Linus Torvalds 提交于
      41f1830f
    • H
      mm: larger stack guard gap, between vmas · 1be7107f
      Hugh Dickins 提交于
      Stack guard page is a useful feature to reduce a risk of stack smashing
      into a different mapping. We have been using a single page gap which
      is sufficient to prevent having stack adjacent to a different mapping.
      But this seems to be insufficient in the light of the stack usage in
      userspace. E.g. glibc uses as large as 64kB alloca() in many commonly
      used functions. Others use constructs liks gid_t buffer[NGROUPS_MAX]
      which is 256kB or stack strings with MAX_ARG_STRLEN.
      
      This will become especially dangerous for suid binaries and the default
      no limit for the stack size limit because those applications can be
      tricked to consume a large portion of the stack and a single glibc call
      could jump over the guard page. These attacks are not theoretical,
      unfortunatelly.
      
      Make those attacks less probable by increasing the stack guard gap
      to 1MB (on systems with 4k pages; but make it depend on the page size
      because systems with larger base pages might cap stack allocations in
      the PAGE_SIZE units) which should cover larger alloca() and VLA stack
      allocations. It is obviously not a full fix because the problem is
      somehow inherent, but it should reduce attack space a lot.
      
      One could argue that the gap size should be configurable from userspace,
      but that can be done later when somebody finds that the new 1MB is wrong
      for some special case applications.  For now, add a kernel command line
      option (stack_guard_gap) to specify the stack gap size (in page units).
      
      Implementation wise, first delete all the old code for stack guard page:
      because although we could get away with accounting one extra page in a
      stack vma, accounting a larger gap can break userspace - case in point,
      a program run with "ulimit -S -v 20000" failed when the 1MB gap was
      counted for RLIMIT_AS; similar problems could come with RLIMIT_MLOCK
      and strict non-overcommit mode.
      
      Instead of keeping gap inside the stack vma, maintain the stack guard
      gap as a gap between vmas: using vm_start_gap() in place of vm_start
      (or vm_end_gap() in place of vm_end if VM_GROWSUP) in just those few
      places which need to respect the gap - mainly arch_get_unmapped_area(),
      and and the vma tree's subtree_gap support for that.
      Original-patch-by: NOleg Nesterov <oleg@redhat.com>
      Original-patch-by: NMichal Hocko <mhocko@suse.com>
      Signed-off-by: NHugh Dickins <hughd@google.com>
      Acked-by: NMichal Hocko <mhocko@suse.com>
      Tested-by: Helge Deller <deller@gmx.de> # parisc
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1be7107f
    • L
      Merge tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc · 1132d5e7
      Linus Torvalds 提交于
      Pull ARM SoC fixes from Olof Johansson:
       "Stream of fixes has slowed down, only a few this week:
      
         - Some DT fixes for Allwinner platforms, and addition of a clock to
           the R_CCU clock controller that had been missed.
      
         - A couple of small DT fixes for am335x-sl50"
      
      * tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
        arm64: allwinner: a64: Add PLL_PERIPH0 clock to the R_CCU
        ARM: sunxi: h3-h5: Add PLL_PERIPH0 clock to the R_CCU
        ARM: dts: am335x-sl50: Fix cannot claim requested pins for spi0
        ARM: dts: am335x-sl50: Fix card detect pin for mmc1
        arm64: allwinner: h5: Remove syslink to shared DTSI
        ARM: sunxi: h3/h5: fix the compatible of R_CCU
      1132d5e7