; functioality as before.
>
> Here, add wrapper functions ioremap_prot() and iounmap() for arc's
> special operation when ioremap_prot() and iounmap().
>
> Signed-off-by: Baoquan He
> Cc: Vineet Gupta
> Cc: linux-snps-arc@lists.infradead.org
Reviewed-by: Mike Rapoport (IBM)
>
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: linux-a...@vger.kernel.org
Reviewed-by:
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
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
as better to
> optimize by the compiler.
>
> Fixes: 9420f89db2dd ("mm: move most of core MM initialization to
> mm/mm_init.c")
> Cc: l...@lists.linux.dev
> Signed-off-by: Arnd Bergmann
Acked-by: Mike Rapoport (IBM)
> ---
> v2: fix logic bug reported-by: kerne
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
> > ma
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 defaul
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
simp
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 defau
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 actuall
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 r
clude/asm/kexec.h| 6 -
> arch/arm64/include/asm/memory.h | 5
> arch/arm64/kernel/machine_kexec.c | 20 --
> arch/arm64/mm/init.c | 6 +
> arch/arm64/mm/mmu.c | 43 ---
> 5 files changed, 1 insertion(+), 79 deletions(-)
Acked-by: Mike Rapoport (IBM)
> --
> 2.34.1
>
--
Sincerely yours,
Mike.
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
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
> > the
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 defaul
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
simp
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 defau
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 (I
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 actuall
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 r
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
> > manageme
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 defaul
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
simp
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 defau
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
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/m68k/Kconfig.cpu | 16 +---
1 file
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)
---
arch/ia64/Kconfig | 3 +--
1 file
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)
---
arch/arm64/Kconfig | 25 ---
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 actuall
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/arm/Kconfig | 16 +---
1 file
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 r
On Wed, Mar 15, 2023 at 05:14:34AM +, Matthew Wilcox (Oracle) wrote:
> Add PFN_PTE_SHIFT and update_mmu_cache_range().
>
> Signed-off-by: Matthew Wilcox (Oracle)
> Cc: Richard Weinberger
> Cc: Anton Ivanov
> Cc: Johannes Berg
> Cc: linux-um@lists.infradead.org
Ac
: Michael Ellerman
> Cc: Nicholas Piggin
> Cc: Christophe Leroy
> Cc: linuxppc-dev@lists.ozlabs.org
Acked-by: Mike Rapoport (IBM)
> ---
> arch/powerpc/include/asm/book3s/pgtable.h | 10 +
> arch/powerpc/include/asm/cacheflush.h | 14 +--
> arch/powerpc/include/
s we don't know that all pages in this
> folio were cleaned). Enhance the internal flush routines to take the
> number of pages to flush.
>
> Signed-off-by: Matthew Wilcox (Oracle)
> Cc: Vineet Gupta
> Cc: linux-snps-arc@lists.infradead.org
Acked-by: Mike Rapoport (IBM)
> ---
Hi Geert,
On Mon, Feb 27, 2023 at 01:31:23PM +0100, Geert Uytterhoeven wrote:
> Hi Mike,
>
> On Mon, Feb 27, 2023 at 12:34 PM Mike Rapoport wrote:
> > On Mon, Feb 27, 2023 at 10:42:34PM +1300, Michael Schmitz wrote:
> > > Am 27.02.2023 um 21:26 schrieb Geert Uytterhoev
Hi,
On Mon, Feb 27, 2023 at 10:42:34PM +1300, Michael Schmitz wrote:
> Hi Geert,
>
> adding Mike Rapoport to the recipient list who would know whether
> memblock_reserve() relies on paging_init() having run.
>
> Cheers,
>
> Michael
>
> Am 27.02.2023 um 21
Hi,
On Fri, Dec 02, 2022 at 02:13:38PM +0800, Chao Peng wrote:
> This patch series implements KVM guest private memory for confidential
> computing scenarios like Intel TDX[1]. If a TDX host accesses
> TDX-protected guest memory, machine check can happen which can further
> crash the running host
Andrew,
On Sun, Feb 12, 2023 at 10:37:15PM -0800, Guenter Roeck wrote:
> On 2/12/23 17:26, Mike Rapoport wrote:
> > On Sun, Feb 12, 2023 at 08:13:20AM -0800, Guenter Roeck wrote:
> > > On Sun, Jan 29, 2023 at 02:42:35PM +0200, Mike Rapoport wrote:
> > >
Andrew,
On Sun, Feb 12, 2023 at 10:37:15PM -0800, Guenter Roeck wrote:
> On 2/12/23 17:26, Mike Rapoport wrote:
> > On Sun, Feb 12, 2023 at 08:13:20AM -0800, Guenter Roeck wrote:
> > > On Sun, Jan 29, 2023 at 02:42:35PM +0200, Mike Rapoport wrote:
> > >
Andrew,
On Sun, Feb 12, 2023 at 10:37:15PM -0800, Guenter Roeck wrote:
> On 2/12/23 17:26, Mike Rapoport wrote:
> > On Sun, Feb 12, 2023 at 08:13:20AM -0800, Guenter Roeck wrote:
> > > On Sun, Jan 29, 2023 at 02:42:35PM +0200, Mike Rapoport wrote:
> > >
On Sun, Feb 12, 2023 at 08:13:20AM -0800, Guenter Roeck wrote:
> On Sun, Jan 29, 2023 at 02:42:35PM +0200, Mike Rapoport wrote:
> > From: "Mike Rapoport (IBM)"
> >
> > Every architecture that supports FLATMEM memory model defines its own
> > version of pfn_va
On Sun, Feb 12, 2023 at 08:13:20AM -0800, Guenter Roeck wrote:
> On Sun, Jan 29, 2023 at 02:42:35PM +0200, Mike Rapoport wrote:
> > From: "Mike Rapoport (IBM)"
> >
> > Every architecture that supports FLATMEM memory model defines its own
> > version of pfn_va
On Sun, Feb 12, 2023 at 08:13:20AM -0800, Guenter Roeck wrote:
> On Sun, Jan 29, 2023 at 02:42:35PM +0200, Mike Rapoport wrote:
> > From: "Mike Rapoport (IBM)"
> >
> > Every architecture that supports FLATMEM memory model defines its own
> > version of pfn_va
Hi,
On Sun, Feb 12, 2023 at 09:35:13AM -0800, Guenter Roeck wrote:
> Hi,
>
> On Sun, Jan 29, 2023 at 02:42:33PM +0200, Mike Rapoport wrote:
> > From: "Mike Rapoport (IBM)"
> >
> > The MMU variant uses generic definitions of page_to_pfn() and
> > pfn_
Hi,
On Sun, Feb 12, 2023 at 09:35:13AM -0800, Guenter Roeck wrote:
> Hi,
>
> On Sun, Jan 29, 2023 at 02:42:33PM +0200, Mike Rapoport wrote:
> > From: "Mike Rapoport (IBM)"
> >
> > The MMU variant uses generic definitions of page_to_pfn() and
> > pfn_
Hi,
On Sun, Feb 12, 2023 at 09:35:13AM -0800, Guenter Roeck wrote:
> Hi,
>
> On Sun, Jan 29, 2023 at 02:42:33PM +0200, Mike Rapoport wrote:
> > From: "Mike Rapoport (IBM)"
> >
> > The MMU variant uses generic definitions of page_to_pfn() and
> > pfn_
Hi Guenter,
On Sun, Feb 12, 2023 at 08:13:20AM -0800, Guenter Roeck wrote:
> On Sun, Jan 29, 2023 at 02:42:35PM +0200, Mike Rapoport wrote:
> > From: "Mike Rapoport (IBM)"
> >
> > Every architecture that supports FLATMEM memory model defines its own
> > ve
Hi Guenter,
On Sun, Feb 12, 2023 at 08:13:20AM -0800, Guenter Roeck wrote:
> On Sun, Jan 29, 2023 at 02:42:35PM +0200, Mike Rapoport wrote:
> > From: "Mike Rapoport (IBM)"
> >
> > Every architecture that supports FLATMEM memory model defines its own
> > ve
Hi Guenter,
On Sun, Feb 12, 2023 at 08:13:20AM -0800, Guenter Roeck wrote:
> On Sun, Jan 29, 2023 at 02:42:35PM +0200, Mike Rapoport wrote:
> > From: "Mike Rapoport (IBM)"
> >
> > Every architecture that supports FLATMEM memory model defines its own
> > ve
From: "Mike Rapoport (IBM)"
There are several architectures that duplicate definitions of
map_page_into_agp(), unmap_page_from_agp() and flush_agp_cache().
Define those in asm-generic/agp.h and use it instead of duplicated
per-architecture headers.
Signed-off-by: Mike Rapoport (IBM)
From: "Mike Rapoport (IBM)"
There is a copy of alloc_gatt_pages() and free_gatt_pages in several
architectures in arch/$ARCH/include/asm/agp.h. All the copies do exactly
the same: alias alloc_gatt_pages() to __get_free_pages(GFP_KERNEL) and
alias free_gatt_pages() to free_pages(
From: "Mike Rapoport (IBM)"
Hi,
asm/agp.h is duplicated in several architectures, with x86 being the
only instance that differs from the rest.
Introduce asm-generic/agp.h and use it instead of per-architecture
headers for the most cases.
I believe that asm-generic is the best tree
From: "Mike Rapoport (IBM)"
There are several architectures that duplicate definitions of
map_page_into_agp(), unmap_page_from_agp() and flush_agp_cache().
Define those in asm-generic/agp.h and use it instead of duplicated
per-architecture headers.
Signed-off-by: Mike Rapoport (IBM)
From: "Mike Rapoport (IBM)"
There is a copy of alloc_gatt_pages() and free_gatt_pages in several
architectures in arch/$ARCH/include/asm/agp.h. All the copies do exactly
the same: alias alloc_gatt_pages() to __get_free_pages(GFP_KERNEL) and
alias free_gatt_pages() to free_pages(
From: "Mike Rapoport (IBM)"
Hi,
asm/agp.h is duplicated in several architectures, with x86 being the
only instance that differs from the rest.
Introduce asm-generic/agp.h and use it instead of per-architecture
headers for the most cases.
I believe that asm-generic is the best tree
On Thu, Jan 26, 2023 at 11:17:09AM +0200, Mike Rapoport wrote:
> On Wed, Jan 25, 2023 at 12:38:46AM -0800, Suren Baghdasaryan wrote:
> > vm_flags are among VMA attributes which affect decisions like VMA merging
> > and splitting. Therefore all vm_flags modifications are performed a
t
> vm_flags modification attempts.
>
> Signed-off-by: Suren Baghdasaryan
Acked-by: Mike Rapoport (IBM)
> ---
> arch/powerpc/kvm/book3s_hv_uvmem.c | 5 -
> arch/s390/mm/gmap.c| 5 -
> mm/khugepaged.c| 2 ++
> mm/ksm.c
m() function.
>
> Signed-off-by: Suren Baghdasaryan
Acked-by: Mike Rapoport (IBM)
> ---
> mm/debug.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/mm/debug.c b/mm/debug.c
> index 9d3d893dc7f4..96d594e16292 100644
> --- a/mm/debug.c
> +++ b/mm/debug.c
>
On Wed, Jan 25, 2023 at 12:38:47AM -0800, Suren Baghdasaryan wrote:
> To simplify the usage of VM_LOCKED_CLEAR_MASK in clear_vm_flags(),
> replace it with VM_LOCKED_MASK bitmask and convert all users.
>
> Signed-off-by: Suren Baghdasaryan
Acked-by: Mike Rapoport (IBM)
> ---
&
rea_struct *vma,
> + unsigned long flags)
I'd suggest to make it vm_flags_init() etc.
Except that
Acked-by: Mike Rapoport (IBM)
> +{
> + vma->vm_flags = flags;
> +}
> +
> +/* Use when VMA is part of the VMA tree and modif
On Wed, Jan 25, 2023 at 12:38:50AM -0800, Suren Baghdasaryan wrote:
> In cases when VMA flags are modified after VMA was isolated and mmap_lock
> was downgraded, flags modifications would result in an assertion because
> mmap write lock is not held.
> Introduce mod_vm_flags_nolock to be used in
On Wed, Jan 25, 2023 at 12:38:48AM -0800, Suren Baghdasaryan wrote:
> Replace direct modifications to vma->vm_flags with calls to modifier
> functions to be able to track flag changes and to keep vma locking
> correctness.
>
> Signed-off-by: Suren Baghdasaryan
Acked-by:
Hi Conor,
On Tue, Jan 31, 2023 at 05:47:24PM +, Conor Dooley wrote:
> Hey Mike,
>
> On Sun, Jan 29, 2023 at 02:42:35PM +0200, Mike Rapoport wrote:
> > From: "Mike Rapoport (IBM)"
> >
> > Every architecture that supports FLATMEM memory model def
Hi Conor,
On Tue, Jan 31, 2023 at 05:47:24PM +, Conor Dooley wrote:
> Hey Mike,
>
> On Sun, Jan 29, 2023 at 02:42:35PM +0200, Mike Rapoport wrote:
> > From: "Mike Rapoport (IBM)"
> >
> > Every architecture that supports FLATMEM memory model def
Hi Conor,
On Tue, Jan 31, 2023 at 05:47:24PM +, Conor Dooley wrote:
> Hey Mike,
>
> On Sun, Jan 29, 2023 at 02:42:35PM +0200, Mike Rapoport wrote:
> > From: "Mike Rapoport (IBM)"
> >
> > Every architecture that supports FLATMEM memory model def
From: "Mike Rapoport (IBM)"
Every architecture that supports FLATMEM memory model defines its own
version of pfn_valid() that essentially compares a pfn to max_mapnr.
Use mips/powerpc version implemented as static inline as a generic
implementation of pfn_valid() and drop its per-ar
From: "Mike Rapoport (IBM)"
There is stale definition of pfn_valid() for DISCONTINGMEM memory model
guarded !FLATMEM && !SPARSEMEM && NUMA ifdefery.
Remove everything but definition of pfn_valid() for FLATMEM.
Signed-off-by: Mike Rapoport (IBM)
---
arch/mi
From: "Mike Rapoport (IBM)"
The MMU variant uses generic definitions of page_to_pfn() and
pfn_to_page(), but !MMU defines them in include/asm/page_no.h for no
good reason.
Include asm-generic/memory_model.h in the common include/asm/page.h and
drop redundant definitions.
Signed-of
From: "Mike Rapoport (IBM)"
Every architecture that supports FLATMEM memory model defines its own
version of pfn_valid() that essentially compares a pfn to max_mapnr.
Use mips/powerpc version implemented as static inline as a generic
implementation of pfn_valid() and drop its per-ar
From: "Mike Rapoport (IBM)"
Every architecture that supports FLATMEM memory model defines its own
version of pfn_valid() that essentially compares a pfn to max_mapnr.
Use mips/powerpc version implemented as static inline as a generic
implementation of pfn_valid() and drop its per-ar
From: "Mike Rapoport (IBM)"
There is stale definition of pfn_valid() for DISCONTINGMEM memory model
guarded !FLATMEM && !SPARSEMEM && NUMA ifdefery.
Remove everything but definition of pfn_valid() for FLATMEM.
Signed-off-by: Mike Rapoport (IBM)
---
arch/mi
From: "Mike Rapoport (IBM)"
There is stale definition of pfn_valid() for DISCONTINGMEM memory model
guarded !FLATMEM && !SPARSEMEM && NUMA ifdefery.
Remove everything but definition of pfn_valid() for FLATMEM.
Signed-off-by: Mike Rapoport (IBM)
---
arch/mi
From: "Mike Rapoport (IBM)"
Makes it consistent with other architectures and allows for generic
definition of pfn_valid() in asm-generic/memory_model.h with clear override
in arch/arm/include/asm/page.h
Signed-off-by: Mike Rapoport (IBM)
---
arch/arm/include/asm/memory.h | 2 --
From: "Mike Rapoport (IBM)"
The MMU variant uses generic definitions of page_to_pfn() and
pfn_to_page(), but !MMU defines them in include/asm/page_no.h for no
good reason.
Include asm-generic/memory_model.h in the common include/asm/page.h and
drop redundant definitions.
Signed-of
From: "Mike Rapoport (IBM)"
The MMU variant uses generic definitions of page_to_pfn() and
pfn_to_page(), but !MMU defines them in include/asm/page_no.h for no
good reason.
Include asm-generic/memory_model.h in the common include/asm/page.h and
drop redundant definitions.
Signed-of
From: "Mike Rapoport (IBM)"
Makes it consistent with other architectures and allows for generic
definition of pfn_valid() in asm-generic/memory_model.h with clear override
in arch/arm/include/asm/page.h
Signed-off-by: Mike Rapoport (IBM)
---
arch/arm/include/asm/memory.h | 2 --
From: "Mike Rapoport (IBM)"
Makes it consistent with other architectures and allows for generic
definition of pfn_valid() in asm-generic/memory_model.h with clear override
in arch/arm/include/asm/page.h
Signed-off-by: Mike Rapoport (IBM)
---
arch/arm/include/asm/memory.h | 2 --
601 - 700 of 6178 matches
Mail list logo
