[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 1/2] xen/mm: fold PGC_broken into PGC_state bits
On Fri, 2020-02-07 at 20:27 +0000, Julien Grall wrote: > Could you please send the series in a separate thread? So we don't mix > the two discussions (i.e merge and free on boot allocated page) together. Well, they're all part of the same mess, really. There are cases where pages end up in free_heap_pages() which were never vetted by init_heap_pages(). While that normally works just fine — to the extent that we've never really cared — the hack excluding MFN0 is one of the things that gets 'missed' for such pages. I was only looking at this because the early vmap support makes it a tiny bit more likely that some pages will be freed that way after being given out by the boot allocator, but there were plenty of reasons it might happen already. These patches basically legitimise that — we make it OK for free_heap_pages() to be given a range which was never in the heap in the first place. And in so doing, we fix the MFN0/zone merge trick even when (for example) MFN0 was part of the dom0 initramfs and assigned directly, but gets freed up later. But sure, having failed to elicit any screams of "don't do it like that", I'll fix up the things you pointed out and I'll repost it as part of the series containing the early vmap() support, since that's why I'm working on it. Although at this point I'm half tempted to declare that there are *so* many ways this can happen already, that the tiny little bit that it's made more likely by the early vmap() support is basically in the noise. In that case we can separate these patches out as an independent fix rather than a dependency of early vmap. Attachment:
smime.p7s _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |