All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Pavel Tatashin <pasha.tatashin@oracle.com>
Cc: linux-kernel@vger.kernel.org, sparclinux@vger.kernel.org,
	linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org,
	linux-s390@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	x86@kernel.org, kasan-dev@googlegroups.com,
	borntraeger@de.ibm.com, heiko.carstens@de.ibm.com,
	davem@davemloft.net, willy@infradead.org,
	ard.biesheuvel@linaro.org, will.deacon@arm.com,
	catalin.marinas@arm.com, sam@ravnborg.org,
	Mel Gorman <mgorman@suse.de>
Subject: Re: [v6 04/15] mm: discard memblock data later
Date: Fri, 11 Aug 2017 11:32:49 +0200	[thread overview]
Message-ID: <20170811093249.GE30811@dhcp22.suse.cz> (raw)
In-Reply-To: <1502138329-123460-5-git-send-email-pasha.tatashin@oracle.com>

[CC Mel]

On Mon 07-08-17 16:38:38, Pavel Tatashin wrote:
> There is existing use after free bug when deferred struct pages are
> enabled:
> 
> The memblock_add() allocates memory for the memory array if more than
> 128 entries are needed.  See comment in e820__memblock_setup():
> 
>   * The bootstrap memblock region count maximum is 128 entries
>   * (INIT_MEMBLOCK_REGIONS), but EFI might pass us more E820 entries
>   * than that - so allow memblock resizing.
> 
> This memblock memory is freed here:
>         free_low_memory_core_early()
> 
> We access the freed memblock.memory later in boot when deferred pages are
> initialized in this path:
> 
>         deferred_init_memmap()
>                 for_each_mem_pfn_range()
>                   __next_mem_pfn_range()
>                     type = &memblock.memory;

Yes you seem to be right.
>
> One possible explanation for why this use-after-free hasn't been hit
> before is that the limit of INIT_MEMBLOCK_REGIONS has never been exceeded
> at least on systems where deferred struct pages were enabled.

Yeah this sounds like the case.
 
> Another reason why we want this problem fixed in this patch series is,
> in the next patch, we will need to access memblock.reserved from
> deferred_init_memmap().
> 

I guess this goes all the way down to 
Fixes: 7e18adb4f80b ("mm: meminit: initialise remaining struct pages in parallel with kswapd")
> Signed-off-by: Pavel Tatashin <pasha.tatashin@oracle.com>
> Reviewed-by: Steven Sistare <steven.sistare@oracle.com>
> Reviewed-by: Daniel Jordan <daniel.m.jordan@oracle.com>
> Reviewed-by: Bob Picco <bob.picco@oracle.com>

Considering that some HW might behave strangely and this would be rather
hard to debug I would be tempted to mark this for stable. It should also
be merged separately from the rest of the series.

I have just one nit below
Acked-by: Michal Hocko <mhocko@suse.com>

[...]
> diff --git a/mm/memblock.c b/mm/memblock.c
> index 2cb25fe4452c..bf14aea6ab70 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -285,31 +285,27 @@ static void __init_memblock memblock_remove_region(struct memblock_type *type, u
>  }
>  
>  #ifdef CONFIG_ARCH_DISCARD_MEMBLOCK

pull this ifdef inside memblock_discard and you do not have an another
one in page_alloc_init_late

[...]
> +/**
> + * Discard memory and reserved arrays if they were allocated
> + */
> +void __init memblock_discard(void)
>  {

here

> -	if (memblock.memory.regions == memblock_memory_init_regions)
> -		return 0;
> +	phys_addr_t addr, size;
>  
> -	*addr = __pa(memblock.memory.regions);
> +	if (memblock.reserved.regions != memblock_reserved_init_regions) {
> +		addr = __pa(memblock.reserved.regions);
> +		size = PAGE_ALIGN(sizeof(struct memblock_region) *
> +				  memblock.reserved.max);
> +		__memblock_free_late(addr, size);
> +	}
>  
> -	return PAGE_ALIGN(sizeof(struct memblock_region) *
> -			  memblock.memory.max);
> +	if (memblock.memory.regions == memblock_memory_init_regions) {
> +		addr = __pa(memblock.memory.regions);
> +		size = PAGE_ALIGN(sizeof(struct memblock_region) *
> +				  memblock.memory.max);
> +		__memblock_free_late(addr, size);
> +	}
>  }
> -
>  #endif
[...]
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index fc32aa81f359..63d16c185736 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1584,6 +1584,10 @@ void __init page_alloc_init_late(void)
>  	/* Reinit limits that are based on free pages after the kernel is up */
>  	files_maxfiles_init();
>  #endif
> +#ifdef CONFIG_ARCH_DISCARD_MEMBLOCK
> +	/* Discard memblock private memory */
> +	memblock_discard();
> +#endif
>  
>  	for_each_populated_zone(zone)
>  		set_zone_contiguous(zone);
> -- 
> 2.14.0

