ons. Convert
> these to use pagetable_alloc() and ptdesc_address() instead to help
> standardize page tables further.
>
> Signed-off-by: Vishal Moola (Oracle)
Acked-by: Mike Rapoport (IBM)
> ---
> arch/loongarch/include/asm/pgalloc.h | 27 +++
On Mon, Jun 12, 2023 at 02:04:12PM -0700, Vishal Moola (Oracle) wrote:
> Part of the conversions to replace pgtable constructor/destructors with
> ptdesc equivalents.
>
> Signed-off-by: Vishal Moola (Oracle)
Acked-by: Mike Rapoport (IBM)
> ---
> arch/hexagon/include
On Mon, Jun 12, 2023 at 02:04:11PM -0700, Vishal Moola (Oracle) wrote:
> Part of the conversions to replace pgtable constructor/destructors with
> ptdesc equivalents.
>
> Signed-off-by: Vishal Moola (Oracle)
> Acked-by: Guo Ren
Acked-by: Mike Rapoport (IBM)
> ---
>
On Mon, Jun 12, 2023 at 02:04:10PM -0700, Vishal Moola (Oracle) wrote:
> As part of the conversions to replace pgtable constructor/destructors with
> ptdesc equivalents, convert various page table functions to use ptdescs.
>
> Signed-off-by: Vishal Moola (Oracle)
Acked-by: Mike R
ion. Convert
> this to use pagetable_alloc() and ptdesc_address() instead to help
> standardize page tables further.
>
> Signed-off-by: Vishal Moola (Oracle)
Acked-by: Mike Rapoport (IBM)
One comment below.
> ---
> arch/arm/include/asm/tlb.h | 12 +++-
>
On Mon, Jun 12, 2023 at 02:04:08PM -0700, Vishal Moola (Oracle) wrote:
> As part of the conversions to replace pgtable constructor/destructors with
> ptdesc equivalents, convert various page table functions to use ptdescs.
>
> Some of the functions use the *get*page*() helper functions. Convert
>
On Mon, Jun 12, 2023 at 02:04:07PM -0700, Vishal Moola (Oracle) wrote:
> The page table members are now split out into their own ptdesc struct.
> Remove them from struct page.
>
> Signed-off-by: Vishal Moola (Oracle)
Acked-by: Mike Rapoport (IBM)
> ---
> include/lin
ons. Convert
> these to use pagetable_alloc() and ptdesc_address() instead to help
> standardize page tables further.
>
> Signed-off-by: Vishal Moola (Oracle)
Acked-by: Mike Rapoport (IBM)
> ---
> arch/s390/include/asm/pgalloc.h | 4 +-
> arch/s390/include/asm/tlb.h |
ptdesc_address() instead to help
> standardize page tables further.
>
> Signed-off-by: Vishal Moola (Oracle)
With folding
ptdesc->_pt_s390_gaddr = 0;
into pagetable_free()
Acked-by: Mike Rapoport (IBM)
> ---
> arch/s390/mm/gmap.c | 230 -
On Mon, Jun 12, 2023 at 02:04:04PM -0700, Vishal Moola (Oracle) wrote:
> In order to split struct ptdesc from struct page, convert various
> functions to use ptdescs.
>
> Some of the functions use the *get*page*() helper functions. Convert
Nit: *get_free_page*()
> these
On Mon, Jun 12, 2023 at 02:04:03PM -0700, Vishal Moola (Oracle) wrote:
> In order to split struct ptdesc from struct page, convert various
> functions to use ptdescs.
>
> Signed-off-by: Vishal Moola (Oracle)
Acked-by: Mike Rapoport (IBM)
> ---
> arch/powerpc/mm/book3s64/
"create ... make"
I like the second form more.
> Signed-off-by: Vishal Moola (Oracle)
Acked-by: Mike Rapoport (IBM)
> ---
> include/linux/mm.h | 56 ++
> 1 file changed, 42 insertions(+), 14 deletions(-)
>
> diff --git a/
On Mon, Jun 12, 2023 at 02:04:01PM -0700, Vishal Moola (Oracle) wrote:
> This removes some direct accesses to struct page, working towards
> splitting out struct ptdesc from struct page.
>
> Signed-off-by: Vishal Moola (Oracle)
Acked-by: Mike Rapoport (IBM)
> ---
> inclu
On Mon, Jun 12, 2023 at 02:04:00PM -0700, Vishal Moola (Oracle) wrote:
> This removes some direct accesses to struct page, working towards
> splitting out struct ptdesc from struct page.
>
> Signed-off-by: Vishal Moola (Oracle)
Acked-by: Mike Rapoport (IBM)
> ---
> inclu
On Mon, Jun 12, 2023 at 02:03:59PM -0700, Vishal Moola (Oracle) wrote:
> This removes some direct accesses to struct page, working towards
> splitting out struct ptdesc from struct page.
>
> Signed-off-by: Vishal Moola (Oracle)
Acked-by: Mike Rapoport (IBM)
> ---
> inclu
On Mon, Jun 12, 2023 at 02:03:58PM -0700, Vishal Moola (Oracle) wrote:
> This removes some direct accesses to struct page, working towards
> splitting out struct ptdesc from struct page.
>
> Signed-off-by: Vishal Moola (Oracle)
Acked-by: Mike Rapoport (IBM)
> ---
> inclu
On Mon, Jun 12, 2023 at 02:03:57PM -0700, Vishal Moola (Oracle) wrote:
> This removes some direct accesses to struct page, working towards
> splitting out struct ptdesc from struct page.
>
> Signed-off-by: Vishal Moola (Oracle)
Acked-by: Mike Rapoport (IBM)
> ---
> arch/x86
On Mon, Jun 12, 2023 at 02:03:56PM -0700, Vishal Moola (Oracle) wrote:
> This removes some direct accesses to struct page, working towards
> splitting out struct ptdesc from struct page.
>
> Signed-off-by: Vishal Moola (Oracle)
Acked-by: Mike Rapoport (IBM)
> ---
> incl
l Moola (Oracle)
Acked-by: Mike Rapoport (IBM)
> ---
> include/linux/mm.h | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index f184f1eba85d..088b7664f897 100644
> --- a/include/linux/mm.h
> +++ b/in
On Mon, Jun 12, 2023 at 02:03:54PM -0700, Vishal Moola (Oracle) wrote:
> Introduce utility functions setting the foundation for ptdescs. These
> will also assist in the splitting out of ptdesc from struct page.
>
> Functions that focus on the descriptor are prefixed with ptdesc_* while
> functions
On Mon, Jun 12, 2023 at 02:03:53PM -0700, Vishal Moola (Oracle) wrote:
> Currently, page table information is stored within struct page. As part
> of simplifying struct page, create struct ptdesc for page table
> information.
>
> Signed-off-by: Vishal Moola (Oracle)
Acked-by: Mik
his improves the safety for _refcount and the page table tracking.
>
> This also allows us to simplify the tracking since we can once again use
> the lower byte of pt_frag_refcount instead of the upper byte of _refcount.
>
> Signed-off-by: Vishal Moola (Oracle)
One nit below
scs")
would be the right place for that.
Otherwise:
Acked-by: Mike Rapoport (IBM)
> This also reverts commit 7e25de77bc5ea ("s390/mm: use pmd_pgtable_page()
> helper in __gmap_segment_gaddr()") which had s390 use
> pmd_pgtable_page() to get a gmap page table, as pmd_pgtab
the memory here.
>
> Signed-off-by: Vishal Moola (Oracle)
Acked-by: Mike Rapoport (IBM)
> ---
> include/linux/page-flags.h | 20 ++--
> 1 file changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
>
r.kernel.org
> Cc: linux...@lists.infradead.org
> Cc: linux-a...@vger.kernel.org
> Cc: linux...@kvack.org
> Suggested-by: Linus Torvalds
> Signed-off-by: Rick Edgecombe
> Link:
> https://lore.kernel.org/lkml/CAHk-=wizjsu7c9sfyzb3q04108stghff2wfbokgccgw7riz...@mail.gmail.com/
Reviewed-by: Mike Rapoport (IBM)
--
Sincerely yours,
Mike.
On Tue, Jun 13, 2023 at 02:56:14PM -0400, Kent Overstreet wrote:
> On Thu, Jun 08, 2023 at 09:41:16PM +0300, Mike Rapoport wrote:
> > On Tue, Jun 06, 2023 at 11:21:59AM -0700, Song Liu wrote:
> > > On Mon, Jun 5, 2023 at 3:09 AM Mark Rutland wrote:
> > >
> > >
On Fri, Jun 09, 2023 at 10:02:16AM -0700, Song Liu wrote:
> On Thu, Jun 8, 2023 at 11:41 AM Mike Rapoport wrote:
> >
> > On Tue, Jun 06, 2023 at 11:21:59AM -0700, Song Liu wrote:
> > > On Mon, Jun 5, 2023 at 3:09 AM Mark Rutland wrote:
> > >
> > > [
On Tue, Jun 06, 2023 at 11:21:59AM -0700, Song Liu wrote:
> On Mon, Jun 5, 2023 at 3:09 AM Mark Rutland wrote:
>
> [...]
>
> > > > > Can you give more detail on what parameters you need? If the only
> > > > > extra
> > > > > parameter is just "does this allocation need to live close to kernel
>
On Mon, Jun 05, 2023 at 11:09:34AM +0100, Mark Rutland wrote:
> On Mon, Jun 05, 2023 at 12:20:40PM +0300, Mike Rapoport wrote:
> > On Fri, Jun 02, 2023 at 10:35:09AM +0100, Mark Rutland wrote:
> >
> > It sill can be achieved with a single jit_alloc_arch_params(), just by
>
On Mon, Jun 05, 2023 at 04:10:21PM +, Edgecombe, Rick P wrote:
> On Mon, 2023-06-05 at 11:11 +0300, Mike Rapoport wrote:
> > On Sun, Jun 04, 2023 at 10:52:44PM -0400, Steven Rostedt wrote:
> > > On Thu, 1 Jun 2023 16:54:36 -0700
> > > Nadav Amit wrote:
> > &g
On Fri, Jun 02, 2023 at 10:35:09AM +0100, Mark Rutland wrote:
> On Thu, Jun 01, 2023 at 02:14:56PM -0400, Kent Overstreet wrote:
> > On Thu, Jun 01, 2023 at 05:12:03PM +0100, Mark Rutland wrote:
> > > For a while I have wanted to give kprobes its own allocator so that it
> > > can work
> > > even
On Sun, Jun 04, 2023 at 10:52:44PM -0400, Steven Rostedt wrote:
> On Thu, 1 Jun 2023 16:54:36 -0700
> Nadav Amit wrote:
>
> > > The way text_poke() is used here, it is creating a new writable alias
> > > and flushing it for *each* write to the module (like for each write of
> > > an individual re
On Thu, Jun 01, 2023 at 12:30:50PM +0200, Peter Zijlstra wrote:
> On Thu, Jun 01, 2023 at 01:12:56PM +0300, Mike Rapoport wrote:
>
> > +static void __init_or_module do_text_poke(void *addr, const void *opcode,
> > size_t len)
> > +{
> > + if
From: "Mike Rapoport (IBM)"
When STRICT_KERNEL_RWX or STRICT_MODULE_RWX is enabled, force text
allocations to use KERNEL_PAGE_ROX.
Signed-off-by: Mike Rapoport (IBM)
---
arch/Kconfig | 3 +++
arch/x86/Kconfig | 1 +
arch/x86/kernel/ftrace.c | 3 ---
arch/x86
before writing to it and to protect memory in the
end.
Signed-off-by: Song Liu
Co-developed-by: Mike Rapoport (IBM)
Signed-off-by: Mike Rapoport (IBM)
---
arch/x86/kernel/alternative.c | 43 +++
arch/x86/kernel/ftrace.c | 41
From: Song Liu
ftrace_process_locs sorts module mcount, which is inside RO memory. Add a
ftrace_swap_func so that archs can use RO-memory-poke function to do the
sorting.
Signed-off-by: Song Liu
---
include/linux/ftrace.h | 2 ++
kernel/trace/ftrace.c | 13 -
2 files changed, 14
From: "Mike Rapoport (IBM)"
When executable memory will be allocated as ROX it won't be possible to
update it using memset() and memcpy().
Introduce jit_update_copy() and jit_update_set() APIs and use them in
modules loading code instead of memcpy() and memset().
Signed-off-by
From: "Mike Rapoport (IBM)"
kprobes depended on CONFIG_MODULES because it has to allocate memory for
code.
Since code allocations are now implemented with jitalloc, kprobes can be
enabled in non-modular kernels.
Add #ifdef CONFIG_MODULE guars for the code dealing with kprobes insi
From: "Mike Rapoport (IBM)"
jitalloc does not depend on modules, on the contrary modules use
jitalloc.
To make jitalloc available when CONFIG_MODULES=n, for instance for
kprobes, split jit_alloc_params initialization out from
arch/kernel/module.c and compile it when CONFIG_JIT_ALLOC
From: "Mike Rapoport (IBM)"
Dynamic ftrace must allocate memory for code and this was impossible
without CONFIG_MODULES.
With jitalloc separated from the modules code, the jit_text_alloc() is
available regardless of CONFIG_MODULE.
Move jitalloc initialization to x86/mm/init.c so tha
From: "Mike Rapoport (IBM)"
Data related to code allocations, such as module data section, need to
comply with architecture constraints for its placement and its
allocation right now was done using jit_text_alloc().
Create a dedicated API for allocating data related to code alloc
From: "Mike Rapoport (IBM)"
Define default parameters for address range for code allocations
using the current values in module_alloc() and make jit_text_alloc() use
these defaults when an architecure does not supply its specific
parameters.
With this, jit_text_alloc() impleme
From: "Mike Rapoport (IBM)"
Extend jitalloc parameters to accommodate more complex overrides of
module_alloc() by architectures.
This includes specification of a fallback range required by arm, arm64
and powerpc and support for allocation of KASAN shadow required by
arm64, s390 and
From: "Mike Rapoport (IBM)"
Several architectures override module_alloc() only to define address
range for code allocations different than VMALLOC address space.
Provide a generic implementation in jitalloc that uses the parameters
for address space ranges, required alignmen
From: "Mike Rapoport (IBM)"
module_alloc() is used everywhere as a mean to allocate memory for code.
Beside being semantically wrong, this unnecessarily ties all subsystmes
that need to allocate code, such as ftrace, kprobes and BPF to modules
and puts the burden of code allocat
From: "Mike Rapoport (IBM)"
nios2 uses kmalloc() to implement module_alloc() because CALL26/PCREL26
cannot reach all of vmalloc address space.
Define module space as 32MiB below the kernel base and switch nios2 to
use vmalloc for module allocations.
Suggested-by: Thomas Gleixner
Sig
From: "Mike Rapoport (IBM)"
Hi,
module_alloc() is used everywhere as a mean to allocate memory for code.
Beside being semantically wrong, this unnecessarily ties all subsystmes
that need to allocate code, such as ftrace, kprobes and BPF to modules
and puts the burden of code allocat
On Sat, May 27, 2023 at 04:09:31PM +0100, Matthew Wilcox wrote:
> On Sat, May 27, 2023 at 01:41:44PM +0300, Mike Rapoport wrote:
> > Sorry if I wasn't clear, by "page table page" I meant the page (or memory
> > for that matter) for actual page table rather than s
On Thu, May 25, 2023 at 01:53:24PM -0700, Vishal Moola wrote:
> On Thu, May 25, 2023 at 1:26 PM Mike Rapoport wrote:
> >
> > On Thu, May 25, 2023 at 11:04:28AM -0700, Vishal Moola wrote:
> > > On Thu, May 25, 2023 at 2:10 AM Mike Rapoport wrote:
> > > > > +
On Thu, May 25, 2023 at 11:04:28AM -0700, Vishal Moola wrote:
> On Thu, May 25, 2023 at 2:10 AM Mike Rapoport wrote:
> > > +
> > > +static inline struct ptdesc *ptdesc_alloc(gfp_t gfp, unsigned int order)
> > > +{
> > > + struct page *pag
On Thu, May 25, 2023 at 10:00:23AM -0700, Vishal Moola wrote:
> On Thu, May 25, 2023 at 1:56 AM Mike Rapoport wrote:
> >
> > Hi,
> >
> > On Mon, May 01, 2023 at 12:27:56PM -0700, Vishal Moola (Oracle) wrote:
> > > No folio equivalents for page type operation
On Mon, May 01, 2023 at 12:28:08PM -0700, Vishal Moola (Oracle) wrote:
> Creates ptdesc_pte_ctor(), ptdesc_pmd_ctor(), ptdesc_pte_dtor(), and
> ptdesc_pmd_dtor() and make the original pgtable constructor/destructors
> wrappers.
I think pgtable_pXY_ctor/dtor names would be better.
> Signed-off-by
On Mon, May 01, 2023 at 12:28:00PM -0700, Vishal Moola (Oracle) wrote:
> Introduce utility functions setting the foundation for ptdescs. These
> will also assist in the splitting out of ptdesc from struct page.
>
> ptdesc_alloc() is defined to allocate new ptdesc pages as compound
> pages. This is
On Mon, May 01, 2023 at 12:27:57PM -0700, Vishal Moola (Oracle) wrote:
> s390 uses page->index to keep track of page tables for the guest address
> space. In an attempt to consolidate the usage of page fields in s390,
> replace _pt_pad_2 with _pt_s390_gaddr to replace page->index in gmap.
>
> This
Hi,
On Mon, May 01, 2023 at 12:27:56PM -0700, Vishal Moola (Oracle) wrote:
> No folio equivalents for page type operations have been defined, so
> define them for later folio conversions.
Can you please elaborate why would we need folios for page table descriptors?
> Also changes the Page##una
n
> Cc: Nicholas Piggin
> Cc: linuxppc-dev@lists.ozlabs.org
Reviewed-by: Mike Rapoport (IBM)
> ---
> arch/powerpc/Kconfig | 1 +
> arch/powerpc/include/asm/io.h | 8 +++-
> arch/powerpc/mm/ioremap.c | 26 +-
> arch/power
in
> the middle of . Let's rely on .
>
> Signed-off-by: Baoquan He
> Cc: loonga...@lists.linux.dev
> Cc: linux-m...@lists.linux-m68k.org
> Cc: linux-m...@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: x...@kernel.org
> Cc: net...@vger.kernel.org
> Cc:
Hi,
On Thu, May 11, 2023 at 03:02:55PM +0100, Matthew Wilcox wrote:
> On Wed, May 10, 2023 at 09:35:44PM -0700, Hugh Dickins wrote:
> > On Wed, 10 May 2023, Matthew Wilcox wrote:
> >
> > I don't really understand why you're going down a remove-CONFIG_HIGHPTE
> > route: I thought you were motivate
On Sat, Mar 25, 2023 at 02:38:15PM +0800, Kefeng Wang wrote:
>
>
> On 2023/3/25 14:08, Mike Rapoport wrote:
> > From: "Mike Rapoport (IBM)"
> >
> > It is enough to keep default values for base and huge pages without
> > letting users to override ARC
On Wed, Mar 29, 2023 at 10:55:37AM -0500, Justin Forbes wrote:
> On Sat, Mar 25, 2023 at 1:09 AM Mike Rapoport wrote:
> >
> > From: "Mike Rapoport (IBM)"
> >
> > It is not a good idea to change fundamental parameters of core memory
> > management.
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Reviewed-by: Max Filippov
Acked-by: Kirill A. Shutemov
Reviewed-by: Zi Yan
Signed-of
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Acked-by: Kirill A. Shutemov
Reviewed-by: Zi Yan
Signed-off-by: Mike Rapoport (IBM)
---
From: "Mike Rapoport (IBM)"
sh defines insane ranges for ARCH_FORCE_MAX_ORDER allowing MAX_ORDER
up to 63, which implies maximal contiguous allocation size of 2^63
pages.
Drop bogus definitions of ranges for ARCH_FORCE_MAX_ORDER and leave it a
simple integer with sensible defaults.
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Acked-by: Kirill A. Shutemov
Reviewed-by: Zi Yan
Signed-off-by: Mike Rapoport (IBM)
---
From: "Mike Rapoport (IBM)"
PowerPC defines ranges for ARCH_FORCE_MAX_ORDER some of which are
insanely allowing MAX_ORDER up to 63, which implies maximal contiguous
allocation size of 2^63 pages.
Drop bogus definitions of ranges for ARCH_FORCE_MAX_ORDER and leave it a
simple in
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Acked-by: Kirill A. Shutemov
Reviewed-by: Zi Yan
Signed-off-by: Mike Rapoport (IBM)
From: "Mike Rapoport (IBM)"
nios2 defines range for ARCH_FORCE_MAX_ORDER allowing MAX_ORDER
up to 19, which implies maximal contiguous allocation size of 2^19
pages or 2GiB.
Drop bogus definition of ranges for ARCH_FORCE_MAX_ORDER and leave it a
simple integer with sensible default.
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Acked-by: Kirill A. Shutemov
Reviewed-by: Zi Yan
Signed-off-by: Mike Rapoport (IBM)
---
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Acked-by: Kirill A. Shutemov
Acked-by: Geert Uytterhoeven
Reviewed-by: Zi Yan
Signed-of
From: "Mike Rapoport (IBM)"
It is enough to keep default values for base and huge pages without
letting users to override ARCH_FORCE_MAX_ORDER.
Drop the prompt to make the option unvisible in *config.
Acked-by: Kirill A. Shutemov
Reviewed-by: Zi Yan
Signed-off-by: Mike Rap
From: "Mike Rapoport (IBM)"
The default value of ARCH_FORCE_MAX_ORDER matches the generic default
defined in the MM code, the architecture does not support huge pages, so
there is no need to keep ARCH_FORCE_MAX_ORDER option available.
Drop it.
Acked-by: Kirill A. Shutemov
Reviewed-
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Acked-by: Kirill A. Shutemov
Reviewed-by: Zi Yan
Signed-off-by: Mike Rapoport (IBM)
---
From: "Mike Rapoport (IBM)"
It is not a good idea to change fundamental parameters of core memory
management. Having predefined ranges suggests that the values within
those ranges are sensible, but one has to *really* understand
implications of changing MAX_ORDER before actually amend
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Acked-by: Kirill A. Shutemov
Reviewed-by: Zi Yan
Signed-off-by: Mike Rapoport (IBM)
---
From: "Mike Rapoport (IBM)"
Hi,
Several architectures have ARCH_FORCE_MAX_ORDER in their Kconfig and
they all have wrong and misleading prompt and help text for this option.
Besides, some define insane limits for possible values of
ARCH_FORCE_MAX_ORDER, some carefully define ranges
On Fri, Mar 24, 2023 at 10:30:07AM -0400, Zi Yan wrote:
> On 24 Mar 2023, at 1:22, Mike Rapoport wrote:
>
> > From: "Mike Rapoport (IBM)"
> >
> > Hi,
> >
> > Several architectures have ARCH_FORCE_MAX_ORDER in their Kconfig and
> > they all hav
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Signed-off-by: Mike Rapoport (IBM)
Reviewed-by: Max Filippov
Acked-by: Kirill A. Shutemov
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Signed-off-by: Mike Rapoport (IBM)
Acked-by: Kirill A. Shutemov
---
arch/sparc/Kc
From: "Mike Rapoport (IBM)"
sh defines insane ranges for ARCH_FORCE_MAX_ORDER allowing MAX_ORDER
up to 63, which implies maximal contiguous allocation size of 2^63
pages.
Drop bogus definitions of ranges for ARCH_FORCE_MAX_ORDER and leave it a
simple integer with sensible defaults.
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Signed-off-by: Mike Rapoport (IBM)
Acked-by: Kirill A. Shutemov
---
arch/sh/mm/Kc
From: "Mike Rapoport (IBM)"
PowerPC defines ranges for ARCH_FORCE_MAX_ORDER some of which are
insanely allowing MAX_ORDER up to 63, which implies maximal contiguous
allocation size of 2^63 pages.
Drop bogus definitions of ranges for ARCH_FORCE_MAX_ORDER and leave it a
simple in
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Signed-off-by: Mike Rapoport (IBM)
Acked-by: Kirill A. Shutemov
---
arch/powerpc/Kc
From: "Mike Rapoport (IBM)"
nios2 defines range for ARCH_FORCE_MAX_ORDER allowing MAX_ORDER
up to 19, which implies maximal contiguous allocation size of 2^19
pages or 2GiB.
Drop bogus definition of ranges for ARCH_FORCE_MAX_ORDER and leave it a
simple integer with sensible default.
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Signed-off-by: Mike Rapoport (IBM)
Acked-by: Kirill A. Shutemov
---
arch/nios2/Kc
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Signed-off-by: Mike Rapoport (IBM)
Acked-by: Kirill A. Shutemov
Acked-by: Geert Uy
From: "Mike Rapoport (IBM)"
It is enough to keep default values for base and huge pages without
letting users to override ARCH_FORCE_MAX_ORDER.
Drop the prompt to make the option unvisible in *config.
Signed-off-by: Mike Rapoport (IBM)
Acked-by: Kirill A. Shutemov
---
arch/ia64/K
From: "Mike Rapoport (IBM)"
The default value of ARCH_FORCE_MAX_ORDER matches the generic default
defined in the MM code, the architecture does not support huge pages, so
there is no need to keep ARCH_FORCE_MAX_ORDER option available.
Drop it.
Signed-off-by: Mike Rapoport (IBM)
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Signed-off-by: Mike Rapoport (IBM)
Acked-by: Kirill A. Shutemov
---
arch/arm64/Kc
From: "Mike Rapoport (IBM)"
It is not a good idea to change fundamental parameters of core memory
management. Having predefined ranges suggests that the values within
those ranges are sensible, but one has to *really* understand
implications of changing MAX_ORDER before actually amend
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Signed-off-by: Mike Rapoport (IBM)
Acked-by: Kirill A. Shutemov
---
arch/arm/Kc
From: "Mike Rapoport (IBM)"
Hi,
Several architectures have ARCH_FORCE_MAX_ORDER in their Kconfig and
they all have wrong and misleading prompt and help text for this option.
Besides, some define insane limits for possible values of
ARCH_FORCE_MAX_ORDER, some carefully define ranges
On Thu, Mar 23, 2023 at 10:15:33AM +, Catalin Marinas wrote:
> On Thu, Mar 23, 2023 at 11:21:44AM +0200, Mike Rapoport wrote:
> > From: "Mike Rapoport (IBM)"
> >
> > It is not a good idea to change fundamental parameters of core memory
> > management. H
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Signed-off-by: Mike Rapoport (IBM)
---
arch/xtensa/Kconfig | 16 +---
1 file
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Signed-off-by: Mike Rapoport (IBM)
---
arch/sparc/Kconfig | 16 +---
1 file
From: "Mike Rapoport (IBM)"
sh defines insane ranges for ARCH_FORCE_MAX_ORDER allowing MAX_ORDER
up to 63, which implies maximal contiguous allocation size of 2^63
pages.
Drop bogus definitions of ranges for ARCH_FORCE_MAX_ORDER and leave it a
simple integer with sensible defaults.
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Signed-off-by: Mike Rapoport (IBM)
---
arch/sh/mm/Kconfig | 17 +
1 file
From: "Mike Rapoport (IBM)"
PowerPC defines ranges for ARCH_FORCE_MAX_ORDER some of which are
insanely allowing MAX_ORDER up to 63, which implies maximal contiguous
allocation size of 2^63 pages.
Drop bogus definitions of ranges for ARCH_FORCE_MAX_ORDER and leave it a
simple in
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Signed-off-by: Mike Rapoport (IBM)
---
arch/powerpc/Kconfig | 16 +---
1 file
From: "Mike Rapoport (IBM)"
nios2 defines range for ARCH_FORCE_MAX_ORDER allowing MAX_ORDER
up to 19, which implies maximal contiguous allocation size of 2^19
pages or 2GiB.
Drop bogus definition of ranges for ARCH_FORCE_MAX_ORDER and leave it a
simple integer with sensible default.
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Signed-off-by: Mike Rapoport (IBM)
---
arch/nios2/Kconfig | 16 +---
1 file
401 - 500 of 1198 matches
Mail list logo