On Tue, 7 May 2019 13:18:06 -0400
Sasha Levin wrote:
> On Tue, May 07, 2019 at 10:15:19AM -0700, Linus Torvalds wrote:
> >On Tue, May 7, 2019 at 10:02 AM Sasha Levin wrote:
> >>
> >> I got it wrong then. I'll fix it up and get efad4e475c31 in instead.
> >
> >Careful. That one had a bug too, and
On Tue 07-05-19 13:45:14, Sasha Levin wrote:
[...]
> We're going to have (quite a) large amount of systems with "weird"
> memory layouts that do memory hotplug quite frequently in production, so
> this whole "tends to work usually" thing kinda scares me.
Memory hotplug is simply not production rea
On Tue 07-05-19 10:43:31, Linus Torvalds wrote:
> On Tue, May 7, 2019 at 10:36 AM Matthew Wilcox wrote:
> >
> > Can we do something with qemu? Is it flexible enough to hotplug memory
> > at the right boundaries?
>
> It's not just the actual hotplugged memory, it's things like how the
> e820 tabl
On Tue, May 07, 2019 at 10:36:55AM -0700, Matthew Wilcox wrote:
On Tue, May 07, 2019 at 07:32:24PM +0200, Michal Hocko wrote:
On Tue 07-05-19 13:18:06, Sasha Levin wrote:
> Michal, is there a testcase I can plug into kselftests to make sure we
> got this right (and don't regress)? We care a lot
On Tue, May 7, 2019 at 10:36 AM Matthew Wilcox wrote:
>
> Can we do something with qemu? Is it flexible enough to hotplug memory
> at the right boundaries?
It's not just the actual hotplugged memory, it's things like how the
e820 tables were laid out for the _regular_ non-hotplug stuff too,
iirc
On Tue 07-05-19 10:36:55, Matthew Wilcox wrote:
> On Tue, May 07, 2019 at 07:32:24PM +0200, Michal Hocko wrote:
> > On Tue 07-05-19 13:18:06, Sasha Levin wrote:
> > > Michal, is there a testcase I can plug into kselftests to make sure we
> > > got this right (and don't regress)? We care a lot about
On Tue, May 07, 2019 at 07:32:24PM +0200, Michal Hocko wrote:
> On Tue 07-05-19 13:18:06, Sasha Levin wrote:
> > Michal, is there a testcase I can plug into kselftests to make sure we
> > got this right (and don't regress)? We care a lot about memory hotplug
> > working right.
>
> As said in other
On Tue 07-05-19 13:18:06, Sasha Levin wrote:
> On Tue, May 07, 2019 at 10:15:19AM -0700, Linus Torvalds wrote:
> > On Tue, May 7, 2019 at 10:02 AM Sasha Levin wrote:
> > >
> > > I got it wrong then. I'll fix it up and get efad4e475c31 in instead.
> >
> > Careful. That one had a bug too, and we h
On Tue 07-05-19 10:15:19, Linus Torvalds wrote:
> On Tue, May 7, 2019 at 10:02 AM Sasha Levin wrote:
> >
> > I got it wrong then. I'll fix it up and get efad4e475c31 in instead.
This patch is not marked for stable backports for good reasons.
>
> Careful. That one had a bug too, and we have 891c
On Tue, May 7, 2019 at 10:02 AM Sasha Levin wrote:
>
> I got it wrong then. I'll fix it up and get efad4e475c31 in instead.
Careful. That one had a bug too, and we have 891cb2a72d82 ("mm,
memory_hotplug: fix off-by-one in is_pageblock_removable").
All of these were *horribly* and subtly buggy, a
On Tue, 7 May 2019 13:02:08 -0400
Sasha Levin wrote:
> On Tue, May 07, 2019 at 09:50:50AM -0700, Linus Torvalds wrote:
> >On Tue, May 7, 2019 at 9:31 AM Alexander Duyck
> > wrote:
> >>
> >> Wasn't this patch reverted in Linus's tree for causing a regression on
> >> some platforms? If so I'm not s
On Tue, May 07, 2019 at 10:15:19AM -0700, Linus Torvalds wrote:
On Tue, May 7, 2019 at 10:02 AM Sasha Levin wrote:
I got it wrong then. I'll fix it up and get efad4e475c31 in instead.
Careful. That one had a bug too, and we have 891cb2a72d82 ("mm,
memory_hotplug: fix off-by-one in is_pageblo
On Tue, May 07, 2019 at 09:50:50AM -0700, Linus Torvalds wrote:
On Tue, May 7, 2019 at 9:31 AM Alexander Duyck
wrote:
Wasn't this patch reverted in Linus's tree for causing a regression on
some platforms? If so I'm not sure we should pull this in as a
candidate for stable should we, or am I mi
On Tue, May 07, 2019 at 09:31:10AM -0700, Alexander Duyck wrote:
On Mon, May 6, 2019 at 10:40 PM Sasha Levin wrote:
From: Mikhail Zaslonko
[ Upstream commit 2830bf6f05fb3e05bc4743274b806c821807a684 ]
If memory end is not aligned with the sparse memory section boundary,
the mapping of such a
On Tue, May 7, 2019 at 9:31 AM Alexander Duyck
wrote:
>
> Wasn't this patch reverted in Linus's tree for causing a regression on
> some platforms? If so I'm not sure we should pull this in as a
> candidate for stable should we, or am I missing something?
Good catch. It was reverted in commit 4aa9
On Mon, May 6, 2019 at 10:40 PM Sasha Levin wrote:
>
> From: Mikhail Zaslonko
>
> [ Upstream commit 2830bf6f05fb3e05bc4743274b806c821807a684 ]
>
> If memory end is not aligned with the sparse memory section boundary,
> the mapping of such a section is only partly initialized. This may lead
> to
From: Mikhail Zaslonko
[ Upstream commit 2830bf6f05fb3e05bc4743274b806c821807a684 ]
If memory end is not aligned with the sparse memory section boundary,
the mapping of such a section is only partly initialized. This may lead
to VM_BUG_ON due to uninitialized struct page access from
is_mem_sect
17 matches
Mail list logo