-- 
Michal Hocko
SUSE Labs

WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [v6 04/15] mm: discard memblock data later
Date: Fri, 11 Aug 2017 09:32:49 +0000	[thread overview]
Message-ID: <20170811093249.GE30811@dhcp22.suse.cz> (raw)
In-Reply-To: <1502138329-123460-5-git-send-email-pasha.tatashin@oracle.com>

[CC Mel]

On Mon 07-08-17 16:38:38, Pavel Tatashin wrote:
> There is existing use after free bug when deferred struct pages are
> enabled:
> 
> The memblock_add() allocates memory for the memory array if more than
> 128 entries are needed.  See comment in e820__memblock_setup():
> 
>   * The bootstrap memblock region count maximum is 128 entries
>   * (INIT_MEMBLOCK_REGIONS), but EFI might pass us more E820 entries
>   * than that - so allow memblock resizing.
> 
> This memblock memory is freed here:
>         free_low_memory_core_early()
> 
> We access the freed memblock.memory later in boot when deferred pages are
> initialized in this path:
> 
>         deferred_init_memmap()
>                 for_each_mem_pfn_range()
>                   __next_mem_pfn_range()
>                     type = &memblock.memory;

Yes you seem to be right.
>
> One possible explanation for why this use-after-free hasn't been hit
> before is that the limit of INIT_MEMBLOCK_REGIONS has never been exceeded
> at least on systems where deferred struct pages were enabled.

Yeah this sounds like the case.
 
> Another reason why we want this problem fixed in this patch series is,
> in the next patch, we will need to access memblock.reserved from
> deferred_init_memmap().
> 

I guess this goes all the way down to 
Fixes: 7e18adb4f80b ("mm: meminit: initialise remaining struct pages in parallel with kswapd")
> Signed-off-by: Pavel Tatashin <pasha.tatashin@oracle.com>
> Reviewed-by: Steven Sistare <steven.sistare@oracle.com>
> Reviewed-by: Daniel Jordan <daniel.m.jordan@oracle.com>
> Reviewed-by: Bob Picco <bob.picco@oracle.com>

Considering that some HW might behave strangely and this would be rather
hard to debug I would be tempted to mark this for stable. It should also
be merged separately from the rest of the series.

I have just one nit below
Acked-by: Michal Hocko <mhocko@suse.com>

[...]
> diff --git a/mm/memblock.c b/mm/memblock.c
> index 2cb25fe4452c..bf14aea6ab70 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -285,31 +285,27 @@ static void __init_memblock memblock_remove_region(struct memblock_type *type, u
>  }
>  
>  #ifdef CONFIG_ARCH_DISCARD_MEMBLOCK

pull this ifdef inside memblock_discard and you do not have an another
one in page_alloc_init_late

[...]
> +/**
> + * Discard memory and reserved arrays if they were allocated
> + */
> +void __init memblock_discard(void)
>  {

here

> -	if (memblock.memory.regions = memblock_memory_init_regions)
> -		return 0;
> +	phys_addr_t addr, size;
>  
> -	*addr = __pa(memblock.memory.regions);
> +	if (memblock.reserved.regions != memblock_reserved_init_regions) {
> +		addr = __pa(memblock.reserved.regions);
> +		size = PAGE_ALIGN(sizeof(struct memblock_region) *
> +				  memblock.reserved.max);
> +		__memblock_free_late(addr, size);
> +	}
>  
> -	return PAGE_ALIGN(sizeof(struct memblock_region) *
> -			  memblock.memory.max);
> +	if (memblock.memory.regions = memblock_memory_init_regions) {
> +		addr = __pa(memblock.memory.regions);
> +		size = PAGE_ALIGN(sizeof(struct memblock_region) *
> +				  memblock.memory.max);
> +		__memblock_free_late(addr, size);
> +	}
>  }
> -
>  #endif
[...]
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index fc32aa81f359..63d16c185736 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1584,6 +1584,10 @@ void __init page_alloc_init_late(void)
>  	/* Reinit limits that are based on free pages after the kernel is up */
>  	files_maxfiles_init();
>  #endif
> +#ifdef CONFIG_ARCH_DISCARD_MEMBLOCK
> +	/* Discard memblock private memory */
> +	memblock_discard();
> +#endif
>  
>  	for_each_populated_zone(zone)
>  		set_zone_contiguous(zone);
> -- 
> 2.14.0

