<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/arch/riscv/include/asm/set_memory.h, branch v6.6.131</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.6.131</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.6.131'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2023-04-19T14:46:28+00:00</updated>
<entry>
<title>riscv: Prepare EFI header for relocatable kernels</title>
<updated>2023-04-19T14:46:28+00:00</updated>
<author>
<name>Alexandre Ghiti</name>
<email>alexghiti@rivosinc.com</email>
</author>
<published>2023-03-29T04:53:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=55de1e4ad43b375566162ae0cc2b56dfa44aae4e'/>
<id>urn:sha1:55de1e4ad43b375566162ae0cc2b56dfa44aae4e</id>
<content type='text'>
ld does not handle relocations correctly as explained here [1],
a fix for that was proposed by Nelson there but we have to support older
toolchains and then provide this fix.

Note that llvm does not need this fix and is then excluded.

[1] https://sourceware.org/pipermail/binutils/2023-March/126690.html

Signed-off-by: Alexandre Ghiti &lt;alexghiti@rivosinc.com&gt;
Link: https://lore.kernel.org/r/20230329045329.64565-2-alexghiti@rivosinc.com
Signed-off-by: Palmer Dabbelt &lt;palmer@rivosinc.com&gt;
</content>
</entry>
<entry>
<title>riscv: Map the kernel with correct permissions the first time</title>
<updated>2021-07-01T04:18:58+00:00</updated>
<author>
<name>Alexandre Ghiti</name>
<email>alex@ghiti.fr</email>
</author>
<published>2021-06-24T12:00:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e5c35fa0401971701dcd7675f471b664698244dd'/>
<id>urn:sha1:e5c35fa0401971701dcd7675f471b664698244dd</id>
<content type='text'>
For 64-bit kernels, we map all the kernel with write and execute
permissions and afterwards remove writability from text and executability
from data.

For 32-bit kernels, the kernel mapping resides in the linear mapping, so we
map all the linear mapping as writable and executable and afterwards we
remove those properties for unused memory and kernel mapping as
described above.

Change this behavior to directly map the kernel with correct permissions
and avoid going through the whole mapping to fix the permissions.

At the same time, this fixes an issue introduced by commit 2bfc6cd81bd1
("riscv: Move kernel mapping outside of linear mapping") as reported
here https://github.com/starfive-tech/linux/issues/17.

Signed-off-by: Alexandre Ghiti &lt;alex@ghiti.fr&gt;
Reviewed-by: Anup Patel &lt;anup@brainfault.org&gt;
Signed-off-by: Palmer Dabbelt &lt;palmerdabbelt@google.com&gt;
</content>
</entry>
<entry>
<title>riscv: Introduce set_kernel_memory helper</title>
<updated>2021-07-01T03:56:50+00:00</updated>
<author>
<name>Alexandre Ghiti</name>
<email>alex@ghiti.fr</email>
</author>
<published>2021-06-24T12:00:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c10bc260e7c030364b5150aac7ebf048ddfb9502'/>
<id>urn:sha1:c10bc260e7c030364b5150aac7ebf048ddfb9502</id>
<content type='text'>
This helper should be used for setting permissions to the kernel
mapping as it takes pointers as arguments and then avoids explicit cast
to unsigned long needed for the set_memory_* API.

