On 03/17/20 at 08:04am, Christophe Leroy wrote:
> When CONFIG_HUGETLB_PAGE is set but not CONFIG_HUGETLBFS, the
> following build failure is encoutered:
>From the definition of HUGETLB_PAGE, isn't it relying on HUGETLBFS?
I could misunderstand the def_bool, please correct me if I am wrong.
config
On 03/17/20 at 11:49am, David Hildenbrand wrote:
> Distributions nowadays use udev rules ([1] [2]) to specify if and
> how to online hotplugged memory. The rules seem to get more complex with
> many special cases. Due to the various special cases,
> CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE cannot be us
On 03/18/20 at 02:58pm, Vitaly Kuznetsov wrote:
> Baoquan He writes:
>
> > On 03/17/20 at 11:49am, David Hildenbrand wrote:
> >> Distributions nowadays use udev rules ([1] [2]) to specify if and
> >> how to online hotplugged memory. The rules seem to get more comple
On 03/18/20 at 02:54pm, Michal Hocko wrote:
> On Wed 18-03-20 21:05:17, Baoquan He wrote:
> > On 03/17/20 at 11:49am, David Hildenbrand wrote:
> > > Distributions nowadays use udev rules ([1] [2]) to specify if and
> > > how to online hotplugged memory. The rules se
On 03/18/20 at 02:50pm, David Hildenbrand wrote:
> On 18.03.20 14:05, Baoquan He wrote:
> > On 03/17/20 at 11:49am, David Hildenbrand wrote:
> >> Distributions nowadays use udev rules ([1] [2]) to specify if and
> >> how to online hotplugged memory. The rules se
: Andrew Morton
> Cc: Michal Hocko
> Cc: Oscar Salvador
> Cc: "Rafael J. Wysocki"
> Cc: Baoquan He
> Cc: Wei Yang
> Signed-off-by: David Hildenbrand
> ---
> drivers/base/memory.c | 38 +++---
> 1 file changed, 23 insertions(+),
On 03/20/20 at 10:50am, David Hildenbrand wrote:
> On 20.03.20 08:36, Baoquan He wrote:
> > On 03/19/20 at 02:12pm, David Hildenbrand wrote:
> >> Let's use a simple array which we can reuse soon. While at it, move the
> >> string->mmop conversion out of the devi
hv_balloon: don't check for memhp_auto_online manually"
> -- "mm/memory_hotplug: unexport memhp_auto_online"
> - "mm/memory_hotplug: convert memhp_auto_online to store an online_type"
> -- No longer touches hv/memtrace code
Ack the series.
Reviewed-by: Baoquan He
Hi Sachin,
On 03/24/20 at 11:25am, Sachin Sant wrote:
> While running ndctl[1] tests against 5.6.0-rc7 following crash is encountered.
>
> Bisect leads me to commit d41e2f3bd546
> mm/hotplug: fix hot remove failure in SPARSEMEM|!VMEMMAP case
>
> Reverting this commit helps and the tests comple
On 03/24/20 at 03:06pm, Sachin Sant wrote:
>
>
> > On 24-Mar-2020, at 2:45 PM, Aneesh Kumar K.V
> > wrote:
> >
> > Sachin Sant writes:
> >
> >> While running ndctl[1] tests against 5.6.0-rc7 following crash is
> >> encountered.
> >>
> >> Bisect leads me to commit d41e2f3bd546
> >> mm/hot
ection_valid(ms, pfn);
> }
>
> where
>
> static inline int pfn_section_valid(struct mem_section *ms, unsigned long pfn)
> {
> int idx = subsection_map_index(pfn);
>
> return test_bit(idx, ms->usage->subsection_map);
> }
>
> Avoid this by cleari
On 03/25/20 at 03:06pm, Baoquan He wrote:
> On 03/25/20 at 08:49am, Aneesh Kumar K.V wrote:
> > mm/sparse.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/mm/sparse.c b/mm/sparse.c
> > index aadb7298dcef..3012d1f3771a 100644
> >
On 03/25/20 at 01:42pm, Aneesh Kumar K.V wrote:
> On 3/25/20 1:07 PM, Baoquan He wrote:
> > On 03/25/20 at 03:06pm, Baoquan He wrote:
> > > On 03/25/20 at 08:49am, Aneesh Kumar K.V wrote:
> >
> > > > mm/sparse.c | 2 ++
> > > > 1 file changed,
r vmmemap mapping
> (16MB),
> a specific vmemmap mapping can cover multiple sections. Hence before a vmemmap
> mapping page can be freed, the kernel needs to make sure there are no valid
> sections
> within that mapping. Clearing the section valid bit before
> depopulate_section_memap ena
On 03/28/20 at 11:31am, Hoan Tran wrote:
> In NUMA layout which nodes have memory ranges that span across other nodes,
> the mm driver can detect the memory node id incorrectly.
>
> For example, with layout below
> Node 0 address:
> Node 1 address:
Sorry, I
On 03/30/20 at 09:44am, Michal Hocko wrote:
> On Sun 29-03-20 08:19:24, Baoquan He wrote:
> > On 03/28/20 at 11:31am, Hoan Tran wrote:
> > > In NUMA layout which nodes have memory ranges that span across other
> > > nodes,
> > > the mm driver can d
On 03/30/20 at 09:42am, Michal Hocko wrote:
> On Sat 28-03-20 11:31:17, Hoan Tran wrote:
> > In NUMA layout which nodes have memory ranges that span across other nodes,
> > the mm driver can detect the memory node id incorrectly.
> >
> > For example, with layout below
> > Node 0 address:
On 03/30/20 at 04:16pm, Baoquan He wrote:
> On 03/30/20 at 09:42am, Michal Hocko wrote:
> > On Sat 28-03-20 11:31:17, Hoan Tran wrote:
> > > In NUMA layout which nodes have memory ranges that span across other
> > > nodes,
> > > the mm driver can d
On 03/30/20 at 09:42am, Michal Hocko wrote:
> On Sat 28-03-20 11:31:17, Hoan Tran wrote:
> > In NUMA layout which nodes have memory ranges that span across other nodes,
> > the mm driver can detect the memory node id incorrectly.
> >
> > For example, with layout below
> > Node 0 address:
On 03/30/20 at 01:26pm, Mike Rapoport wrote:
> On Mon, Mar 30, 2020 at 11:58:43AM +0200, Michal Hocko wrote:
> > On Mon 30-03-20 12:21:27, Mike Rapoport wrote:
> > > On Mon, Mar 30, 2020 at 09:42:46AM +0200, Michal Hocko wrote:
> > > > On Sat 28-03-20 11:31:17, Hoan Tran wrote:
> > > > > In NUMA la
Hi Michal,
On 03/31/20 at 10:55am, Michal Hocko wrote:
> On Tue 31-03-20 11:14:23, Mike Rapoport wrote:
> > Maybe I mis-read the code, but I don't see how this could happen. In the
> > HAVE_MEMBLOCK_NODE_MAP=y case, free_area_init_node() calls
> > calculate_node_totalpages() that ensures that node
On 03/31/20 at 04:21pm, Michal Hocko wrote:
> On Tue 31-03-20 22:03:32, Baoquan He wrote:
> > Hi Michal,
> >
> > On 03/31/20 at 10:55am, Michal Hocko wrote:
> > > On Tue 31-03-20 11:14:23, Mike Rapoport wrote:
> > > > Maybe I mis-read the code, but
On 04/01/20 at 12:56am, Mike Rapoport wrote:
> On Mon, Mar 30, 2020 at 11:58:43AM +0200, Michal Hocko wrote:
> >
> > What would it take to make ia64 use HAVE_MEMBLOCK_NODE_MAP? I would
> > really love to see that thing go away. It is causing problems when
> > people try to use memblock api.
>
> W
On 04/02/20 at 09:46pm, Hoan Tran wrote:
> Hi All,
>
> On 3/31/20 7:31 AM, Baoquan He wrote:
> > On 03/31/20 at 04:21pm, Michal Hocko wrote:
> > > On Tue 31-03-20 22:03:32, Baoquan He wrote:
> > > > Hi Michal,
> > > >
> > > > On 03/31/
> Cc: Michael Ellerman
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Michal Hocko
> Cc: Andrew Morton
> Cc: Oscar Salvador
> Cc: Baoquan He
> Cc: Wei Yang
> Signed-off-by: David Hildenbrand
> ---
> .../platforms/pseries/hotplug-memory.c| 2
Cc: Oscar Salvador
> Cc: Baoquan He
> Cc: Wei Yang
> Signed-off-by: David Hildenbrand
Assuming no issue to patch 1, this one looks good.
Reviewed-by: Baoquan He
> ---
> include/linux/memory_hotplug.h | 7
> mm/memory_hotplug.c| 75 -
On 04/02/20 at 10:01am, Michal Hocko wrote:
> On Wed 01-04-20 10:51:55, Mike Rapoport wrote:
> > Hi,
> >
> > On Wed, Apr 01, 2020 at 01:42:27PM +0800, Baoquan He wrote:
> [...]
> > > From above information, we can remove HAVE_MEMBLOCK_NODE_MAP, and
> > >
On 04/09/20 at 05:33pm, Michal Hocko wrote:
> On Thu 09-04-20 22:41:19, Baoquan He wrote:
> > On 04/02/20 at 10:01am, Michal Hocko wrote:
> > > On Wed 01-04-20 10:51:55, Mike Rapoport wrote:
> > > > Hi,
> > > >
> > > > On W
On 04/09/20 at 07:27pm, Mike Rapoport wrote:
> On Tue, Mar 31, 2020 at 04:21:38PM +0200, Michal Hocko wrote:
> > On Tue 31-03-20 22:03:32, Baoquan He wrote:
> > > Hi Michal,
> > >
> > > On 03/31/20 at 10:55am, Michal Hocko wrote:
> > > &g
On 04/14/20 at 10:00am, David Hildenbrand wrote:
> On 14.04.20 08:40, Baoquan He wrote:
> > On 04/13/20 at 08:15am, Eric W. Biederman wrote:
> >> Baoquan He writes:
> >>
> >>> On 04/12/20 at 02:52pm, Eric W. Biederman wrote:
> >>>>
> >
On 04/14/20 at 11:37am, David Hildenbrand wrote:
> On 14.04.20 11:22, Baoquan He wrote:
> > On 04/14/20 at 10:00am, David Hildenbrand wrote:
> >> On 14.04.20 08:40, Baoquan He wrote:
> >>> On 04/13/20 at 08:15am, Eric W. Biederman wrote:
> >>>> Baoquan
On 04/14/20 at 04:49pm, David Hildenbrand wrote:
> > The root cause is kexec-ed kernel is targeted at hotpluggable memory
> > region. Just avoiding the movable area can fix it. In kexec_file_load(),
> > just checking or picking those unmovable region to put kernel/initrd in
> > func
On 04/16/20 at 03:31pm, David Hildenbrand wrote:
> > Not sure if I get the notifier idea clearly. If you mean
> >
> > 1) Add a common function to pick memory in unmovable zone;
>
> Not strictly required IMHO. But, minor detail.
>
> > 2) Let DLPAR, balloon register with notifier;
>
> Yeah, or v
On 04/16/20 at 04:09pm, David Hildenbrand wrote:
> >>> Sounds doable to me, and not complicated.
> >>>
> images. It would apply to
>
> - arm64 and filter out all hotadded memory (IIRC, only boot memory can
> be used).
> >>>
> >>> Do you mean hot added memory after boot can't b
ck_is_hotpluggable(r))
> continue;
>
> - nid = r->nid;
> + nid = memblock_get_region_node(r);
>
> usable_startpfn = PFN_DOWN(r->base);
> zone_movable_pfn[nid] = zone_movable_pfn[nid] ?
> @@ -7229,7 +7229,7 @@ static void __init
> find_zone_movable_pfns_for_nodes(void)
> if (memblock_is_mirror(r))
> continue;
>
> - nid = r->nid;
> + nid = memblock_get_region_node(r);
>
> usable_startpfn = memblock_region_memory_base_pfn(r);
Looks good to me.
Reviewed-by: Baoquan He
ARLY_PFN_TO_NID) || \
defined(CONFIG_HAVE_MEMBLOCK_NODE_MAP)
This is the upper layer of ifdeffery scope.
>
> static struct mminit_pfnnid_cache early_pfnnid_cache __meminitdata;
>
> +#ifndef CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID
Moving __early_pfn_to_nid() here makes the upper layer of ifdefer
On 04/12/20 at 10:48pm, Mike Rapoport wrote:
> From: Mike Rapoport
>
> The early_pfn_to_nid() and it's helper __early_pfn_to_nid() are spread
> around include/linux/mm.h, include/linux/mmzone.h and mm/page_alloc.c.
>
> Drop unused stub for __early_pfn_to_nid() and move its actual generic
> imple
On 04/12/20 at 10:48pm, Mike Rapoport wrote:
> From: Mike Rapoport
>
> The CONFIG_HAVE_MEMBLOCK_NODE_MAP is used to differentiate initialization
> of nodes and zones structures between the systems that have region to node
> mapping in memblock and those that don't.
>
> Currently all the NUMA arc
On 04/21/20 at 11:49am, Mike Rapoport wrote:
> On Tue, Apr 21, 2020 at 10:24:35AM +0800, Baoquan He wrote:
> > On 04/12/20 at 10:48pm, Mike Rapoport wrote:
> > > From: Mike Rapoport
> > >
> > > The early_pfn_to_nid() and it's helper __early_pfn_to_nid() a
On 04/21/20 at 12:09pm, Mike Rapoport wrote:
> > > diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> > > index fc0aad0bc1f5..e67dc501576a 100644
> > > --- a/mm/memory_hotplug.c
> > > +++ b/mm/memory_hotplug.c
> > > @@ -1372,11 +1372,7 @@ check_pages_isolated_cb(unsigned long start_pfn,
> >
On 04/21/20 at 03:29pm, David Hildenbrand wrote:
> >> ACPI SRAT is embeded into efi, need read out the rsdp pointer. If we don't
> >> pass the efi, it won't get the SRAT table correctly, if I remember
> >> correctly. Yeah, I remeber kvm guest can get memory hotplugged with
> >> ACPI only, this won'
On 04/22/20 at 11:24am, David Hildenbrand wrote:
> On 22.04.20 11:17, Baoquan He wrote:
> > On 04/21/20 at 03:29pm, David Hildenbrand wrote:
> >>>> ACPI SRAT is embeded into efi, need read out the rsdp pointer. If we
> >>>> don't
> >>>>
On 04/22/20 at 12:05pm, David Hildenbrand wrote:
> On 22.04.20 11:57, Baoquan He wrote:
> > On 04/22/20 at 11:24am, David Hildenbrand wrote:
> >> On 22.04.20 11:17, Baoquan He wrote:
> >>> On 04/21/20 at 03:29pm, David Hildenbrand wrote:
> >>>>>&g
lude/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -2272,7 +2272,7 @@ static inline spinlock_t *pud_lock(struct mm_struct
> *mm, pud_t *pud)
> }
>
> extern void __init pagecache_init(void);
> -extern void free_area_init(unsigned long * zones_size);
> +extern void free_area_init(unsigned long * max_zone_pfn);
> extern void __init free_area_init_node(int nid, unsigned long * zones_size,
> unsigned long zone_start_pfn, unsigned long *zholes_size);
> extern void free_initmem(void);
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 4530e9cfd9f7..530701b38bc7 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -7700,11 +7700,10 @@ void __init set_dma_reserve(unsigned long
> new_dma_reserve)
> dma_reserve = new_dma_reserve;
> }
>
> -void __init free_area_init(unsigned long *zones_size)
> +void __init free_area_init(unsigned long *max_zone_pfn)
> {
> init_unavailable_mem();
> - free_area_init_node(0, zones_size,
> - __pa(PAGE_OFFSET) >> PAGE_SHIFT, NULL);
> + free_area_init_nodes(max_zone_pfn);
Reviewed-by: Baoquan He
> }
>
> static int page_alloc_cpu_dead(unsigned int cpu)
> --
> 2.25.1
>
lise all pg_data_t and zone data
> * @max_zone_pfn: an array of max PFNs for each zone
> *
> * This will call free_area_init_node() for each active node in the system.
It's __free_area_init_node() here being called, while
it dosn't matter much because it's updated in later patch.
> @@ -7440,7 +7440,7 @@ static void check_for_memory(pg_data_t *pgdat, int nid)
> * starts where the previous one ended. For example, ZONE_DMA32 starts
> * at arch_max_dma_pfn.
> */
> -void __init free_area_init_nodes(unsigned long *max_zone_pfn)
> +void __init free_area_init(unsigned long *max_zone_pfn)
> {
> unsigned long start_pfn, end_pfn;
> int i, nid;
> @@ -7700,12 +7700,6 @@ void __init set_dma_reserve(unsigned long
> new_dma_reserve)
> dma_reserve = new_dma_reserve;
> }
>
> -void __init free_area_init(unsigned long *max_zone_pfn)
> -{
> - init_unavailable_mem();
> - free_area_init_nodes(max_zone_pfn);
> -}
> -
> static int page_alloc_cpu_dead(unsigned int cpu)
> {
Reviewed-by: Baoquan He
>
> --
> 2.25.1
>
y_pfnnid_cache);
> - if (nid >= 0 && nid != node)
> - return false;
> - return true;
> -}
> -
> -#else
> -static inline bool __meminit early_pfn_in_nid(unsigned long pfn, int node)
> -{
> - return true;
> -}
> -#endif
And macro early_pfn_valid() is not needed either, we may need remove it
too.
Otherwise, removing NODES_SPAN_OTHER_NODES in this patch looks good.
Reviewed-by: Baoquan He
> -
> -
> void __init memblock_free_pages(struct page *page, unsigned long pfn,
> unsigned int order)
> {
> --
> 2.25.1
>
On 04/12/20 at 10:48pm, Mike Rapoport wrote:
> From: Mike Rapoport
>
> Some architectures (e.g. ARC) have the ZONE_HIGHMEM zone below the
> ZONE_NORMAL. Allowing free_area_init() parse max_zone_pfn array even it is
> sorted in descending order allows using free_area_init() on such
> architectures
On 04/23/20 at 10:53am, Baoquan He wrote:
> On 04/12/20 at 10:48pm, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > Some architectures (e.g. ARC) have the ZONE_HIGHMEM zone below the
> > ZONE_NORMAL. Allowing free_area_init() parse max_zone_pfn array even it
On 04/12/20 at 10:48pm, Mike Rapoport wrote:
> From: Mike Rapoport
>
> The free_area_init_node() is only used by x86 to initialize a memory-less
> nodes.
> Make its name reflect this and drop all the function parameters except node
> ID as they are anyway zero.
>
> Signed-off-by: Mike Rapoport
On 04/23/20 at 08:55am, Mike Rapoport wrote:
> On Thu, Apr 23, 2020 at 10:57:20AM +0800, Baoquan He wrote:
> > On 04/23/20 at 10:53am, Baoquan He wrote:
> > > On 04/12/20 at 10:48pm, Mike Rapoport wrote:
> > > > From: Mike Rapoport
> > > >
>
On 12/10/18 at 12:08pm, Pingfan Liu wrote:
> Hi,
> I found in powerpc code, it is doable to reserve memory region in
> movable zone, such as crashkernel does. But in x86 code, it checks the
> hotpluggable attribute of memory, hence if manually specifying a
> region in hotpluggable region, it will f
resource siblings. This is suggested by
Andrew.
Rewrite walk_system_ram_res_rev() after list_head is taken to link
resouce siblings.
Baoquan He (4):
resource: Move reparent_resources() to kernel/resource.c and make it
public
resource: Use list_head to link sibling resource
reparent_resources() is duplicated in arch/microblaze/pci/pci-common.c
and arch/powerpc/kernel/pci-common.c, so move it to kernel/resource.c
so that it's shared. Later its code also need be updated using list_head
to replace singly linked list.
Signed-off-by: Baoquan He
Cc: Michal Sime
type of member variables of struct resource, sibling and child, are
changed from 'struct resource *' to 'struct list_head'. This brings two
pointers of size increase.
Suggested-by: Andrew Morton
Signed-off-by: Baoquan He
Cc: Patrik Jakobsson
Cc: David Airlie
Cc: "K. Y.
_file code.
Signed-off-by: Baoquan He
Cc: Andrew Morton
Cc: Thomas Gleixner
Cc: Brijesh Singh
Cc: "Jérôme Glisse"
Cc: Borislav Petkov
Cc: Tom Lendacky
Cc: Wei Yang
---
include/linux/ioport.h | 3 +++
kernel/resource.c | 40
2 files ch
op to down to load kernel.
Signed-off-by: Baoquan He
Cc: Eric Biederman
Cc: Vivek Goyal
Cc: Dave Young
Cc: Andrew Morton
Cc: Yinghai Lu
Cc: ke...@lists.infradead.org
---
kernel/kexec_file.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index 7
On 06/12/18 at 11:28am, Baoquan He wrote:
> reparent_resources() is duplicated in arch/microblaze/pci/pci-common.c
> and arch/powerpc/kernel/pci-common.c, so move it to kernel/resource.c
> so that it's shared. Later its code also need be updated using list_head
> to replace s
On 06/12/18 at 11:29am, Andy Shevchenko wrote:
> On Tue, Jun 12, 2018 at 6:28 AM, Baoquan He wrote:
> > reparent_resources() is duplicated in arch/microblaze/pci/pci-common.c
> > and arch/powerpc/kernel/pci-common.c, so move it to kernel/resource.c
> > so that it's s
On 06/12/18 at 11:29am, Andy Shevchenko wrote:
> On Tue, Jun 12, 2018 at 6:28 AM, Baoquan He wrote:
> > reparent_resources() is duplicated in arch/microblaze/pci/pci-common.c
> > and arch/powerpc/kernel/pci-common.c, so move it to kernel/resource.c
> > so that it's s
On 06/12/18 at 05:10pm, Julia Lawall wrote:
> This looks wrong. After a list iterator, the index variable points to a
> dummy structure.
>
> julia
>
> url:
> https://github.com/0day-ci/linux/commits/Baoquan-He/resource-Use-list_head-to-link-sibling-resource/20180612-1
Hi Andy,
On 06/12/18 at 05:24pm, Andy Shevchenko wrote:
> On Tue, Jun 12, 2018 at 5:20 PM, Andy Shevchenko
> wrote:
> >> Hmm, I just copied it from arch/powerpc/kernel/pci-common.c. The
> >> function interface expects an integer returned value, not sure what a
> >> real error codes look like, cou
ter list_head is taken to link
resouce siblings.
Baoquan He (4):
resource: Move reparent_resources() to kernel/resource.c and make it
public
resource: Use list_head to link sibling resource
resource: add walk_system_ram_res_rev()
kexec_file: Load kernel at top of system RAM if req
reparent_resources() is duplicated in arch/microblaze/pci/pci-common.c
and arch/powerpc/kernel/pci-common.c, so move it to kernel/resource.c
so that it's shared.
Signed-off-by: Baoquan He
---
arch/microblaze/pci/pci-common.c | 37 -
arch/powerpc/kerne
type of member variables of struct resource, sibling and child, are
changed from 'struct resource *' to 'struct list_head'. This brings two
pointers of size increase.
Suggested-by: Andrew Morton
Signed-off-by: Baoquan He
Cc: Patrik Jakobsson
Cc: David Airlie
Cc: "K. Y.
_file code.
Signed-off-by: Baoquan He
Cc: Andrew Morton
Cc: Thomas Gleixner
Cc: Brijesh Singh
Cc: "Jérôme Glisse"
Cc: Borislav Petkov
Cc: Tom Lendacky
Cc: Wei Yang
---
include/linux/ioport.h | 3 +++
kernel/resource.c | 40
2 files ch
op to down to load kernel.
Signed-off-by: Baoquan He
Cc: Eric Biederman
Cc: Vivek Goyal
Cc: Dave Young
Cc: Andrew Morton
Cc: Yinghai Lu
Cc: ke...@lists.infradead.org
---
kernel/kexec_file.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index c
On 07/03/18 at 11:57pm, Andy Shevchenko wrote:
> On Tue, Jul 3, 2018 at 5:55 PM, Baoquan He wrote:
> > On 06/12/18 at 05:24pm, Andy Shevchenko wrote:
> >> On Tue, Jun 12, 2018 at 5:20 PM, Andy Shevchenko
> >> wrote:
>
> >> > I briefly looked at the cod
On 07/04/18 at 07:46pm, Andy Shevchenko wrote:
> On Wed, Jul 4, 2018 at 7:10 AM, Baoquan He wrote:
> > reparent_resources() is duplicated in arch/microblaze/pci/pci-common.c
> > and arch/powerpc/kernel/pci-common.c, so move it to kernel/resource.c
> > so that it's s
ase drop us a note to
> help improve the system]
Thanks for telling.
I cloned 0day-ci/linut to my local pc.
https://github.com/0day-ci/linux.git
However, I didn't find below branch. And tried to open it in web
broswer, also failed.
> url:
> https://github.com/0day-ci/linux/commit
On 07/08/18 at 08:48pm, Andy Shevchenko wrote:
> On Sun, Jul 8, 2018 at 5:59 AM, Baoquan He wrote:
> > On 07/05/18 at 01:00am, kbuild test robot wrote:
>
> > However, I didn't find below branch. And tried to open it in web
> > broswer, also failed.
>
&
On 07/10/18 at 08:59am, Ye Xiaolong wrote:
> Hi,
>
> On 07/08, Baoquan He wrote:
> >Hi,
> >
> >On 07/05/18 at 01:00am, kbuild test robot wrote:
> >> Hi Baoquan,
> >>
> >> I love your patch! Yet something to improve:
> >>
> >
Hi Michael,
On 07/11/18 at 10:49pm, Michael Ellerman wrote:
> a...@linux-foundation.org writes:
> > The mm-of-the-moment snapshot 2018-07-10-16-50 has been uploaded to
> >
> >http://www.ozlabs.org/~akpm/mmotm/
> ...
>
> > * mm-sparse-add-a-static-variable-nr_present_sections.patch
> > * mm-sp
>v2:
Use list_head instead to link resource siblings. This is suggested by
Andrew.
Rewrite walk_system_ram_res_rev() after list_head is taken to link
resouce siblings.
Baoquan He (4):
resource: Move reparent_resources() to kernel/resource.c and make it
public
resource: Use li
reparent_resources() is duplicated in arch/microblaze/pci/pci-common.c
and arch/powerpc/kernel/pci-common.c, so move it to kernel/resource.c
so that it's shared.
Reviewed-by: Andy Shevchenko
Signed-off-by: Baoquan He
Cc: Michal Simek
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Mi
type of member variables of struct resource, sibling and child, are
changed from 'struct resource *' to 'struct list_head'. This brings two
pointers of size increase.
Suggested-by: Andrew Morton
Signed-off-by: Baoquan He
Cc: Patrik Jakobsson
Cc: David Airlie
Cc: "K. Y.
_file code.
Signed-off-by: Baoquan He
Cc: Andrew Morton
Cc: Thomas Gleixner
Cc: Brijesh Singh
Cc: "Jérôme Glisse"
Cc: Borislav Petkov
Cc: Tom Lendacky
Cc: Wei Yang
---
include/linux/ioport.h | 3 +++
kernel/resource.c | 40
2 files ch
op to down to load kernel.
Signed-off-by: Baoquan He
Cc: Eric Biederman
Cc: Vivek Goyal
Cc: Dave Young
Cc: Andrew Morton
Cc: Yinghai Lu
Cc: ke...@lists.infradead.org
---
kernel/kexec_file.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index c
Hi Andrew,
On 07/18/18 at 03:33pm, Andrew Morton wrote:
> On Wed, 18 Jul 2018 10:49:44 +0800 Baoquan He wrote:
>
> > For kexec_file loading, if kexec_buf.top_down is 'true', the memory which
> > is used to load kernel/initrd/purgatory is supposed to be allocated f
On 07/18/18 at 07:37pm, Andy Shevchenko wrote:
> On Wed, Jul 18, 2018 at 7:36 PM, Andy Shevchenko
> wrote:
> > On Wed, Jul 18, 2018 at 5:49 AM, Baoquan He wrote:
> >> reparent_resources() is duplicated in arch/microblaze/pci/pci-common.c
> >> and arch/powerpc/kern
Hi Andrew,
On 07/19/18 at 12:44pm, Andrew Morton wrote:
> On Thu, 19 Jul 2018 23:17:53 +0800 Baoquan He wrote:
> > > As far as I can tell, the above is the whole reason for the patchset,
> > > yes? To avoid confusing users.
> >
> >
> > In fact, it
On 07/23/18 at 04:34pm, Michal Hocko wrote:
> On Thu 19-07-18 23:17:53, Baoquan He wrote:
> > Kexec has been a formal feature in our distro, and customers owning
> > those kind of very large machine can make use of this feature to speed
> > up the reboot process. On uefi ma
On 07/26/18 at 02:59pm, Michal Hocko wrote:
> On Wed 25-07-18 14:48:13, Baoquan He wrote:
> > On 07/23/18 at 04:34pm, Michal Hocko wrote:
> > > On Thu 19-07-18 23:17:53, Baoquan He wrote:
> > > > Kexec has been a formal feature in our distro, and customers owning
&g
On 07/26/18 at 03:14pm, Michal Hocko wrote:
> On Thu 26-07-18 15:12:42, Michal Hocko wrote:
> > On Thu 26-07-18 21:09:04, Baoquan He wrote:
> > > On 07/26/18 at 02:59pm, Michal Hocko wrote:
> > > > On Wed 25-07-18 14:48:13, Baoquan He wrote:
> > > > &g
On 07/26/18 at 04:01pm, Michal Hocko wrote:
> On Thu 26-07-18 21:37:05, Baoquan He wrote:
> > On 07/26/18 at 03:14pm, Michal Hocko wrote:
> > > On Thu 26-07-18 15:12:42, Michal Hocko wrote:
> > > > On Thu 26-07-18 21:09:04, Baoquan He wrote:
> > > > &g
On 10/06/19 at 10:56am, David Hildenbrand wrote:
> If we have holes, the holes will automatically get detected and removed
> once we remove the next bigger/smaller section. The extra checks can
> go.
>
> Cc: Andrew Morton
> Cc: Oscar Salvador
> Cc: Michal Hocko
> Cc: David Hildenbrand
> Cc: Pa
On 02/04/20 at 03:42pm, David Hildenbrand wrote:
> On 04.02.20 15:25, Baoquan He wrote:
> > On 10/06/19 at 10:56am, David Hildenbrand wrote:
> >> If we have holes, the holes will automatically get detected and removed
> >> once we remove the next bigger/smaller se
On 02/05/20 at 02:20pm, David Hildenbrand wrote:
> On 05.02.20 13:43, Baoquan He wrote:
> > On 02/04/20 at 03:42pm, David Hildenbrand wrote:
> >> On 04.02.20 15:25, Baoquan He wrote:
> >>> On 10/06/19 at 10:56am, David Hildenbrand wrote:
> >>>> If we
On 02/05/20 at 02:38pm, David Hildenbrand wrote:
> On 05.02.20 14:34, Baoquan He wrote:
> > On 02/05/20 at 02:20pm, David Hildenbrand wrote:
> >> On 05.02.20 13:43, Baoquan He wrote:
> >>> On 02/04/20 at 03:42pm, David Hildenbrand wrote:
> >>>> On 04.02
On 02/05/20 at 03:16pm, David Hildenbrand wrote:
> Anyhow, that patch is already upstream and I don't consider this high
> priority. Thanks :)
> >>>
> >>> Yeah, noticed you told Wei the status in another patch thread, I am fine
> >>> with it, just leave it to you to decide. Thanks.
> >>
>
Hi Wei Yang,
On 02/05/20 at 05:59pm, Wei Yang wrote:
> >diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> >index f294918f7211..8dafa1ba8d9f 100644
> >--- a/mm/memory_hotplug.c
> >+++ b/mm/memory_hotplug.c
> >@@ -393,6 +393,9 @@ static void shrink_zone_span(struct zone *zone, unsigned
> >lo
On 02/06/20 at 06:56am, Wei Yang wrote:
> On Wed, Feb 05, 2020 at 10:48:11PM +0800, Baoquan He wrote:
> >Hi Wei Yang,
> >
> >On 02/05/20 at 05:59pm, Wei Yang wrote:
> >> >diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> >> >index f29
On 02/06/20 at 07:26am, Wei Yang wrote:
> On Thu, Feb 06, 2020 at 07:08:26AM +0800, Baoquan He wrote:
> >On 02/06/20 at 06:56am, Wei Yang wrote:
> >> On Wed, Feb 05, 2020 at 10:48:11PM +0800, Baoquan He wrote:
> >> >Hi Wei Yang,
> >> >
> >> >
On 02/21/20 at 02:26pm, Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> Function declarations don't need externs, remove the existing ones
> so they are consistent with newer code
>
> Signed-off-by: Alastair D'Silva
> ---
> arch/powerpc/include/asm/pnv-ocxl.h | 32 ++--
On 02/26/20 at 10:01am, Greg Kurz wrote:
> On Wed, 26 Feb 2020 19:26:34 +1100
> "Alastair D'Silva" wrote:
>
> > > -Original Message-
> > > From: Baoquan He
> > > Sent: Wednesday, 26 February 2020 7:15 PM
> > > To: Alastair
On 02/26/20 at 03:20pm, Greg Kurz wrote:
> On Wed, 26 Feb 2020 22:15:23 +0800
> 'Baoquan He' wrote:
>
> > On 02/26/20 at 10:01am, Greg Kurz wrote:
> > > On Wed, 26 Feb 2020 19:26:34 +1100
> > > "Alastair D'Silva" wrote:
> > &g
On 09/11/23 at 05:13pm, Michael Ellerman wrote:
> Hari Bathini writes:
> > Currently, is_kdump_kernel() returns true when elfcorehdr_addr is set.
> > While elfcorehdr_addr is set for kexec based kernel dump mechanism,
> > alternate dump capturing methods like fadump [1] also set it to export
> > t
vmcore_unusable() from is_kdump_kernel()
> as suggested here:
>
> https://lore.kernel.org/linuxppc-dev/ZP7si3UMVpPfYV+w@MiWiFi-R3L-srv/T/#m13ae5a7e4ba6f4d8397f0f66581832292eee3a85
>
>
> include/linux/crash_dump.h | 8 +++++---
> 1 file changed, 5 insertions(+)
/powerpc/include/asm/kexec.h | 8 ++--
> arch/powerpc/kernel/crash_dump.c | 12
> 2 files changed, 18 insertions(+), 2 deletions(-)
LGTM,
Acked-by: Baoquan He
>
> diff --git a/arch/powerpc/include/asm/kexec.h
> b/arch/powerpc/include/asm/kexec.h
> index a1ddba01e7d1..e
.
If any new invocation of ioremap_uc() need be added, please consider
using ioremap() intead or adding a ARCH specific version if necessary.
Signed-off-by: Baoquan He
Acked-by: Geert Uytterhoeven
Acked-by: Michael Ellerman (powerpc)
Acked-by: Helge Deller # parisc
Cc: linux-al
)
> Cc: Herbert Xu
> Cc: "David S. Miller"
> Cc: linux-cry...@vger.kernel.org
> Signed-off-by: Arnd Bergmann
> ---
> kernel/Kconfig.kexec | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
LGTM,
Acked-by: Baoquan He
>
> diff --git a/kernel/Kconfig
1 - 100 of 337 matches
Mail list logo