-- 
Michal Hocko
SUSE Labs

WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org>
To: Pavel Tatashin <pasha.tatashin@oracle.com>
Cc: linux-kernel@vger.kernel.org, sparclinux@vger.kernel.org,
	linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org,
	linux-s390@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	x86@kernel.org, kasan-dev@googlegroups.com,
	borntraeger@de.ibm.com, heiko.carstens@de.ibm.com,
	davem@davemloft.net, willy@infradead.org,
	ard.biesheuvel@linaro.org, will.deacon@arm.com,
	catalin.marinas@arm.com, sam@ravnborg.org,
	Mel Gorman <mgorman@suse.de>
Subject: Re: [v6 04/15] mm: discard memblock data later
Date: Fri, 11 Aug 2017 11:32:49 +0200	[thread overview]
Message-ID: <20170811093249.GE30811@dhcp22.suse.cz> (raw)
In-Reply-To: <1502138329-123460-5-git-send-email-pasha.tatashin@oracle.com>

[CC Mel]

On Mon 07-08-17 16:38:38, Pavel Tatashin wrote:
> There is existing use after free bug when deferred struct pages are
> enabled:
> 
> The memblock_add() allocates memory for the memory array if more than
> 128 entries are needed.  See comment in e820__memblock_setup():
> 
>   * The bootstrap memblock region count maximum is 128 entries
>   * (INIT_MEMBLOCK_REGIONS), but EFI might pass us more E820 entries
>   * than that - so allow memblock resizing.
> 
> This memblock memory is freed here:
>         free_low_memory_core_early()
> 
> We access the freed memblock.memory later in boot when deferred pages are
> initialized in this path:
> 
>         deferred_init_memmap()
>                 for_each_mem_pfn_range()
>                   __next_mem_pfn_range()
>                     type = &memblock.memory;

Yes you seem to be right.
>
> One possible explanation for why this use-after-free hasn't been hit
> before is that the limit of INIT_MEMBLOCK_REGIONS has never been exceeded
> at least on systems where deferred struct pages were enabled.

Yeah this sounds like the case.
 
> Another reason why we want this problem fixed in this patch series is,
> in the next patch, we will need to access memblock.reserved from
> deferred_init_memmap().
> 

I guess this goes all the way down to 
Fixes: 7e18adb4f80b ("mm: meminit: initialise remaining struct pages in parallel with kswapd")
> Signed-off-by: Pavel Tatashin <pasha.tatashin@oracle.com>
> Reviewed-by: Steven Sistare <steven.sistare@oracle.com>
> Reviewed-by: Daniel Jordan <daniel.m.jordan@oracle.com>
> Reviewed-by: Bob Picco <bob.picco@oracle.com>

Considering that some HW might behave strangely and this would be rather
hard to debug I would be tempted to mark this for stable. It should also
be merged separately from the rest of the series.

I have just one nit below
Acked-by: Michal Hocko <mhocko@suse.com>

[...]
> diff --git a/mm/memblock.c b/mm/memblock.c
> index 2cb25fe4452c..bf14aea6ab70 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -285,31 +285,27 @@ static void __init_memblock memblock_remove_region(struct memblock_type *type, u
>  }
>  
>  #ifdef CONFIG_ARCH_DISCARD_MEMBLOCK

pull this ifdef inside memblock_discard and you do not have an another
one in page_alloc_init_late

[...]
> +/**
> + * Discard memory and reserved arrays if they were allocated
> + */
> +void __init memblock_discard(void)
>  {

here

> -	if (memblock.memory.regions == memblock_memory_init_regions)
> -		return 0;
> +	phys_addr_t addr, size;
>  
> -	*addr = __pa(memblock.memory.regions);
> +	if (memblock.reserved.regions != memblock_reserved_init_regions) {
> +		addr = __pa(memblock.reserved.regions);
> +		size = PAGE_ALIGN(sizeof(struct memblock_region) *
> +				  memblock.reserved.max);
> +		__memblock_free_late(addr, size);
> +	}
>  
> -	return PAGE_ALIGN(sizeof(struct memblock_region) *
> -			  memblock.memory.max);
> +	if (memblock.memory.regions == memblock_memory_init_regions) {
> +		addr = __pa(memblock.memory.regions);
> +		size = PAGE_ALIGN(sizeof(struct memblock_region) *
> +				  memblock.memory.max);
> +		__memblock_free_late(addr, size);
> +	}
>  }
> -
>  #endif
[...]
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index fc32aa81f359..63d16c185736 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1584,6 +1584,10 @@ void __init page_alloc_init_late(void)
>  	/* Reinit limits that are based on free pages after the kernel is up */
>  	files_maxfiles_init();
>  #endif
> +#ifdef CONFIG_ARCH_DISCARD_MEMBLOCK
> +	/* Discard memblock private memory */
> +	memblock_discard();
> +#endif
>  
>  	for_each_populated_zone(zone)
>  		set_zone_contiguous(zone);
> -- 
> 2.14.0

