From: Mike Rapoport
The memory initialization of SGI-IP27 is already half-way to support
SPARSEMEM. It only had free_bootmem_with_active_regions() left-overs
interfering with sparse_memory_present_with_active_regions().
Replace these calls with simpler memblocks_present() call in prom_meminit
On Mon, Sep 16, 2019 at 11:07:05AM +0200, Thomas Bogendoerfer wrote:
> On Sat, Sep 14, 2019 at 11:41:13AM +0100, Mike Rapoport wrote:
> > On Thu, Sep 12, 2019 at 04:09:12PM +0200, Thomas Bogendoerfer wrote:
> > > On Thu, Sep 12, 2019 at 03:55:39PM +0200, Thomas
From: Mike Rapoport
arm64 calls memblock_free() for the initrd area in its implementation of
free_initrd_mem(), but this call has no actual effect that late in the boot
process. By the time initrd is freed, all the reserved memory is managed by
the page allocator and the memblock.reserved
On Mon, Sep 16, 2019 at 11:17:37AM +0530, Anshuman Khandual wrote:
> In add_memory_resource() the memory range to be hot added first gets into
> the memblock via memblock_add() before arch_add_memory() is called on it.
> Reverse sequence should be followed during memory hot removal which already
>
recognize foo() as a function.
>
> Suggested-by: Mike Rapoport
> Signed-off-by: Cao jin
Reviewed-by: Mike Rapoport
> ---
> mm/memblock.c | 44
> 1 file changed, 20 insertions(+), 24 deletions(-)
>
> diff --git a/mm/memblock.c b/m
Hi Thomas,
On Thu, Sep 12, 2019 at 04:09:12PM +0200, Thomas Bogendoerfer wrote:
> On Thu, Sep 12, 2019 at 03:55:39PM +0200, Thomas Bogendoerfer wrote:
> > - reserved[0xd] [0x00035bff8000-0x00035bff],
> > 0x8000 bytes flags: 0x0
> >
> > I have no idea which
On September 12, 2019 3:09:12 PM GMT+01:00, Thomas Bogendoerfer
wrote:
>On Thu, Sep 12, 2019 at 03:55:39PM +0200, Thomas Bogendoerfer wrote:
>> - reserved[0xd] [0x00035bff8000-0x00035bff],
>0x8000 bytes flags: 0x0
>>
>> I have no idea which reservation this is, but
On Wed, Sep 11, 2019 at 04:09:39PM +0200, Thomas Bogendoerfer wrote:
> On Tue, 10 Sep 2019 12:32:44 +0100
> Mike Rapoport wrote:
>
> > [..]
>
> Patch below works on the same Origin.
>
> Does memblocks_present() deal better with the one re
On Thu, Sep 12, 2019 at 10:54:09AM +0800, Cao jin wrote:
> On 9/11/19 10:42 PM, Mike Rapoport wrote:
> > On Wed, Sep 11, 2019 at 11:08:56AM +0800, Cao jin wrote:
> >> elaboarte -> elaborate
> >> architecure -> architecture
> >> compltes -&g
On September 11, 2019 3:09:39 PM GMT+01:00, Thomas Bogendoerfer
wrote:
>On Tue, 10 Sep 2019 12:32:44 +0100
>Mike Rapoport wrote:
>
>> [..]
>
>Patch below works on the same Origin.
>
>Does memblocks_present() deal better with the one re
On Wed, Sep 11, 2019 at 11:08:56AM +0800, Cao jin wrote:
> elaboarte -> elaborate
> architecure -> architecture
> compltes -> completes
>
> Signed-off-by: Cao jin
> ---
> mm/memblock.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/mm/memblock.c b/mm/memblock.c
On Tue, Sep 10, 2019 at 03:21:28PM +0100, Russell King - ARM Linux admin wrote:
> This is correctly signed off, but Mike didn't send the patch correctly.
> It missed a From: line for the proper author, so the patch was committed
> as if Mike had authored it, which he didn't.
Sorry about that,
On Mon, Sep 09, 2019 at 06:22:42PM +0200, Thomas Bogendoerfer wrote:
> On Fri, 6 Sep 2019 16:02:24 +0300
> Mike Rapoport wrote:
>
> > I suspect that unaligned access comes from __page_to_pfn, can you please
> > check what scripts/fadd2line reports for kernel_init_
On Thu, Sep 05, 2019 at 11:38:00PM +0200, Thomas Bogendoerfer wrote:
> On Thu, 5 Sep 2019 18:47:49 +0300
> Mike Rapoport wrote:
>
> > On Thu, Sep 05, 2019 at 03:48:31PM +0200, Thomas Bogendoerfer wrote:
> > > On Thu, 5 Sep 2019 16:32:53 +0300
> > > Mike Rapop
On Thu, Sep 05, 2019 at 03:48:31PM +0200, Thomas Bogendoerfer wrote:
> On Thu, 5 Sep 2019 16:32:53 +0300
> Mike Rapoport wrote:
>
> > On Thu, Sep 05, 2019 at 03:21:50PM +0200, Thomas Bogendoerfer wrote:
> > > On Thu, 5 Sep 2019 08:47:57 +0300
> > > Mike Rap
On Thu, Sep 05, 2019 at 03:21:50PM +0200, Thomas Bogendoerfer wrote:
> On Thu, 5 Sep 2019 08:47:57 +0300
> Mike Rapoport wrote:
>
> > From: Mike Rapoport
> >
> > The memory initialization of SGI-IP27 is already half-way to support
> > SPARSEMEM and only a
From: Mike Rapoport
The memory initialization of SGI-IP27 is already half-way to support
SPARSEMEM and only a call to sparse_init() was missing. Add it to
prom_meminit() and adjust arch/mips/Kconfig to enable SPARSEMEM and
SPARSEMEM_EXTREME for SGI-IP27
Signed-off-by: Mike Rapoport
---
Thomas
On Mon, Sep 02, 2019 at 03:51:25PM +0200, Michal Simek wrote:
> On 31. 07. 19 19:15, Mike Rapoport wrote:
> > On Wed, Jul 31, 2019 at 04:41:14PM +0200, Michal Hocko wrote:
> >> On Wed 31-07-19 17:21:29, Mike Rapoport wrote:
> >>> On Wed, Jul 31, 2019 at 03:00:
On Wed, Aug 28, 2019 at 04:19:53PM +0200, Christoph Hellwig wrote:
> Add a new header for the two handful of users of the walk_page_range /
> walk_page_vma interface instead of polluting all users of mm.h with it.
>
> Signed-off-by: Christoph Hellwig
> Reviewed-by: Thomas Hellstrom
>
ed-off-by: Logan Gunthorpe
> Reviewed-by: Palmer Dabbelt
> Reviewed-by: Christoph Hellwig
> Cc: Albert Ou
> Cc: Andrew Waterman
> Cc: Olof Johansson
> Cc: Michael Clark
> Cc: Rob Herring
> Cc: Zong Li
Reviewed-by: Mike Rapoport
> ---
> arch/riscv/Kconfi
Hi,
On Wed, Aug 28, 2019 at 10:12:52PM +0800, Guo Ren wrote:
> Acked-by: Guo Ren
Do you mind taking it via csky tree?
> On Wed, Aug 28, 2019 at 9:35 PM Mike Rapoport wrote:
> >
> > The csky implementation of free_initrd_mem() is an open-coded version of
> > free
The csky implementation of free_initrd_mem() is an open-coded version of
free_reserved_area() without poisoning.
Remove it and make csky use the generic version of free_initrd_mem().
Signed-off-by: Mike Rapoport
---
arch/csky/mm/init.c | 16
1 file changed, 16 deletions
On Tue, Aug 27, 2019 at 01:53:23PM +0530, Anup Patel wrote:
> On Tue, Aug 27, 2019 at 1:28 PM Mike Rapoport wrote:
> >
> > On Mon, Aug 26, 2019 at 04:32:56PM -0700, Atish Patra wrote:
> > > The SBI v0.2 introduces a base extension which is backward compatible
> > >
On Tue, Aug 27, 2019 at 01:58:03PM +0530, Anup Patel wrote:
> On Tue, Aug 27, 2019 at 1:21 PM Mike Rapoport wrote:
> >
> > On Mon, Aug 26, 2019 at 04:32:55PM -0700, Atish Patra wrote:
> > > As per the new SBI specification, current SBI implementation is
> > > defi
On Mon, Aug 26, 2019 at 04:32:55PM -0700, Atish Patra wrote:
> As per the new SBI specification, current SBI implementation is
> defined as legacy and will be removed/replaced in future.
>
> Rename existing implementation to reflect that. This patch is just
> a preparatory patch for SBI v0.2 and
On Mon, Aug 26, 2019 at 04:32:56PM -0700, Atish Patra wrote:
> The SBI v0.2 introduces a base extension which is backward compatible
> with v0.1. Implement all helper functions and minimum required SBI
> calls from v0.2 for now. All other base extension function will be
> added later as per need.
On Tue, Aug 27, 2019 at 03:36:54PM +1000, Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> Use the function written to do it instead.
>
> Signed-off-by: Alastair D'Silva
Acked-by: Mike Rapoport
> ---
> mm/sparse.c | 4 +++-
> 1 file changed, 3 insertions(+),
On Thu, Aug 22, 2019 at 10:04:39AM -0600, Logan Gunthorpe wrote:
> This patch implements sparsemem support for risc-v which helps pave the
Please avoid "This patch" in the commit message:
git grep "This patch" Documentation/process/submitting-patches.rst
> way for memory hotplug and eventually
Hi,
On Thu, Aug 22, 2019 at 09:52:07AM +0200, Rasmus Villemoes wrote:
> init_mm is sizeof(long) larger than it needs to be. Use the
> CPU_BITS_NONE macro meant for this, which will initialize just the
> indices 0...(BITS_TO_LONGS(NR_CPUS)-1) and hence make the array size
> actually
implementation of pgd_cache_init(). Since there is no such default for
pgtable_cache_init(), its empty stub is duplicated among most
architectures.
Rename the definitions of pgd_cache_init() to pgtable_cache_init() and drop
empty stubs of pgtable_cache_init().
Signed-off-by: Mike Rapoport
Acked
t the change to disregard
> NOMAP memblocks in adjust_lowmem_bounds() should be separated as a single
> patch.
>
> Please let me know if any suggestion, thank you.
Let's add this one to the series:
>From 06a986e79d60c310c804b3e550bd50316597aec5 Mon Sep 17 00:00:00 2001
From: Mike Rapoport
Date: Thu, 22 Aug 2019
lculating
> the boundary.
>
> Signed-off-by: Chester Lin
Reviewed-by: Mike Rapoport
> ---
> arch/arm/mm/mmu.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> index 426d9085396b..b86dba44d828 100644
> --- a/arch
On Wed, Aug 21, 2019 at 06:17:12PM +0200, Marc Gonzalez wrote:
> On 21/08/2019 17:06, Mike Rapoport wrote:
>
> > Both pgtable_cache_init() and pgd_cache_init() are used to initialize kmem
> > cache for page table allocations on several architectures that do not use
> >
On Wed, Aug 21, 2019 at 04:49:42PM +0100, Will Deacon wrote:
> On Wed, Aug 21, 2019 at 06:06:58PM +0300, Mike Rapoport wrote:
> > Both pgtable_cache_init() and pgd_cache_init() are used to initialize kmem
> > cache for page table allocations on several architectures that do not us
On Wed, Aug 21, 2019 at 08:15:44AM -0700, Matthew Wilcox wrote:
> On Wed, Aug 21, 2019 at 06:06:58PM +0300, Mike Rapoport wrote:
> > +++ b/arch/alpha/include/asm/pgtable.h
> > @@ -362,7 +362,6 @@ extern void paging_init(void);
> > /*
> > * No page
implementation of pgd_cache_init(). Since there is no such default for
pgtable_cache_init(), its empty stub is duplicated among most
architectures.
Rename the definitions of pgd_cache_init() to pgtable_cache_init() and drop
empty stubs of pgtable_cache_init().
Signed-off-by: Mike Rapoport
be triggered from
userspace via /proc/kpageflags
Otherwise:
Reviewed-by: Mike Rapoport
> Signed-off-by: Zhaoyang Huang
> ---
> arch/arm/mm/init.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> index c2daabb..cc769fa
On Sun, Aug 18, 2019 at 03:46:51PM +0800, Zhaoyang Huang wrote:
> On Sun, Aug 18, 2019 at 2:32 AM Russell King - ARM Linux admin
> wrote:
> >
> > On Sat, Aug 17, 2019 at 11:00:13AM +0800, Zhaoyang Huang wrote:
> > > From: Zhaoyang Huang
> > >
> > > pfn_valid can be wrong while the MSB of
On Sat, Aug 17, 2019 at 11:00:13AM +0800, Zhaoyang Huang wrote:
> From: Zhaoyang Huang
>
> pfn_valid can be wrong while the MSB of physical address be trimed as pfn
> larger than the max_pfn.
How the overflow of __pfn_to_phys() is related to max_pfn?
Where is the guarantee that
hexagon never reserves or initializes initrd and the only mention of it is
the empty free_initrd_mem() function.
As we have a generic implementation of free_initrd_mem(), there is no need
to define an empty stub for the hexagon implementation and it can be
dropped.
Signed-off-by: Mike Rapoport
On Thu, Aug 15, 2019 at 02:10:49PM +1000, Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> When presented with large amounts of memory being hotplugged
> (in my test case, ~890GB), the call to flush_dcache_range takes
> a while (~50 seconds), triggering RCU stalls.
>
> This patch breaks up
On Tue, Aug 13, 2019 at 11:20:50AM +0100, Mark Rutland wrote:
> On Tue, Aug 13, 2019 at 01:09:12PM +0300, Mike Rapoport wrote:
> > The microblaze implementation of pte_alloc_one() has a provision to
> > allocated PTEs from high memory, but neither CONFIG_HIGHPTE nor pte_map*
as the implementations of pte_free() and
pte_free_kernel().
Switch microblaze to use the generic versions of these functions.
Also remove pte_free_slow() that is not referenced anywhere in the code.
Signed-off-by: Mike Rapoport
---
The patch is vs. mmots/master since this tree contains bothi "mm: r
On Thu, Aug 08, 2019 at 11:56:32PM +0200, Christoph Hellwig wrote:
> On Thu, Aug 08, 2019 at 10:50:37AM -0700, Linus Torvalds wrote:
> > > Note that both Thomas and Steven have series touching this area pending,
> > > and there are a couple consumer in flux too - the hmm tree already
> > >
Signed-off-by: Mike Rapoport
---
arch/alpha/include/asm/pgalloc.h | 2 -
arch/arc/include/asm/pgalloc.h| 1 -
arch/arm/include/asm/pgalloc.h| 2 -
arch/arm64/include/asm/pgalloc.h | 2 -
arch/csky/include/asm/pgalloc.h | 2 -
arch/hexagon/include/asm/pgalloc.
The sh implementation pte_alloc_one(), pte_alloc_one_kernel(),
pte_free_kernel() and pte_free() is identical to the generic except of lack
of __GFP_ACCOUNT for the user PTEs allocation.
Switch sh to use generic version of these functions.
Signed-off-by: Mike Rapoport
---
arch/sh/include/asm
The ia64 implementation pte_alloc_one(), pte_alloc_one_kernel(),
pte_free_kernel() and pte_free() is identical to the generic except of lack
of __GFP_ACCOUNT for the user PTEs allocation.
Switch ia64 to use generic version of these functions.
Signed-off-by: Mike Rapoport
---
arch/ia64/include
Hi,
I while ago Nicholas proposed to remove quicklist page table caches [1].
I've rebased his patch on the curren upstream and switched ia64 and sh to
use generic versions of PTE allocation.
[1] https://lore.kernel.org/linux-mm/20190711030339.20892-1-npig...@gmail.com
Mike Rapoport (2):
ia64
The madvise_behavior() function converts -ENOMEM to -EAGAIN in several
places using identical code.
Move that code to a common error handling path.
No functional changes.
Signed-off-by: Mike Rapoport
---
mm/madvise.c | 52
1 file changed
On Wed, Jul 31, 2019 at 04:41:14PM +0200, Michal Hocko wrote:
> On Wed 31-07-19 17:21:29, Mike Rapoport wrote:
> > On Wed, Jul 31, 2019 at 03:00:37PM +0200, Michal Hocko wrote:
> > >
> > > I am sorry, but I still do not follow. Who is consuming that node id
> > &g
On Wed, Jul 31, 2019 at 03:00:37PM +0200, Michal Hocko wrote:
> On Wed 31-07-19 15:26:32, Mike Rapoport wrote:
> > On Wed, Jul 31, 2019 at 01:40:16PM +0200, Michal Hocko wrote:
> > > On Wed 31-07-19 14:14:22, Mike Rapoport wrote:
> > > > On Wed, Jul 31, 2019 at 10:03:
On Wed, Jul 31, 2019 at 01:40:16PM +0200, Michal Hocko wrote:
> On Wed 31-07-19 14:14:22, Mike Rapoport wrote:
> > On Wed, Jul 31, 2019 at 10:03:09AM +0200, Michal Hocko wrote:
> > > On Wed 31-07-19 09:24:21, Mike Rapoport wrote:
> > > > [ sorry for a late reply too
On Wed, Jul 31, 2019 at 10:03:09AM +0200, Michal Hocko wrote:
> On Wed 31-07-19 09:24:21, Mike Rapoport wrote:
> > [ sorry for a late reply too, somehow I missed this thread before ]
> >
> > On Tue, Jul 30, 2019 at 10:14:15AM +0200, Michal Hocko wrote:
> >
[ sorry for a late reply too, somehow I missed this thread before ]
On Tue, Jul 30, 2019 at 10:14:15AM +0200, Michal Hocko wrote:
> [Sorry for a late reply]
>
> On Mon 15-07-19 17:55:07, Hoan Tran OS wrote:
> > Hi,
> >
> > On 7/12/19 10:00 PM, Michal Hocko wrote:
> [...]
> > > Hmm, I thought
free_initrd_mem() implementation.
Signed-off-by: Mike Rapoport
---
arch/xtensa/kernel/setup.c | 9 +++--
arch/xtensa/mm/init.c | 10 --
2 files changed, 3 insertions(+), 16 deletions(-)
diff --git a/arch/xtensa/kernel/setup.c b/arch/xtensa/kernel/setup.c
index 5cb8a62..63c865b
On Tue, Jul 23, 2019 at 01:51:13PM +0800, Hanjun Guo wrote:
> From: Jia He
>
> After skipping some invalid pfns in memmap_init_zone(), there is still
> some room for improvement.
>
> E.g. if pfn and pfn+1 are in the same memblock region, we can simply pfn++
> instead of doing the binary search
On Tue, Jul 23, 2019 at 01:51:12PM +0800, Hanjun Guo wrote:
> From: Jia He
>
> Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns
> where possible") optimized the loop in memmap_init_zone(). But it causes
> possible panic on x86 due to specific memory mapping on x86_64 which
lashes aligned.
>
> There should be no functional change as a result of this patch.
>
> Signed-off-by: Mark Rutland
> Cc: Andrew Morton
> Cc: Anshuman Khandual
> Cc: Matthew Wilcox
> Cc: Michal Hocko
> Cc: Yu Zhao
> Cc: linux...@kvack.org
Reviewed-by: Mike Rapoport
still go in?
--
Sincerely yours,
Mike.
>From e298accfb0b023de70e255adf3f9a8d1b2c01063 Mon Sep 17 00:00:00 2001
From: Mike Rapoport
Date: Tue, 30 Apr 2019 17:27:50 +0300
Subject: [PATCH v2 06/14] hexagon: switch to generic version of pte allocation
The hexagon implementation pte_alloc_
On Wed, Jul 17, 2019 at 11:41:34PM -0300, Leonardo Bras wrote:
> Adds an option on kernel config to make hot-added memory online in
> ZONE_MOVABLE by default.
>
> This would be great in systems with MEMORY_HOTPLUG_DEFAULT_ONLINE=y by
> allowing to choose which zone it will be auto-onlined
On Fri, Jul 12, 2019 at 10:45:06AM -0600, Andy Lutomirski wrote:
>
>
> > On Jul 12, 2019, at 10:37 AM, Alexandre Chartre
> > wrote:
> >
> >
> >
> >> On 7/12/19 5:16 PM, Thomas Gleixner wrote:
> >>> On Fri, 12 Jul 2019, Peter Zijlstra wrote:
> On Fri, Jul 12, 2019 at 01:56:44PM +0200,
On Thu, Jul 11, 2019 at 01:11:43PM -0700, Andi Kleen wrote:
> Alexandre Chartre writes:
> > jmp paranoid_exit
> > @@ -1182,6 +1196,16 @@ ENTRY(paranoid_entry)
> > xorl%ebx, %ebx
> >
> > 1:
> > +#ifdef CONFIG_ADDRESS_SPACE_ISOLATION
> > + /*
> > +* If address space
On Tue, Jun 18, 2019 at 10:52:29PM -0700, Dan Williams wrote:
> Explain the general mechanisms of 'ZONE_DEVICE' pages and list the users
> of 'devm_memremap_pages()'.
>
> Cc: Jonathan Corbet
> Reported-by: Mike Rapoport
> Signed-off-by: Dan Williams
With one nit below
in pgd_cache_init().
Fixes: caa841360134 ("x86/mm: Initialize PGD cache during mm initialization")
Signed-off-by: Mike Rapoport
---
arch/arm64/include/asm/pgtable.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm
On Mon, Jun 17, 2019 at 05:36:30PM +0100, Will Deacon wrote:
> Hi Mike,
>
> On Mon, Jun 17, 2019 at 06:12:52PM +0300, Mike Rapoport wrote:
> > Andrew, can you please add the patch below as an incremental fix?
> >
> > With this the arm64::pgd_alloc() s
On Thu, Jun 13, 2019 at 03:11:01PM +0300, Mike Rapoport wrote:
> On Tue, Jun 11, 2019 at 11:03:49AM +0100, Mark Rutland wrote:
> > On Mon, Jun 10, 2019 at 01:26:15PM -0400, Qian Cai wrote:
> > > On Mon, 2019-06-10 at 12:43 +0100, Will Deacon wrote:
> > > > On Tue, Ju
On Mon, Jun 17, 2019 at 02:36:30PM +1000, Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> When removing sufficiently large amounts of memory, we trigger RCU stall
> detection. By periodically calling cond_resched(), we avoid bogus stall
> warnings.
>
> Signed-off-by: Alastair D'Silva
>
On Mon, Jun 17, 2019 at 02:36:29PM +1000, Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> Use the function written to do it instead.
>
> Signed-off-by: Alastair D'Silva
Reviewed-by: Mike Rapoport
> ---
> mm/sparse.c | 4 +++-
> 1 file changed, 3 insertions(+),
tch passes the offset to clear_hwpoisoned_pages instead, allowing
> memmap to successfully peform it's null check.
>
> Signed-off-by: Alastair D'Silva
One nit below, otherwise
Reviewed-by: Mike Rapoport
> ---
> mm/sparse.c | 12 +++-
> 1 file changed, 7 insertions(
On Mon, Jun 17, 2019 at 02:36:27PM +1000, Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> If a memory section comes in where the physical address is greater than
> that which is managed by the kernel, this function would not trigger the
> bug and instead return a bogus section number.
>
>
On Thu, Jun 13, 2019 at 09:22:36AM -0400, Qian Cai wrote:
> On Thu, 2019-06-13 at 15:11 +0300, Mike Rapoport wrote:
> > The log Qian Cai posted at [1] and partially cited below confirms that the
> > failure happens when *user* PGDs are allocated and the addition of
> > __GFP
FDT to RO after early fixups are done.
>
> Signed-off-by: Hsin-Yi Wang
> Reviewed-by: Stephen Boyd
Reviewed-by: Mike Rapoport
> ---
> change log v5->v6:
> * no change.
> ---
> arch/arm64/include/asm/mmu.h | 2 +-
> arch/arm64/kernel/kaslr.c| 5 +
> ar
(added Roman)
On Tue, Jun 11, 2019 at 11:03:49AM +0100, Mark Rutland wrote:
> On Mon, Jun 10, 2019 at 01:26:15PM -0400, Qian Cai wrote:
> > On Mon, 2019-06-10 at 12:43 +0100, Will Deacon wrote:
> > > On Tue, Jun 04, 2019 at 03:23:38PM +0100, Mark Rutland wrote:
> > > > On Tue, Jun 04, 2019 at
Hi,
On Tue, Jun 11, 2019 at 08:46:45AM -0400, Qian Cai wrote:
>
> > On Jun 11, 2019, at 8:41 AM, Mike Rapoport wrote:
> >
> > Sorry for the delay, I'm mostly offline these days.
> >
> > I wanted to understand first what is the reason for the failure. I've tr
On Tue, Jun 11, 2019 at 11:03:49AM +0100, Mark Rutland wrote:
> On Mon, Jun 10, 2019 at 01:26:15PM -0400, Qian Cai wrote:
> > On Mon, 2019-06-10 at 12:43 +0100, Will Deacon wrote:
> > > On Tue, Jun 04, 2019 at 03:23:38PM +0100, Mark Rutland wrote:
> > > > On Tue, Jun 04, 2019 at 10:00:36AM -0400,
Hi Tejun,
On Wed, Jun 05, 2019 at 06:53:19AM -0700, Tejun Heo wrote:
> Hello, Daniel.
>
> On Wed, Jun 05, 2019 at 09:36:45AM -0400, Daniel Jordan wrote:
> > My use case for this work is kernel multithreading, the series formerly
> > known
> > as ktask[2] that I'm now trying to combine with
On Tue, Jun 04, 2019 at 03:30:20PM +0100, Mark Rutland wrote:
> On Tue, Jun 04, 2019 at 03:23:38PM +0100, Mark Rutland wrote:
> > On Tue, Jun 04, 2019 at 10:00:36AM -0400, Qian Cai wrote:
> > > The commit "arm64: switch to generic version of pte allocation"
> > > introduced endless failures during
On Tue, Jun 04, 2019 at 03:23:38PM +0100, Mark Rutland wrote:
> On Tue, Jun 04, 2019 at 10:00:36AM -0400, Qian Cai wrote:
> > The commit "arm64: switch to generic version of pte allocation"
> > introduced endless failures during boot like,
> >
> > kobject_add_internal failed for
On Wed, May 08, 2019 at 05:43:20PM +0300, Kirill A. Shutemov wrote:
> = Intro =
>
> The patchset brings enabling of Intel Multi-Key Total Memory Encryption.
> It consists of changes into multiple subsystems:
>
> * Core MM: infrastructure for allocation pages, dealing with encrypted VMAs
>
On Wed, May 08, 2019 at 05:44:17PM +0300, Kirill A. Shutemov wrote:
> From: Alison Schofield
>
> Provide an overview of MKTME on Intel Platforms.
>
> Signed-off-by: Alison Schofield
> Signed-off-by: Kirill A. Shutemov
> ---
> Documentation/x86/mktme/index.rst | 8 +++
>
On Wed, May 08, 2019 at 05:43:25PM +0300, Kirill A. Shutemov wrote:
> For encrypted memory, we need to allocate pages for a specific
> encryption KeyID.
>
> There are two cases when we need to allocate a page for encryption:
>
> - Allocation for an encrypted VMA;
>
> - Allocation for
On Wed, May 08, 2019 at 05:44:03PM +0300, Kirill A. Shutemov wrote:
> From: Alison Schofield
>
> encrypt_mprotect() is a new system call to support memory encryption.
>
> It takes the same parameters as legacy mprotect, plus an additional
> key serial number that is mapped to an encryption
On Wed, May 08, 2019 at 05:43:22PM +0300, Kirill A. Shutemov wrote:
> When kernel setups an encrypted page mapping, encryption KeyID is
Nit: "when kernel sets up an encrypted..."
> derived from a VMA. KeyID is going to be part of vma->vm_page_prot and
> it will be propagated transparently to
);
>
> Signed-off-by: Alakesh Haloi
Reviewed-by: Mike Rapoport
> ---
> tools/testing/selftests/vm/userfaultfd.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/vm/userfaultfd.c
> b/tools/testing/selftests/vm/userfa
On Thu, May 23, 2019 at 05:04:18PM -0700, Stephen Boyd wrote:
> Quoting Hsin-Yi Wang (2019-05-19 09:04:44)
> > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> > index a170c6369a68..29648e86f7e5 100644
> > --- a/arch/arm64/mm/mmu.c
> > +++ b/arch/arm64/mm/mmu.c
> > @@ -940,12 +940,12 @@
On Thu, May 23, 2019 at 10:31:38AM +0100, Will Deacon wrote:
> Hi Steven,
>
> On Thu, May 16, 2019 at 03:20:59PM +0100, Steven Price wrote:
> > I'll spin a real patch and add your Tested-by
>
> Did you send this out? I can't spot it in my inbox.
(added kvm)
On Wed, May 22, 2019 at 12:21:13PM -0700, Andrew Morton wrote:
> On Tue, 14 May 2019 17:29:55 +0300 Mike Rapoport wrote:
>
> > When get_user_pages*() is called with pages = NULL, the processing of
> > VM_FAULT_RETRY terminates early without actually retryi
On Wed, May 22, 2019 at 09:47:04AM +0200, Geert Uytterhoeven wrote:
> Hi Mike,
>
> On Tue, May 21, 2019 at 5:53 PM Mike Rapoport wrote:
> > On Tue, May 21, 2019 at 04:56:39PM +0200, Geert Uytterhoeven wrote:
> > > On Wed, Apr 24, 2019 at 12:50 AM S
Hi,
Any comments on this?
On Tue, May 14, 2019 at 05:29:55PM +0300, Mike Rapoport wrote:
> When get_user_pages*() is called with pages = NULL, the processing of
> VM_FAULT_RETRY terminates early without actually retrying to fault-in all
> the pages.
>
> If the pages in the
Gentle ping ...
On Wed, May 15, 2019 at 08:41:22AM +0300, Mike Rapoport wrote:
> Since commit 350e88bad496 ("mm: memblock: make keeping memblock memory
> opt-in rather than opt-out") the default behaviour is to discard memblock
> data after init and the ARCH_DISCARD_M
Hi Geert,
On Tue, May 21, 2019 at 04:56:39PM +0200, Geert Uytterhoeven wrote:
> Hi Serge,
>
> On Wed, Apr 24, 2019 at 12:50 AM Serge Semin wrote:
> > The reserved_end variable had been used by the bootmem_init() code
> > to find a lowest limit of memory available for memmap blob. The original
>
f opening /initrd.image
> fails")
> Reported-by: Mark Rutland
> Tested-by: Mark Rutland
> Signed-off-by: Steven Price
> ---
Reviewed-by: Mike Rapoport
> init/initramfs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/init/initramf
On Thu, May 16, 2019 at 02:41:06PM +0100, Mark Rutland wrote:
> On Thu, May 16, 2019 at 02:38:20PM +0100, Mark Rutland wrote:
> > Hi,
> >
> > Since commit:
> >
> > 54c7a8916a887f35 ("initramfs: free initrd memory if opening /initrd.image
> > fails")
>
> Ugh, I dropped a paragarph here.
>
>
Andrew,
Can this go via the -mm tree?
On Wed, May 01, 2019 at 10:56:14PM +0300, Mike Rapoport wrote:
> Hi,
>
> For several architectures the ARCH_SELECT_MEMORY_MODEL has no real effect
> because the dependencies for the memory model are always evaluated to a
> single val
Since commit 350e88bad496 ("mm: memblock: make keeping memblock memory
opt-in rather than opt-out") the default behaviour is to discard memblock
data after init and the ARCH_DISCARD_MEMBLOCK is obsolete.
Remove it.
Signed-off-by: Mike Rapoport
---
arch/parisc/Kconfig | 1 -
1 file
the retry for pre-fault case in get_user_pages()
causes a crash of the restored process.
Making the pre-fault behavior of get_user_pages() the same as the "normal"
one fixes the issue.
Fixes: d9c9ce34ed5c ("x86/fpu: Fault-in user stack if
copy_fpstate_to_sigframe() fails")
Signed-
Hi Dan,
On Mon, May 06, 2019 at 04:39:26PM -0700, Dan Williams wrote:
> Changes since v7 [1]:
Sorry for jumping late, but presuming there will be v9, it'd be great if it
would also include include updates to
Documentation/admin-guide/mm/memory-hotplug.rst and
Documentation/vm/memory-model.rst
one and can be
simply dropped.
Signed-off-by: Mike Rapoport
---
arch/nds32/include/asm/pgalloc.h | 31 ---
1 file changed, 4 insertions(+), 27 deletions(-)
diff --git a/arch/nds32/include/asm/pgalloc.h b/arch/nds32/include/asm/pgalloc.h
index 3c5fee5..954696c 100644
The hexagon implementation pte_alloc_one(), pte_alloc_one_kernel(),
pte_free_kernel() and pte_free() is identical to the generic except of
lack of __GFP_ACCOUNT for the user PTEs allocation.
Switch hexagon to use generic version of these functions.
Signed-off-by: Mike Rapoport
---
arch/hexagon
check for pte.
The pte_free() version on arm64 is identical to the generic one and
can be simply dropped.
Signed-off-by: Mike Rapoport
---
arch/arm64/include/asm/pgalloc.h | 47 +++-
arch/arm64/mm/mmu.c | 2 +-
arch/arm64/mm/pgd.c | 9
1201 - 1300 of 2824 matches
Mail list logo
