1. 16 12月, 2020 1 次提交
    • K
      arm64: mremap speedup - enable HAVE_MOVE_PUD · f5308c89
      Kalesh Singh 提交于
      HAVE_MOVE_PUD enables remapping pages at the PUD level if both the source
      and destination addresses are PUD-aligned.
      
      With HAVE_MOVE_PUD enabled it can be inferred that there is approximately
      a 19x improvement in performance on arm64.  (See data below).
      
      ------- Test Results ---------
      
      The following results were obtained using a 5.4 kernel, by remapping a
      PUD-aligned, 1GB sized region to a PUD-aligned destination.  The results
      from 10 iterations of the test are given below:
      
      Total mremap times for 1GB data on arm64. All times are in nanoseconds.
      
        Control          HAVE_MOVE_PUD
      
        1247761          74271
        1219896          46771
        1094792          59687
        1227760          48385
        1043698          76666
        1101771          50365
        1159896          52500
        1143594          75261
        1025833          61354
        1078125          48697
      
        1134312.6        59395.7    <-- Mean time in nanoseconds
      
      A 1GB mremap completion time drops from ~1.1 milliseconds to ~59
      microseconds on arm64.  (~19x speed up).
      
      Link: https://lkml.kernel.org/r/20201014005320.2233162-5-kaleshsingh@google.comSigned-off-by: NKalesh Singh <kaleshsingh@google.com>
      Acked-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will@kernel.org>
      Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
      Cc: Anshuman Khandual <anshuman.khandual@arm.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Geffon <bgeffon@google.com>
      Cc: Christian Brauner <christian.brauner@ubuntu.com>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Frederic Weisbecker <frederic@kernel.org>
      Cc: Gavin Shan <gshan@redhat.com>
      Cc: Hassan Naveed <hnaveed@wavecomp.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Jia He <justin.he@arm.com>
      Cc: John Hubbard <jhubbard@nvidia.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Krzysztof Kozlowski <krzk@kernel.org>
      Cc: Lokesh Gidra <lokeshgidra@google.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Masahiro Yamada <masahiroy@kernel.org>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Mike Rapoport <rppt@kernel.org>
      Cc: Mina Almasry <almasrymina@google.com>
      Cc: Minchan Kim <minchan@google.com>
      Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Ralph Campbell <rcampbell@nvidia.com>
      Cc: Ram Pai <linuxram@us.ibm.com>
      Cc: Sami Tolvanen <samitolvanen@google.com>
      Cc: Sandipan Das <sandipan@linux.ibm.com>
      Cc: SeongJae Park <sjpark@amazon.de>
      Cc: Shuah Khan <shuah@kernel.org>
      Cc: Steven Price <steven.price@arm.com>
      Cc: Suren Baghdasaryan <surenb@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Zi Yan <ziy@nvidia.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f5308c89
  2. 01 12月, 2020 1 次提交
  3. 03 11月, 2020 1 次提交
  4. 29 10月, 2020 1 次提交
  5. 15 10月, 2020 1 次提交
  6. 14 10月, 2020 1 次提交
  7. 09 10月, 2020 1 次提交
  8. 29 9月, 2020 1 次提交
    • W
      arm64: Remove Spectre-related CONFIG_* options · 6e5f0927
      Will Deacon 提交于
      The spectre mitigations are too configurable for their own good, leading
      to confusing logic trying to figure out when we should mitigate and when
      we shouldn't. Although the plethora of command-line options need to stick
      around for backwards compatibility, the default-on CONFIG options that
      depend on EXPERT can be dropped, as the mitigations only do anything if
      the system is vulnerable, a mitigation is available and the command-line
      hasn't disabled it.
      
      Remove CONFIG_HARDEN_BRANCH_PREDICTOR and CONFIG_ARM64_SSBD in favour of
      enabling this code unconditionally.
      Signed-off-by: NWill Deacon <will@kernel.org>
      6e5f0927
  9. 18 9月, 2020 1 次提交
  10. 14 9月, 2020 1 次提交
    • M
      arm64: Allow IPIs to be handled as normal interrupts · d3afc7f1
      Marc Zyngier 提交于
      In order to deal with IPIs as normal interrupts, let's add
      a new way to register them with the architecture code.
      
      set_smp_ipi_range() takes a range of interrupts, and allows
      the arch code to request them as if the were normal interrupts.
      A standard handler is then called by the core IRQ code to deal
      with the IPI.
      
      This means that we don't need to call irq_enter/irq_exit, and
      that we don't need to deal with set_irq_regs either. So let's
      move the dispatcher into its own function, and leave handle_IPI()
      as a compatibility function.
      
      On the sending side, let's make use of ipi_send_mask, which
      already exists for this purpose.
      
      One of the major difference is that we end up, in some cases
      (such as when performing IRQ time accounting on the scheduler
      IPI), end up with nested irq_enter()/irq_exit() pairs.
      Other than the (relatively small) overhead, there should be
      no consequences to it (these pairs are designed to nest
      correctly, and the accounting shouldn't be off).
      Reviewed-by: NValentin Schneider <valentin.schneider@arm.com>
      Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NMarc Zyngier <maz@kernel.org>
      d3afc7f1
  11. 11 9月, 2020 3 次提交
  12. 09 9月, 2020 1 次提交
  13. 04 9月, 2020 1 次提交
  14. 29 7月, 2020 1 次提交
  15. 28 7月, 2020 1 次提交
  16. 25 7月, 2020 1 次提交
  17. 22 7月, 2020 1 次提交
  18. 15 7月, 2020 1 次提交
  19. 05 7月, 2020 1 次提交
  20. 03 7月, 2020 1 次提交
    • M
      arm64: Document sysctls for emulated deprecated instructions · dd720784
      Mark Brown 提交于
      We have support for emulating a number of deprecated instructions in the
      kernel with individual Kconfig options enabling this support per
      instruction. In addition to the Kconfig options we also provide runtime
      control via sysctls but this is not currently mentioned in the Kconfig so
      not very discoverable for users. This is particularly important for
      SWP/SWPB since this is disabled by default at runtime and must be enabled
      via the sysctl, causing considerable frustration for users who have enabled
      the config option and are then confused to find that the instruction is
      still faulting.
      
      Add a reference to the sysctls in the help text for each of the config
      options, noting that SWP/SWPB is disabled by default, to improve the
      user experience.
      Signed-off-by: NMark Brown <broonie@kernel.org>
      Link: https://lore.kernel.org/r/20200625131507.32334-1-broonie@kernel.orgSigned-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      dd720784
  21. 23 6月, 2020 1 次提交
    • M
      arm64: Depend on newer binutils when building PAC · 4dc9b282
      Mark Brown 提交于
      Versions of binutils prior to 2.33.1 don't understand the ELF notes that
      are added by modern compilers to indicate the PAC and BTI options used
      to build the code. This causes them to emit large numbers of warnings in
      the form:
      
      aarch64-linux-gnu-nm: warning: .tmp_vmlinux.kallsyms2: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0000000
      
      during the kernel build which is currently causing quite a bit of
      disruption for automated build testing using clang.
      
      In commit 15cd0e67 (arm64: Kconfig: ptrauth: Add binutils version
      check to fix mismatch) we added a dependency on binutils to avoid this
      issue when building with versions of GCC that emit the notes but did not
      do so for clang as it was believed that the existing check for
      .cfi_negate_ra_state was already requiring a new enough binutils. This
      does not appear to be the case for some versions of binutils (eg, the
      binutils in Debian 10) so instead refactor so we require a new enough
      GNU binutils in all cases other than when we are using an old GCC
      version that does not emit notes.
      
      Other, more exotic, combinations of tools are possible such as using
      clang, lld and gas together are possible and may have further problems
      but rather than adding further version checks it looks like the most
      robust thing will be to just test that we can build cleanly with the
      configured tools but that will require more review and discussion so do
      this for now to address the immediate problem disrupting build testing.
      Reported-by: NKernelCI <bot@kernelci.org>
      Reported-by: NNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>
      Link: https://github.com/ClangBuiltLinux/linux/issues/1054
      Link: https://lore.kernel.org/r/20200619123550.48098-1-broonie@kernel.orgSigned-off-by: NWill Deacon <will@kernel.org>
      4dc9b282
  22. 22 6月, 2020 1 次提交
  23. 17 6月, 2020 2 次提交
    • W
      arm64: bti: Require clang >= 10.0.1 for in-kernel BTI support · b9249cba
      Will Deacon 提交于
      Unfortunately, most versions of clang that support BTI are capable of
      miscompiling the kernel when converting a switch statement into a jump
      table. As an example, attempting to spawn a KVM guest results in a panic:
      
      [   56.253312] Kernel panic - not syncing: bad mode
      [   56.253834] CPU: 0 PID: 279 Comm: lkvm Not tainted 5.8.0-rc1 #2
      [   56.254225] Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
      [   56.254712] Call trace:
      [   56.254952]  dump_backtrace+0x0/0x1d4
      [   56.255305]  show_stack+0x1c/0x28
      [   56.255647]  dump_stack+0xc4/0x128
      [   56.255905]  panic+0x16c/0x35c
      [   56.256146]  bad_el0_sync+0x0/0x58
      [   56.256403]  el1_sync_handler+0xb4/0xe0
      [   56.256674]  el1_sync+0x7c/0x100
      [   56.256928]  kvm_vm_ioctl_check_extension_generic+0x74/0x98
      [   56.257286]  __arm64_sys_ioctl+0x94/0xcc
      [   56.257569]  el0_svc_common+0x9c/0x150
      [   56.257836]  do_el0_svc+0x84/0x90
      [   56.258083]  el0_sync_handler+0xf8/0x298
      [   56.258361]  el0_sync+0x158/0x180
      
      This is because the switch in kvm_vm_ioctl_check_extension_generic()
      is executed as an indirect branch to tail-call through a jump table:
      
      ffff800010032dc8:       3869694c        ldrb    w12, [x10, x9]
      ffff800010032dcc:       8b0c096b        add     x11, x11, x12, lsl #2
      ffff800010032dd0:       d61f0160        br      x11
      
      However, where the target case uses the stack, the landing pad is elided
      due to the presence of a paciasp instruction:
      
      ffff800010032e14:       d503233f        paciasp
      ffff800010032e18:       a9bf7bfd        stp     x29, x30, [sp, #-16]!
      ffff800010032e1c:       910003fd        mov     x29, sp
      ffff800010032e20:       aa0803e0        mov     x0, x8
      ffff800010032e24:       940017c0        bl      ffff800010038d24 <kvm_vm_ioctl_check_extension>
      ffff800010032e28:       93407c00        sxtw    x0, w0
      ffff800010032e2c:       a8c17bfd        ldp     x29, x30, [sp], #16
      ffff800010032e30:       d50323bf        autiasp
      ffff800010032e34:       d65f03c0        ret
      
      Unfortunately, this results in a fatal exception because paciasp is
      compatible only with branch-and-link (call) instructions and not simple
      indirect branches.
      
      A fix is being merged into Clang 10.0.1 so that a 'bti j' instruction is
      emitted as an explicit landing pad in this situation. Make in-kernel
      BTI depend on that compiler version when building with clang.
      
      Cc: Tom Stellard <tstellar@redhat.com>
      Cc: Daniel Kiss <daniel.kiss@arm.com>
      Reviewed-by: NMark Brown <broonie@kernel.org>
      Acked-by: NDave Martin <Dave.Martin@arm.com>
      Reviewed-by: NNathan Chancellor <natechancellor@gmail.com>
      Acked-by: NNick Desaulniers <ndesaulniers@google.com>
      Link: https://lore.kernel.org/r/20200615105524.GA2694@willie-the-truck
      Link: https://lore.kernel.org/r/20200616183630.2445-1-will@kernel.orgSigned-off-by: NWill Deacon <will@kernel.org>
      b9249cba
    • M
      kconfig: unify cc-option and as-option · 4d0831e8
      Masahiro Yamada 提交于
      cc-option and as-option are almost the same; both pass the flag to
      $(CC). The main difference is the cc-option stops before the assemble
      stage (-S option) whereas as-option stops after (-c option).
      
      I chose -S because it is slightly faster, but $(cc-option,-gz=zlib)
      returns a wrong result (https://lkml.org/lkml/2020/6/9/1529).
      It has been fixed by commit 7b169944 ("Makefile: Improve compressed
      debug info support detection"), but the assembler should always be
      invoked for more reliable compiler option tests.
      
      However, you cannot simply replace -S with -c because the following
      code in lib/Kconfig.debug would break:
      
          depends on $(cc-option,-gsplit-dwarf)
      
      The combination of -c and -gsplit-dwarf does not accept /dev/null as
      output.
      
        $ cat /dev/null | gcc -gsplit-dwarf -S -x c - -o /dev/null
        $ echo $?
        0
      
        $ cat /dev/null | gcc -gsplit-dwarf -c -x c - -o /dev/null
        objcopy: Warning: '/dev/null' is not an ordinary file
        $ echo $?
        1
      
        $ cat /dev/null | gcc -gsplit-dwarf -c -x c - -o tmp.o
        $ echo $?
        0
      
      There is another flag that creates an separate file based on the
      object file path:
      
        $ cat /dev/null | gcc -ftest-coverage -c -x c - -o /dev/null
        <stdin>:1: error: cannot open /dev/null.gcno
      
      So, we cannot use /dev/null to sink the output.
      
      Align the cc-option implementation with scripts/Kbuild.include.
      
      With -c option used in cc-option, as-option is unneeded.
      Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      Acked-by: NWill Deacon <will@kernel.org>
      4d0831e8
  24. 14 6月, 2020 1 次提交
    • M
      treewide: replace '---help---' in Kconfig files with 'help' · a7f7f624
      Masahiro Yamada 提交于
      Since commit 84af7a61 ("checkpatch: kconfig: prefer 'help' over
      '---help---'"), the number of '---help---' has been gradually
      decreasing, but there are still more than 2400 instances.
      
      This commit finishes the conversion. While I touched the lines,
      I also fixed the indentation.
      
      There are a variety of indentation styles found.
      
        a) 4 spaces + '---help---'
        b) 7 spaces + '---help---'
        c) 8 spaces + '---help---'
        d) 1 space + 1 tab + '---help---'
        e) 1 tab + '---help---'    (correct indentation)
        f) 1 tab + 1 space + '---help---'
        g) 1 tab + 2 spaces + '---help---'
      
      In order to convert all of them to 1 tab + 'help', I ran the
      following commend:
      
        $ find . -name 'Kconfig*' | xargs sed -i 's/^[[:space:]]*---help---/\thelp/'
      Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      a7f7f624
  25. 11 6月, 2020 1 次提交
  26. 10 6月, 2020 1 次提交
  27. 05 6月, 2020 1 次提交
    • A
      mm/debug: add tests validating architecture page table helpers · 399145f9
      Anshuman Khandual 提交于
      This adds tests which will validate architecture page table helpers and
      other accessors in their compliance with expected generic MM semantics.
      This will help various architectures in validating changes to existing
      page table helpers or addition of new ones.
      
      This test covers basic page table entry transformations including but not
      limited to old, young, dirty, clean, write, write protect etc at various
      level along with populating intermediate entries with next page table page
      and validating them.
      
      Test page table pages are allocated from system memory with required size
      and alignments.  The mapped pfns at page table levels are derived from a
      real pfn representing a valid kernel text symbol.  This test gets called
      via late_initcall().
      
      This test gets built and run when CONFIG_DEBUG_VM_PGTABLE is selected.
      Any architecture, which is willing to subscribe this test will need to
      select ARCH_HAS_DEBUG_VM_PGTABLE.  For now this is limited to arc, arm64,
      x86, s390 and powerpc platforms where the test is known to build and run
      successfully Going forward, other architectures too can subscribe the test
      after fixing any build or runtime problems with their page table helpers.
      
      Folks interested in making sure that a given platform's page table helpers
      conform to expected generic MM semantics should enable the above config
      which will just trigger this test during boot.  Any non conformity here
      will be reported as an warning which would need to be fixed.  This test
      will help catch any changes to the agreed upon semantics expected from
      generic MM and enable platforms to accommodate it thereafter.
      
      [anshuman.khandual@arm.com: v17]
        Link: http://lkml.kernel.org/r/1587436495-22033-3-git-send-email-anshuman.khandual@arm.com
      [anshuman.khandual@arm.com: v18]
        Link: http://lkml.kernel.org/r/1588564865-31160-3-git-send-email-anshuman.khandual@arm.comSuggested-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NAnshuman Khandual <anshuman.khandual@arm.com>
      Signed-off-by: NChristophe Leroy <christophe.leroy@c-s.fr>
      Signed-off-by: NQian Cai <cai@lca.pw>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Tested-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>	[s390]
      Tested-by: Christophe Leroy <christophe.leroy@c-s.fr>	[ppc32]
      Reviewed-by: NIngo Molnar <mingo@kernel.org>
      Cc: Mike Rapoport <rppt@linux.ibm.com>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will@kernel.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Vasily Gorbik <gor@linux.ibm.com>
      Cc: Christian Borntraeger <borntraeger@de.ibm.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Kirill A. Shutemov <kirill@shutemov.name>
      Cc: Paul Walmsley <paul.walmsley@sifive.com>
      Cc: Palmer Dabbelt <palmer@dabbelt.com>
      Link: http://lkml.kernel.org/r/1583919272-24178-1-git-send-email-anshuman.khandual@arm.comSigned-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      399145f9
  28. 04 6月, 2020 2 次提交
    • Z
      arm64: mm: use ARCH_HAS_DEBUG_WX instead of arch defined · 09587a09
      Zong Li 提交于
      Extract DEBUG_WX to mm/Kconfig.debug for shared use.  Change to use
      ARCH_HAS_DEBUG_WX instead of DEBUG_WX defined by arch port.
      Signed-off-by: NZong Li <zong.li@sifive.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Palmer Dabbelt <palmer@dabbelt.com>
      Cc: Paul Walmsley <paul.walmsley@sifive.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Will Deacon <will@kernel.org>
      Link: http://lkml.kernel.org/r/e19709e7576f65e303245fe520cad5f7bae72763.1587455584.git.zong.li@sifive.comSigned-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      09587a09
    • M
      mm: remove CONFIG_HAVE_MEMBLOCK_NODE_MAP option · 3f08a302
      Mike Rapoport 提交于
      CONFIG_HAVE_MEMBLOCK_NODE_MAP is used to differentiate initialization of
      nodes and zones structures between the systems that have region to node
      mapping in memblock and those that don't.
      
      Currently all the NUMA architectures enable this option and for the
      non-NUMA systems we can presume that all the memory belongs to node 0 and
      therefore the compile time configuration option is not required.
      
      The remaining few architectures that use DISCONTIGMEM without NUMA are
      easily updated to use memblock_add_node() instead of memblock_add() and
      thus have proper correspondence of memblock regions to NUMA nodes.
      
      Still, free_area_init_node() must have a backward compatible version
      because its semantics with and without CONFIG_HAVE_MEMBLOCK_NODE_MAP is
      different.  Once all the architectures will use the new semantics, the
      entire compatibility layer can be dropped.
      
      To avoid addition of extra run time memory to store node id for
      architectures that keep memblock but have only a single node, the node id
      field of the memblock_region is guarded by CONFIG_NEED_MULTIPLE_NODES and
      the corresponding accessors presume that in those cases it is always 0.
      Signed-off-by: NMike Rapoport <rppt@linux.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Tested-by: Hoan Tran <hoan@os.amperecomputing.com>	[arm64]
      Acked-by: Catalin Marinas <catalin.marinas@arm.com>	[arm64]
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Brian Cain <bcain@codeaurora.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Greentime Hu <green.hu@gmail.com>
      Cc: Greg Ungerer <gerg@linux-m68k.org>
      Cc: Guan Xuetao <gxt@pku.edu.cn>
      Cc: Guo Ren <guoren@kernel.org>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Helge Deller <deller@gmx.de>
      Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Ley Foon Tan <ley.foon.tan@intel.com>
      Cc: Mark Salter <msalter@redhat.com>
      Cc: Matt Turner <mattst88@gmail.com>
      Cc: Max Filippov <jcmvbkbc@gmail.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Michal Hocko <mhocko@kernel.org>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Nick Hu <nickhu@andestech.com>
      Cc: Paul Walmsley <paul.walmsley@sifive.com>
      Cc: Richard Weinberger <richard@nod.at>
      Cc: Rich Felker <dalias@libc.org>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Stafford Horne <shorne@gmail.com>
      Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Link: http://lkml.kernel.org/r/20200412194859.12663-4-rppt@kernel.orgSigned-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3f08a302
  29. 15 5月, 2020 2 次提交
  30. 12 5月, 2020 1 次提交
  31. 08 5月, 2020 1 次提交
  32. 05 5月, 2020 1 次提交
  33. 04 5月, 2020 2 次提交
  34. 23 4月, 2020 1 次提交