Suggested-by: Christoph Hellwig &lt;hch@infradead.org&gt;
Signed-off-by: Alexandre Ghiti &lt;alex@ghiti.fr&gt;
Reviewed-by: Anup Patel &lt;anup@brainfault.org&gt;
Reviewed-by: Atish Patra &lt;atish.patra@wdc.com&gt;
Reviewed-by: Jisheng Zhang &lt;jszhang@kernel.org&gt;
Signed-off-by: Palmer Dabbelt &lt;palmerdabbelt@google.com&gt;
</content>
</entry>
<entry>
<title>riscv: Consistify protect_kernel_linear_mapping_text_rodata() use</title>
<updated>2021-05-06T16:40:15+00:00</updated>
<author>
<name>Geert Uytterhoeven</name>
<email>geert+renesas@glider.be</email>
</author>
<published>2021-04-29T15:10:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8d91b097335892bfbc9fd5783e80e25f0fb5bb2b'/>
<id>urn:sha1:8d91b097335892bfbc9fd5783e80e25f0fb5bb2b</id>
<content type='text'>
The various uses of protect_kernel_linear_mapping_text_rodata() are
not consistent:
  - Its definition depends on "64BIT &amp;&amp; !XIP_KERNEL",
  - Its forward declaration depends on MMU,
  - Its single caller depends on "STRICT_KERNEL_RWX &amp;&amp; 64BIT &amp;&amp; MMU &amp;&amp;
    !XIP_KERNEL".

Fix this by settling on the dependencies of the caller, which can be
simplified as STRICT_KERNEL_RWX depends on "MMU &amp;&amp; !XIP_KERNEL".
Provide a dummy definition, as the caller is protected by
"IS_ENABLED(CONFIG_STRICT_KERNEL_RWX)" instead of "#ifdef
CONFIG_STRICT_KERNEL_RWX".

Signed-off-by: Geert Uytterhoeven &lt;geert+renesas@glider.be&gt;
Tested-by: Alexandre Ghiti &lt;alex@ghiti.fr&gt;
Signed-off-by: Palmer Dabbelt &lt;palmerdabbelt@google.com&gt;
</content>
</entry>
<entry>
<title>riscv: Move kernel mapping outside of linear mapping</title>
<updated>2021-04-26T15:25:04+00:00</updated>
<author>
<name>Alexandre Ghiti</name>
<email>alex@ghiti.fr</email>
</author>
<published>2021-04-11T16:41:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2bfc6cd81bd17e4306e24ee47b9554c967bcb499'/>
<id>urn:sha1:2bfc6cd81bd17e4306e24ee47b9554c967bcb499</id>
<content type='text'>
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: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Alexandre Ghiti &lt;alex@ghiti.fr&gt;
[Palmer: Squash the STRICT_RWX fix, and a !MMU fix]
Signed-off-by: Palmer Dabbelt &lt;palmerdabbelt@google.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'riscv-for-linus-5.12-mw0' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux</title>
<updated>2021-02-26T18:28:35+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2021-02-26T18:28:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8b83369ddcb3fb9cab5c1088987ce477565bb630'/>
<id>urn:sha1:8b83369ddcb3fb9cab5c1088987ce477565bb630</id>
<content type='text'>
Pull RISC-V updates from Palmer Dabbelt:
 "A handful of new RISC-V related patches for this merge window:

   - A check to ensure drivers are properly using uaccess. This isn't
     manifesting with any of the drivers I'm currently using, but may
     catch errors in new drivers.

   - Some preliminary support for the FU740, along with the HiFive
     Unleashed it will appear on.

   - NUMA support for RISC-V, which involves making the arm64 code
     generic.

   - Support for kasan on the vmalloc region.

   - A handful of new drivers for the Kendryte K210, along with the DT
     plumbing required to boot on a handful of K210-based boards.

   - Support for allocating ASIDs.

   - Preliminary support for kernels larger than 128MiB.

   - Various other improvements to our KASAN support, including the
     utilization of huge pages when allocating the KASAN regions.

  We may have already found a bug with the KASAN_VMALLOC code, but it's
  passing my tests. There's a fix in the works, but that will probably
  miss the merge window.

