Hi Christophe,
Le 22/11/2021 à 09:48, Christophe Leroy a écrit :
Commit e7142bf5d231 ("arm64, mm: make randomization selected by
generic topdown mmap layout") introduced a default version of
arch_randomize_brk() provided when
CONFIG_ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT is selected.
powerpc cou
Le 18/05/2021 à 12:12, Alexandre Ghiti a écrit :
After multiple attempts, this patchset is now based on the fact that the
64b kernel mapping was moved outside the linear mapping.
The first patch allows to build relocatable kernels but is not selected
by default. That patch should ease KASLR impl
Le 7/21/20 à 7:36 PM, Palmer Dabbelt a écrit :
On Tue, 21 Jul 2020 16:11:02 PDT (-0700), b...@kernel.crashing.org wrote:
On Tue, 2020-07-21 at 14:36 -0400, Alex Ghiti wrote:
> > I guess I don't understand why this is necessary at all.
> > Specifically: why
> > can
y when there's a cost to what already exists (for those who
haven't
been watching, so far all the sv48 patch sets have imposed a significant
performance penalty on all systems).
Alex
Alex
Le 7/9/20 à 7:11 AM, Alex Ghiti a écrit :
Hi Palmer,
Le 7/9/20 à 1:05 AM, Palmer Dabbelt a
Hi Benjamin,
Le 7/21/20 à 7:11 PM, Benjamin Herrenschmidt a écrit :
On Tue, 2020-07-21 at 14:36 -0400, Alex Ghiti wrote:
I guess I don't understand why this is necessary at all.
Specifically: why
can't we just relocate the kernel within the linear map? That would
let the
bootload
Let's try to make progress here: I add linux-mm in CC to get feedback on
this patch as it blocks sv48 support too.
Alex
Le 7/9/20 à 7:11 AM, Alex Ghiti a écrit :
Hi Palmer,
Le 7/9/20 à 1:05 AM, Palmer Dabbelt a écrit :
On Sun, 07 Jun 2020 00:59:46 PDT (-0700), a...@ghiti.fr wrote:
Th
Hi Palmer,
Le 7/9/20 à 1:05 AM, Palmer Dabbelt a écrit :
On Sun, 07 Jun 2020 00:59:46 PDT (-0700), a...@ghiti.fr wrote:
This is a preparatory patch for relocatable kernel.
The kernel used to be linked at PAGE_OFFSET address and used to be loaded
physically at the beginning of the main memory.
Hi Palmer,
Le 6/7/20 à 3:59 AM, Alexandre Ghiti a écrit :
This patchset originally implemented relocatable kernel support but now
also moves the kernel mapping into the vmalloc zone.
The first patch explains why w
Hi Atish,
Le 6/11/20 à 5:34 PM, Atish Patra a écrit :
On Sun, Jun 7, 2020 at 1:01 AM Alexandre Ghiti wrote:
This is a preparatory patch for relocatable kernel.
The kernel used to be linked at PAGE_OFFSET address and used to be loaded
physically at the beginning of the main memory. Therefore,
Hi Jerome,
Le 6/10/20 à 10:10 AM, Jerome Forissier a écrit :
On 6/7/20 9:59 AM, Alexandre Ghiti wrote:
[...]
+config RELOCATABLE
+ bool
+ depends on MMU
+ help
+ This builds a kernel as a Position Independent Executable (PIE),
+ which retains all relocation
Hi Zong,
Le 6/3/20 à 10:52 PM, Zong Li a écrit :
On Wed, Jun 3, 2020 at 4:01 PM Alexandre Ghiti wrote:
This is a preparatory patch for relocatable kernel.
The kernel used to be linked at PAGE_OFFSET address and used to be loaded
physically at the beginning of the main memory. Therefore, we co
Hi Zong,
Le 5/27/20 à 3:29 AM, Alex Ghiti a écrit :
Le 5/27/20 à 2:05 AM, Zong Li a écrit :
On Wed, May 27, 2020 at 1:06 AM Alex Ghiti wrote:
Hi Zong,
Le 5/26/20 à 5:43 AM, Zong Li a écrit :
On Sun, May 24, 2020 at 4:54 PM Alexandre Ghiti wrote:
This is a preparatory patch for
Le 5/27/20 à 2:05 AM, Zong Li a écrit :
On Wed, May 27, 2020 at 1:06 AM Alex Ghiti wrote:
Hi Zong,
Le 5/26/20 à 5:43 AM, Zong Li a écrit :
On Sun, May 24, 2020 at 4:54 PM Alexandre Ghiti wrote:
This is a preparatory patch for relocatable kernel.
The kernel used to be linked at PAGE_OFFSET
Hi Zong,
Le 5/26/20 à 5:43 AM, Zong Li a écrit :
On Sun, May 24, 2020 at 4:54 PM Alexandre Ghiti wrote:
This is a preparatory patch for relocatable kernel.
The kernel used to be linked at PAGE_OFFSET address and used to be loaded
physically at the beginning of the main memory. Therefore, we c
On 1/18/20 12:03 PM, Alexandre Ghiti wrote:
Commit 8580ac9404f6 ("bpf: Process in-kernel BTF") introduced two weak
symbols that may be unresolved at link time which result in an absolute
relocation to 0. relocs_check.sh emits the following warning:
"WARNING: 2 bad relocations
c1a41478 R_
Hi Stephen,
On 1/15/20 6:39 PM, Stephen Rothwell wrote:
Hi Alexandre,
Thanks for sorting this out. Just a few comments below.
On Wed, 15 Jan 2020 15:46:48 -0500 Alexandre Ghiti wrote:
# Have Kbuild supply the path to objdump so we handle cross compilation.
On 3/28/19 4:43 PM, Mike Kravetz wrote:
On 3/26/19 11:36 PM, Alexandre Ghiti wrote:
On systems without CONTIG_ALLOC activated but that support gigantic pages,
boottime reserved gigantic pages can not be freed at all. This patch
simply enables the possibility to hand back those pages to memory
al
On 3/17/19 2:31 PM, christophe leroy wrote:
Le 17/03/2019 à 17:28, Alexandre Ghiti a écrit :
On systems without CONTIG_ALLOC activated but that support gigantic
pages,
boottime reserved gigantic pages can not be freed at all. This patch
simply enables the possibility to hand back those pages
On 3/8/19 2:05 PM, Mike Kravetz wrote:
On 3/7/19 5:20 AM, Alexandre Ghiti wrote:
On systems without CONTIG_ALLOC activated but that support gigantic pages,
boottime reserved gigantic pages can not be freed at all. This patch
simply enables the possibility to hand back those pages to memory
alloc
On 3/6/19 2:16 PM, Dave Hansen wrote:
On 3/6/19 11:00 AM, Alexandre Ghiti wrote:
+static int set_max_huge_pages(struct hstate *h, unsigned long count,
+ nodemask_t *nodes_allowed)
{
unsigned long min_count, ret;
- if (hstate_is_gigantic(h) && !gigantic_pa
On 3/6/19 2:30 PM, Vlastimil Babka wrote:
On 3/6/19 8:00 PM, Alexandre Ghiti wrote:
This condition allows to define alloc_contig_range, so simplify
it into a more accurate naming.
Suggested-by: Vlastimil Babka
Signed-off-by: Alexandre Ghiti
Acked-by: Vlastimil Babka
(you could have sent th
On 3/6/19 2:04 PM, David Miller wrote:
From: Alexandre Ghiti
Date: Wed, 6 Mar 2019 14:00:03 -0500
sparc actually supports gigantic pages and selecting
ARCH_HAS_GIGANTIC_PAGE allows it to allocate and free
gigantic pages at runtime.
sparc allows configuration such as huge pages of 16GB,
pages
On 2/15/19 12:34 PM, Dave Hansen wrote:
-#if (defined(CONFIG_MEMORY_ISOLATION) && defined(CONFIG_COMPACTION)) ||
defined(CONFIG_CMA)
+#ifdef CONFIG_CONTIG_ALLOC
/* The below functions must be run on a range from a single zone. */
extern int alloc_contig_range(unsigned long start, unsigned lo
On 2/13/19 6:27 AM, Vlastimil Babka wrote:
On 1/17/19 7: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 enabl
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
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
Hi everyone,
Does someone need anything more to be done regarding this series ?
Thanks,
Alex
On 08/06/2018 05:57 PM, Alexandre Ghiti wrote:
[CC linux-mm for inclusion in -mm tree]
In order to reduce copy/paste
Thanks for your time,
Alex
Le 07/08/2018 à 09:54, Ingo Molnar a écrit :
* Alexandre Ghiti wrote:
[CC linux-mm for inclusion in -mm tree]
In order to reduce copy/paste of functions across architectures and then
Ok, I tried every defconfig available:
- for the nohash/32, I found that I could use mpc885_ads_defconfig and I
activated HUGETLBFS.
I removed the definition of huge_ptep_set_wrprotect from
nohash/32/pgtable.h, add an #error in
include/asm-generic/hugetlb.h right before the generic definition o
://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/8.1.0/
On 07/26/2018 05:01 PM, Alex Ghiti wrote:
Hi Helge,
Thanks for your tests.
In case it can help you, this is what I get when I try to build
generic-64bit_defconfig (I truncated the output):
...
LD vmlinux.o
MODPOST
: 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:
Hi Christophe,
Sorry, I should have done it already: with and without huge page
activated, the build for mpc885_ads_defconfig is OK.
Thanks,
Alex
On 07/26/2018 03:13 PM, LEROY Christophe wrote:
Alex Ghiti a écrit :
Hi everyone,
This is the result of the build for all arches tackled in
Ellerman wrote:
Alex Ghiti writes:
Does anyone have any suggestion about those patches ?
Cross compiling it for some non-x86 arches would be a good start :)
There are cross compilers available here:
https://mirrors.edge.kernel.org/pub/tools/crosstool/
cheers
On 07/09/2018 02:16 PM, Michal
Ok will do and report when done.
Thanks for your feedback,
Alex
On 07/23/2018 02:00 PM, Michael Ellerman wrote:
Alex Ghiti writes:
Does anyone have any suggestion about those patches ?
Cross compiling it for some non-x86 arches would be a good start :)
There are cross compilers available
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
My bad, when I moved the #include at the bottom
of the file, I did not pay attention to that #ifdef.
I'm going to fix powerpc and check other architectures if I did not make
the same mistake.
I'll send a v4 as soon as possible.
Thanks for your comment,
Alex
On 07/05/2018 10:22 AM, Christophe
Please drop this serie, sorry for the noise.
On 07/05/2018 04:58 AM, Alexandre Ghiti wrote:
arm, x86 architectures use the same version of
huge_ptep_clear_flush, so move this generic implementation into
asm-generic/hugetlb.h.
Signed-off-by: Alexandre Ghiti
---
arch/arm/include/asm/hugetlb-3
Please drop this serie, sorry for the noise.
On 07/05/2018 05:12 AM, Alexandre Ghiti wrote:
arm, arm64, ia64, parisc, powerpc, sh, sparc, x86 architectures
use the same version of huge_pte_none, so move this generic
implementation into asm-generic/hugetlb.h.
Signed-off-by: Alexandre Ghiti
---
38 matches
Mail list logo
