1. 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
  2. 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
  3. 01 5月, 2021 1 次提交
  4. 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
  5. 15 1月, 2021 2 次提交
  6. 10 1月, 2021 1 次提交
  7. 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
  8. 03 10月, 2020 2 次提交
  9. 10 6月, 2020 2 次提交
    • M
      mm: consolidate pte_index() and pte_offset_*() definitions · 974b9b2c
      Mike Rapoport 提交于
      All architectures define pte_index() as
      
      	(address >> PAGE_SHIFT) & (PTRS_PER_PTE - 1)
      
      and all architectures define pte_offset_kernel() as an entry in the array
      of PTEs indexed by the pte_index().
      
      For the most architectures the pte_offset_kernel() implementation relies
      on the availability of pmd_page_vaddr() that converts a PMD entry value to
      the virtual address of the page containing PTEs array.
      
      Let's move x86 definitions of the PTE accessors to the generic place in
      <linux/pgtable.h> and then simply drop the respective definitions from the
      other architectures.
      
      The architectures that didn't provide pmd_page_vaddr() are updated to have
      that defined.
      
      The generic implementation of pte_offset_kernel() can be overridden by an
      architecture and alpha makes use of this because it has special ordering
      requirements for its version of pte_offset_kernel().
      
      [rppt@linux.ibm.com: v2]
        Link: http://lkml.kernel.org/r/20200514170327.31389-11-rppt@kernel.org
      [rppt@linux.ibm.com: update]
        Link: http://lkml.kernel.org/r/20200514170327.31389-12-rppt@kernel.org
      [rppt@linux.ibm.com: update]
        Link: http://lkml.kernel.org/r/20200514170327.31389-13-rppt@kernel.org
      [akpm@linux-foundation.org: fix x86 warning]
      [sfr@canb.auug.org.au: fix powerpc build]
        Link: http://lkml.kernel.org/r/20200607153443.GB738695@linux.ibm.comSigned-off-by: NMike Rapoport <rppt@linux.ibm.com>
      Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Cain <bcain@codeaurora.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Chris Zankel <chris@zankel.net>
      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: Ingo Molnar <mingo@redhat.com>
      Cc: Ley Foon Tan <ley.foon.tan@intel.com>
      Cc: Mark Salter <msalter@redhat.com>
      Cc: Matthew Wilcox <willy@infradead.org>
      Cc: Matt Turner <mattst88@gmail.com>
      Cc: Max Filippov <jcmvbkbc@gmail.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      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: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Vincent Chen <deanbo422@gmail.com>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Will Deacon <will@kernel.org>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Link: http://lkml.kernel.org/r/20200514170327.31389-10-rppt@kernel.orgSigned-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      974b9b2c
    • M
      mm: introduce include/linux/pgtable.h · ca5999fd
      Mike Rapoport 提交于
      The include/linux/pgtable.h is going to be the home of generic page table
      manipulation functions.
      
      Start with moving asm-generic/pgtable.h to include/linux/pgtable.h and
      make the latter include asm/pgtable.h.
      Signed-off-by: NMike Rapoport <rppt@linux.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Cain <bcain@codeaurora.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Chris Zankel <chris@zankel.net>
      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: Ingo Molnar <mingo@redhat.com>
      Cc: Ley Foon Tan <ley.foon.tan@intel.com>
      Cc: Mark Salter <msalter@redhat.com>
      Cc: Matthew Wilcox <willy@infradead.org>
      Cc: Matt Turner <mattst88@gmail.com>
      Cc: Max Filippov <jcmvbkbc@gmail.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      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: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Vincent Chen <deanbo422@gmail.com>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Will Deacon <will@kernel.org>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Link: http://lkml.kernel.org/r/20200514170327.31389-3-rppt@kernel.orgSigned-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ca5999fd
  10. 03 6月, 2020 1 次提交
    • C
      mm: switch the test_vmalloc module to use __vmalloc_node · c3f896dc
      Christoph Hellwig 提交于
      No need to export the very low-level __vmalloc_node_range when the test
      module can use a slightly higher level variant.
      
      [akpm@linux-foundation.org: add missing `node' arg]
      [akpm@linux-foundation.org: fix riscv nommu build]
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Christian Borntraeger <borntraeger@de.ibm.com>
      Cc: Christophe Leroy <christophe.leroy@c-s.fr>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: David Airlie <airlied@linux.ie>
      Cc: Gao Xiang <xiang@kernel.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Haiyang Zhang <haiyangz@microsoft.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: "K. Y. Srinivasan" <kys@microsoft.com>
      Cc: Laura Abbott <labbott@redhat.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Michael Kelley <mikelley@microsoft.com>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Nitin Gupta <ngupta@vflare.org>
      Cc: Robin Murphy <robin.murphy@arm.com>
      Cc: Sakari Ailus <sakari.ailus@linux.intel.com>
      Cc: Stephen Hemminger <sthemmin@microsoft.com>
      Cc: Sumit Semwal <sumit.semwal@linaro.org>
      Cc: Wei Liu <wei.liu@kernel.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Paul Mackerras <paulus@ozlabs.org>
      Cc: Vasily Gorbik <gor@linux.ibm.com>
      Cc: Will Deacon <will@kernel.org>
      Link: http://lkml.kernel.org/r/20200414131348.444715-26-hch@lst.deSigned-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c3f896dc
  11. 14 5月, 2020 1 次提交
  12. 13 5月, 2020 1 次提交
  13. 27 3月, 2020 2 次提交
    • A
      RISC-V: Move all address space definition macros to one place · 2191b4f2
      Atish Patra 提交于
      We get the following compilation error if CONFIG_SPARSEMEM_VMEMMAP is set.
      
      ---------------------------------------------------------------
      ./arch/riscv/include/asm/pgtable-64.h: In function ‘pud_page’:
      ./include/asm-generic/memory_model.h:54:29: error: ‘vmemmap’ undeclared
      (first use in this function); did you mean ‘mem_map’?
       #define __pfn_to_page(pfn) (vmemmap + (pfn))
                                   ^~~~~~~
      ./include/asm-generic/memory_model.h:82:21: note: in expansion of
      macro ‘__pfn_to_page’
      
       #define pfn_to_page __pfn_to_page
                           ^~~~~~~~~~~~~
      ./arch/riscv/include/asm/pgtable-64.h:70:9: note: in expansion of macro
      ‘pfn_to_page’
        return pfn_to_page(pud_val(pud) >> _PAGE_PFN_SHIFT);
      ---------------------------------------------------------------
      
      Fix the compliation errors by moving all the address space definition
      macros before including pgtable-64.h.
      
      Fixes: 8ad8b727 (riscv: Add KASAN support)
      Signed-off-by: NAtish Patra <atish.patra@wdc.com>
      Reviewed-by: NAnup Patel <anup@brainfault.org>
      Signed-off-by: NPalmer Dabbelt <palmerdabbelt@google.com>
      2191b4f2
    • Z
      riscv: Add support to dump the kernel page tables · 59c4da86
      Zong Li 提交于
      In a similar manner to arm64, x86, powerpc, etc., it can traverse all
      page tables, and dump the page table layout with the memory types and
      permissions.
      
      Add a debugfs file at /sys/kernel/debug/kernel_page_tables to export
      the page table layout to userspace.
      Signed-off-by: NZong Li <zong.li@sifive.com>
      Tested-by: NAlexandre Ghiti <alex@ghiti.fr>
      Signed-off-by: NPalmer Dabbelt <palmerdabbelt@google.com>
      59c4da86
  14. 06 3月, 2020 1 次提交
    • A
      RISC-V: Move all address space definition macros to one place · 9f40b6e7
      Atish Patra 提交于
      If both CONFIG_KASAN and CONFIG_SPARSEMEM_VMEMMAP are set, we get the
      following compilation error.
      
      ---------------------------------------------------------------
      ./arch/riscv/include/asm/pgtable-64.h: In function ‘pud_page’:
      ./include/asm-generic/memory_model.h:54:29: error: ‘vmemmap’ undeclared
      (first use in this function); did you mean ‘mem_map’?
       #define __pfn_to_page(pfn) (vmemmap + (pfn))
                                   ^~~~~~~
      ./include/asm-generic/memory_model.h:82:21: note: in expansion of
      macro ‘__pfn_to_page’
      
       #define pfn_to_page __pfn_to_page
                           ^~~~~~~~~~~~~
      ./arch/riscv/include/asm/pgtable-64.h:70:9: note: in expansion of macro
      ‘pfn_to_page’
        return pfn_to_page(pud_val(pud) >> _PAGE_PFN_SHIFT);
      ---------------------------------------------------------------
      
      Fix the compliation errors by moving all the address space definition
      macros before including pgtable-64.h.
      
      Fixes: 8ad8b727 (riscv: Add KASAN support)
      Signed-off-by: NAtish Patra <atish.patra@wdc.com>
      Reviewed-by: NAnup Patel <anup@brainfault.org>
      Signed-off-by: NPalmer Dabbelt <palmerdabbelt@google.com>
      9f40b6e7
  15. 04 2月, 2020 1 次提交
    • S
      riscv: mm: add p?d_leaf() definitions · af6513ea
      Steven Price 提交于
      walk_page_range() is going to be allowed to walk page tables other than
      those of user space.  For this it needs to know when it has reached a
      'leaf' entry in the page tables.  This information is provided by the
      p?d_leaf() functions/macros.
      
      For riscv a page is a leaf page when it has a read, write or execute bit
      set on it.
      
      Link: http://lkml.kernel.org/r/20191218162402.45610-8-steven.price@arm.comSigned-off-by: NSteven Price <steven.price@arm.com>
      Reviewed-by: NAlexandre Ghiti <alex@ghiti.fr>
      Reviewed-by: NZong Li <zong.li@sifive.com>
      Acked-by: Paul Walmsley <paul.walmsley@sifive.com>	[arch/riscv]
      Cc: Albert Ou <aou@eecs.berkeley.edu>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      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: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: James Morse <james.morse@arm.com>
      Cc: Jerome Glisse <jglisse@redhat.com>
      Cc: "Liang, Kan" <kan.liang@linux.intel.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Paul Burton <paul.burton@mips.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vasily Gorbik <gor@linux.ibm.com>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Will Deacon <will@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      af6513ea
  16. 20 12月, 2019 1 次提交
  17. 19 12月, 2019 1 次提交
  18. 18 11月, 2019 1 次提交
    • C
      riscv: add nommu support · 6bd33e1e
      Christoph Hellwig 提交于
      The kernel runs in M-mode without using page tables, and thus can't run
      bare metal without help from additional firmware.
      
      Most of the patch is just stubbing out code not needed without page
      tables, but there is an interesting detail in the signals implementation:
      
       - The normal RISC-V syscall ABI only implements rt_sigreturn as VDSO
         entry point, but the ELF VDSO is not supported for nommu Linux.
         We instead copy the code to call the syscall onto the stack.
      
      In addition to enabling the nommu code a new defconfig for a small
      kernel image that can run in nommu mode on qemu is also provided, to run
      a kernel in qemu you can use the following command line:
      
      qemu-system-riscv64 -smp 2 -m 64 -machine virt -nographic \
      	-kernel arch/riscv/boot/loader \
      	-drive file=rootfs.ext2,format=raw,id=hd0 \
      	-device virtio-blk-device,drive=hd0
      
      Contains contributions from Damien Le Moal <Damien.LeMoal@wdc.com>.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NAnup Patel <anup@brainfault.org>
      [paul.walmsley@sifive.com: updated to apply; add CONFIG_MMU guards
       around PCI_IOBASE definition to fix build issues; fixed checkpatch
       issues; move the PCI_IO_* and VMEMMAP address space macros along
       with the others; resolve sparse warning]
      Signed-off-by: NPaul Walmsley <paul.walmsley@sifive.com>
      6bd33e1e
  19. 12 11月, 2019 1 次提交
  20. 29 10月, 2019 1 次提交
  21. 24 10月, 2019 2 次提交
  22. 16 10月, 2019 1 次提交
  23. 25 9月, 2019 1 次提交
  24. 19 9月, 2019 1 次提交
    • G
      RISC-V: Fix building error when CONFIG_SPARSEMEM_MANUAL=y · b6f2b2e6
      Greentime Hu 提交于
      Fix a build break by adjusting where VMALLOC_* and FIXADDR_* are
      defined.  This fixes the definition of the MEMMAP_* macros.
      
        CC      init/main.o
      In file included from ./include/linux/mm.h:99,
                       from ./include/linux/ring_buffer.h:5,
                       from ./include/linux/trace_events.h:6,
                       from ./include/trace/syscall.h:7,
                       from ./include/linux/syscalls.h:85,
                       from init/main.c:21:
      ./arch/riscv/include/asm/pgtable.h: In function ‘pmd_page’:
      ./arch/riscv/include/asm/pgtable.h:95:24: error: ‘VMALLOC_START’ undeclared (first use in this function); did you mean ‘VMEMMAP_START’?
       #define VMEMMAP_START (VMALLOC_START - VMEMMAP_SIZE)
                              ^~~~~~~~~~~~~
      
      Fixes: d95f1a54 ("RISC-V: Implement sparsemem")
      Signed-off-by: NGreentime Hu <greentime.hu@sifive.com>
      [paul.walmsley@sifive.com: minor patch description fix]
      Signed-off-by: NPaul Walmsley <paul.walmsley@sifive.com>
      b6f2b2e6
  25. 31 8月, 2019 1 次提交
    • L
      RISC-V: Implement sparsemem · d95f1a54
      Logan Gunthorpe 提交于
      Implement sparsemem support for Risc-v which helps pave the
      way for memory hotplug and eventually P2P support.
      
      Introduce Kconfig options for virtual and physical address bits which
      are used to calculate the size of the vmemmap and set the
      MAX_PHYSMEM_BITS.
      
      The vmemmap is located directly before the VMALLOC region and sized
      such that we can allocate enough pages to populate all the virtual
      address space in the system (similar to the way it's done in arm64).
      
      During initialization, call memblocks_present() and sparse_init(),
      and provide a stub for vmemmap_populate() (all of which is similar to
      arm64).
      
      [greentime.hu@sifive.com: fixed pfn_valid, FIXADDR_TOP and fixed a bug
       rebasing onto v5.3]
      Signed-off-by: NGreentime Hu <greentime.hu@sifive.com>
      Signed-off-by: NLogan Gunthorpe <logang@deltatee.com>
      Reviewed-by: NPalmer Dabbelt <palmer@sifive.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Cc: Albert Ou <aou@eecs.berkeley.edu>
      Cc: Andrew Waterman <andrew@sifive.com>
      Cc: Olof Johansson <olof@lixom.net>
      Cc: Michael Clark <michaeljclark@mac.com>
      Cc: Rob Herring <robh@kernel.org>
      Cc: Zong Li <zong@andestech.com>
      Reviewed-by: NMike Rapoport <rppt@linux.ibm.com>
      [paul.walmsley@sifive.com: updated to apply; minor commit message
       reformat]
      Signed-off-by: NPaul Walmsley <paul.walmsley@sifive.com>
      d95f1a54
  26. 29 8月, 2019 1 次提交
    • A
      RISC-V: Fix FIXMAP area corruption on RV32 systems · a256f2e3
      Anup Patel 提交于
      Currently, various virtual memory areas of Linux RISC-V are organized
      in increasing order of their virtual addresses is as follows:
      1. User space area (This is lowest area and starts at 0x0)
      2. FIXMAP area
      3. VMALLOC area
      4. Kernel area (This is highest area and starts at PAGE_OFFSET)
      
      The maximum size of user space aread is represented by TASK_SIZE.
      
      On RV32 systems, TASK_SIZE is defined as VMALLOC_START which causes the
      user space area to overlap the FIXMAP area. This allows user space apps
      to potentially corrupt the FIXMAP area and kernel OF APIs will crash
      whenever they access corrupted FDT in the FIXMAP area.
      
      On RV64 systems, TASK_SIZE is set to fixed 256GB and no other areas
      happen to overlap so we don't see any FIXMAP area corruptions.
      
      This patch fixes FIXMAP area corruption on RV32 systems by setting
      TASK_SIZE to FIXADDR_START. We also move FIXADDR_TOP, FIXADDR_SIZE,
      and FIXADDR_START defines to asm/pgtable.h so that we can avoid cyclic
      header includes.
      Signed-off-by: NAnup Patel <anup.patel@wdc.com>
      Tested-by: NAlistair Francis <alistair.francis@wdc.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NPaul Walmsley <paul.walmsley@sifive.com>
      a256f2e3
  27. 10 7月, 2019 1 次提交
    • A
      RISC-V: Setup initial page tables in two stages · 671f9a3e
      Anup Patel 提交于
      Currently, the setup_vm() does initial page table setup in one-shot
      very early before enabling MMU. Due to this, the setup_vm() has to map
      all possible kernel virtual addresses since it does not know size and
      location of RAM. This means we have kernel mappings for non-existent
      RAM and any buggy driver (or kernel) code doing out-of-bound access
      to RAM will not fault and cause underterministic behaviour.
      
      Further, the setup_vm() creates PMD mappings (i.e. 2M mappings) for
      RV64 systems. This means for PAGE_OFFSET=0xffffffe000000000 (i.e.
      MAXPHYSMEM_128GB=y), the setup_vm() will require 129 pages (i.e.
      516 KB) of memory for initial page tables which is never freed. The
      memory required for initial page tables will further increase if
      we chose a lower value of PAGE_OFFSET (e.g. 0xffffff0000000000)
      
      This patch implements two-staged initial page table setup, as follows:
      1. Early (i.e. setup_vm()): This stage maps kernel image and DTB in
      a early page table (i.e. early_pg_dir). The early_pg_dir will be used
      only by boot HART so it can be freed as-part of init memory free-up.
      2. Final (i.e. setup_vm_final()): This stage maps all possible RAM
      banks in the final page table (i.e. swapper_pg_dir). The boot HART
      will start using swapper_pg_dir at the end of setup_vm_final(). All
      non-boot HARTs directly use the swapper_pg_dir created by boot HART.
      
      We have following advantages with this new approach:
      1. Kernel mappings for non-existent RAM don't exists anymore.
      2. Memory consumed by initial page tables is now indpendent of the
      chosen PAGE_OFFSET.
      3. Memory consumed by initial page tables on RV64 system is 2 pages
      (i.e. 8 KB) which has significantly reduced and these pages will be
      freed as-part of the init memory free-up.
      
      The patch also provides a foundation for implementing strict kernel
      mappings where we protect kernel text and rodata using PTE permissions.
      Suggested-by: NMike Rapoport <rppt@linux.ibm.com>
      Signed-off-by: NAnup Patel <anup.patel@wdc.com>
      [paul.walmsley@sifive.com: updated to apply; fixed a checkpatch warning]
      Signed-off-by: NPaul Walmsley <paul.walmsley@sifive.com>
      671f9a3e
  28. 04 7月, 2019 1 次提交
  29. 05 6月, 2019 1 次提交
  30. 21 2月, 2019 1 次提交
  31. 12 2月, 2019 1 次提交
  32. 08 1月, 2018 1 次提交
  33. 01 12月, 2017 1 次提交
    • A
      RISC-V: Flush I$ when making a dirty page executable · 08f051ed
      Andrew Waterman 提交于
      The RISC-V ISA allows for instruction caches that are not coherent WRT
      stores, even on a single hart.  As a result, we need to explicitly flush
      the instruction cache whenever marking a dirty page as executable in
      order to preserve the correct system behavior.
      
      Local instruction caches aren't that scary (our implementations actually
      flush the cache, but RISC-V is defined to allow higher-performance
      implementations to exist), but RISC-V defines no way to perform an
      instruction cache shootdown.  When explicitly asked to do so we can
      shoot down remote instruction caches via an IPI, but this is a bit on
      the slow side.
      
      Instead of requiring an IPI to all harts whenever marking a page as
      executable, we simply flush the currently running harts.  In order to
      maintain correct behavior, we additionally mark every other hart as
      needing a deferred instruction cache which will be taken before anything
      runs on it.
      Signed-off-by: NAndrew Waterman <andrew@sifive.com>
      Signed-off-by: NPalmer Dabbelt <palmer@sifive.com>
      08f051ed
  34. 27 9月, 2017 1 次提交