1. 01 12月, 2022 1 次提交
  2. 18 7月, 2022 1 次提交
    • A
      riscv/mm: enable ARCH_HAS_VM_GET_PAGE_PROT · 4147b5e2
      Anshuman Khandual 提交于
      This enables ARCH_HAS_VM_GET_PAGE_PROT on the platform and exports
      standard vm_get_page_prot() implementation via DECLARE_VM_GET_PAGE_PROT,
      which looks up a private and static protection_map[] array.  Subsequently
      all __SXXX and __PXXX macros can be dropped which are no longer needed.
      
      Link: https://lkml.kernel.org/r/20220711070600.2378316-17-anshuman.khandual@arm.comSigned-off-by: NAnshuman Khandual <anshuman.khandual@arm.com>
      Cc: Paul Walmsley <paul.walmsley@sifive.com>
      Cc: Palmer Dabbelt <palmer@dabbelt.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Brian Cain <bcain@quicinc.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Chris Zankel <chris@zankel.net>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Dinh Nguyen <dinguyen@kernel.org>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Guo Ren <guoren@kernel.org>
      Cc: Heiko Carstens <hca@linux.ibm.com>
      Cc: Huacai Chen <chenhuacai@kernel.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Jonas Bonn <jonas@southpole.se>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Nicholas Piggin <npiggin@gmail.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Rich Felker <dalias@libc.org>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Cc: Stafford Horne <shorne@gmail.com>
      Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vasily Gorbik <gor@linux.ibm.com>
      Cc: Vineet Gupta <vgupta@kernel.org>
      Cc: WANG Xuerui <kernel@xen0n.name>
      Cc: Will Deacon <will@kernel.org>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      4147b5e2
  3. 11 7月, 2022 1 次提交
  4. 20 5月, 2022 1 次提交
  5. 13 5月, 2022 1 次提交
  6. 12 5月, 2022 3 次提交
  7. 27 4月, 2022 1 次提交
  8. 04 3月, 2022 1 次提交
  9. 15 2月, 2022 2 次提交
  10. 20 1月, 2022 4 次提交
  11. 08 1月, 2022 2 次提交
    • N
      riscv/mm: Enable THP migration · d062a79b
      Nanyong Sun 提交于
      Add two THP helpers required to create PMD migration swap entries,
      and enable THP migration via ARCH_ENABLE_THP_MIGRATION. This can
      reduce time of THP migration without splitting and guarantee the
      migrated pages are still contiguous.
      Signed-off-by: NNanyong Sun <sunnanyong@huawei.com>
      Signed-off-by: NPalmer Dabbelt <palmer@rivosinc.com>
      d062a79b
    • N
      riscv/mm: Adjust PAGE_PROT_NONE to comply with THP semantics · fba88ede
      Nanyong Sun 提交于
      This is a preparation for enabling THP migration.
      As the commit b65399f6("arm64/mm: Change THP helpers
      to comply with generic MM semantics") mentioned, pmd_present()
      and pmd_trans_huge() are expected to behave in the following
      manner:
      -------------------------------------------------------------------------
      |	PMD states	|	pmd_present	|	pmd_trans_huge	|
      -------------------------------------------------------------------------
      |	Mapped		|	Yes		|	Yes		|
      -------------------------------------------------------------------------
      |	Splitting	|	Yes		|	Yes		|
      -------------------------------------------------------------------------
      |	Migration/Swap	|	No		|	No		|
      -------------------------------------------------------------------------
      
      At present the PROT_NONE bit reuses the READ bit could not comply with
      above semantics with two problems:
      1. When splitting a PMD THP, PMD is first invalidated with
      pmdp_invalidate()->pmd_mkinvalid(), which clears the PRESENT bit
      and PROT_NONE bit/READ bit, if the PMD is read-only, then the PAGE_LEAF
      property is also cleared, which results in pmd_present() return false.
      2. When migrating, the swap entry only clear the PRESENT bit
      and PROT_NONE bit/READ bit, the W/X bit may be set, so _PAGE_LEAF may be
      true which results in pmd_present() return true.
      
      Solution:
      Adjust PROT_NONE bit from READ to GLOBAL bit can satisfy the above rules:
      1. GLOBAL bit has no other meanings, not like the R/W/X bit, which is
      also relative with _PAGE_LEAF property.
      2. GLOBAL bit is at bit 5, making swap entry start from bit 6, bit 0-5
      are zero, which means the PRESENT, PROT_NONE, and PAGE_LEAF are
      all false, then the pmd_present() and pmd_trans_huge() return false when
      in migration/swap.
      Signed-off-by: NNanyong Sun <sunnanyong@huawei.com>
      Signed-off-by: NPalmer Dabbelt <palmer@rivosinc.com>
      fba88ede
  12. 06 1月, 2022 1 次提交
  13. 27 10月, 2021 1 次提交
  14. 06 7月, 2021 1 次提交
    • N
      riscv: mm: fix build errors caused by mk_pmd() · 9eb4fcff
      Nanyong Sun 提交于
      With "riscv: mm: add THP support on 64-bit", mk_pmd() function
      introduce build errors,
      1.build with CONFIG_ARCH_RV32I=y:
      arch/riscv/include/asm/pgtable.h: In function 'mk_pmd':
      arch/riscv/include/asm/pgtable.h:513:9: error: implicit declaration of function 'pfn_pmd';
       did you mean 'pfn_pgd'? [-Werror=implicit-function-declaration]
      
      2.build with CONFIG_SPARSEMEM=y && CONFIG_SPARSEMEM_VMEMMAP=n
      arch/riscv/include/asm/pgtable.h: In function 'mk_pmd':
      include/asm-generic/memory_model.h:64:14: error: implicit declaration of function 'page_to_section';
       did you mean 'present_section'? [-Werror=implicit-function-declaration]
      
      Move the definition of mk_pmd to pgtable-64.h to fix the first error.
      Use macro definition instead of inline function for mk_pmd
      to fix the second problem. It is similar to the mk_pte macro.
      Reported-by: Nkernel test robot <lkp@intel.com>
      Signed-off-by: NNanyong Sun <sunnanyong@huawei.com>
      Tested-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: NPalmer Dabbelt <palmerdabbelt@google.com>
      9eb4fcff
  15. 02 7月, 2021 1 次提交
    • A
      mm: define default value for FIRST_USER_ADDRESS · fac7757e
      Anshuman Khandual 提交于
      Currently most platforms define FIRST_USER_ADDRESS as 0UL duplication the
      same code all over.  Instead just define a generic default value (i.e 0UL)
      for FIRST_USER_ADDRESS and let the platforms override when required.  This
      makes it much cleaner with reduced code.
      
      The default FIRST_USER_ADDRESS here would be skipped in <linux/pgtable.h>
      when the given platform overrides its value via <asm/pgtable.h>.
      
      Link: https://lkml.kernel.org/r/1620615725-24623-1-git-send-email-anshuman.khandual@arm.comSigned-off-by: NAnshuman Khandual <anshuman.khandual@arm.com>
      Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>	[m68k]
      Acked-by: Guo Ren <guoren@kernel.org>			[csky]
      Acked-by: Stafford Horne <shorne@gmail.com>		[openrisc]
      Acked-by: Catalin Marinas <catalin.marinas@arm.com>	[arm64]
      Acked-by: NMike Rapoport <rppt@linux.ibm.com>
      Acked-by: Palmer Dabbelt <palmerdabbelt@google.com>	[RISC-V]
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will@kernel.org>
      Cc: Guo Ren <guoren@kernel.org>
      Cc: Brian Cain <bcain@codeaurora.org>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
      Cc: Ley Foon Tan <ley.foon.tan@intel.com>
      Cc: Jonas Bonn <jonas@southpole.se>
      Cc: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
      Cc: Stafford Horne <shorne@gmail.com>
      Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
      Cc: Paul Walmsley <paul.walmsley@sifive.com>
      Cc: Heiko Carstens <hca@linux.ibm.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Chris Zankel <chris@zankel.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      fac7757e
  16. 19 6月, 2021 1 次提交
    • J
      riscv: Ensure BPF_JIT_REGION_START aligned with PMD size · 3a02764c
      Jisheng Zhang 提交于
      Andreas reported commit fc850476 ("riscv: bpf: Avoid breaking W^X")
      breaks booting with one kind of defconfig, I reproduced a kernel panic
      with the defconfig:
      
      [    0.138553] Unable to handle kernel paging request at virtual address ffffffff81201220
      [    0.139159] Oops [#1]
      [    0.139303] Modules linked in:
      [    0.139601] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.13.0-rc5-default+ #1
      [    0.139934] Hardware name: riscv-virtio,qemu (DT)
      [    0.140193] epc : __memset+0xc4/0xfc
      [    0.140416]  ra : skb_flow_dissector_init+0x1e/0x82
      [    0.140609] epc : ffffffff8029806c ra : ffffffff8033be78 sp : ffffffe001647da0
      [    0.140878]  gp : ffffffff81134b08 tp : ffffffe001654380 t0 : ffffffff81201158
      [    0.141156]  t1 : 0000000000000002 t2 : 0000000000000154 s0 : ffffffe001647dd0
      [    0.141424]  s1 : ffffffff80a43250 a0 : ffffffff81201220 a1 : 0000000000000000
      [    0.141654]  a2 : 000000000000003c a3 : ffffffff81201258 a4 : 0000000000000064
      [    0.141893]  a5 : ffffffff8029806c a6 : 0000000000000040 a7 : ffffffffffffffff
      [    0.142126]  s2 : ffffffff81201220 s3 : 0000000000000009 s4 : ffffffff81135088
      [    0.142353]  s5 : ffffffff81135038 s6 : ffffffff8080ce80 s7 : ffffffff80800438
      [    0.142584]  s8 : ffffffff80bc6578 s9 : 0000000000000008 s10: ffffffff806000ac
      [    0.142810]  s11: 0000000000000000 t3 : fffffffffffffffc t4 : 0000000000000000
      [    0.143042]  t5 : 0000000000000155 t6 : 00000000000003ff
      [    0.143220] status: 0000000000000120 badaddr: ffffffff81201220 cause: 000000000000000f
      [    0.143560] [<ffffffff8029806c>] __memset+0xc4/0xfc
      [    0.143859] [<ffffffff8061e984>] init_default_flow_dissectors+0x22/0x60
      [    0.144092] [<ffffffff800010fc>] do_one_initcall+0x3e/0x168
      [    0.144278] [<ffffffff80600df0>] kernel_init_freeable+0x1c8/0x224
      [    0.144479] [<ffffffff804868a8>] kernel_init+0x12/0x110
      [    0.144658] [<ffffffff800022de>] ret_from_exception+0x0/0xc
      [    0.145124] ---[ end trace f1e9643daa46d591 ]---
      
      After some investigation, I think I found the root cause: commit
      2bfc6cd8 ("move kernel mapping outside of linear mapping") moves
      BPF JIT region after the kernel:
      
      | #define BPF_JIT_REGION_START	PFN_ALIGN((unsigned long)&_end)
      
      The &_end is unlikely aligned with PMD size, so the front bpf jit
      region sits with part of kernel .data section in one PMD size mapping.
      But kernel is mapped in PMD SIZE, when bpf_jit_binary_lock_ro() is
      called to make the first bpf jit prog ROX, we will make part of kernel
      .data section RO too, so when we write to, for example memset the
      .data section, MMU will trigger a store page fault.
      
      To fix the issue, we need to ensure the BPF JIT region is PMD size
      aligned. This patch acchieve this goal by restoring the BPF JIT region
      to original position, I.E the 128MB before kernel .text section. The
      modification to kasan_init.c is inspired by Alexandre.
      
      Fixes: fc850476 ("riscv: bpf: Avoid breaking W^X")
      Reported-by: NAndreas Schwab <schwab@linux-m68k.org>
      Signed-off-by: NJisheng Zhang <jszhang@kernel.org>
      Signed-off-by: NPalmer Dabbelt <palmerdabbelt@google.com>
      3a02764c
  17. 12 6月, 2021 1 次提交
  18. 09 6月, 2021 1 次提交
  19. 30 5月, 2021 1 次提交
  20. 26 5月, 2021 2 次提交
  21. 23 5月, 2021 3 次提交
  22. 01 5月, 2021 1 次提交
  23. 26 4月, 2021 2 次提交
    • V
      RISC-V: enable XIP · 44c92257
      Vitaly Wool 提交于
      Introduce XIP (eXecute In Place) support for RISC-V platforms.
      It allows code to be executed directly from non-volatile storage
      directly addressable by the CPU, such as QSPI NOR flash which can
      be found on many RISC-V platforms. This makes way for significant
      optimization of RAM footprint. The XIP kernel is not compressed
      since it has to run directly from flash, so it will occupy more
      space on the non-volatile storage. The physical flash address used
      to link the kernel object files and for storing it has to be known
      at compile time and is represented by a Kconfig option.
      
      XIP on RISC-V will for the time being only work on MMU-enabled
      kernels.
      Signed-off-by: NVitaly Wool <vitaly.wool@konsulko.com>
      [Alex: Rebase on top of "Move kernel mapping outside the linear mapping" ]
      Signed-off-by: NAlexandre Ghiti <alex@ghiti.fr>
      [Palmer: disable XIP for allyesconfig]
      Signed-off-by: NPalmer Dabbelt <palmerdabbelt@google.com>
      44c92257
    • A
      riscv: Move kernel mapping outside of linear mapping · 2bfc6cd8
      Alexandre Ghiti 提交于
      This is a preparatory patch for relocatable kernel and sv48 support.
      
      The kernel used to be linked at PAGE_OFFSET address therefore we could use
      the linear mapping for the kernel mapping. But the relocated kernel base
      address will be different from PAGE_OFFSET and since in the linear mapping,
      two different virtual addresses cannot point to the same physical address,
      the kernel mapping needs to lie outside the linear mapping so that we don't
      have to copy it at the same physical offset.
      
      The kernel mapping is moved to the last 2GB of the address space, BPF
      is now always after the kernel and modules use the 2GB memory range right
      before the kernel, so BPF and modules regions do not overlap. KASLR
      implementation will simply have to move the kernel in the last 2GB range
      and just take care of leaving enough space for BPF.
      
      In addition, by moving the kernel to the end of the address space, both
      sv39 and sv48 kernels will be exactly the same without needing to be
      relocated at runtime.
      Suggested-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NAlexandre Ghiti <alex@ghiti.fr>
      [Palmer: Squash the STRICT_RWX fix, and a !MMU fix]
      Signed-off-by: NPalmer Dabbelt <palmerdabbelt@google.com>
      2bfc6cd8
  24. 15 1月, 2021 2 次提交
  25. 10 1月, 2021 1 次提交
  26. 16 12月, 2020 1 次提交
    • M
      arch, mm: restore dependency of __kernel_map_pages() on DEBUG_PAGEALLOC · 5d6ad668
      Mike Rapoport 提交于
      The design of DEBUG_PAGEALLOC presumes that __kernel_map_pages() must
      never fail.  With this assumption is wouldn't be safe to allow general
      usage of this function.
      
      Moreover, some architectures that implement __kernel_map_pages() have this
      function guarded by #ifdef DEBUG_PAGEALLOC and some refuse to map/unmap
      pages when page allocation debugging is disabled at runtime.
      
      As all the users of __kernel_map_pages() were converted to use
      debug_pagealloc_map_pages() it is safe to make it available only when
      DEBUG_PAGEALLOC is set.
      
      Link: https://lkml.kernel.org/r/20201109192128.960-4-rppt@kernel.orgSigned-off-by: NMike Rapoport <rppt@linux.ibm.com>
      Acked-by: NDavid Hildenbrand <david@redhat.com>
      Acked-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Albert Ou <aou@eecs.berkeley.edu>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Christian Borntraeger <borntraeger@de.ibm.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
      Cc: Heiko Carstens <hca@linux.ibm.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Palmer Dabbelt <palmer@dabbelt.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Paul Walmsley <paul.walmsley@sifive.com>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vasily Gorbik <gor@linux.ibm.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: Will Deacon <will@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5d6ad668
  27. 03 10月, 2020 2 次提交