1. 02 3月, 2018 5 次提交
    • H
      parisc: Reduce irq overhead when run in qemu · 636a415b
      Helge Deller 提交于
      When run under QEMU, calling mfctl(16) creates some overhead because the
      qemu timer has to be scaled and moved into the register. This patch
      reduces the number of calls to mfctl(16) by moving the calls out of the
      loops.
      
      Additionally, increase the minimal time interval to 8000 cycles instead
      of 500 to compensate possible QEMU delays when delivering interrupts.
      Signed-off-by: NHelge Deller <deller@gmx.de>
      Cc: stable@vger.kernel.org # 4.14+
      636a415b
    • H
      parisc: Use cr16 interval timers unconditionally on qemu · 5ffa8518
      Helge Deller 提交于
      When running on qemu we know that the (emulated) cr16 cpu-internal
      clocks are syncronized. So let's use them unconditionally on qemu.
      Signed-off-by: NHelge Deller <deller@gmx.de>
      Cc: stable@vger.kernel.org # 4.14+
      5ffa8518
    • H
      parisc: Check if secondary CPUs want own PDC calls · 0ed1fe4a
      Helge Deller 提交于
      The architecture specification says (for 64-bit systems): PDC is a per
      processor resource, and operating system software must be prepared to
      manage separate pointers to PDCE_PROC for each processor.  The address
      of PDCE_PROC for the monarch processor is stored in the Page Zero
      location MEM_PDC. The address of PDCE_PROC for each non-monarch
      processor is passed in gr26 when PDCE_RESET invokes OS_RENDEZ.
      
      Currently we still use one PDC for all CPUs, but in case we face a
      machine which is following the specification let's warn about it.
      Signed-off-by: NHelge Deller <deller@gmx.de>
      0ed1fe4a
    • H
      parisc: Hide virtual kernel memory layout · fd8d0ca2
      Helge Deller 提交于
      For security reasons do not expose the virtual kernel memory layout to
      userspace.
      Signed-off-by: NHelge Deller <deller@gmx.de>
      Suggested-by: NKees Cook <keescook@chromium.org>
      Cc: stable@vger.kernel.org # 4.15
      Reviewed-by: NKees Cook <keescook@chromium.org>
      fd8d0ca2
    • J
      parisc: Fix ordering of cache and TLB flushes · 0adb24e0
      John David Anglin 提交于
      The change to flush_kernel_vmap_range() wasn't sufficient to avoid the
      SMP stalls.  The problem is some drivers call these routines with
      interrupts disabled.  Interrupts need to be enabled for flush_tlb_all()
      and flush_cache_all() to work.  This version adds checks to ensure
      interrupts are not disabled before calling routines that need IPI
      interrupts.  When interrupts are disabled, we now drop into slower code.
      
      The attached change fixes the ordering of cache and TLB flushes in
      several cases.  When we flush the cache using the existing PTE/TLB
      entries, we need to flush the TLB after doing the cache flush.  We don't
      need to do this when we flush the entire instruction and data caches as
      these flushes don't use the existing TLB entries.  The same is true for
      tmpalias region flushes.
      
      The flush_kernel_vmap_range() and invalidate_kernel_vmap_range()
      routines have been updated.
      
      Secondly, we added a new purge_kernel_dcache_range_asm() routine to
      pacache.S and use it in invalidate_kernel_vmap_range().  Nominally,
      purges are faster than flushes as the cache lines don't have to be
      written back to memory.
      
      Hopefully, this is sufficient to resolve the remaining problems due to
      cache speculation.  So far, testing indicates that this is the case.  I
      did work up a patch using tmpalias flushes, but there is a performance
      hit because we need the physical address for each page, and we also need
      to sequence access to the tmpalias flush code.  This increases the
      probability of stalls.
      
      Signed-off-by: John David Anglin <dave.anglin@bell.net>
      Cc: stable@vger.kernel.org # 4.9+
      Signed-off-by: NHelge Deller <deller@gmx.de>
      0adb24e0
  2. 24 1月, 2018 1 次提交
  3. 16 1月, 2018 3 次提交
    • E
      signal: Unify and correct copy_siginfo_to_user32 · ea64d5ac
      Eric W. Biederman 提交于
      Among the existing architecture specific versions of
      copy_siginfo_to_user32 there are several different implementation
      problems.  Some architectures fail to handle all of the cases in in
      the siginfo union.  Some architectures perform a blind copy of the
      siginfo union when the si_code is negative.  A blind copy suggests the
      data is expected to be in 32bit siginfo format, which means that
      receiving such a signal via signalfd won't work, or that the data is
      in 64bit siginfo and the code is copying nonsense to userspace.
      
      Create a single instance of copy_siginfo_to_user32 that all of the
      architectures can share, and teach it to handle all of the cases in
      the siginfo union correctly, with the assumption that siginfo is
      stored internally to the kernel is 64bit siginfo format.
      
      A special case is made for x86 x32 format.  This is needed as presence
      of both x32 and ia32 on x86_64 results in two different 32bit signal
      formats.  By allowing this small special case there winds up being
      exactly one code base that needs to be maintained between all of the
      architectures.  Vastly increasing the testing base and the chances of
      finding bugs.
      
      As the x86 copy of copy_siginfo_to_user32 the call of the x86
      signal_compat_build_tests were moved into sigaction_compat_abi, so
      that they will keep running.
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      ea64d5ac
    • E
      signal: Unify and correct copy_siginfo_from_user32 · 212a36a1
      Eric W. Biederman 提交于
      The function copy_siginfo_from_user32 is used for two things, in ptrace
      since the dawn of siginfo for arbirarily modifying a signal that
      user space sees, and in sigqueueinfo to send a signal with arbirary
      siginfo data.
      
      Create a single copy of copy_siginfo_from_user32 that all architectures
      share, and teach it to handle all of the cases in the siginfo union.
      
      In the generic version of copy_siginfo_from_user32 ensure that all
      of the fields in siginfo are initialized so that the siginfo structure
      can be safely copied to userspace if necessary.
      
      When copying the embedded sigval union copy the si_int member.  That
      ensures the 32bit values passes through the kernel unchanged.
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      212a36a1
    • A
      signal: unify compat_siginfo_t · b713da69
      Al Viro 提交于
      --EWB Added #ifdef CONFIG_X86_X32_ABI to arch/x86/kernel/signal_compat.c
            Changed #ifdef CONFIG_X86_X32 to #ifdef CONFIG_X86_X32_ABI in
            linux/compat.h
      
            CONFIG_X86_X32 is set when the user requests X32 support.
      
            CONFIG_X86_X32_ABI is set when the user requests X32 support
            and the tool-chain has X32 allowing X32 support to be built.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      b713da69
  4. 13 1月, 2018 2 次提交
    • E
      signal: Remove _sys_private and _overrun_incr from struct compat_siginfo · 2f82a46f
      Eric W. Biederman 提交于
      We have never passed either field to or from userspace so just remove them.
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      2f82a46f
    • E
      signal/parisc: Document a conflict with SI_USER with SIGFPE · b5daf2b9
      Eric W. Biederman 提交于
      Setting si_code to 0 results in a userspace seeing an si_code of 0.
      This is the same si_code as SI_USER.  Posix and common sense requires
      that SI_USER not be a signal specific si_code.  As such this use of 0
      for the si_code is a pretty horribly broken ABI.
      
      Further use of si_code == 0 guaranteed that copy_siginfo_to_user saw a
      value of __SI_KILL and now sees a value of SIL_KILL with the result
      that uid and pid fields are copied and which might copying the si_addr
      field by accident but certainly not by design.  Making this a very
      flakey implementation.
      
      Utilizing FPE_FIXME siginfo_layout will now return SIL_FAULT and the
      appropriate fields will reliably be copied.
      
      This bug is 13 years old and parsic machines are no longer being built
      so I don't know if it possible or worth fixing it.  But it is at least
      worth documenting this so other architectures don't make the same
      mistake.
      
      Possible ABI fixes includee:
        - Send the signal without siginfo
        - Don't generate a signal
        - Possibly assign and use an appropriate si_code
        - Don't handle cases which can't happen
      
      Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
      Cc: Helge Deller <deller@gmx.de>
      Cc: linux-parisc@vger.kernel.org
      Ref: 313c01d3e3fd ("[PATCH] PA-RISC update for 2.6.0")
      Histroy Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.gitSigned-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      b5daf2b9
  5. 10 1月, 2018 2 次提交
  6. 09 1月, 2018 1 次提交
    • S
      parisc64: Add .opd based function descriptor dereference · 1705bd6a
      Sergey Senozhatsky 提交于
      We are moving towards separate kernel and module function descriptor
      dereference callbacks. This patch enables it for parisc64.
      
      For pointers that belong to the kernel
      -  Added __start_opd and __end_opd pointers, to track the kernel
         .opd section address range;
      
      -  Added dereference_kernel_function_descriptor(). Now we
         will dereference only function pointers that are within
         [__start_opd, __end_opd);
      
      For pointers that belong to a module
      -  Added dereference_module_function_descriptor() to handle module
         function descriptor dereference. Now we will dereference only
         pointers that are within [module->opd.start, module->opd.end).
      
      Link: http://lkml.kernel.org/r/20171109234830.5067-5-sergey.senozhatsky@gmail.com
      To: Tony Luck <tony.luck@intel.com>
      To: Fenghua Yu <fenghua.yu@intel.com>
      To: Helge Deller <deller@gmx.de>
      To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      To: Paul Mackerras <paulus@samba.org>
      To: Michael Ellerman <mpe@ellerman.id.au>
      To: James Bottomley <jejb@parisc-linux.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Jessica Yu <jeyu@kernel.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: linux-ia64@vger.kernel.org
      Cc: linux-parisc@vger.kernel.org
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Tested-by: Helge Deller <deller@gmx.de> #parisc64
      Signed-off-by: NPetr Mladek <pmladek@suse.com>
      1705bd6a
  7. 06 1月, 2018 1 次提交
    • H
      parisc: qemu idle sleep support · 310d8278
      Helge Deller 提交于
      Add qemu idle sleep support when running under qemu with SeaBIOS PDC
      firmware.
      
      Like the power architecture we use the "or" assembler instructions,
      which translate to nops on real hardware, to indicate that qemu shall
      idle sleep.
      Signed-off-by: NHelge Deller <deller@gmx.de>
      Cc: Richard Henderson <rth@twiddle.net>
      CC: stable@vger.kernel.org # v4.9+
      310d8278
  8. 04 1月, 2018 1 次提交
  9. 03 1月, 2018 3 次提交
  10. 18 12月, 2017 5 次提交
    • J
      parisc: Reduce thread stack to 16 kb · da57c541
      John David Anglin 提交于
      In testing, I found that the thread stack can be 16 kB when using an irq
      stack.  Without it, the thread stack needs to be 32 kB. Currently, the irq
      stack is 32 kB. While it probably could be 16 kB, I would prefer to leave it
      as is for safety.
      Signed-off-by: NJohn David Anglin <dave.anglin@bell.net>
      Signed-off-by: NHelge Deller <deller@gmx.de>
      da57c541
    • J
      Revert "parisc: Re-enable interrupts early" · 9352aead
      John David Anglin 提交于
      This reverts commit 5c38602d.
      
      Interrupts can't be enabled early because the register saves are done on
      the thread stack prior to switching to the IRQ stack.  This caused stack
      overflows and the thread stack needed increasing to 32k.  Even then,
      stack overflows still occasionally occurred.
      
      Background:
      Even with a 32 kB thread stack, I have seen instances where the thread
      stack overflowed on the mx3210 buildd.  Detection of stack overflow only
      occurs when we have an external interrupt.  When an external interrupt
      occurs, we switch to the thread stack if we are not already on a kernel
      stack.  Then, registers and specials are saved to the kernel stack.
      
      The bug occurs in intr_return where interrupts are reenabled prior to
      returning from the interrupt.  This was done incase we need to schedule
      or deliver signals.  However, it introduces the possibility that
      multiple external interrupts may occur on the thread stack and cause a
      stack overflow.  These might not be detected and cause the kernel to
      misbehave in random ways.
      
      This patch changes the code back to only reenable interrupts when we are
      going to schedule or deliver signals.  As a result, we generally return
      from an interrupt before reenabling interrupts.  This minimizes the
      growth of the thread stack.
      
      Fixes: 5c38602d ("parisc: Re-enable interrupts early")
      Signed-off-by: NJohn David Anglin <dave.anglin@bell.net>
      Cc: <stable@vger.kernel.org> # v4.10+
      Signed-off-by: NHelge Deller <deller@gmx.de>
      9352aead
    • P
      parisc: remove duplicate includes · 6a16fc32
      Pravin Shedge 提交于
      These duplicate includes have been found with scripts/checkincludes.pl
      but they have been removed manually to avoid removing false positives.
      Signed-off-by: NPravin Shedge <pravin.shedge4linux@gmail.com>
      Signed-off-by: NHelge Deller <deller@gmx.de>
      6a16fc32
    • H
      parisc: Align os_hpmc_size on word boundary · 0ed9d3de
      Helge Deller 提交于
      The os_hpmc_size variable sometimes wasn't aligned at word boundary and thus
      triggered the unaligned fault handler at startup.
      Fix it by aligning it properly.
      Signed-off-by: NHelge Deller <deller@gmx.de>
      Cc: <stable@vger.kernel.org> # v4.14+
      0ed9d3de
    • H
      parisc: Fix indenting in puts() · 203c110b
      Helge Deller 提交于
      Static analysis tools complain that we intended to have curly braces
      around this indent block. In this case this assumption is wrong, so fix
      the indenting.
      
      Fixes: 2f3c7b81 ("parisc: Add core code for self-extracting kernel")
      Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NHelge Deller <deller@gmx.de>
      Cc: <stable@vger.kernel.org> # v4.14+
      203c110b
  11. 05 12月, 2017 1 次提交
    • H
      bpf: correct broken uapi for BPF_PROG_TYPE_PERF_EVENT program type · c895f6f7
      Hendrik Brueckner 提交于
      Commit 0515e599 ("bpf: introduce BPF_PROG_TYPE_PERF_EVENT
      program type") introduced the bpf_perf_event_data structure which
      exports the pt_regs structure.  This is OK for multiple architectures
      but fail for s390 and arm64 which do not export pt_regs.  Programs
      using them, for example, the bpf selftest fail to compile on these
      architectures.
      
      For s390, exporting the pt_regs is not an option because s390 wants
      to allow changes to it.  For arm64, there is a user_pt_regs structure
      that covers parts of the pt_regs structure for use by user space.
      
      To solve the broken uapi for s390 and arm64, introduce an abstract
      type for pt_regs and add an asm/bpf_perf_event.h file that concretes
      the type.  An asm-generic header file covers the architectures that
      export pt_regs today.
      
      The arch-specific enablement for s390 and arm64 follows in separate
      commits.
      Reported-by: NThomas Richter <tmricht@linux.vnet.ibm.com>
      Fixes: 0515e599 ("bpf: introduce BPF_PROG_TYPE_PERF_EVENT program type")
      Signed-off-by: NHendrik Brueckner <brueckner@linux.vnet.ibm.com>
      Reviewed-and-tested-by: NThomas Richter <tmricht@linux.vnet.ibm.com>
      Acked-by: NAlexei Starovoitov <ast@kernel.org>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      c895f6f7
  12. 22 11月, 2017 1 次提交
    • K
      treewide: Switch DEFINE_TIMER callbacks to struct timer_list * · 24ed960a
      Kees Cook 提交于
      This changes all DEFINE_TIMER() callbacks to use a struct timer_list
      pointer instead of unsigned long. Since the data argument has already been
      removed, none of these callbacks are using their argument currently, so
      this renames the argument to "unused".
      
      Done using the following semantic patch:
      
      @match_define_timer@
      declarer name DEFINE_TIMER;
      identifier _timer, _callback;
      @@
      
       DEFINE_TIMER(_timer, _callback);
      
      @change_callback depends on match_define_timer@
      identifier match_define_timer._callback;
      type _origtype;
      identifier _origarg;
      @@
      
       void
      -_callback(_origtype _origarg)
      +_callback(struct timer_list *unused)
       { ... }
      Signed-off-by: NKees Cook <keescook@chromium.org>
      24ed960a
  13. 17 11月, 2017 5 次提交
    • B
      arch: Fix duplicates in Kconfig for parisc and sparc · 7b8b098c
      Babu Moger 提交于
      Fix duplicates for sparc and parisc. This was due these following commits.
      
      1. commit 4c97a0c8 ("arch: define CPU_BIG_ENDIAN for all fixed big
         endian archs")
      2. commit 97d9f969 ("arch/sparc: Define config parameter
         CPU_BIG_ENDIAN")
      3. commit 74ad3d28 ("parisc: Define CONFIG_CPU_BIG_ENDIAN")
      
      Remove duplicates.
      Signed-off-by: NBabu Moger <babu.moger@oracle.com>
      Signed-off-by: NHelge Deller <deller@gmx.de>
      7b8b098c
    • H
      parisc: Make some PDC structures accessible in uapi headers · bc5a768e
      Helge Deller 提交于
      While working on a qemu and SeaBIOS-port to parisc, those PDC structures are
      useful to have accessible from userspace.
      Signed-off-by: NHelge Deller <deller@gmx.de>
      bc5a768e
    • L
      parisc: Pass endianness info to sparse · 3744d988
      Luc Van Oostenryck 提交于
      parisc is big-endian only but sparse assumes the same endianness as the
      building machine.
      This is problematic for code which expect __BYTE_ORDER__ being correctly
      predefined by the compiler which sparse can then pre-process differently
      from what gcc would.
      
      Fix this by letting sparse know about the architecture endianness.
      
      To: James Bottomley <jejb@parisc-linux.org>
      To: Helge Deller <deller@gmx.de>
      CC: linux-parisc@vger.kernel.org
      Signed-off-by: NLuc Van Oostenryck <luc.vanoostenryck@gmail.com>
      Signed-off-by: NHelge Deller <deller@gmx.de>
      3744d988
    • H
      parisc: Add CPU topology support · bf7b4c1b
      Helge Deller 提交于
      Add topology support, including multi-core scheduler support on
      PA8800/PA8900 CPUs and enhanced output in /proc/cpuinfo, e.g.
      lscpu now reports on a single-socket, dual-core machine:
      
      Architecture:          parisc64
      CPU(s):                2
      On-line CPU(s) list:   0,1
      Thread(s) per core:    1
      Core(s) per socket:    2
      Socket(s):             1
      CPU family:            PA-RISC 2.0
      Model name:            PA8800 (Mako)
      Signed-off-by: NHelge Deller <deller@gmx.de>
      bf7b4c1b
    • J
      parisc: Fix validity check of pointer size argument in new CAS implementation · 05f016d2
      John David Anglin 提交于
      As noted by Christoph Biedl, passing a pointer size of 4 in the new CAS
      implementation causes a kernel crash.  The attached patch corrects the
      off by one error in the argument validity check.
      
      In reviewing the code, I noticed that we only perform word operations
      with the pointer size argument.  The subi instruction intentionally uses
      a word condition on 64-bit kernels.  Nullification was used instead of a
      cmpib instruction as the branch should never be taken.  The shlw
      pseudo-operation generates a depw,z instruction and it clears the target
      before doing a shift left word deposit.  Thus, we don't need to clip the
      upper 32 bits of this argument on 64-bit kernels.
      
      Tested with a gcc testsuite run with a 64-bit kernel.  The gcc atomic
      code in libgcc is the only direct user of the new CAS implementation
      that I am aware of.
      Signed-off-by: NJohn David Anglin <dave.anglin@bell.net>
      Cc: stable@vger.kernel.org # 3.13+
      Signed-off-by: NHelge Deller <deller@gmx.de>
      05f016d2
  14. 15 11月, 2017 1 次提交
  15. 08 11月, 2017 2 次提交
  16. 03 11月, 2017 1 次提交
    • D
      mm: introduce MAP_SHARED_VALIDATE, a mechanism to safely define new mmap flags · 1c972597
      Dan Williams 提交于
      The mmap(2) syscall suffers from the ABI anti-pattern of not validating
      unknown flags. However, proposals like MAP_SYNC need a mechanism to
      define new behavior that is known to fail on older kernels without the
      support. Define a new MAP_SHARED_VALIDATE flag pattern that is
      guaranteed to fail on all legacy mmap implementations.
      
      It is worth noting that the original proposal was for a standalone
      MAP_VALIDATE flag. However, when that  could not be supported by all
      archs Linus observed:
      
          I see why you *think* you want a bitmap. You think you want
          a bitmap because you want to make MAP_VALIDATE be part of MAP_SYNC
          etc, so that people can do
      
          ret = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED
      		    | MAP_SYNC, fd, 0);
      
          and "know" that MAP_SYNC actually takes.
      
          And I'm saying that whole wish is bogus. You're fundamentally
          depending on special semantics, just make it explicit. It's already
          not portable, so don't try to make it so.
      
          Rename that MAP_VALIDATE as MAP_SHARED_VALIDATE, make it have a value
          of 0x3, and make people do
      
          ret = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED_VALIDATE
      		    | MAP_SYNC, fd, 0);
      
          and then the kernel side is easier too (none of that random garbage
          playing games with looking at the "MAP_VALIDATE bit", but just another
          case statement in that map type thing.
      
          Boom. Done.
      
      Similar to ->fallocate() we also want the ability to validate the
      support for new flags on a per ->mmap() 'struct file_operations'
      instance basis.  Towards that end arrange for flags to be generically
      validated against a mmap_supported_flags exported by 'struct
      file_operations'. By default all existing flags are implicitly
      supported, but new flags require MAP_SHARED_VALIDATE and
      per-instance-opt-in.
      
      Cc: Jan Kara <jack@suse.cz>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Suggested-by: NChristoph Hellwig <hch@lst.de>
      Suggested-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Reviewed-by: NRoss Zwisler <ross.zwisler@linux.intel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      Signed-off-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      1c972597
  17. 02 11月, 2017 3 次提交
    • G
      License cleanup: add SPDX license identifier to uapi header files with a license · e2be04c7
      Greg Kroah-Hartman 提交于
      Many user space API headers have licensing information, which is either
      incomplete, badly formatted or just a shorthand for referring to the
      license under which the file is supposed to be.  This makes it hard for
      compliance tools to determine the correct license.
      
      Update these files with an SPDX license identifier.  The identifier was
      chosen based on the license information in the file.
      
      GPL/LGPL licensed headers get the matching GPL/LGPL SPDX license
      identifier with the added 'WITH Linux-syscall-note' exception, which is
      the officially assigned exception identifier for the kernel syscall
      exception:
      
         NOTE! This copyright does *not* cover user programs that use kernel
         services by normal system calls - this is merely considered normal use
         of the kernel, and does *not* fall under the heading of "derived work".
      
      This exception makes it possible to include GPL headers into non GPL
      code, without confusing license compliance tools.
      
      Headers which have either explicit dual licensing or are just licensed
      under a non GPL license are updated with the corresponding SPDX
      identifier and the GPLv2 with syscall exception identifier.  The format
      is:
              ((GPL-2.0 WITH Linux-syscall-note) OR SPDX-ID-OF-OTHER-LICENSE)
      
      SPDX license identifiers are a legally binding shorthand, which can be
      used instead of the full boiler plate text.  The update does not remove
      existing license information as this has to be done on a case by case
      basis and the copyright holders might have to be consulted. This will
      happen in a separate step.
      
      This patch is based on work done by Thomas Gleixner and Kate Stewart and
      Philippe Ombredanne.  See the previous patch in this series for the
      methodology of how this patch was researched.
      Reviewed-by: NKate Stewart <kstewart@linuxfoundation.org>
      Reviewed-by: NPhilippe Ombredanne <pombredanne@nexb.com>
      Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e2be04c7
    • G
      License cleanup: add SPDX license identifier to uapi header files with no license · 6f52b16c
      Greg Kroah-Hartman 提交于
      Many user space API headers are missing licensing information, which
      makes it hard for compliance tools to determine the correct license.
      
      By default are files without license information under the default
      license of the kernel, which is GPLV2.  Marking them GPLV2 would exclude
      them from being included in non GPLV2 code, which is obviously not
      intended. The user space API headers fall under the syscall exception
      which is in the kernels COPYING file:
      
         NOTE! This copyright does *not* cover user programs that use kernel
         services by normal system calls - this is merely considered normal use
         of the kernel, and does *not* fall under the heading of "derived work".
      
      otherwise syscall usage would not be possible.
      
      Update the files which contain no license information with an SPDX
      license identifier.  The chosen identifier is 'GPL-2.0 WITH
      Linux-syscall-note' which is the officially assigned identifier for the
      Linux syscall exception.  SPDX license identifiers are a legally binding
      shorthand, which can be used instead of the full boiler plate text.
      
      This patch is based on work done by Thomas Gleixner and Kate Stewart and
      Philippe Ombredanne.  See the previous patch in this series for the
      methodology of how this patch was researched.
      Reviewed-by: NKate Stewart <kstewart@linuxfoundation.org>
      Reviewed-by: NPhilippe Ombredanne <pombredanne@nexb.com>
      Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6f52b16c
    • G
      License cleanup: add SPDX GPL-2.0 license identifier to files with no license · b2441318
      Greg Kroah-Hartman 提交于
      Many source files in the tree are missing licensing information, which
      makes it harder for compliance tools to determine the correct license.
      
      By default all files without license information are under the default
      license of the kernel, which is GPL version 2.
      
      Update the files which contain no license information with the 'GPL-2.0'
      SPDX license identifier.  The SPDX identifier is a legally binding
      shorthand, which can be used instead of the full boiler plate text.
      
      This patch is based on work done by Thomas Gleixner and Kate Stewart and
      Philippe Ombredanne.
      
      How this work was done:
      
      Patches were generated and checked against linux-4.14-rc6 for a subset of
      the use cases:
       - file had no licensing information it it.
       - file was a */uapi/* one with no licensing information in it,
       - file was a */uapi/* one with existing licensing information,
      
      Further patches will be generated in subsequent months to fix up cases
      where non-standard license headers were used, and references to license
      had to be inferred by heuristics based on keywords.
      
      The analysis to determine which SPDX License Identifier to be applied to
      a file was done in a spreadsheet of side by side results from of the
      output of two independent scanners (ScanCode & Windriver) producing SPDX
      tag:value files created by Philippe Ombredanne.  Philippe prepared the
      base worksheet, and did an initial spot review of a few 1000 files.
      
      The 4.13 kernel was the starting point of the analysis with 60,537 files
      assessed.  Kate Stewart did a file by file comparison of the scanner
      results in the spreadsheet to determine which SPDX license identifier(s)
      to be applied to the file. She confirmed any determination that was not
      immediately clear with lawyers working with the Linux Foundation.
      
      Criteria used to select files for SPDX license identifier tagging was:
       - Files considered eligible had to be source code files.
       - Make and config files were included as candidates if they contained >5
         lines of source
       - File already had some variant of a license header in it (even if <5
         lines).
      
      All documentation files were explicitly excluded.
      
      The following heuristics were used to determine which SPDX license
      identifiers to apply.
      
       - when both scanners couldn't find any license traces, file was
         considered to have no license information in it, and the top level
         COPYING file license applied.
      
         For non */uapi/* files that summary was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0                                              11139
      
         and resulted in the first patch in this series.
      
         If that file was a */uapi/* path one, it was "GPL-2.0 WITH
         Linux-syscall-note" otherwise it was "GPL-2.0".  Results of that was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0 WITH Linux-syscall-note                        930
      
         and resulted in the second patch in this series.
      
       - if a file had some form of licensing information in it, and was one
         of the */uapi/* ones, it was denoted with the Linux-syscall-note if
         any GPL family license was found in the file or had no licensing in
         it (per prior point).  Results summary:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|------
         GPL-2.0 WITH Linux-syscall-note                       270
         GPL-2.0+ WITH Linux-syscall-note                      169
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)    21
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)    17
         LGPL-2.1+ WITH Linux-syscall-note                      15
         GPL-1.0+ WITH Linux-syscall-note                       14
         ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)    5
         LGPL-2.0+ WITH Linux-syscall-note                       4
         LGPL-2.1 WITH Linux-syscall-note                        3
         ((GPL-2.0 WITH Linux-syscall-note) OR MIT)              3
         ((GPL-2.0 WITH Linux-syscall-note) AND MIT)             1
      
         and that resulted in the third patch in this series.
      
       - when the two scanners agreed on the detected license(s), that became
         the concluded license(s).
      
       - when there was disagreement between the two scanners (one detected a
         license but the other didn't, or they both detected different
         licenses) a manual inspection of the file occurred.
      
       - In most cases a manual inspection of the information in the file
         resulted in a clear resolution of the license that should apply (and
         which scanner probably needed to revisit its heuristics).
      
       - When it was not immediately clear, the license identifier was
         confirmed with lawyers working with the Linux Foundation.
      
       - If there was any question as to the appropriate license identifier,
         the file was flagged for further research and to be revisited later
         in time.
      
      In total, over 70 hours of logged manual review was done on the
      spreadsheet to determine the SPDX license identifiers to apply to the
      source files by Kate, Philippe, Thomas and, in some cases, confirmation
      by lawyers working with the Linux Foundation.
      
      Kate also obtained a third independent scan of the 4.13 code base from
      FOSSology, and compared selected files where the other two scanners
      disagreed against that SPDX file, to see if there was new insights.  The
      Windriver scanner is based on an older version of FOSSology in part, so
      they are related.
      
      Thomas did random spot checks in about 500 files from the spreadsheets
      for the uapi headers and agreed with SPDX license identifier in the
      files he inspected. For the non-uapi files Thomas did random spot checks
      in about 15000 files.
      
      In initial set of patches against 4.14-rc6, 3 files were found to have
      copy/paste license identifier errors, and have been fixed to reflect the
      correct identifier.
      
      Additionally Philippe spent 10 hours this week doing a detailed manual
      inspection and review of the 12,461 patched files from the initial patch
      version early this week with:
       - a full scancode scan run, collecting the matched texts, detected
         license ids and scores
       - reviewing anything where there was a license detected (about 500+
         files) to ensure that the applied SPDX license was correct
       - reviewing anything where there was no detection but the patch license
         was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
         SPDX license was correct
      
      This produced a worksheet with 20 files needing minor correction.  This
      worksheet was then exported into 3 different .csv files for the
      different types of files to be modified.
      
      These .csv files were then reviewed by Greg.  Thomas wrote a script to
      parse the csv files and add the proper SPDX tag to the file, in the
      format that the file expected.  This script was further refined by Greg
      based on the output to detect more types of files automatically and to
      distinguish between header and source .c files (which need different
      comment types.)  Finally Greg ran the script using the .csv files to
      generate the patches.
      Reviewed-by: NKate Stewart <kstewart@linuxfoundation.org>
      Reviewed-by: NPhilippe Ombredanne <pombredanne@nexb.com>
      Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b2441318
  18. 25 10月, 2017 1 次提交
    • M
      locking/atomics: COCCINELLE/treewide: Convert trivial ACCESS_ONCE() patterns... · 6aa7de05
      Mark Rutland 提交于
      locking/atomics: COCCINELLE/treewide: Convert trivial ACCESS_ONCE() patterns to READ_ONCE()/WRITE_ONCE()
      
      Please do not apply this to mainline directly, instead please re-run the
      coccinelle script shown below and apply its output.
      
      For several reasons, it is desirable to use {READ,WRITE}_ONCE() in
      preference to ACCESS_ONCE(), and new code is expected to use one of the
      former. So far, there's been no reason to change most existing uses of
      ACCESS_ONCE(), as these aren't harmful, and changing them results in
      churn.
      
      However, for some features, the read/write distinction is critical to
      correct operation. To distinguish these cases, separate read/write
      accessors must be used. This patch migrates (most) remaining
      ACCESS_ONCE() instances to {READ,WRITE}_ONCE(), using the following
      coccinelle script:
      
      ----
      // Convert trivial ACCESS_ONCE() uses to equivalent READ_ONCE() and
      // WRITE_ONCE()
      
      // $ make coccicheck COCCI=/home/mark/once.cocci SPFLAGS="--include-headers" MODE=patch
      
      virtual patch
      
      @ depends on patch @
      expression E1, E2;
      @@
      
      - ACCESS_ONCE(E1) = E2
      + WRITE_ONCE(E1, E2)
      
      @ depends on patch @
      expression E;
      @@
      
      - ACCESS_ONCE(E)
      + READ_ONCE(E)
      ----
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: davem@davemloft.net
      Cc: linux-arch@vger.kernel.org
      Cc: mpe@ellerman.id.au
      Cc: shuah@kernel.org
      Cc: snitzer@redhat.com
      Cc: thor.thayer@linux.intel.com
      Cc: tj@kernel.org
      Cc: viro@zeniv.linux.org.uk
      Cc: will.deacon@arm.com
      Link: http://lkml.kernel.org/r/1508792849-3115-19-git-send-email-paulmck@linux.vnet.ibm.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      6aa7de05
  19. 19 10月, 2017 1 次提交