-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: mhocko@kernel.org (Michal Hocko)
To: linux-arm-kernel@lists.infradead.org
Subject: [v6 04/15] mm: discard memblock data later
Date: Fri, 11 Aug 2017 11:32:49 +0200	[thread overview]
Message-ID: <20170811093249.GE30811@dhcp22.suse.cz> (raw)
In-Reply-To: <1502138329-123460-5-git-send-email-pasha.tatashin@oracle.com>

[CC Mel]

On Mon 07-08-17 16:38:38, Pavel Tatashin wrote:
> There is existing use after free bug when deferred struct pages are
> enabled:
> 
> The memblock_add() allocates memory for the memory array if more than
> 128 entries are needed.  See comment in e820__memblock_setup():
> 
>   * The bootstrap memblock region count maximum is 128 entries
>   * (INIT_MEMBLOCK_REGIONS), but EFI might pass us more E820 entries
>   * than that - so allow memblock resizing.
> 
> This memblock memory is freed here:
>         free_low_memory_core_early()
> 
> We access the freed memblock.memory later in boot when deferred pages are
> initialized in this path:
> 
>         deferred_init_memmap()
>                 for_each_mem_pfn_range()
>                   __next_mem_pfn_range()
>                     type = &memblock.memory;

Yes you seem to be right.
>
> One possible explanation for why this use-after-free hasn't been hit
> before is that the limit of INIT_MEMBLOCK_REGIONS has never been exceeded
> at least on systems where deferred struct pages were enabled.

Yeah this sounds like the case.
 
> Another reason why we want this problem fixed in this patch series is,
> in the next patch, we will need to access memblock.reserved from
> deferred_init_memmap().
> 

I guess this goes all the way down to 
Fixes: 7e18adb4f80b ("mm: meminit: initialise remaining struct pages in parallel with kswapd")
> Signed-off-by: Pavel Tatashin <pasha.tatashin@oracle.com>
> Reviewed-by: Steven Sistare <steven.sistare@oracle.com>
> Reviewed-by: Daniel Jordan <daniel.m.jordan@oracle.com>
> Reviewed-by: Bob Picco <bob.picco@oracle.com>

Considering that some HW might behave strangely and this would be rather
hard to debug I would be tempted to mark this for stable. It should also
be merged separately from the rest of the series.

I have just one nit below
Acked-by: Michal Hocko <mhocko@suse.com>

[...]
> diff --git a/mm/memblock.c b/mm/memblock.c
> index 2cb25fe4452c..bf14aea6ab70 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -285,31 +285,27 @@ static void __init_memblock memblock_remove_region(struct memblock_type *type, u
>  }
>  
>  #ifdef CONFIG_ARCH_DISCARD_MEMBLOCK

pull this ifdef inside memblock_discard and you do not have an another
one in page_alloc_init_late

[...]
> +/**
> + * Discard memory and reserved arrays if they were allocated
> + */
> +void __init memblock_discard(void)
>  {

here

> -	if (memblock.memory.regions == memblock_memory_init_regions)
> -		return 0;
> +	phys_addr_t addr, size;
>  
> -	*addr = __pa(memblock.memory.regions);
> +	if (memblock.reserved.regions != memblock_reserved_init_regions) {
> +		addr = __pa(memblock.reserved.regions);
> +		size = PAGE_ALIGN(sizeof(struct memblock_region) *
> +				  memblock.reserved.max);
> +		__memblock_free_late(addr, size);
> +	}
>  
> -	return PAGE_ALIGN(sizeof(struct memblock_region) *
> -			  memblock.memory.max);
> +	if (memblock.memory.regions == memblock_memory_init_regions) {
> +		addr = __pa(memblock.memory.regions);
> +		size = PAGE_ALIGN(sizeof(struct memblock_region) *
> +				  memblock.memory.max);
> +		__memblock_free_late(addr, size);
> +	}
>  }
> -
>  #endif
[...]
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index fc32aa81f359..63d16c185736 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1584,6 +1584,10 @@ void __init page_alloc_init_late(void)
>  	/* Reinit limits that are based on free pages after the kernel is up */
>  	files_maxfiles_init();
>  #endif
> +#ifdef CONFIG_ARCH_DISCARD_MEMBLOCK
> +	/* Discard memblock private memory */
> +	memblock_discard();
> +#endif
>  
>  	for_each_populated_zone(zone)
>  		set_zone_contiguous(zone);
> -- 
> 2.14.0

