1. 13 3月, 2018 1 次提交
    • T
      timekeeping: Add the new CLOCK_MONOTONIC_ACTIVE clock · 72199320
      Thomas Gleixner 提交于
      The planned change to unify the behaviour of the MONOTONIC and BOOTTIME
      clocks vs. suspend removes the ability to retrieve the active
      non-suspended time of a system.
      
      Provide a new CLOCK_MONOTONIC_ACTIVE clock which returns the active
      non-suspended time of the system via clock_gettime().
      
      This preserves the old behaviour of CLOCK_MONOTONIC before the
      BOOTTIME/MONOTONIC unification.
      
      This new clock also allows applications to detect programmatically that
      the MONOTONIC and BOOTTIME clocks are identical.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Kevin Easton <kevin@guarana.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mark Salyzyn <salyzyn@android.com>
      Cc: Michael Kerrisk <mtk.manpages@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Petr Mladek <pmladek@suse.com>
      Cc: Prarit Bhargava <prarit@redhat.com>
      Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Link: http://lkml.kernel.org/r/20180301165149.965235774@linutronix.deSigned-off-by: NIngo Molnar <mingo@kernel.org>
      72199320
  2. 22 2月, 2018 1 次提交
  3. 14 2月, 2018 1 次提交
    • H
      uapi/if_ether.h: move __UAPI_DEF_ETHHDR libc define · da360299
      Hauke Mehrtens 提交于
      This fixes a compile problem of some user space applications by not
      including linux/libc-compat.h in uapi/if_ether.h.
      
      linux/libc-compat.h checks which "features" the header files, included
      from the libc, provide to make the Linux kernel uapi header files only
      provide no conflicting structures and enums. If a user application mixes
      kernel headers and libc headers it could happen that linux/libc-compat.h
      gets included too early where not all other libc headers are included
      yet. Then the linux/libc-compat.h would not prevent all the
      redefinitions and we run into compile problems.
      This patch removes the include of linux/libc-compat.h from
      uapi/if_ether.h to fix the recently introduced case, but not all as this
      is more or less impossible.
      
      It is no problem to do the check directly in the if_ether.h file and not
      in libc-compat.h as this does not need any fancy glibc header detection
      as glibc never provided struct ethhdr and should define
      __UAPI_DEF_ETHHDR by them self when they will provide this.
      
      The following test program did not compile correctly any more:
      
      #include <linux/if_ether.h>
      #include <netinet/in.h>
      #include <linux/in.h>
      
      int main(void)
      {
      	return 0;
      }
      
      Fixes: 6926e041 ("uapi/if_ether.h: prevent redefinition of struct ethhdr")
      Reported-by: NGuillaume Nault <g.nault@alphalink.fr>
      Cc: <stable@vger.kernel.org> # 4.15
      Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      da360299
  4. 07 2月, 2018 2 次提交
  5. 06 2月, 2018 2 次提交
    • M
      membarrier: Provide core serializing command, *_SYNC_CORE · 70216e18
      Mathieu Desnoyers 提交于
      Provide core serializing membarrier command to support memory reclaim
      by JIT.
      
      Each architecture needs to explicitly opt into that support by
      documenting in their architecture code how they provide the core
      serializing instructions required when returning from the membarrier
      IPI, and after the scheduler has updated the curr->mm pointer (before
      going back to user-space). They should then select
      ARCH_HAS_MEMBARRIER_SYNC_CORE to enable support for that command on
      their architecture.
      
      Architectures selecting this feature need to either document that
      they issue core serializing instructions when returning to user-space,
      or implement their architecture-specific sync_core_before_usermode().
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Andrea Parri <parri.andrea@gmail.com>
      Cc: Andrew Hunter <ahh@google.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Avi Kivity <avi@scylladb.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Boqun Feng <boqun.feng@gmail.com>
      Cc: Dave Watson <davejwatson@fb.com>
      Cc: David Sehr <sehr@google.com>
      Cc: Greg Hackmann <ghackmann@google.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Maged Michael <maged.michael@gmail.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: linux-api@vger.kernel.org
      Cc: linux-arch@vger.kernel.org
      Link: http://lkml.kernel.org/r/20180129202020.8515-9-mathieu.desnoyers@efficios.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      70216e18
    • M
      membarrier: Provide GLOBAL_EXPEDITED command · c5f58bd5
      Mathieu Desnoyers 提交于
      Allow expedited membarrier to be used for data shared between processes
      through shared memory.
      
      Processes wishing to receive the membarriers register with
      MEMBARRIER_CMD_REGISTER_GLOBAL_EXPEDITED. Those which want to issue
      membarrier invoke MEMBARRIER_CMD_GLOBAL_EXPEDITED.
      
      This allows extremely simple kernel-level implementation: we have almost
      everything we need with the PRIVATE_EXPEDITED barrier code. All we need
      to do is to add a flag in the mm_struct that will be used to check
      whether we need to send the IPI to the current thread of each CPU.
      
      There is a slight downside to this approach compared to targeting
      specific shared memory users: when performing a membarrier operation,
      all registered "global" receivers will get the barrier, even if they
      don't share a memory mapping with the sender issuing
      MEMBARRIER_CMD_GLOBAL_EXPEDITED.
      
      This registration approach seems to fit the requirement of not
      disturbing processes that really deeply care about real-time: they
      simply should not register with MEMBARRIER_CMD_REGISTER_GLOBAL_EXPEDITED.
      
      In order to align the membarrier command names, the "MEMBARRIER_CMD_SHARED"
      command is renamed to "MEMBARRIER_CMD_GLOBAL", keeping an alias of
      MEMBARRIER_CMD_SHARED to MEMBARRIER_CMD_GLOBAL for UAPI header backward
      compatibility.
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Andrea Parri <parri.andrea@gmail.com>
      Cc: Andrew Hunter <ahh@google.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Avi Kivity <avi@scylladb.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Boqun Feng <boqun.feng@gmail.com>
      Cc: Dave Watson <davejwatson@fb.com>
      Cc: David Sehr <sehr@google.com>
      Cc: Greg Hackmann <ghackmann@google.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Maged Michael <maged.michael@gmail.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: linux-api@vger.kernel.org
      Link: http://lkml.kernel.org/r/20180129202020.8515-5-mathieu.desnoyers@efficios.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      c5f58bd5
  6. 02 2月, 2018 2 次提交
  7. 31 1月, 2018 3 次提交
  8. 30 1月, 2018 1 次提交
  9. 26 1月, 2018 9 次提交
  10. 24 1月, 2018 1 次提交
    • J
      PCI: Add pci_enable_atomic_ops_to_root() · 430a2368
      Jay Cornwall 提交于
      The Atomic Operations feature (PCIe r4.0, sec 6.15) allows atomic
      transctions to be requested by, routed through and completed by PCIe
      components. Routing and completion do not require software support.
      Component support for each is detectable via the DEVCAP2 register.
      
      A Requester may use AtomicOps only if its PCI_EXP_DEVCTL2_ATOMIC_REQ is
      set. This should be set only if the Completer and all intermediate routing
      elements support AtomicOps.
      
      A concrete example is the AMD Fiji-class GPU (which is capable of making
      AtomicOp requests), below a PLX 8747 switch (advertising AtomicOp routing)
      with a Haswell host bridge (advertising AtomicOp completion support).
      
      Add pci_enable_atomic_ops_to_root() for per-device control over AtomicOp
      requests. This checks to be sure the Root Port supports completion of the
      desired AtomicOp sizes and the path to the Root Port supports routing the
      AtomicOps.
      Signed-off-by: NJay Cornwall <Jay.Cornwall@amd.com>
      Signed-off-by: NFelix Kuehling <Felix.Kuehling@amd.com>
      [bhelgaas: changelog, comments, whitespace]
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      430a2368
  11. 23 1月, 2018 4 次提交
  12. 22 1月, 2018 3 次提交
  13. 21 1月, 2018 1 次提交
  14. 20 1月, 2018 2 次提交
  15. 19 1月, 2018 4 次提交
  16. 18 1月, 2018 3 次提交