1. 18 10月, 2018 6 次提交
    • L
      mremap: properly flush TLB before releasing the page · eb66ae03
      Linus Torvalds 提交于
      Jann Horn points out that our TLB flushing was subtly wrong for the
      mremap() case.  What makes mremap() special is that we don't follow the
      usual "add page to list of pages to be freed, then flush tlb, and then
      free pages".  No, mremap() obviously just _moves_ the page from one page
      table location to another.
      
      That matters, because mremap() thus doesn't directly control the
      lifetime of the moved page with a freelist: instead, the lifetime of the
      page is controlled by the page table locking, that serializes access to
      the entry.
      
      As a result, we need to flush the TLB not just before releasing the lock
      for the source location (to avoid any concurrent accesses to the entry),
      but also before we release the destination page table lock (to avoid the
      TLB being flushed after somebody else has already done something to that
      page).
      
      This also makes the whole "need_flush" logic unnecessary, since we now
      always end up flushing the TLB for every valid entry.
      Reported-and-tested-by: NJann Horn <jannh@google.com>
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Tested-by: NIngo Molnar <mingo@kernel.org>
      Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      eb66ae03
    • C
      LICENSES: Remove CC-BY-SA-4.0 license text · 19e6420e
      Christoph Hellwig 提交于
      Using non-GPL licenses for our documentation is rather problematic,
      as it can directly include other files, which generally are GPLv2
      licensed and thus not compatible.
      
      Remove this license now that the only user (idr.rst) is gone to avoid
      people semi-accidentally using it again.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      19e6420e
    • G
      Merge branch 'ida-fixes-4.19-rc8' of git://git.infradead.org/users/willy/linux-dax · ca9f672f
      Greg Kroah-Hartman 提交于
      Matthew writes:
        "IDA/IDR fixes for 4.19
      
         I have two tiny fixes, one for the IDA test-suite and one for the IDR
         documentation license."
      
      * 'ida-fixes-4.19-rc8' of git://git.infradead.org/users/willy/linux-dax:
        idr: Change documentation license
        test_ida: Fix lockdep warning
      ca9f672f
    • G
      Merge tag 'trace-v4.19-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace · 9bd871df
      Greg Kroah-Hartman 提交于
      Steven writes:
        "tracing: Two fixes for 4.19
      
         This fixes two bugs:
          - Fix size mismatch of tracepoint array
          - Have preemptirq test module use same clock source of the selftest"
      
      * tag 'trace-v4.19-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
        tracing: Use trace_clock_local() for looping in preemptirq_delay_test.c
        tracepoint: Fix tracepoint array element size mismatch
      9bd871df
    • S
      tracing: Use trace_clock_local() for looping in preemptirq_delay_test.c · 12ad0cb2
      Steven Rostedt (VMware) 提交于
      The preemptirq_delay_test module is used for the ftrace selftest code that
      tests the latency tracers. The problem is that it uses ktime for the delay
      loop, and then checks the tracer to see if the delay loop is caught, but the
      tracer uses trace_clock_local() which uses various different other clocks to
      measure the latency. As ktime uses the clock cycles, and the code then
      converts that to nanoseconds, it causes rounding errors, and the preemptirq
      latency tests are failing due to being off by 1 (it expects to see a delay
      of 500000 us, but the delay is only 499999 us). This is happening due to a
      rounding error in the ktime (which is totally legit). The purpose of the
      test is to see if it can catch the delay, not to test the accuracy between
      trace_clock_local() and ktime_get(). Best to use apples to apples, and have
      the delay loop use the same clock as the latency tracer does.
      
      Cc: stable@vger.kernel.org
      Fixes: f96e8577 ("lib: Add module for testing preemptoff/irqsoff latency tracers")
      Acked-by: NJoel Fernandes (Google) <joel@joelfernandes.org>
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      12ad0cb2
    • M
      tracepoint: Fix tracepoint array element size mismatch · 9c0be3f6
      Mathieu Desnoyers 提交于
      commit 46e0c9be ("kernel: tracepoints: add support for relative
      references") changes the layout of the __tracepoint_ptrs section on
      architectures supporting relative references. However, it does so
      without turning struct tracepoint * const into const int elsewhere in
      the tracepoint code, which has the following side-effect:
      
      Setting mod->num_tracepoints is done in by module.c:
      
          mod->tracepoints_ptrs = section_objs(info, "__tracepoints_ptrs",
                                               sizeof(*mod->tracepoints_ptrs),
                                               &mod->num_tracepoints);
      
      Basically, since sizeof(*mod->tracepoints_ptrs) is a pointer size
      (rather than sizeof(int)), num_tracepoints is erroneously set to half the
      size it should be on 64-bit arch. So a module with an odd number of
      tracepoints misses the last tracepoint due to effect of integer
      division.
      
      So in the module going notifier:
      
              for_each_tracepoint_range(mod->tracepoints_ptrs,
                      mod->tracepoints_ptrs + mod->num_tracepoints,
                      tp_module_going_check_quiescent, NULL);
      
      the expression (mod->tracepoints_ptrs + mod->num_tracepoints) actually
      evaluates to something within the bounds of the array, but miss the
      last tracepoint if the number of tracepoints is odd on 64-bit arch.
      
      Fix this by introducing a new typedef: tracepoint_ptr_t, which
      is either "const int" on architectures that have PREL32 relocations,
      or "struct tracepoint * const" on architectures that does not have
      this feature.
      
      Also provide a new tracepoint_ptr_defer() static inline to
      encapsulate deferencing this type rather than duplicate code and
      ugly idefs within the for_each_tracepoint_range() implementation.
      
      This issue appears in 4.19-rc kernels, and should ideally be fixed
      before the end of the rc cycle.
      Acked-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Acked-by: NJessica Yu <jeyu@kernel.org>
      Link: http://lkml.kernel.org/r/20181013191050.22389-1-mathieu.desnoyers@efficios.com
      Link: http://lkml.kernel.org/r/20180704083651.24360-7-ard.biesheuvel@linaro.org
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: James Morris <james.morris@microsoft.com>
      Cc: James Morris <jmorris@namei.org>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Nicolas Pitre <nico@linaro.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Petr Mladek <pmladek@suse.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: "Serge E. Hallyn" <serge@hallyn.com>
      Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Cc: Thomas Garnier <thgarnie@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      9c0be3f6
  2. 17 10月, 2018 4 次提交
  3. 16 10月, 2018 4 次提交
  4. 15 10月, 2018 4 次提交
    • D
      afs: Fix clearance of reply · f0a7d188
      David Howells 提交于
      The recent patch to fix the afs_server struct leak didn't actually fix the
      bug, but rather fixed some of the symptoms.  The problem is that an
      asynchronous call that holds a resource pointed to by call->reply[0] will
      find the pointer cleared in the call destructor, thereby preventing the
      resource from being cleaned up.
      
      In the case of the server record leak, the afs_fs_get_capabilities()
      function in devel code sets up a call with reply[0] pointing at the server
      record that should be altered when the result is obtained, but this was
      being cleared before the destructor was called, so the put in the
      destructor does nothing and the record is leaked.
      
      Commit f014ffb0 removed the additional ref obtained by
      afs_install_server(), but the removal of this ref is actually used by the
      garbage collector to mark a server record as being defunct after the record
      has expired through lack of use.
      
      The offending clearance of call->reply[0] upon completion in
      afs_process_async_call() has been there from the origin of the code, but
      none of the asynchronous calls actually use that pointer currently, so it
      should be safe to remove (note that synchronous calls don't involve this
      function).
      
      Fix this by the following means:
      
       (1) Revert commit f014ffb0.
      
       (2) Remove the clearance of reply[0] from afs_process_async_call().
      
      Without this, afs_manage_servers() will suffer an assertion failure if it
      sees a server record that didn't get used because the usage count is not 1.
      
      Fixes: f014ffb0 ("afs: Fix afs_server struct leak")
      Fixes: 08e0e7c8 ("[AF_RXRPC]: Make the in-kernel AFS filesystem use AF_RXRPC.")
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f0a7d188
    • G
      Linux 4.19-rc8 · 35a7f35a
      Greg Kroah-Hartman 提交于
      35a7f35a
    • D
      sparc64: Set %l4 properly on trap return after handling signals. · d1f1f98c
      David S. Miller 提交于
      If we did some signal processing, we have to reload the pt_regs
      tstate register because it's value may have changed.
      
      In doing so we also have to extract the %pil value contained in there
      anre load that into %l4.
      
      This value is at bit 20 and thus needs to be shifted down before we
      later write it into the %pil register.
      
      Most of the time this is harmless as we are returning to userspace
      and the %pil is zero for that case.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d1f1f98c
    • D
      sparc64: Make proc_id signed. · b3e1eb8e
      David S. Miller 提交于
      So that when it is unset, ie. '-1', userspace can see it
      properly.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b3e1eb8e
  5. 14 10月, 2018 2 次提交
  6. 13 10月, 2018 13 次提交
  7. 12 10月, 2018 7 次提交