From: Michael Ellerman <mpe@ellerman.id.au> To: Mike Rapoport <rppt@linux.ibm.com> Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH v2 10/21] memblock: refactor internal allocation functions Date: Mon, 04 Feb 2019 19:45:17 +1100 [thread overview] Message-ID: <878sywndr6.fsf@concordia.ellerman.id.au> (raw) In-Reply-To: <20190203113915.GC8620@rapoport-lnx> Mike Rapoport <rppt@linux.ibm.com> writes: > On Sun, Feb 03, 2019 at 08:39:20PM +1100, Michael Ellerman wrote: >> Mike Rapoport <rppt@linux.ibm.com> writes: >> > Currently, memblock has several internal functions with overlapping >> > functionality. They all call memblock_find_in_range_node() to find free >> > memory and then reserve the allocated range and mark it with kmemleak. >> > However, there is difference in the allocation constraints and in fallback >> > strategies. ... >> >> This is causing problems on some of my machines. ... >> >> On some of my other systems it does that, and then panics because it >> can't allocate anything at all: >> >> [ 0.000000] numa: NODE_DATA [mem 0x7ffcaee80-0x7ffcb3fff] >> [ 0.000000] numa: NODE_DATA [mem 0x7ffc99d00-0x7ffc9ee7f] >> [ 0.000000] numa: NODE_DATA(1) on node 0 >> [ 0.000000] Kernel panic - not syncing: Cannot allocate 20864 bytes for node 16 data >> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.0.0-rc4-gccN-next-20190201-gdc4c899 #1 >> [ 0.000000] Call Trace: >> [ 0.000000] [c0000000011cfca0] [c000000000c11044] dump_stack+0xe8/0x164 (unreliable) >> [ 0.000000] [c0000000011cfcf0] [c0000000000fdd6c] panic+0x17c/0x3e0 >> [ 0.000000] [c0000000011cfd90] [c000000000f61bc8] initmem_init+0x128/0x260 >> [ 0.000000] [c0000000011cfe60] [c000000000f57940] setup_arch+0x398/0x418 >> [ 0.000000] [c0000000011cfee0] [c000000000f50a94] start_kernel+0xa0/0x684 >> [ 0.000000] [c0000000011cff90] [c00000000000af70] start_here_common+0x1c/0x52c >> [ 0.000000] Rebooting in 180 seconds.. >> >> >> So there's something going wrong there, I haven't had time to dig into >> it though (Sunday night here). > > Yeah, I've misplaced 'nid' and 'MEMBLOCK_ALLOC_ACCESSIBLE' in > memblock_phys_alloc_try_nid() :( > > Can you please check if the below patch fixes the issue on your systems? Yes it does, thanks. Tested-by: Michael Ellerman <mpe@ellerman.id.au> cheers > From 5875b7440e985ce551e6da3cb28aa8e9af697e10 Mon Sep 17 00:00:00 2001 > From: Mike Rapoport <rppt@linux.ibm.com> > Date: Sun, 3 Feb 2019 13:35:42 +0200 > Subject: [PATCH] memblock: fix parameter order in > memblock_phys_alloc_try_nid() > > The refactoring of internal memblock allocation functions used wrong order > of parameters in memblock_alloc_range_nid() call from > memblock_phys_alloc_try_nid(). > Fix it. > > Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> > --- > mm/memblock.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/mm/memblock.c b/mm/memblock.c > index e047933..0151a5b 100644 > --- a/mm/memblock.c > +++ b/mm/memblock.c > @@ -1402,8 +1402,8 @@ phys_addr_t __init memblock_phys_alloc_range(phys_addr_t size, > > phys_addr_t __init memblock_phys_alloc_try_nid(phys_addr_t size, phys_addr_t align, int nid) > { > - return memblock_alloc_range_nid(size, align, 0, nid, > - MEMBLOCK_ALLOC_ACCESSIBLE); > + return memblock_alloc_range_nid(size, align, 0, > + MEMBLOCK_ALLOC_ACCESSIBLE, nid); > } > > /** > -- > 2.7.4 > > > -- > Sincerely yours, > Mike.
WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <mpe@ellerman.id.au> To: Mike Rapoport <rppt@linux.ibm.com> Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 10/21] memblock: refactor internal allocation functions Date: Mon, 04 Feb 2019 19:45:17 +1100 [thread overview] Message-ID: <878sywndr6.fsf@concordia.ellerman.id.au> (raw) In-Reply-To: <20190203113915.GC8620@rapoport-lnx> Mike Rapoport <rppt@linux.ibm.com> writes: > On Sun, Feb 03, 2019 at 08:39:20PM +1100, Michael Ellerman wrote: >> Mike Rapoport <rppt@linux.ibm.com> writes: >> > Currently, memblock has several internal functions with overlapping >> > functionality. They all call memblock_find_in_range_node() to find free >> > memory and then reserve the allocated range and mark it with kmemleak. >> > However, there is difference in the allocation constraints and in fallback >> > strategies. ... >> >> This is causing problems on some of my machines. ... >> >> On some of my other systems it does that, and then panics because it >> can't allocate anything at all: >> >> [ 0.000000] numa: NODE_DATA [mem 0x7ffcaee80-0x7ffcb3fff] >> [ 0.000000] numa: NODE_DATA [mem 0x7ffc99d00-0x7ffc9ee7f] >> [ 0.000000] numa: NODE_DATA(1) on node 0 >> [ 0.000000] Kernel panic - not syncing: Cannot allocate 20864 bytes for node 16 data >> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.0.0-rc4-gccN-next-20190201-gdc4c899 #1 >> [ 0.000000] Call Trace: >> [ 0.000000] [c0000000011cfca0] [c000000000c11044] dump_stack+0xe8/0x164 (unreliable) >> [ 0.000000] [c0000000011cfcf0] [c0000000000fdd6c] panic+0x17c/0x3e0 >> [ 0.000000] [c0000000011cfd90] [c000000000f61bc8] initmem_init+0x128/0x260 >> [ 0.000000] [c0000000011cfe60] [c000000000f57940] setup_arch+0x398/0x418 >> [ 0.000000] [c0000000011cfee0] [c000000000f50a94] start_kernel+0xa0/0x684 >> [ 0.000000] [c0000000011cff90] [c00000000000af70] start_here_common+0x1c/0x52c >> [ 0.000000] Rebooting in 180 seconds.. >> >> >> So there's something going wrong there, I haven't had time to dig into >> it though (Sunday night here). > > Yeah, I've misplaced 'nid' and 'MEMBLOCK_ALLOC_ACCESSIBLE' in > memblock_phys_alloc_try_nid() :( > > Can you please check if the below patch fixes the issue on your systems? Yes it does, thanks. Tested-by: Michael Ellerman <mpe@ellerman.id.au> cheers > From 5875b7440e985ce551e6da3cb28aa8e9af697e10 Mon Sep 17 00:00:00 2001 > From: Mike Rapoport <rppt@linux.ibm.com> > Date: Sun, 3 Feb 2019 13:35:42 +0200 > Subject: [PATCH] memblock: fix parameter order in > memblock_phys_alloc_try_nid() > > The refactoring of internal memblock allocation functions used wrong order > of parameters in memblock_alloc_range_nid() call from > memblock_phys_alloc_try_nid(). > Fix it. > > Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> > --- > mm/memblock.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/mm/memblock.c b/mm/memblock.c > index e047933..0151a5b 100644 > --- a/mm/memblock.c > +++ b/mm/memblock.c > @@ -1402,8 +1402,8 @@ phys_addr_t __init memblock_phys_alloc_range(phys_addr_t size, > > phys_addr_t __init memblock_phys_alloc_try_nid(phys_addr_t size, phys_addr_t align, int nid) > { > - return memblock_alloc_range_nid(size, align, 0, nid, > - MEMBLOCK_ALLOC_ACCESSIBLE); > + return memblock_alloc_range_nid(size, align, 0, > + MEMBLOCK_ALLOC_ACCESSIBLE, nid); > } > > /** > -- > 2.7.4 > > > -- > Sincerely yours, > Mike.
next prev parent reply other threads:[~2019-02-04 8:45 UTC|newest] Thread overview: 469+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-01-21 8:03 [PATCH v2 00/21] Refine memblock API Mike Rapoport 2019-01-21 8:03 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 01/21] openrisc: prefer memblock APIs returning virtual address Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [v2,01/21] " Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 01/21] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-27 3:07 ` Stafford Horne 2019-01-27 3:07 ` Stafford Horne 2019-01-27 3:07 ` [OpenRISC] " Stafford Horne 2019-01-27 3:07 ` Stafford Horne 2019-01-27 3:07 ` Stafford Horne 2019-01-27 3:07 ` [v2,01/21] " Stafford Horne 2019-01-27 3:07 ` [PATCH v2 01/21] " Stafford Horne 2019-01-27 3:07 ` Stafford Horne 2019-01-27 3:07 ` Stafford Horne 2019-01-21 8:03 ` [PATCH v2 02/21] powerpc: use memblock functions " Mike Rapoport 2019-01-21 8:03 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [v2,02/21] " Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 02/21] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-29 9:52 ` Michael Ellerman 2019-01-29 9:52 ` [OpenRISC] " Michael Ellerman 2019-01-29 9:52 ` Michael Ellerman 2019-01-29 9:52 ` Michael Ellerman 2019-01-29 9:52 ` [v2,02/21] " Michael Ellerman 2019-01-29 9:52 ` [PATCH v2 02/21] " Michael Ellerman 2019-01-29 9:52 ` Michael Ellerman 2019-01-29 9:52 ` Michael Ellerman 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 03/21] memblock: replace memblock_alloc_base(ANYWHERE) with memblock_phys_alloc Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [v2,03/21] " Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 03/21] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 04/21] memblock: drop memblock_alloc_base_nid() Mike Rapoport 2019-01-21 8:03 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [v2,04/21] " Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 04/21] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 05/21] memblock: emphasize that memblock_alloc_range() returns a physical address Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [v2,05/21] " Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 05/21] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 06/21] memblock: memblock_phys_alloc_try_nid(): don't panic Mike Rapoport 2019-01-21 8:03 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [v2,06/21] " Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 06/21] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-25 17:45 ` Catalin Marinas 2019-01-25 17:45 ` Catalin Marinas 2019-01-25 17:45 ` [OpenRISC] " Catalin Marinas 2019-01-25 17:45 ` Catalin Marinas 2019-01-25 17:45 ` Catalin Marinas 2019-01-25 17:45 ` [v2,06/21] " Catalin Marinas 2019-01-25 17:45 ` [PATCH v2 06/21] " Catalin Marinas 2019-01-25 17:45 ` Catalin Marinas 2019-01-25 17:45 ` Catalin Marinas 2019-01-25 19:32 ` Mike Rapoport 2019-01-25 19:32 ` [OpenRISC] " Mike Rapoport 2019-01-25 19:32 ` Mike Rapoport 2019-01-25 19:32 ` Mike Rapoport 2019-01-25 19:32 ` [v2,06/21] " Mike Rapoport 2019-01-25 19:32 ` [PATCH v2 06/21] " Mike Rapoport 2019-01-25 19:32 ` Mike Rapoport 2019-01-25 19:32 ` Mike Rapoport 2019-01-25 19:32 ` Mike Rapoport 2019-01-29 9:56 ` Michael Ellerman 2019-01-29 9:56 ` Michael Ellerman 2019-01-29 9:56 ` [OpenRISC] " Michael Ellerman 2019-01-29 9:56 ` Michael Ellerman 2019-01-29 9:56 ` Michael Ellerman 2019-01-29 9:56 ` Michael Ellerman 2019-01-29 9:56 ` [v2,06/21] " Michael Ellerman 2019-01-29 9:56 ` [PATCH v2 06/21] " Michael Ellerman 2019-01-29 9:56 ` Michael Ellerman 2019-01-29 9:56 ` Michael Ellerman 2019-01-29 9:58 ` Michael Ellerman 2019-01-29 9:58 ` Michael Ellerman 2019-01-29 9:58 ` [OpenRISC] " Michael Ellerman 2019-01-29 9:58 ` Michael Ellerman 2019-01-29 9:58 ` Michael Ellerman 2019-01-29 9:58 ` Michael Ellerman 2019-01-29 9:58 ` [v2,06/21] " Michael Ellerman 2019-01-29 9:58 ` [PATCH v2 06/21] " Michael Ellerman 2019-01-29 9:58 ` Michael Ellerman 2019-01-29 9:58 ` Michael Ellerman 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 07/21] memblock: memblock_phys_alloc(): " Mike Rapoport 2019-01-21 8:03 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [v2,07/21] " Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 07/21] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 08/21] memblock: drop __memblock_alloc_base() Mike Rapoport 2019-01-21 8:03 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [v2,08/21] " Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 08/21] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 09/21] memblock: drop memblock_alloc_base() Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [v2,09/21] " Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 09/21] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-29 10:29 ` Michael Ellerman 2019-01-29 10:29 ` [OpenRISC] " Michael Ellerman 2019-01-29 10:29 ` Michael Ellerman 2019-01-29 10:29 ` Michael Ellerman 2019-01-29 10:29 ` Michael Ellerman 2019-01-29 10:29 ` [v2,09/21] " Michael Ellerman 2019-01-29 10:29 ` [PATCH v2 09/21] " Michael Ellerman 2019-01-29 10:29 ` Michael Ellerman 2019-01-29 10:29 ` Michael Ellerman 2019-01-29 10:29 ` Michael Ellerman 2019-01-21 8:03 ` [PATCH v2 10/21] memblock: refactor internal allocation functions Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [v2,10/21] " Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 10/21] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-02-03 9:39 ` Michael Ellerman 2019-02-03 9:39 ` Michael Ellerman 2019-02-03 9:39 ` [OpenRISC] " Michael Ellerman 2019-02-03 9:39 ` Michael Ellerman 2019-02-03 9:39 ` Michael Ellerman 2019-02-03 9:39 ` Michael Ellerman 2019-02-03 9:39 ` [v2,10/21] " Michael Ellerman 2019-02-03 9:39 ` [PATCH v2 10/21] " Michael Ellerman 2019-02-03 9:39 ` Michael Ellerman 2019-02-03 9:39 ` Michael Ellerman 2019-02-03 10:04 ` Mike Rapoport 2019-02-03 10:04 ` [OpenRISC] " Mike Rapoport 2019-02-03 10:04 ` Mike Rapoport 2019-02-03 10:04 ` Mike Rapoport 2019-02-03 10:04 ` [v2,10/21] " Mike Rapoport 2019-02-03 10:04 ` [PATCH v2 10/21] " Mike Rapoport 2019-02-03 10:04 ` Mike Rapoport 2019-02-03 10:04 ` Mike Rapoport 2019-02-03 10:04 ` Mike Rapoport 2019-02-03 11:39 ` Mike Rapoport 2019-02-03 11:39 ` Mike Rapoport 2019-02-04 8:45 ` Michael Ellerman [this message] 2019-02-04 8:45 ` Michael Ellerman 2019-02-04 23:08 ` Stephen Rothwell 2019-02-04 23:08 ` Stephen Rothwell 2019-01-21 8:03 ` [PATCH v2 11/21] memblock: make memblock_find_in_range_node() and choose_memblock_flags() static Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [v2,11/21] " Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 11/21] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 12/21] arch: use memblock_alloc() instead of memblock_alloc_from(size, align, 0) Mike Rapoport 2019-01-21 8:03 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [v2,12/21] " Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 12/21] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 13/21] arch: don't memset(0) memory returned by memblock_alloc() Mike Rapoport 2019-01-21 8:04 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [v2,13/21] " Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 13/21] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 14/21] ia64: add checks for the return value of memblock_alloc*() Mike Rapoport 2019-01-21 8:04 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [v2,14/21] " Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 14/21] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 15/21] sparc: " Mike Rapoport 2019-01-21 8:04 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [v2,15/21] " Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 15/21] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 16/21] mm/percpu: " Mike Rapoport 2019-01-21 8:04 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [v2,16/21] " Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 16/21] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 17/21] init/main: " Mike Rapoport 2019-01-21 8:04 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [v2,17/21] " Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 17/21] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 18/21] swiotlb: " Mike Rapoport 2019-01-21 8:04 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [v2,18/21] " Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 18/21] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 19/21] treewide: " Mike Rapoport 2019-01-21 8:04 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [v2,19/21] " Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 19/21] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:39 ` Geert Uytterhoeven 2019-01-21 8:39 ` Geert Uytterhoeven 2019-01-21 8:39 ` Geert Uytterhoeven 2019-01-21 8:39 ` Geert Uytterhoeven 2019-01-21 8:39 ` [OpenRISC] " Geert Uytterhoeven 2019-01-21 8:39 ` Geert Uytterhoeven 2019-01-21 8:39 ` Geert Uytterhoeven 2019-01-21 8:39 ` Geert Uytterhoeven 2019-01-21 8:39 ` Geert Uytterhoeven 2019-01-21 8:39 ` Geert Uytterhoeven 2019-01-21 17:18 ` Rob Herring 2019-01-21 17:18 ` Rob Herring 2019-01-21 17:18 ` [OpenRISC] " Rob Herring 2019-01-21 17:18 ` Rob Herring 2019-01-21 17:18 ` Rob Herring 2019-01-21 17:18 ` [v2,19/21] " Rob Herring 2019-01-21 17:18 ` [PATCH v2 19/21] " Rob Herring 2019-01-21 17:18 ` Rob Herring 2019-01-21 17:18 ` Rob Herring 2019-01-31 6:07 ` Christophe Leroy 2019-01-31 6:07 ` [OpenRISC] " Christophe Leroy 2019-01-31 6:07 ` Christophe Leroy 2019-01-31 6:07 ` Christophe Leroy 2019-01-31 6:07 ` [v2,19/21] " Christophe Leroy 2019-01-31 6:07 ` [PATCH v2 19/21] " Christophe Leroy 2019-01-31 6:07 ` Christophe Leroy 2019-01-31 6:07 ` Christophe Leroy 2019-01-31 6:41 ` Mike Rapoport 2019-01-31 6:41 ` Mike Rapoport 2019-01-31 6:41 ` Mike Rapoport 2019-01-31 6:41 ` [OpenRISC] " Mike Rapoport 2019-01-31 6:41 ` Mike Rapoport 2019-01-31 6:41 ` Mike Rapoport 2019-01-31 6:41 ` [v2,19/21] " Mike Rapoport 2019-01-31 6:41 ` [PATCH v2 19/21] " Mike Rapoport 2019-01-31 6:41 ` Mike Rapoport 2019-01-31 6:41 ` Mike Rapoport 2019-01-31 6:44 ` Christophe Leroy 2019-01-31 6:44 ` Christophe Leroy 2019-01-31 6:44 ` [OpenRISC] " Christophe Leroy 2019-01-31 6:44 ` Christophe Leroy 2019-01-31 6:44 ` Christophe Leroy 2019-01-31 6:44 ` [v2,19/21] " Christophe Leroy 2019-01-31 6:44 ` [PATCH v2 19/21] " Christophe Leroy 2019-01-31 6:44 ` Christophe Leroy 2019-01-31 6:44 ` Christophe Leroy 2019-01-31 7:07 ` Christophe Leroy 2019-01-31 7:07 ` [OpenRISC] " Christophe Leroy 2019-01-31 7:07 ` Christophe Leroy 2019-01-31 7:07 ` Christophe Leroy 2019-01-31 7:07 ` [v2,19/21] " Christophe Leroy 2019-01-31 7:07 ` [PATCH v2 19/21] " Christophe Leroy 2019-01-31 7:07 ` Christophe Leroy 2019-01-31 7:07 ` Christophe Leroy 2019-01-31 7:14 ` Mike Rapoport 2019-01-31 7:14 ` Mike Rapoport 2019-01-31 7:14 ` Mike Rapoport 2019-01-31 7:14 ` [OpenRISC] " Mike Rapoport 2019-01-31 7:14 ` Mike Rapoport 2019-01-31 7:14 ` Mike Rapoport 2019-01-31 7:14 ` [v2,19/21] " Mike Rapoport 2019-01-31 7:14 ` [PATCH v2 19/21] " Mike Rapoport 2019-01-31 7:14 ` Mike Rapoport 2019-01-31 7:14 ` Mike Rapoport 2019-01-31 7:07 ` Christophe Leroy 2019-01-31 6:07 ` Christophe Leroy 2019-01-31 15:23 ` Max Filippov 2019-01-31 15:23 ` Max Filippov 2019-01-31 15:23 ` Max Filippov 2019-01-31 15:23 ` Max Filippov 2019-01-31 15:23 ` [OpenRISC] " Max Filippov 2019-01-31 15:23 ` Max Filippov 2019-01-31 15:23 ` Max Filippov 2019-01-31 15:23 ` Max Filippov 2019-01-31 15:23 ` Max Filippov 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 20/21] memblock: memblock_alloc_try_nid: don't panic Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [v2,20/21] " Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 20/21] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 21/21] memblock: drop memblock_alloc_*_nopanic() variants Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [v2,21/21] " Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 21/21] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-30 13:38 ` Petr Mladek 2019-01-30 13:38 ` Petr Mladek 2019-01-30 13:38 ` [OpenRISC] " Petr Mladek 2019-01-30 13:38 ` Petr Mladek 2019-01-30 13:38 ` Petr Mladek 2019-01-30 13:38 ` [v2,21/21] " Petr Mladek 2019-01-30 13:38 ` [PATCH v2 21/21] " Petr Mladek 2019-01-30 13:38 ` Petr Mladek 2019-01-30 13:38 ` Petr Mladek 2019-09-24 17:52 ` [PATCH v2 00/21] Refine memblock API Adam Ford 2019-09-24 17:52 ` [OpenRISC] " Adam Ford 2019-09-24 17:52 ` [Xen-devel] " Adam Ford 2019-09-24 17:52 ` Adam Ford 2019-09-24 17:52 ` Adam Ford 2019-09-24 17:52 ` Adam Ford 2019-09-24 17:52 ` Adam Ford 2019-09-24 17:52 ` Adam Ford 2019-09-25 6:42 ` Mike Rapoport 2019-09-25 6:42 ` Mike Rapoport 2019-09-25 12:12 ` Fabio Estevam 2019-09-25 12:12 ` [OpenRISC] " Fabio Estevam 2019-09-25 12:12 ` [Xen-devel] " Fabio Estevam 2019-09-25 12:12 ` Fabio Estevam 2019-09-25 12:12 ` Fabio Estevam 2019-09-25 12:12 ` Fabio Estevam 2019-09-25 12:17 ` Adam Ford 2019-09-25 12:17 ` [OpenRISC] " Adam Ford 2019-09-25 12:17 ` [Xen-devel] " Adam Ford 2019-09-25 12:17 ` Adam Ford 2019-09-25 12:17 ` Adam Ford 2019-09-25 12:17 ` Adam Ford 2019-09-25 15:17 ` Fabio Estevam 2019-09-25 15:17 ` [OpenRISC] " Fabio Estevam 2019-09-25 15:17 ` [Xen-devel] " Fabio Estevam 2019-09-25 15:17 ` Fabio Estevam 2019-09-25 15:17 ` Fabio Estevam 2019-09-25 15:17 ` Fabio Estevam 2019-09-26 13:09 ` Adam Ford 2019-09-26 13:09 ` [OpenRISC] " Adam Ford 2019-09-26 13:09 ` [Xen-devel] " Adam Ford 2019-09-26 13:09 ` Adam Ford 2019-09-26 13:09 ` Adam Ford 2019-09-26 13:09 ` Adam Ford 2019-09-26 16:04 ` Mike Rapoport 2019-09-26 16:04 ` [OpenRISC] " Mike Rapoport 2019-09-26 16:04 ` [Xen-devel] " Mike Rapoport 2019-09-26 16:04 ` Mike Rapoport 2019-09-26 16:04 ` Mike Rapoport 2019-09-26 16:04 ` Mike Rapoport 2019-09-26 19:35 ` Adam Ford 2019-09-26 19:35 ` [OpenRISC] " Adam Ford 2019-09-26 19:35 ` [Xen-devel] " Adam Ford 2019-09-26 19:35 ` Adam Ford 2019-09-26 19:35 ` Adam Ford 2019-09-26 19:35 ` Adam Ford 2019-09-28 7:33 ` Mike Rapoport 2019-09-28 7:33 ` [OpenRISC] " Mike Rapoport 2019-09-28 7:33 ` [Xen-devel] " Mike Rapoport 2019-09-28 7:33 ` Mike Rapoport 2019-09-28 7:33 ` Mike Rapoport 2019-09-28 7:33 ` Mike Rapoport 2019-09-29 13:33 ` Adam Ford 2019-09-29 13:33 ` [OpenRISC] " Adam Ford 2019-09-29 13:33 ` [Xen-devel] " Adam Ford 2019-09-29 13:33 ` Adam Ford 2019-09-29 13:33 ` Adam Ford 2019-09-29 13:33 ` Adam Ford 2019-10-02 0:14 ` Adam Ford 2019-10-02 0:14 ` [OpenRISC] " Adam Ford 2019-10-02 0:14 ` [Xen-devel] " Adam Ford 2019-10-02 0:14 ` Adam Ford 2019-10-02 0:14 ` Adam Ford 2019-10-02 0:14 ` Adam Ford 2019-10-02 7:36 ` Mike Rapoport 2019-10-02 7:36 ` [OpenRISC] " Mike Rapoport 2019-10-02 7:36 ` [Xen-devel] " Mike Rapoport 2019-10-02 7:36 ` Mike Rapoport 2019-10-02 7:36 ` Mike Rapoport 2019-10-02 7:36 ` Mike Rapoport 2019-10-02 7:36 ` Mike Rapoport 2019-10-02 11:14 ` Adam Ford 2019-10-02 11:14 ` [OpenRISC] " Adam Ford 2019-10-02 11:14 ` [Xen-devel] " Adam Ford 2019-10-02 11:14 ` Adam Ford 2019-10-02 11:14 ` Adam Ford 2019-10-02 11:14 ` Adam Ford 2019-10-03 5:34 ` Mike Rapoport 2019-10-03 5:34 ` Mike Rapoport 2019-10-03 8:49 ` Russell King - ARM Linux admin 2019-10-03 8:49 ` Russell King - ARM Linux admin 2019-10-03 11:30 ` Mike Rapoport 2019-10-03 11:30 ` Mike Rapoport 2019-10-03 13:17 ` Lucas Stach 2019-10-03 13:17 ` Lucas Stach 2019-10-03 13:17 ` Lucas Stach 2019-10-04 9:27 ` Russell King - ARM Linux admin 2019-10-04 9:27 ` Russell King - ARM Linux admin 2019-10-04 13:21 ` Lucas Stach 2019-10-04 13:21 ` Lucas Stach 2019-10-04 13:21 ` Lucas Stach 2019-10-04 13:58 ` Adam Ford 2019-10-04 13:58 ` Adam Ford 2019-10-04 13:58 ` Adam Ford 2019-10-04 17:10 ` Mike Rapoport 2019-10-04 17:10 ` Mike Rapoport 2019-10-04 17:29 ` Mike Rapoport 2019-10-04 17:29 ` Mike Rapoport 2019-10-03 14:46 ` Chris Healy 2019-10-03 14:46 ` Chris Healy 2019-10-03 14:46 ` Chris Healy 2019-10-04 9:12 ` Russell King - ARM Linux admin 2019-10-04 9:12 ` Russell King - ARM Linux admin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=878sywndr6.fsf@concordia.ellerman.id.au \ --to=mpe@ellerman.id.au \ --cc=akpm@linux-foundation.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linuxppc-dev@lists.ozlabs.org \ --cc=rppt@linux.ibm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.