-- 
Michal Hocko
SUSE Labs

  reply	other threads:[~2017-08-11  9:32 UTC|newest]

Thread overview: 282+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-07 20:38 [v6 00/15] complete deferred page initialization Pavel Tatashin
2017-08-07 20:38 ` Pavel Tatashin
2017-08-07 20:38 ` Pavel Tatashin
2017-08-07 20:38 ` Pavel Tatashin
2017-08-07 20:38 ` [v6 01/15] x86/mm: reserve only exiting low pages Pavel Tatashin
2017-08-07 20:38   ` Pavel Tatashin
2017-08-07 20:38   ` Pavel Tatashin
2017-08-07 20:38   ` Pavel Tatashin
2017-08-11  8:07   ` Michal Hocko
2017-08-11  8:07     ` Michal Hocko
2017-08-11  8:07     ` Michal Hocko
2017-08-11  8:07     ` Michal Hocko
2017-08-11 15:24     ` Pasha Tatashin
2017-08-11 15:24       ` Pasha Tatashin
2017-08-11 15:24       ` Pasha Tatashin
2017-08-11 15:24       ` Pasha Tatashin
2017-08-14 11:40       ` Michal Hocko
2017-08-14 11:40         ` Michal Hocko
2017-08-14 11:40         ` Michal Hocko
2017-08-14 11:40         ` Michal Hocko
2017-08-14 13:30         ` Pasha Tatashin
2017-08-14 13:30           ` Pasha Tatashin
2017-08-14 13:30           ` Pasha Tatashin
2017-08-14 13:30           ` Pasha Tatashin
2017-08-14 13:55   ` Michal Hocko
2017-08-14 13:55     ` Michal Hocko
2017-08-14 13:55     ` Michal Hocko
2017-08-14 13:55     ` Michal Hocko
2017-08-17 15:37     ` Pasha Tatashin
2017-08-17 15:37       ` Pasha Tatashin
2017-08-17 15:37       ` Pasha Tatashin
2017-08-17 15:37       ` Pasha Tatashin
2017-08-07 20:38 ` [v6 02/15] x86/mm: setting fields in deferred pages Pavel Tatashin
2017-08-07 20:38   ` Pavel Tatashin
2017-08-07 20:38   ` Pavel Tatashin
2017-08-07 20:38   ` Pavel Tatashin
2017-08-11  9:02   ` Michal Hocko
2017-08-11  9:02     ` Michal Hocko
2017-08-11  9:02     ` Michal Hocko
2017-08-11  9:02     ` Michal Hocko
2017-08-11 15:39     ` Pasha Tatashin
2017-08-11 15:39       ` Pasha Tatashin
2017-08-11 15:39       ` Pasha Tatashin
2017-08-11 15:39       ` Pasha Tatashin
2017-08-14 11:43       ` Michal Hocko
2017-08-14 11:43         ` Michal Hocko
2017-08-14 11:43         ` Michal Hocko
2017-08-14 11:43         ` Michal Hocko
2017-08-14 13:32         ` Pasha Tatashin
2017-08-14 13:32           ` Pasha Tatashin
2017-08-14 13:32           ` Pasha Tatashin
2017-08-14 13:32           ` Pasha Tatashin
2017-08-07 20:38 ` [v6 03/15] sparc64/mm: " Pavel Tatashin
2017-08-07 20:38   ` Pavel Tatashin
2017-08-07 20:38   ` Pavel Tatashin
2017-08-07 20:38   ` Pavel Tatashin
2017-08-07 20:38 ` [v6 04/15] mm: discard memblock data later Pavel Tatashin
2017-08-07 20:38   ` Pavel Tatashin
2017-08-07 20:38   ` Pavel Tatashin
2017-08-07 20:38   ` Pavel Tatashin
2017-08-11  9:32   ` Michal Hocko [this message]
2017-08-11  9:32     ` Michal Hocko
2017-08-11  9:32     ` Michal Hocko
2017-08-11  9:32     ` Michal Hocko
2017-08-11  9:50     ` Mel Gorman
2017-08-11  9:50       ` Mel Gorman
2017-08-11  9:50       ` Mel Gorman
2017-08-11  9:50       ` Mel Gorman
2017-08-11 15:49     ` Pasha Tatashin
2017-08-11 15:49       ` Pasha Tatashin
2017-08-11 15:49       ` Pasha Tatashin
2017-08-11 15:49       ` Pasha Tatashin
2017-08-11 16:04       ` Michal Hocko
2017-08-11 16:04         ` Michal Hocko
2017-08-11 16:04         ` Michal Hocko
2017-08-11 16:04         ` Michal Hocko
2017-08-11 16:22         ` Pasha Tatashin
2017-08-11 16:22           ` Pasha Tatashin
2017-08-11 16:22           ` Pasha Tatashin
2017-08-11 16:22           ` Pasha Tatashin
2017-08-14 11:36           ` Michal Hocko
2017-08-14 11:36             ` Michal Hocko
2017-08-14 11:36             ` Michal Hocko
2017-08-14 11:36             ` Michal Hocko
2017-08-14 13:35             ` Pasha Tatashin
2017-08-14 13:35               ` Pasha Tatashin
2017-08-14 13:35               ` Pasha Tatashin
2017-08-14 13:35               ` Pasha Tatashin
2017-08-11 19:00     ` Pasha Tatashin
2017-08-11 19:00       ` Pasha Tatashin
2017-08-11 19:00       ` Pasha Tatashin
2017-08-11 19:00       ` Pasha Tatashin
2017-08-14 11:34       ` Michal Hocko
2017-08-14 11:34         ` Michal Hocko
2017-08-14 11:34         ` Michal Hocko
2017-08-14 11:34         ` Michal Hocko
2017-08-14 13:39         ` Pasha Tatashin
2017-08-14 13:39           ` Pasha Tatashin
2017-08-14 13:39           ` Pasha Tatashin
2017-08-14 13:39           ` Pasha Tatashin
2017-08-14 13:42           ` Michal Hocko
2017-08-14 13:42             ` Michal Hocko
2017-08-14 13:42             ` Michal Hocko
2017-08-14 13:42             ` Michal Hocko
2017-08-07 20:38 ` [v6 05/15] mm: don't accessed uninitialized struct pages Pavel Tatashin
2017-08-07 20:38   ` Pavel Tatashin
2017-08-07 20:38   ` Pavel Tatashin
2017-08-07 20:38   ` Pavel Tatashin
2017-08-11  9:37   ` Michal Hocko
2017-08-11  9:37     ` Michal Hocko
2017-08-11  9:37     ` Michal Hocko
2017-08-11  9:37     ` Michal Hocko
2017-08-11 15:55     ` Pasha Tatashin
2017-08-11 15:55       ` Pasha Tatashin
2017-08-11 15:55       ` Pasha Tatashin
2017-08-11 15:55       ` Pasha Tatashin
2017-08-14 11:47       ` Michal Hocko
2017-08-14 11:47         ` Michal Hocko
2017-08-14 11:47         ` Michal Hocko
2017-08-14 11:47         ` Michal Hocko
2017-08-14 13:51         ` Pasha Tatashin
2017-08-14 13:51           ` Pasha Tatashin
2017-08-14 13:51           ` Pasha Tatashin
2017-08-14 13:51           ` Pasha Tatashin
2017-08-17 15:28           ` Pasha Tatashin
2017-08-17 15:28             ` Pasha Tatashin
2017-08-17 15:28             ` Pasha Tatashin
2017-08-17 15:28             ` Pasha Tatashin
2017-08-17 15:43             ` Michal Hocko
2017-08-17 15:43               ` Michal Hocko
2017-08-17 15:43               ` Michal Hocko
2017-08-17 15:43               ` Michal Hocko
2017-08-15  9:33   ` Michal Hocko
2017-08-15  9:33     ` Michal Hocko
2017-08-15  9:33     ` Michal Hocko
2017-08-15  9:33     ` Michal Hocko
2017-08-07 20:38 ` [v6 06/15] sparc64: simplify vmemmap_populate Pavel Tatashin
2017-08-07 20:38   ` Pavel Tatashin
2017-08-07 20:38   ` Pavel Tatashin
2017-08-07 20:38   ` Pavel Tatashin
2017-08-07 20:38 ` [v6 07/15] mm: defining memblock_virt_alloc_try_nid_raw Pavel Tatashin
2017-08-07 20:38   ` Pavel Tatashin
2017-08-07 20:38   ` Pavel Tatashin
2017-08-07 20:38   ` Pavel Tatashin
2017-08-11 12:39   ` Michal Hocko
2017-08-11 12:39     ` Michal Hocko
2017-08-11 12:39     ` Michal Hocko
2017-08-11 12:39     ` Michal Hocko
2017-08-11 15:58     ` Pasha Tatashin
2017-08-11 15:58       ` Pasha Tatashin
2017-08-11 15:58       ` Pasha Tatashin
2017-08-11 15:58       ` Pasha Tatashin
2017-08-11 16:06       ` Michal Hocko
2017-08-11 16:06         ` Michal Hocko
2017-08-11 16:06         ` Michal Hocko
2017-08-11 16:06         ` Michal Hocko
2017-08-11 16:24         ` Pasha Tatashin
2017-08-11 16:24           ` Pasha Tatashin
2017-08-11 16:24           ` Pasha Tatashin
2017-08-11 16:24           ` Pasha Tatashin
2017-08-07 20:38 ` [v6 08/15] mm: zero struct pages during initialization Pavel Tatashin
2017-08-07 20:38   ` Pavel Tatashin
2017-08-07 20:38   ` Pavel Tatashin
2017-08-07 20:38   ` Pavel Tatashin
2017-08-11 12:50   ` Michal Hocko
2017-08-11 12:50     ` Michal Hocko
2017-08-11 12:50     ` Michal Hocko
2017-08-11 12:50     ` Michal Hocko
2017-08-11 16:03     ` Pasha Tatashin
2017-08-11 16:03       ` Pasha Tatashin
2017-08-11 16:03       ` Pasha Tatashin
2017-08-11 16:03       ` Pasha Tatashin
2017-08-07 20:38 ` [v6 09/15] sparc64: optimized struct page zeroing Pavel Tatashin
2017-08-07 20:38   ` Pavel Tatashin
2017-08-07 20:38   ` Pavel Tatashin
2017-08-07 20:38   ` Pavel Tatashin
2017-08-11 12:53   ` Michal Hocko
2017-08-11 12:53     ` Michal Hocko
2017-08-11 12:53     ` Michal Hocko
2017-08-11 12:53     ` Michal Hocko
2017-08-11 16:04     ` Pasha Tatashin
2017-08-11 16:04       ` Pasha Tatashin
2017-08-11 16:04       ` Pasha Tatashin
2017-08-11 16:04       ` Pasha Tatashin
2017-08-07 20:38 ` [v6 10/15] x86/kasan: explicitly zero kasan shadow memory Pavel Tatashin
2017-08-07 20:38   ` Pavel Tatashin
2017-08-07 20:38   ` Pavel Tatashin
2017-08-07 20:38   ` Pavel Tatashin
2017-08-07 20:38 ` [v6 11/15] arm64/kasan: " Pavel Tatashin
2017-08-07 20:38   ` Pavel Tatashin
2017-08-07 20:38   ` Pavel Tatashin
2017-08-07 20:38   ` Pavel Tatashin
2017-08-08  9:07   ` Will Deacon
2017-08-08  9:07     ` Will Deacon
2017-08-08  9:07     ` Will Deacon
2017-08-08  9:07     ` Will Deacon
2017-08-08 11:49     ` Pasha Tatashin
2017-08-08 11:49       ` Pasha Tatashin
2017-08-08 11:49       ` Pasha Tatashin
2017-08-08 11:49       ` Pasha Tatashin
2017-08-08 12:30       ` Will Deacon
2017-08-08 12:30         ` Will Deacon
2017-08-08 12:30         ` Will Deacon
2017-08-08 12:30         ` Will Deacon
2017-08-08 12:49         ` Pasha Tatashin
2017-08-08 12:49           ` Pasha Tatashin
2017-08-08 12:49           ` Pasha Tatashin
2017-08-08 12:49           ` Pasha Tatashin
2017-08-08 13:15       ` David Laight
2017-08-08 13:15         ` David Laight
2017-08-08 13:15         ` David Laight
2017-08-08 13:15         ` David Laight
2017-08-08 13:15         ` David Laight
2017-08-08 13:30         ` Pasha Tatashin
2017-08-08 13:30           ` Pasha Tatashin
2017-08-08 13:30           ` Pasha Tatashin
2017-08-08 13:30           ` Pasha Tatashin
2017-08-08 13:30           ` Pasha Tatashin
2017-08-07 20:38 ` [v6 12/15] mm: explicitly zero pagetable memory Pavel Tatashin
2017-08-07 20:38   ` Pavel Tatashin
2017-08-07 20:38   ` Pavel Tatashin
2017-08-07 20:38   ` Pavel Tatashin
2017-08-07 20:38 ` [v6 13/15] mm: stop zeroing memory during allocation in vmemmap Pavel Tatashin
2017-08-07 20:38   ` Pavel Tatashin
2017-08-07 20:38   ` Pavel Tatashin
2017-08-07 20:38   ` Pavel Tatashin
2017-08-11 13:04   ` Michal Hocko
2017-08-11 13:04     ` Michal Hocko
2017-08-11 13:04     ` Michal Hocko
2017-08-11 13:04     ` Michal Hocko
2017-08-11 16:11     ` Pasha Tatashin
2017-08-11 16:11       ` Pasha Tatashin
2017-08-11 16:11       ` Pasha Tatashin
2017-08-11 16:11       ` Pasha Tatashin
2017-08-07 20:38 ` [v6 14/15] mm: optimize early system hash allocations Pavel Tatashin
2017-08-07 20:38   ` Pavel Tatashin
2017-08-07 20:38   ` Pavel Tatashin
2017-08-07 20:38   ` Pavel Tatashin
2017-08-11 13:05   ` Michal Hocko
2017-08-11 13:05     ` Michal Hocko
2017-08-11 13:05     ` Michal Hocko
2017-08-11 13:05     ` Michal Hocko
2017-08-11 16:13     ` Pasha Tatashin
2017-08-11 16:13       ` Pasha Tatashin
2017-08-11 16:13       ` Pasha Tatashin
2017-08-11 16:13       ` Pasha Tatashin
2017-08-07 20:38 ` [v6 15/15] mm: debug for raw alloctor Pavel Tatashin
2017-08-07 20:38   ` Pavel Tatashin
2017-08-07 20:38   ` Pavel Tatashin
2017-08-07 20:38   ` Pavel Tatashin
2017-08-11 13:08   ` Michal Hocko
2017-08-11 13:08     ` Michal Hocko
2017-08-11 13:08     ` Michal Hocko
2017-08-11 13:08     ` Michal Hocko
2017-08-11 16:18     ` Pasha Tatashin
2017-08-11 16:18       ` Pasha Tatashin
2017-08-11 16:18       ` Pasha Tatashin
2017-08-11 16:18       ` Pasha Tatashin
2017-08-14 11:50       ` Michal Hocko
2017-08-14 11:50         ` Michal Hocko
2017-08-14 11:50         ` Michal Hocko
2017-08-14 11:50         ` Michal Hocko
2017-08-14 14:01         ` Pasha Tatashin
2017-08-14 14:01           ` Pasha Tatashin
2017-08-14 14:01           ` Pasha Tatashin
2017-08-14 14:01           ` Pasha Tatashin
2017-08-15  9:36           ` Michal Hocko
2017-08-15  9:36             ` Michal Hocko
2017-08-15  9:36             ` Michal Hocko
2017-08-15  9:36             ` Michal Hocko
2017-08-11  7:58 ` [v6 00/15] complete deferred page initialization Michal Hocko
2017-08-11  7:58   ` Michal Hocko
2017-08-11  7:58   ` Michal Hocko
2017-08-11  7:58   ` Michal Hocko
2017-08-11 15:13   ` Pasha Tatashin
2017-08-11 15:13     ` Pasha Tatashin
2017-08-11 15:13     ` Pasha Tatashin
2017-08-11 15:13     ` Pasha Tatashin
2017-08-11 15:22     ` Michal Hocko
2017-08-11 15:22       ` Michal Hocko
2017-08-11 15:22       ` Michal Hocko
2017-08-11 15:22       ` Michal Hocko

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=20170811093249.GE30811@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=ard.biesheuvel@linaro.org \
    --cc=borntraeger@de.ibm.com \
    --cc=catalin.marinas@arm.com \
    --cc=davem@davemloft.net \
    --cc=heiko.carstens@de.ibm.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mgorman@suse.de \
    --cc=pasha.tatashin@oracle.com \
    --cc=sam@ravnborg.org \
    --cc=sparclinux@vger.kernel.org \
    --cc=will.deacon@arm.com \
    --cc=willy@infradead.org \
    --cc=x86@kernel.org \
    /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: link
Be 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.