On Mon 14-08-17 09:39:17, Pasha Tatashin wrote:
> >>#ifdef CONFIG_MEMBLOCK in page_alloc, or define memblock_discard() stubs in
> >>nobootmem headfile.
> >
> >This is the standard way to do this. And it is usually preferred to
> >proliferate ifdefs in the code.
>
> Hi Michal,
>
> As you suggested
#ifdef CONFIG_MEMBLOCK in page_alloc, or define memblock_discard() stubs in
nobootmem headfile.
This is the standard way to do this. And it is usually preferred to
proliferate ifdefs in the code.
Hi Michal,
As you suggested, I sent-out this patch separately. If you feel
strongly, that this s
OK, I will post it separately. No it does not depend on the rest, but the
reset depends on this. So, I am not sure how to enforce that this comes
before the rest.
Andrew will take care of that. Just make it explicit that some of the
patch depends on an earlier work when reposting.
Ok.
Yes, t
On Fri 11-08-17 12:22:52, Pasha Tatashin wrote:
> >>I will address your comment, and send out a new patch. Should I send it out
> >>separately from the series or should I keep it inside?
> >
> >I would post it separatelly. It doesn't depend on the rest.
>
> OK, I will post it separately. No it doe
On Fri 11-08-17 15:00:47, Pasha Tatashin wrote:
> Hi Michal,
>
> This suggestion won't work, because there are arches without memblock
> support: tile, sh...
>
> So, I would still need to have:
>
> #ifdef CONFIG_MEMBLOCK in page_alloc, or define memblock_discard() stubs in
> nobootmem headfile.
Hi Michal,
This suggestion won't work, because there are arches without memblock
support: tile, sh...
So, I would still need to have:
#ifdef CONFIG_MEMBLOCK in page_alloc, or define memblock_discard() stubs
in nobootmem headfile. In either case it would become messier than what
it is right
I will address your comment, and send out a new patch. Should I send it out
separately from the series or should I keep it inside?
I would post it separatelly. It doesn't depend on the rest.
OK, I will post it separately. No it does not depend on the rest, but
the reset depends on this. So, I
On Fri 11-08-17 11:49:15, Pasha Tatashin wrote:
> >I guess this goes all the way down to
> >Fixes: 7e18adb4f80b ("mm: meminit: initialise remaining struct pages in
> >parallel with kswapd")
>
> I will add this to the patch.
>
> >>Signed-off-by: Pavel Tatashin
> >>Reviewed-by: Steven Sistare
>
I guess this goes all the way down to
Fixes: 7e18adb4f80b ("mm: meminit: initialise remaining struct pages in parallel
with kswapd")
I will add this to the patch.
Signed-off-by: Pavel Tatashin
Reviewed-by: Steven Sistare
Reviewed-by: Daniel Jordan
Reviewed-by: Bob Picco
Considering that
On Fri, Aug 11, 2017 at 11:32:49AM +0200, Michal Hocko wrote:
> > Signed-off-by: Pavel Tatashin
> > Reviewed-by: Steven Sistare
> > Reviewed-by: Daniel Jordan
> > Reviewed-by: Bob Picco
>
> Considering that some HW might behave strangely and this would be rather
> hard to debug I would be temp
[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 bootst
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_REGI
12 matches
Mail list logo