* tag 'riscv-for-linus-5.12-mw0' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: (75 commits)
  riscv: Improve kasan population by using hugepages when possible
  riscv: Improve kasan population function
  riscv: Use KASAN_SHADOW_INIT define for kasan memory initialization
  riscv: Improve kasan definitions
  riscv: Get rid of MAX_EARLY_MAPPING_SIZE
  soc: canaan: Sort the Makefile alphabetically
  riscv: Disable KSAN_SANITIZE for vDSO
  riscv: Remove unnecessary declaration
  riscv: Add Canaan Kendryte K210 SD card defconfig
  riscv: Update Canaan Kendryte K210 defconfig
  riscv: Add Kendryte KD233 board device tree
  riscv: Add SiPeed MAIXDUINO board device tree
  riscv: Add SiPeed MAIX GO board device tree
  riscv: Add SiPeed MAIX DOCK board device tree
  riscv: Add SiPeed MAIX BiT board device tree
  riscv: Update Canaan Kendryte K210 device tree
  dt-bindings: add resets property to dw-apb-timer
  dt-bindings: fix sifive gpio properties
  dt-bindings: update sifive uart compatible string
  dt-bindings: update sifive clint compatible string
  ...
</content>
</entry>
<entry>
<title>RISC-V: remove unneeded semicolon</title>
<updated>2021-02-19T07:18:03+00:00</updated>
<author>
<name>Chengyang Fan</name>
<email>cy.fan@huawei.com</email>
</author>
<published>2021-01-25T11:23:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3449831d92fea50b470d5b22435cfeaf15a6dd54'/>
<id>urn:sha1:3449831d92fea50b470d5b22435cfeaf15a6dd54</id>
<content type='text'>
Remove a superfluous semicolon after function definition.

Signed-off-by: Chengyang Fan &lt;cy.fan@huawei.com&gt;
Signed-off-by: Palmer Dabbelt &lt;palmerdabbelt@google.com&gt;
</content>
</entry>
<entry>
<title>riscv: Align on L1_CACHE_BYTES when STRICT_KERNEL_RWX</title>
<updated>2021-02-03T02:36:29+00:00</updated>
<author>
<name>Sebastien Van Cauwenberghe</name>
<email>svancau@gmail.com</email>
</author>
<published>2021-01-29T19:00:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=eefb5f3ab2e8e0b3ef5eba5c5a9f33457741300d'/>
<id>urn:sha1:eefb5f3ab2e8e0b3ef5eba5c5a9f33457741300d</id>
<content type='text'>
Allows the sections to be aligned on smaller boundaries and
therefore results in a smaller kernel image size.

Signed-off-by: Sebastien Van Cauwenberghe &lt;svancau@gmail.com&gt;
Reviewed-by: Atish Patra &lt;atish.patra@wdc.com&gt;
Signed-off-by: Palmer Dabbelt &lt;palmerdabbelt@google.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'riscv-for-linus-5.11-mw0' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux</title>
<updated>2020-12-18T18:43:07+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2020-12-18T18:43:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e2ae634014d3a8839a99f8897b3f6346a133a33b'/>
<id>urn:sha1:e2ae634014d3a8839a99f8897b3f6346a133a33b</id>
<content type='text'>
Pull RISC-V updates from Palmer Dabbelt:
 "We have a handful of new kernel features for 5.11:

   - Support for the contiguous memory allocator.

   - Support for IRQ Time Accounting

   - Support for stack tracing

   - Support for strict /dev/mem

   - Support for kernel section protection

  I'm being a bit conservative on the cutoff for this round due to the
  timing, so this is all the new development I'm going to take for this
  cycle (even if some of it probably normally would have been OK). There
  are, however, some fixes on the list that I will likely be sending
  along either later this week or early next week.

  There is one issue in here: one of my test configurations
  (PREEMPT{,_DEBUG}=y) fails to boot on QEMU 5.0.0 (from April) as of
  the .text.init alignment patch.

  With any luck we'll sort out the issue, but given how many bugs get
  fixed all over the place and how unrelated those features seem my
  guess is that we're just running into something that's been lurking
  for a while and has already been fixed in the newer QEMU (though I
  wouldn't be surprised if it's one of these implicit assumptions we
  have in the boot flow). If it was hardware I'd be strongly inclined to
  look more closely, but given that users can upgrade their simulators
  I'm less worried about it"

