Re: [PATCH v4 00/11] hugetlb: Factorize hugetlb architecture primitives

: init/do_mounts.o(.text+0x158): cannot reach strncmp hppa64-linux-ld: init/do_mounts.o(.text+0x180): cannot reach strchr ... On 07/26/2018 12:59 PM, Helge Deller wrote: * Alex Ghiti : This is the result of the build for all arches tackled in this series rebased on 4.18-rc6: ... parisc:    

Re: [PATCH v4 00/11] hugetlb: Factorize hugetlb architecture primitives

Does anyone have any suggestion about those patches ? On 07/09/2018 02:16 PM, Michal Hocko wrote: [CC hugetlb guys - http://lkml.kernel.org/r/20180705110716.3919-1-a...@ghiti.fr] On Thu 05-07-18 11:07:05, Alexandre Ghiti wrote: In order to reduce copy/paste of functions across architectures an

Re: [PATCH] hugetlb: fix ARM 3level page tables

Thanks Arnd, this change intervened in v5, that seemed straightforward enough...Sorry about that, and thanks for your fix. Alex On 10/05/2018 04:16 PM, Arnd Bergmann wrote: The check for __HAVE_ARCH_HUGE_PTEP_GET comes before the definition, leading to an extraneous definition of huge_ptep_ge

Re: riscv+KASAN does not boot

Hi Dmitry, Le 2/16/21 à 6:25 AM, Dmitry Vyukov a écrit : On Tue, Feb 16, 2021 at 12:17 PM Dmitry Vyukov wrote: On Fri, Jan 29, 2021 at 9:11 AM Dmitry Vyukov wrote: I was fixing KASAN support for my sv48 patchset so I took a look at your issue: I built a kernel on top of the branch riscv/fix

Re: [PATCH v7] RISC-V: enable XIP

Le 4/9/21 à 2:51 AM, Alexandre Ghiti a écrit : From: 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. T

Re: [PATCH] scripts: checkpatch: Check multiple blank lines when deleting code

On 3/1/19 2:31 PM, Joe Perches wrote: On Thu, 2019-02-28 at 13:15 -0500, Alexandre Ghiti wrote: By matching only current line starting with '+', we miss the case when deleting code makes consecutive blank lines appear: this patch then makes it possible to detect this case by also matching curren

Re: [PATCH v3 02/11] arm64: Make use of is_compat_task instead of hardcoding this test

On 4/18/19 12:32 AM, Kees Cook wrote: On Wed, Apr 17, 2019 at 12:25 AM Alexandre Ghiti wrote: Each architecture has its own way to determine if a task is a compat task, by using is_compat_task in arch_mmap_rnd, it allows more genericity and then it prepares its moving to mm/. Signed-off-by: Al

Re: [PATCH v3 03/11] arm64: Consider stack randomization for mmap base only when necessary

On 4/18/19 12:37 AM, Kees Cook wrote: On Wed, Apr 17, 2019 at 12:26 AM Alexandre Ghiti wrote: Do not offset mmap base address because of stack randomization if current task does not want randomization. Maybe mention that this makes this logic match the existing x86 behavior too? Ok I will a

Re: [PATCH v3 04/11] arm64, mm: Move generic mmap layout functions to mm

On 4/18/19 1:17 AM, Kees Cook wrote: ( On Wed, Apr 17, 2019 at 12:27 AM Alexandre Ghiti wrote: arm64 handles top-down mmap layout in a way that can be easily reused by other architectures, so make it available in mm. It then introduces a new config ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT that ca

Re: [PATCH v3 05/11] arm: Properly account for stack randomization and stack guard gap

On 4/18/19 1:26 AM, Kees Cook wrote: On Wed, Apr 17, 2019 at 12:28 AM Alexandre Ghiti wrote: This commit takes care of stack randomization and stack guard gap when computing mmap base address and checks if the task asked for randomization. This fixes the problem uncovered and not fixed for arm

Re: [PATCH v3 06/11] arm: Use STACK_TOP when computing mmap base address

On 4/18/19 1:27 AM, Kees Cook wrote: On Wed, Apr 17, 2019 at 12:29 AM Alexandre Ghiti wrote: mmap base address must be computed wrt stack top address, using TASK_SIZE is wrong since STACK_TOP and TASK_SIZE are not equivalent. Signed-off-by: Alexandre Ghiti --- arch/arm/mm/mmap.c | 4 ++--

Re: [PATCH v3 07/11] arm: Use generic mmap top-down layout

On 4/18/19 1:28 AM, Kees Cook wrote: On Wed, Apr 17, 2019 at 12:30 AM Alexandre Ghiti wrote: arm uses a top-down mmap layout by default that exactly fits the generic functions, so get rid of arch specific code and use the generic version by selecting ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT. Sign

Re: [PATCH v3 08/11] mips: Properly account for stack randomization and stack guard gap

On 4/18/19 1:30 AM, Kees Cook wrote: On Wed, Apr 17, 2019 at 12:31 AM Alexandre Ghiti wrote: This commit takes care of stack randomization and stack guard gap when computing mmap base address and checks if the task asked for randomization. This fixes the problem uncovered and not fixed for mips

Re: [PATCH v3 09/11] mips: Use STACK_TOP when computing mmap base address

On 4/18/19 1:31 AM, Kees Cook wrote: On Wed, Apr 17, 2019 at 12:32 AM Alexandre Ghiti wrote: mmap base address must be computed wrt stack top address, using TASK_SIZE is wrong since STACK_TOP and TASK_SIZE are not equivalent. Signed-off-by: Alexandre Ghiti Acked-by: Kees Cook Thanks !

Re: [PATCH v3 10/11] mips: Use generic mmap top-down layout

On 4/18/19 1:31 AM, Kees Cook wrote: On Wed, Apr 17, 2019 at 12:33 AM Alexandre Ghiti wrote: mips uses a top-down layout by default that fits the generic functions. At the same time, this commit allows to fix problem uncovered and not fixed for mips here: https://www.mail-archive.com/linux-kern

Re: [PATCH v3 11/11] riscv: Make mmap allocation top-down by default

On 4/18/19 1:31 AM, Kees Cook wrote: On Wed, Apr 17, 2019 at 12:34 AM Alexandre Ghiti wrote: In order to avoid wasting user address space by using bottom-up mmap allocation scheme, prefer top-down scheme when possible. Before: root@qemuriscv64:~# cat /proc/self/maps 0001-00016000 r-xp

Re: [PATCH v2 2/2] riscv: Introduce huge page support for 32/64bit kernel

On 4/25/19 1:42 PM, Palmer Dabbelt wrote: On Mon, 08 Apr 2019 23:14:49 PDT (-0700), a...@ghiti.fr wrote: This patch implements both 4MB huge page support for 32bit kernel and 2MB/1GB huge pages support for 64bit kernel. Signed-off-by: Alexandre Ghiti ---  arch/riscv/Kconfig   |  8

Re: [PATCH] hugetlb: allow to free gigantic pages regardless of the configuration

On 2/5/19 6:23 AM, Michael Ellerman wrote: Alexandre Ghiti writes: From: Alexandre Ghiti On systems without CMA or (MEMORY_ISOLATION && COMPACTION) activated but that support gigantic pages, boottime reserved gigantic pages can not be freed at all. This patchs simply enables the possibility

Re: [PATCH v2 1/1] riscv/kasan: add KASAN_VMALLOC support

Hi Nylon, Palmer, Le 2/8/21 à 1:28 AM, Alex Ghiti a écrit : Hi Nylon, Le 1/22/21 à 10:56 PM, Palmer Dabbelt a écrit : On Fri, 15 Jan 2021 21:58:35 PST (-0800), nyl...@andestech.com wrote: It references to x86/s390 architecture. >> So, it doesn't map the early shadow page to co

Re: [PATCH] riscv: Pass virtual addresses to kasan_mem_to_shadow

Hi Palmer, Le 2/22/21 à 9:58 PM, Palmer Dabbelt a écrit : On Mon, 22 Feb 2021 00:07:34 PST (-0800), a...@ghiti.fr wrote: kasan_mem_to_shadow translates virtual addresses to kasan shadow addresses whereas for_each_mem_range returns physical addresses: it is then required to use __va on those add

Re: [PATCH] riscv: mm: Remove the copy operation of pmd

Le 3/30/20 à 7:53 AM, Chuanhua Han a écrit : Since all processes share the kernel address space, we only need to copy pgd in case of a vmalloc page fault exception, the other levels of page tables are shared, so the operation of copying pmd is unnecessary. Signed-off-by: Chuanhua Han --- arch

Re: [PATCH v2 1/1] riscv/kasan: add KASAN_VMALLOC support

Hi Nylon, Le 2/22/21 à 12:13 PM, Alex Ghiti a écrit : Le 2/21/21 à 8:37 PM, Nylon Chen a écrit : Hi Alex, Palmer Sorry I missed this message. On Sun, Feb 21, 2021 at 09:38:04PM +0800, Alex Ghiti wrote: Le 2/13/21 à 5:52 AM, Alex Ghiti a écrit : Hi Nylon, Palmer, Le 2/8/21 à 1:28 AM, Alex

Re: [PATCH] riscv: Add KASAN_VMALLOC support

Le 2/25/21 à 2:42 AM, Alexandre Ghiti a écrit : Populate the top-level of the kernel page table to implement KASAN_VMALLOC, lower levels are filled dynamically upon memory allocation at runtime. Co-developed-by: Nylon Chen Signed-off-by: Nylon Chen Co-developed-by: Nick Hu Signed-off-by: Nick

Re: riscv+KASAN does not boot

Le 2/16/21 à 11:42 PM, Dmitry Vyukov a écrit : On Tue, Feb 16, 2021 at 9:42 PM Alex Ghiti wrote: Hi Dmitry, Le 2/16/21 à 6:25 AM, Dmitry Vyukov a écrit : On Tue, Feb 16, 2021 at 12:17 PM Dmitry Vyukov wrote: On Fri, Jan 29, 2021 at 9:11 AM Dmitry Vyukov wrote: I was fixing KASAN

Re: riscv+KASAN does not boot

Hi Dmitry, On Wed, Feb 17, 2021 at 5:36 PM Alex Ghiti wrote: Le 2/16/21 à 11:42 PM, Dmitry Vyukov a écrit : On Tue, Feb 16, 2021 at 9:42 PM Alex Ghiti wrote: Hi Dmitry, Le 2/16/21 à 6:25 AM, Dmitry Vyukov a écrit : On Tue, Feb 16, 2021 at 12:17 PM Dmitry Vyukov wrote: On Fri, Jan 29

Re: riscv+KASAN does not boot

Hi Dmitry, On 1/18/21 10:43 AM, Dmitry Vyukov wrote: On Mon, Jan 18, 2021 at 4:05 PM Dmitry Vyukov wrote: On Mon, Jan 18, 2021 at 3:53 PM Tobias Klauser wrote: On Thu, Jan 14, 2021 at 5:57 AM Palmer Dabbelt wrote: On Fri, 25 Dec 2020 09:13:23 PST (-0800), dvyu...@google.com wrote: On Fr

Re: [RFC PATCH 00/12] Introduce sv48 support without relocable kernel

Hi Palmer, On 1/4/21 2:58 PM, Alexandre Ghiti wrote: This patchset, contrary to the previous versions, allows to have a single kernel for sv39 and sv48 without being relocatable. The idea comes from Arnd Bergmann

Re: [PATCH] riscv: kasan: remove unneeded semicolon

Hi Yang, Le 2/2/21 à 12:51 AM, Yang Li a écrit : Eliminate the following coccicheck warning: ./arch/riscv/mm/kasan_init.c:103:2-3: Unneeded semicolon Reported-by: Abaci Robot Signed-off-by: Yang Li --- arch/riscv/mm/kasan_init.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -

Re: [PATCH] riscv: Improve kasan population by using hugepages when possible

Hi, Le 2/1/21 à 3:00 AM, Alexandre Ghiti a écrit : Kasan function that populates the shadow regions used to allocate them page by page and did not take advantage of hugepages, so fix this by trying to allocate hugepages of 1GB and fallback to 2MB hugepages or 4K pages in case it fails. This red

Re: [PATCH] riscv: Improve kasan population by using hugepages when possible

Le 2/2/21 à 3:50 AM, Alex Ghiti a écrit : Hi, Le 2/1/21 à 3:00 AM, Alexandre Ghiti a écrit : Kasan function that populates the shadow regions used to allocate them page by page and did not take advantage of hugepages, so fix this by trying to allocate hugepages of 1GB and fallback to 2MB

Re: [PATCH 2/3] Documentation: riscv: Add documentation that describes the VM layout

Le 2/25/21 à 5:34 AM, David Hildenbrand a écrit : |    |  | |> + ffc0 | -256    GB | ffc7 |   32 GB | kasan +   ffcefee0 | -196    GB | ffcefeff |    2 MB | fixmap +   ffceff00 | -196    GB | ff

Re: [PATCH] riscv: Add KASAN_VMALLOC support

Hi Palmer, Le 2/26/21 à 12:32 AM, Palmer Dabbelt a écrit : On Wed, 24 Feb 2021 23:48:13 PST (-0800), a...@ghiti.fr wrote: Le 2/25/21 à 2:42 AM, Alexandre Ghiti a écrit : Populate the top-level of the kernel page table to implement KASAN_VMALLOC, lower levels are filled dynamically upon memory

Re: [RFC PATCH 1/8] RISC-V: Enable CPU_IDLE drivers

Hi Anup, Le 2/21/21 à 4:37 AM, Anup Patel a écrit : We force select CPU_PM and provide asm/cpuidle.h so that we can use CPU IDLE drivers for Linux RISC-V kernel. Signed-off-by: Anup Patel --- arch/riscv/Kconfig| 7 +++ arch/riscv/configs/defconfig | 7 +++ ar

Re: [PATCH] Insert SFENCE.VMA in function set_pte_at for RISCV

as anything but a last resort. On Tue, Mar 16, 2021 at 10:03 PM Andrew Waterman wrote: On Tue, Mar 16, 2021 at 5:05 AM Alex Ghiti wrote: Le 3/16/21 à 4:40 AM, Anup Patel a écrit : On Tue, Mar 16, 2021 at 1:59 PM Andrew Waterman wrote: On Tue, Mar 16, 2021 at 12:32 AM Anup Patel wrote:

Re: [PATCH 0/3] Move kernel mapping outside the linear mapping

Le 3/9/21 à 9:54 PM, Palmer Dabbelt a écrit : On Thu, 25 Feb 2021 00:04:50 PST (-0800), a...@ghiti.fr wrote: I decided to split sv48 support in small series to ease the review. This patchset pushes the kernel mapping (modules and BPF too) to the last 4GB of the 64bit address space, this allows

Re: [PATCH v6] RISC-V: enable XIP

Le 3/30/21 à 2:26 AM, Vitaly Wool a écrit : On Tue, Mar 30, 2021 at 8:23 AM Palmer Dabbelt wrote: On Sun, 21 Mar 2021 17:12:15 PDT (-0700), vitaly.w...@konsulko.com wrote: Introduce XIP (eXecute In Place) support for RISC-V platforms. It allows code to be executed directly from non-volatil

Re: [PATCH v6] RISC-V: enable XIP

Le 3/30/21 à 3:33 PM, Palmer Dabbelt a écrit : On Tue, 30 Mar 2021 11:39:10 PDT (-0700), a...@ghiti.fr wrote: Le 3/30/21 à 2:26 AM, Vitaly Wool a écrit : On Tue, Mar 30, 2021 at 8:23 AM Palmer Dabbelt wrote: On Sun, 21 Mar 2021 17:12:15 PDT (-0700), vitaly.w...@konsulko.com wrote: Introd

Re: [PATCH v5] RISC-V: enable XIP

Hi Vitaly, Le 3/10/21 à 4:22 AM, Vitaly Wool a écrit : 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 w

Re: [PATCH v5] RISC-V: enable XIP

Le 3/21/21 à 2:06 PM, Vitaly Wool a écrit : Hey Alex, On Sun, Mar 21, 2021 at 4:11 PM Alex Ghiti wrote: Hi Vitaly, Le 3/10/21 à 4:22 AM, Vitaly Wool a écrit : Introduce XIP (eXecute In Place) support for RISC-V platforms. It allows code to be executed directly from non-volatile storage

Re: [PATCH] Insert SFENCE.VMA in function set_pte_at for RISCV

Le 3/16/21 à 4:40 AM, Anup Patel a écrit : On Tue, Mar 16, 2021 at 1:59 PM Andrew Waterman wrote: On Tue, Mar 16, 2021 at 12:32 AM Anup Patel wrote: On Tue, Mar 16, 2021 at 12:27 PM Jiuyang Liu wrote: As per my understanding, we don't need to explicitly invalidate local TLB in set_pte()

Re: [PATCH] implement flush_cache_vmap and flush_cache_vunmap for RISC-V

Hi Jiuyang, Le 3/28/21 à 9:55 PM, Jiuyang Liu a écrit : This patch implements flush_cache_vmap and flush_cache_vunmap for RISC-V, since these functions might modify PTE. Without this patch, SFENCE.VMA won't be added to related codes, which might introduce a bug in some out-of-order micro-archite

Re: [PATCH v4 3/5] RISC-V: Initial DTS for Microchip ICICLE board

Hi Atish, Le 3/3/21 à 3:02 PM, Atish Patra a écrit : Add initial DTS for Microchip ICICLE board having only essential devices (clocks, sdhci, ethernet, serial, etc). The device tree is based on the U-Boot patch. https://patchwork.ozlabs.org/project/uboot/patch/20201110103414.10142-6-padmarao.be

Re: [PATCH v5 1/3] riscv: Move kernel mapping outside of linear mapping

Le 4/15/21 à 12:54 AM, Alex Ghiti a écrit : Le 4/15/21 à 12:20 AM, Palmer Dabbelt a écrit : On Sun, 11 Apr 2021 09:41:44 PDT (-0700), a...@ghiti.fr wrote: This is a preparatory patch for relocatable kernel and sv48 support. The kernel used to be linked at PAGE_OFFSET address therefore we

Re: [PATCH] riscv: Protect kernel linear mapping only if CONFIG_STRICT_KERNEL_RWX is set

Hi Anup, Le 4/16/21 à 6:41 AM, Anup Patel a écrit : On Thu, Apr 15, 2021 at 4:34 PM Alexandre Ghiti wrote: If CONFIG_STRICT_KERNEL_RWX is not set, we cannot set different permissions to the kernel data and text sections, so make sure it is defined before trying to protect the kernel linear ma

Re: [PATCH v8] RISC-V: enable XIP

Le 4/13/21 à 2:35 AM, Alexandre Ghiti a écrit : From: 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.

Re: [PATCH] implement flush_cache_vmap for RISC-V

Hi, Le 4/12/21 à 3:08 AM, Jisheng Zhang a écrit : Hi Jiuyang, On Mon, 12 Apr 2021 00:05:30 + Jiuyang Liu wrote: This patch implements flush_cache_vmap for RISC-V, since it modifies PTE. Without this patch, SFENCE.VMA won't be added to related codes, which might introduce a bug in the o

Re: [PATCH v5 1/3] riscv: Move kernel mapping outside of linear mapping

Le 4/15/21 à 12:20 AM, Palmer Dabbelt a écrit : On Sun, 11 Apr 2021 09:41:44 PDT (-0700), a...@ghiti.fr wrote: 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 mapp

Re: [PATCH] driver: of: Properly truncate command line if too long

Le 4/6/21 à 9:40 AM, Rob Herring a écrit : On Sat, Apr 3, 2021 at 7:09 AM Alex Ghiti wrote: Hi, Le 3/16/21 à 3:38 PM, Alexandre Ghiti a écrit : In case the command line given by the user is too long, warn about it and truncate it to the last full argument. This is what efi already does in

Re: [PATCH v6] RISC-V: enable XIP

Le 4/6/21 à 3:54 AM, Vitaly Wool a écrit : On Tue, Apr 6, 2021 at 8:47 AM Alex Ghiti wrote: Hi Vitaly, Le 4/5/21 à 4:34 AM, Vitaly Wool a écrit : On Sun, Apr 4, 2021 at 10:39 AM Vitaly Wool wrote: On Sat, Apr 3, 2021 at 12:00 PM Alex Ghiti wrote: Hi Vitaly, Le 4/1/21 à 7:10 AM

Re: [PATCH v3 4/5] RISC-V: Add kdump support

Hi Nick, Le 4/5/21 à 4:57 AM, Nick Kossifidis a écrit : This patch adds support for kdump, the kernel will reserve a region for the crash kernel and jump there on panic. In order for userspace tools (kexec-tools) to prepare the crash kernel kexec image, we also need to expose some information on

Re: [PATCH v3 2/5] RISC-V: Add kexec support

Le 4/5/21 à 4:57 AM, Nick Kossifidis a écrit : This patch adds support for kexec on RISC-V. On SMP systems it depends on HOTPLUG_CPU in order to be able to bring up all harts after kexec. It also needs a recent OpenSBI version that supports the HSM extension. I tested it on riscv64 QEMU on both

Re: [PATCH] driver: of: Properly truncate command line if too long

Hi Andy, Le 4/6/21 à 6:56 PM, Andy Shevchenko a écrit : On Tuesday, March 16, 2021, Alexandre Ghiti > wrote: In case the command line given by the user is too long, warn about it and truncate it to the last full argument. This is what efi already does in co

Re: [PATCH v6] RISC-V: enable XIP

Hi, Le 3/30/21 à 4:04 PM, Alex Ghiti a écrit : Le 3/30/21 à 3:33 PM, Palmer Dabbelt a écrit : On Tue, 30 Mar 2021 11:39:10 PDT (-0700), a...@ghiti.fr wrote: Le 3/30/21 à 2:26 AM, Vitaly Wool a écrit : On Tue, Mar 30, 2021 at 8:23 AM Palmer Dabbelt wrote: On Sun, 21 Mar 2021 17:12:15 PDT

Re: [PATCH v6] RISC-V: enable XIP

Le 4/1/21 à 4:52 AM, Vitaly Wool a écrit : Hi Alex, On Thu, Apr 1, 2021 at 10:11 AM Alex Ghiti wrote: Hi, Le 3/30/21 à 4:04 PM, Alex Ghiti a écrit : Le 3/30/21 à 3:33 PM, Palmer Dabbelt a écrit : On Tue, 30 Mar 2021 11:39:10 PDT (-0700), a...@ghiti.fr wrote: Le 3/30/21 à 2:26 AM

Re: [PATCH v4 1/3] riscv: Move kernel mapping outside of linear mapping

Hi Guenter, Le 4/16/21 à 2:51 PM, Guenter Roeck a écrit : On Fri, Apr 09, 2021 at 02:14:58AM -0400, Alexandre Ghiti wrote: 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

Re: [PATCH] riscv: Protect kernel linear mapping only if CONFIG_STRICT_KERNEL_RWX is set

Le 4/16/21 à 12:33 PM, Palmer Dabbelt a écrit : On Fri, 16 Apr 2021 03:47:19 PDT (-0700), a...@ghiti.fr wrote: Hi Anup, Le 4/16/21 à 6:41 AM, Anup Patel a écrit : On Thu, Apr 15, 2021 at 4:34 PM Alexandre Ghiti wrote: If CONFIG_STRICT_KERNEL_RWX is not set, we cannot set different permissi

Re: [PATCH v5 1/3] riscv: Move kernel mapping outside of linear mapping

Hi Palmer, Le 4/15/21 à 2:00 PM, Alex Ghiti a écrit : Le 4/15/21 à 12:54 AM, Alex Ghiti a écrit : Le 4/15/21 à 12:20 AM, Palmer Dabbelt a écrit : On Sun, 11 Apr 2021 09:41:44 PDT (-0700), a...@ghiti.fr wrote: This is a preparatory patch for relocatable kernel and sv48 support. The kernel

Re: [PATCH v7] RISC-V: enable XIP

Hi David, Le 4/9/21 à 4:23 AM, David Hildenbrand a écrit : On 09.04.21 09:14, Alex Ghiti wrote: Le 4/9/21 à 2:51 AM, Alexandre Ghiti a écrit : From: Vitaly Wool Introduce XIP (eXecute In Place) support for RISC-V platforms. It allows code to be executed directly from non-volatile storage

Re: [PATCH v7] RISC-V: enable XIP

Le 4/9/21 à 8:07 AM, David Hildenbrand a écrit : On 09.04.21 13:39, Alex Ghiti wrote: Hi David, Le 4/9/21 à 4:23 AM, David Hildenbrand a écrit : On 09.04.21 09:14, Alex Ghiti wrote: Le 4/9/21 à 2:51 AM, Alexandre Ghiti a écrit : From: Vitaly Wool Introduce XIP (eXecute In Place) support

Re: [PATCH v7] RISC-V: enable XIP

Le 4/9/21 à 10:42 AM, Vitaly Wool a écrit : On Fri, Apr 9, 2021 at 3:59 PM Mike Rapoport wrote: On Fri, Apr 09, 2021 at 02:46:17PM +0200, David Hildenbrand wrote: Also, will that memory properly be exposed in the resource tree as System RAM (e.g., /proc/iomem) ? Otherwise some things (/proc/k

Re: [PATCH v6] RISC-V: enable XIP

Hi Vitaly, Le 4/1/21 à 7:10 AM, Alex Ghiti a écrit : Le 4/1/21 à 4:52 AM, Vitaly Wool a écrit : Hi Alex, On Thu, Apr 1, 2021 at 10:11 AM Alex Ghiti wrote: Hi, Le 3/30/21 à 4:04 PM, Alex Ghiti a écrit : Le 3/30/21 à 3:33 PM, Palmer Dabbelt a écrit : On Tue, 30 Mar 2021 11:39:10 PDT

Re: [PATCH] driver: of: Properly truncate command line if too long

Hi, Le 3/16/21 à 3:38 PM, Alexandre Ghiti a écrit : In case the command line given by the user is too long, warn about it and truncate it to the last full argument. This is what efi already does in commit 80b1bfe1cb2f ("efi/libstub: Don't parse overlong command lines"). Reported-by: Dmitry Vyu

Re: [PATCH v6] RISC-V: enable XIP

Hi Vitaly, Le 4/5/21 à 4:34 AM, Vitaly Wool a écrit : On Sun, Apr 4, 2021 at 10:39 AM Vitaly Wool wrote: On Sat, Apr 3, 2021 at 12:00 PM Alex Ghiti wrote: Hi Vitaly, Le 4/1/21 à 7:10 AM, Alex Ghiti a écrit : Le 4/1/21 à 4:52 AM, Vitaly Wool a écrit : Hi Alex, On Thu, Apr 1, 2021 at 10

Re: riscv+KASAN does not boot

Hi Dmitry, Le 2/18/21 à 6:36 AM, Dmitry Vyukov a écrit : On Thu, Feb 18, 2021 at 8:54 AM Alex Ghiti wrote: Hi Dmitry, On Wed, Feb 17, 2021 at 5:36 PM Alex Ghiti wrote: Le 2/16/21 à 11:42 PM, Dmitry Vyukov a écrit : On Tue, Feb 16, 2021 at 9:42 PM Alex Ghiti wrote: Hi Dmitry, Le 2

Re: [PATCH v2 1/1] riscv/kasan: add KASAN_VMALLOC support

Le 2/13/21 à 5:52 AM, Alex Ghiti a écrit : Hi Nylon, Palmer, Le 2/8/21 à 1:28 AM, Alex Ghiti a écrit : Hi Nylon, Le 1/22/21 à 10:56 PM, Palmer Dabbelt a écrit : On Fri, 15 Jan 2021 21:58:35 PST (-0800), nyl...@andestech.com wrote: It references to x86/s390 architecture. >> So, it d

Re: [PATCH 0/4] Kasan improvements and fixes

Hi, Le 2/8/21 à 2:30 PM, Alexandre Ghiti a écrit : This small series contains some improvements for the riscv KASAN code: - it brings a better readability of the code (patch 1/2) - it fixes oversight regarding page table population which I uncovered while working on my sv48 patchset (patch 3

Re: [PATCH] riscv: Get rid of MAX_EARLY_MAPPING_SIZE

Hi Dmitry, Le 2/21/21 à 10:38 AM, Dmitry Vyukov a écrit : On Sun, Feb 21, 2021 at 3:22 PM Alexandre Ghiti wrote: At early boot stage, we have a whole PGDIR to map the kernel, so there is no need to restrict the early mapping size to 128MB. Removing this define also allows us to simplify some

Re: [PATCH] riscv: Get rid of MAX_EARLY_MAPPING_SIZE

Le 2/22/21 à 12:40 AM, Alex Ghiti a écrit : Hi Dmitry, Le 2/21/21 à 10:38 AM, Dmitry Vyukov a écrit : On Sun, Feb 21, 2021 at 3:22 PM Alexandre Ghiti wrote: At early boot stage, we have a whole PGDIR to map the kernel, so there is no need to restrict the early mapping size to 128MB

Re: [PATCH v2 1/1] riscv/kasan: add KASAN_VMALLOC support

Le 2/21/21 à 8:37 PM, Nylon Chen a écrit : Hi Alex, Palmer Sorry I missed this message. On Sun, Feb 21, 2021 at 09:38:04PM +0800, Alex Ghiti wrote: Le 2/13/21 à 5:52 AM, Alex Ghiti a écrit : Hi Nylon, Palmer, Le 2/8/21 à 1:28 AM, Alex Ghiti a écrit : Hi Nylon, Le 1/22/21 à 10:56 PM, Palmer

Re: [syzbot] BUG: unable to handle kernel access to user memory in schedule_tail

Le 3/12/21 à 10:12 AM, Dmitry Vyukov a écrit : On Fri, Mar 12, 2021 at 2:50 PM Ben Dooks wrote: On 10/03/2021 17:16, Dmitry Vyukov wrote: On Wed, Mar 10, 2021 at 5:46 PM syzbot wrote: Hello, syzbot found the following issue on: HEAD commit:0d7588ab riscv: process: Fix no prototype

Re: [PATCH 2/3] Documentation: riscv: Add documentation that describes the VM layout

Hi Arnd, Le 3/11/21 à 3:42 AM, Arnd Bergmann a écrit : On Wed, Mar 10, 2021 at 8:12 PM Alex Ghiti wrote: Le 3/10/21 à 6:42 AM, Arnd Bergmann a écrit : On Thu, Feb 25, 2021 at 12:56 PM Alex Ghiti wrote: Le 2/25/21 à 5:34 AM, David Hildenbrand a écrit

Re: [PATCH 0/3] Move kernel mapping outside the linear mapping

Hi Palmer, Le 3/9/21 à 9:54 PM, Palmer Dabbelt a écrit : On Thu, 25 Feb 2021 00:04:50 PST (-0800), a...@ghiti.fr wrote: I decided to split sv48 support in small series to ease the review. This patchset pushes the kernel mapping (modules and BPF too) to the last 4GB of the 64bit address space,

Re: [PATCH 2/3] Documentation: riscv: Add documentation that describes the VM layout

Hi Arnd, Le 3/10/21 à 6:42 AM, Arnd Bergmann a écrit : On Thu, Feb 25, 2021 at 12:56 PM Alex Ghiti wrote: Le 2/25/21 à 5:34 AM, David Hildenbrand a écrit : || | |> + ffc0 | -256GB | ffc7 | 32 GB | ka

Re: [PATCH v2] riscv: Improve KASAN_VMALLOC support

Le 3/9/21 à 9:37 PM, Palmer Dabbelt a écrit : On Fri, 26 Feb 2021 10:01:54 PST (-0800), a...@ghiti.fr wrote: When KASAN vmalloc region is populated, there is no userspace process and the page table in use is swapper_pg_dir, so there is no need to read SATP. Then we can use the same scheme used b

Re: [syzbot] BUG: unable to handle kernel access to user memory in schedule_tail

Hi Ben, Le 3/10/21 à 5:24 PM, Ben Dooks a écrit : On 10/03/2021 17:16, Dmitry Vyukov wrote: On Wed, Mar 10, 2021 at 5:46 PM syzbot wrote: Hello, syzbot found the following issue on: HEAD commit:    0d7588ab riscv: process: Fix no prototype for arch_dup_tas.. git tree: git://git.ker

Re: riscv+KASAN does not boot

Le 3/9/21 à 12:11 PM, Dmitry Vyukov a écrit : On Fri, Feb 19, 2021 at 11:26 PM 'Palmer Dabbelt' via syzkaller wrote: On Fri, 19 Feb 2021 10:53:43 PST (-0800), dvyu...@google.com wrote: On Fri, Feb 19, 2021 at 6:01 PM Alex Ghiti wrote: Hi Dmitry, Le 2/18/21 à 6:36 AM, Dmitr

Re: [PATCH v2 1/1] riscv/kasan: add KASAN_VMALLOC support

Hi Nylon, Le 1/22/21 à 10:56 PM, Palmer Dabbelt a écrit : On Fri, 15 Jan 2021 21:58:35 PST (-0800), nyl...@andestech.com wrote: It references to x86/s390 architecture. >> So, it doesn't map the early shadow page to cover VMALLOC space. Prepopulate top level page table for the range that would

Re: [RFC PATCH 01/12] riscv: Move kernel mapping outside of linear mapping

Hi Anup, Le 1/5/21 à 6:40 AM, Anup Patel a écrit : On Tue, Jan 5, 2021 at 1:29 AM Alexandre Ghiti wrote: 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.

Re: [RFC PATCH 04/12] riscv: Allow to dynamically define VA_BITS

Le 1/5/21 à 7:06 AM, Anup Patel a écrit : On Tue, Jan 5, 2021 at 1:33 AM Alexandre Ghiti wrote: With 4-level page table folding at runtime, we don't know at compile time the size of the virtual address space so we must set VA_BITS dynamically so that sparsemem reserves the right amount of m

Re: [RFC PATCH 01/12] riscv: Move kernel mapping outside of linear mapping

Le 1/6/21 à 1:44 AM, Anup Patel a écrit : On Wed, Jan 6, 2021 at 12:06 PM Alex Ghiti wrote: Hi Anup, Le 1/5/21 à 6:40 AM, Anup Patel a écrit : On Tue, Jan 5, 2021 at 1:29 AM Alexandre Ghiti wrote: This is a preparatory patch for relocatable kernel and sv48 support. The kernel used to

Re: [PATCH] scripts: checkpatch: Check block comments start with /* empty line outside net

On 3/6/19 7:12 AM, Alexandre Ghiti wrote: Le 3/6/19 à 12:08 AM, Joe Perches a écrit : On Tue, 2019-03-05 at 13:02 -0500, Alexandre Ghiti wrote: This patch ensures that apart from net code, block comments start with an empty /* line. I'm not sure it's useful to try to eliminate these types of

Re: [PATCH v3] scripts: checkpatch: Check multiple blank lines when deleting code

On 3/6/19 2:53 PM, Alexandre Ghiti wrote: By matching only current line starting with '+', we miss the case when deleting code makes consecutive blank lines appear: this patch then makes it possible to detect this case by also matching current line starting with ' ', which is an already existing

Re: [PATCH RESEND 0/8] Fix mmap base in bottom-up mmap

On 8/26/19 6:37 PM, Helge Deller wrote: On 26.08.19 09:34, Alexandre Ghiti wrote: On 6/20/19 7:03 AM, Alexandre Ghiti wrote: This series fixes the fallback of the top-down mmap: in case of failure, a bottom-up scheme can be tried as a last resort between the top-down mmap base and the stack, ho

Re: [PATCH v6 14/14] riscv: Make mmap allocation top-down by default

On 10/7/19 5:11 AM, Alex Ghiti wrote: On 10/4/19 10:12 PM, Atish Patra wrote: On Thu, 2019-08-08 at 02:17 -0400, Alexandre Ghiti wrote: In order to avoid wasting user address space by using bottom-up mmap allocation scheme, prefer top-down scheme when possible. Before: root@qemuriscv64:~# cat

Re: [PATCH v11 07/22] riscv: mm: Add p?d_leaf() definitions

On 10/7/19 11:38 AM, Steven Price wrote: 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

Re: [PATCH v6 14/14] riscv: Make mmap allocation top-down by default

On 10/7/19 8:46 PM, Atish Patra wrote: On Mon, 2019-10-07 at 05:11 -0400, Alex Ghiti wrote: On 10/4/19 10:12 PM, Atish Patra wrote: On Thu, 2019-08-08 at 02:17 -0400, Alexandre Ghiti wrote: In order to avoid wasting user address space by using bottom-up mmap allocation scheme, prefer top-down

Re: [PATCH v6 14/14] riscv: Make mmap allocation top-down by default

On 10/8/19 10:07 PM, Atish Patra wrote: On Tue, 2019-10-08 at 07:58 -0400, Alex Ghiti wrote: On 10/7/19 8:46 PM, Atish Patra wrote: On Mon, 2019-10-07 at 05:11 -0400, Alex Ghiti wrote: On 10/4/19 10:12 PM, Atish Patra wrote: On Thu, 2019-08-08 at 02:17 -0400, Alexandre Ghiti wrote: In order

Re: [PATCH v6 14/14] riscv: Make mmap allocation top-down by default

On 10/4/19 10:12 PM, Atish Patra wrote: On Thu, 2019-08-08 at 02:17 -0400, Alexandre Ghiti wrote: In order to avoid wasting user address space by using bottom-up mmap allocation scheme, prefer top-down scheme when possible. Before: root@qemuriscv64:~# cat /proc/self/maps 0001-00016000 r-xp

Re: [PATCH] hugetlb: allow to free gigantic pages regardless of the configuration

On 1/17/19 1:39 PM, Alexandre Ghiti wrote: From: Alexandre Ghiti On systems without CMA or (MEMORY_ISOLATION && COMPACTION) activated but that support gigantic pages, boottime reserved gigantic pages can not be freed at all. This patchs simply enables the possibility to hand back those pages to

Re: [PATCH REBASE v2 1/2] x86, arm64: Move ARCH_WANT_HUGE_PMD_SHARE config in arch/Kconfig

On 5/26/19 10:42 AM, Ingo Molnar wrote: * Alexandre Ghiti wrote: ARCH_WANT_HUGE_PMD_SHARE config was declared in both architectures: move this declaration in arch/Kconfig and make those architectures select it. Signed-off-by: Alexandre Ghiti Reviewed-by: Palmer Dabbelt --- arch/Kconfig

Re: [PATCH v3 08/11] mips: Properly account for stack randomization and stack guard gap

On 4/18/19 5:27 PM, Paul Burton wrote: Hi Alexandre, On Wed, Apr 17, 2019 at 01:22:44AM -0400, Alexandre Ghiti wrote: This commit takes care of stack randomization and stack guard gap when computing mmap base address and checks if the task asked for randomization. This fixes the problem uncover

Re: [PATCH v3 04/11] arm64, mm: Move generic mmap layout functions to mm

On 4/18/19 10:19 AM, Kees Cook wrote: On Thu, Apr 18, 2019 at 12:55 AM Alex Ghiti wrote: Regarding the help text, I agree that it does not seem to be frequent to place comment above config like that, I'll let Christoph and you decide what's best. And I'll add the possibility

Re: [PATCH v3 04/11] arm64, mm: Move generic mmap layout functions to mm

On 4/18/19 10:19 AM, Kees Cook wrote: On Thu, Apr 18, 2019 at 12:55 AM Alex Ghiti wrote: Regarding the help text, I agree that it does not seem to be frequent to place comment above config like that, I'll let Christoph and you decide what's best. And I'll add the possibility

Re: [PATCH v5 14/14] riscv: Make mmap allocation top-down by default

On 7/30/19 1:51 AM, Alexandre Ghiti wrote: In order to avoid wasting user address space by using bottom-up mmap allocation scheme, prefer top-down scheme when possible. Before: root@qemuriscv64:~# cat /proc/self/maps 0001-00016000 r-xp fe:00 6389 /bin/cat.coreutils 00016000-00

Re: [PATCH RESEND 1/8] s390: Start fallback of top-down mmap at mm->mmap_base

Really sorry about that, my connection is weird this morning, I'll retry tomorrow. Sorry again, Alex On 6/19/19 1:42 AM, Alexandre Ghiti wrote: In case of mmap failure in top-down mode, there is no need to go through the whole address space again for the bottom-up fallback: the goal of this f

Re: [PATCH RESEND 6/8] parisc: Use mmap_base, not mmap_legacy_base, as low_limit for bottom-up mmap

On 6/25/19 10:09 AM, Helge Deller wrote: On 20.06.19 07:03, Alexandre Ghiti wrote: Bottom-up mmap scheme is used twice: - for legacy mode, in which mmap_legacy_base and mmap_base are equal. - in case of mmap failure in top-down mode, where there is no need to go through the whole address space

Re: [PATCH REBASE v2 0/2] Hugetlbfs support for riscv

On 6/13/19 1:18 AM, Alex Ghiti wrote: Hi Paul, Palmer, Now Ingo and Catalin have acked their part, do you consider this patch for inclusion ? Thanks, Alex Hi Paul, Palmer, Any thought about this patch ? Thanks, Alex On 5/26/19 8:50 AM, Alexandre Ghiti wrote: This series is simply

Re: [PATCH v4 00/14] Provide generic top-down mmap layout functions

On 6/13/19 1:29 AM, Alex Ghiti wrote: On 5/26/19 9:47 AM, Alexandre Ghiti wrote: This series introduces generic functions to make top-down mmap layout easily accessible to architectures, in particular riscv which was the initial goal of this series. The generic implementation was taken from

Re: [PATCH REBASE v2 1/2] x86, arm64: Move ARCH_WANT_HUGE_PMD_SHARE config in arch/Kconfig

On 6/30/19 9:58 PM, Hanjun Guo wrote: On 2019/5/26 20:50, Alexandre Ghiti wrote: ARCH_WANT_HUGE_PMD_SHARE config was declared in both architectures: move this declaration in arch/Kconfig and make those architectures select it. Signed-off-by: Alexandre Ghiti Reviewed-by: Palmer Dabbelt --- a

Re: [PATCH v3 0/2] Hugetlbfs support for riscv

On 7/4/19 7:35 AM, Paul Walmsley wrote: On Thu, 4 Jul 2019, Alexandre Ghiti wrote: On 7/4/19 12:57 AM, Paul Walmsley wrote: On Mon, 1 Jul 2019, Alexandre Ghiti wrote: - libhugetlbfs testsuite on riscv64/2M: - brk_near_huge triggers an assert in malloc.c, does not on x86. I was able to

  1   2   >