* tag 'riscv-for-linus-5.11-mw0' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
  arm64: Use the generic devmem_is_allowed()
  arm: Use the generic devmem_is_allowed()
  RISC-V: Use the new generic devmem_is_allowed()
  lib: Add a generic version of devmem_is_allowed()
  riscv: Fixed kernel test robot warning
  riscv: kernel: Drop unused clean rule
  riscv: provide memmove implementation
  RISC-V: Move dynamic relocation section under __init
  RISC-V: Protect all kernel sections including init early
  RISC-V: Align the .init.text section
  RISC-V: Initialize SBI early
  riscv: Enable ARCH_STACKWALK
  riscv: Make stack walk callback consistent with generic code
  riscv: Cleanup stacktrace
  riscv: Add HAVE_IRQ_TIME_ACCOUNTING
  riscv: Enable CMA support
  riscv: Ignore Image.* and loader.bin
  riscv: Clean up boot dir
  riscv: Fix compressed Image formats build
  RISC-V: Add kernel image sections to the resource tree
</content>
</entry>
<entry>
<title>arch, mm: make kernel_page_present() always available</title>
<updated>2020-12-15T20:13:43+00:00</updated>
<author>
<name>Mike Rapoport</name>
<email>rppt@linux.ibm.com</email>
</author>
<published>2020-12-15T03:10:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=32a0de886eb3cb7e6990da27a9cdfa50baa8be64'/>
<id>urn:sha1:32a0de886eb3cb7e6990da27a9cdfa50baa8be64</id>
<content type='text'>
For architectures that enable ARCH_HAS_SET_MEMORY having the ability to
verify that a page is mapped in the kernel direct map can be useful
regardless of hibernation.

Add RISC-V implementation of kernel_page_present(), update its forward
declarations and stubs to be a part of set_memory API and remove ugly
ifdefery in inlcude/linux/mm.h around current declarations of
kernel_page_present().

Link: https://lkml.kernel.org/r/20201109192128.960-5-rppt@kernel.org
Signed-off-by: Mike Rapoport &lt;rppt@linux.ibm.com&gt;
Acked-by: Kirill A. Shutemov &lt;kirill.shutemov@linux.intel.com&gt;
Cc: Albert Ou &lt;aou@eecs.berkeley.edu&gt;
Cc: Andy Lutomirski &lt;luto@kernel.org&gt;
Cc: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
Cc: Borislav Petkov &lt;bp@alien8.de&gt;
Cc: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Cc: Christian Borntraeger &lt;borntraeger@de.ibm.com&gt;
Cc: Christoph Lameter &lt;cl@linux.com&gt;
Cc: Dave Hansen &lt;dave.hansen@linux.intel.com&gt;
Cc: David Hildenbrand &lt;david@redhat.com&gt;
Cc: David Rientjes &lt;rientjes@google.com&gt;
Cc: "David S. Miller" &lt;davem@davemloft.net&gt;
Cc: "Edgecombe, Rick P" &lt;rick.p.edgecombe@intel.com&gt;
Cc: Heiko Carstens &lt;hca@linux.ibm.com&gt;
Cc: "H. Peter Anvin" &lt;hpa@zytor.com&gt;
Cc: Ingo Molnar &lt;mingo@redhat.com&gt;
Cc: Joonsoo Kim &lt;iamjoonsoo.kim@lge.com&gt;
Cc: Len Brown &lt;len.brown@intel.com&gt;
Cc: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Cc: Palmer Dabbelt &lt;palmer@dabbelt.com&gt;
Cc: Paul Mackerras &lt;paulus@samba.org&gt;
Cc: Paul Walmsley &lt;paul.walmsley@sifive.com&gt;
Cc: Pavel Machek &lt;pavel@ucw.cz&gt;
Cc: Pekka Enberg &lt;penberg@kernel.org&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Cc: "Rafael J. Wysocki" &lt;rjw@rjwysocki.net&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
Cc: Vlastimil Babka &lt;vbabka@suse.cz&gt;
Cc: Will Deacon &lt;will@kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
</feed>
