[PATCH 1/2] kexec: update VMCOREINFO for compound_order/dtor

[PATCH 1/2] kexec: update VMCOREINFO for compound_order/dtor

[Atsushi Kumagai]

makedumpfile refers page.lru.next to get the order of compound pages
for page filtering. However, now the order is stored in page.compound_order,
hence VMCOREINFO should be updated to export the offset of
page.compound_order.

The fact is, page.compound_order was introduced already in kernel 4.0,
but the offset of it was the same as page.lru.next until kernel 4.3,
so this was not actual problem.

The above can be said also for page.lru.prev and page.compound_dtor,
it's necessary to detect hugetlbfs pages. Further, the content was
changed from direct address to the ID which means dtor.

Signed-off-by: Atsushi Kumagai <ats-kumagai@wm.jp.nec.com>
---
 kernel/kexec_core.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index 8dc6591..7c0b61d 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -1413,6 +1413,8 @@ static int __init crash_save_vmcoreinfo_init(void)
 	VMCOREINFO_OFFSET(page, lru);
 	VMCOREINFO_OFFSET(page, _mapcount);
 	VMCOREINFO_OFFSET(page, private);
+	VMCOREINFO_OFFSET(page, compound_dtor);
+	VMCOREINFO_OFFSET(page, compound_order);
 	VMCOREINFO_OFFSET(pglist_data, node_zones);
 	VMCOREINFO_OFFSET(pglist_data, nr_zones);
 #ifdef CONFIG_FLAT_NODE_MEM_MAP
@@ -1445,8 +1447,8 @@ static int __init crash_save_vmcoreinfo_init(void)
 #ifdef CONFIG_X86
 	VMCOREINFO_NUMBER(KERNEL_IMAGE_SIZE);
 #endif
-#ifdef CONFIG_HUGETLBFS
-	VMCOREINFO_SYMBOL(free_huge_page);
+#ifdef CONFIG_HUGETLB_PAGE
+	VMCOREINFO_NUMBER(HUGETLB_PAGE_DTOR);
 #endif
 
 	arch_crash_save_vmcoreinfo();
-- 
2.7.2

Re: [PATCH 1/2] kexec: update VMCOREINFO for compound_order/dtor

[Andrew Morton]

On Tue, 1 Mar 2016 06:14:32 +0000 Atsushi Kumagai <ats-kumagai@wm.jp.nec.com> wrote:

> makedumpfile refers page.lru.next to get the order of compound pages
> for page filtering. However, now the order is stored in page.compound_order,
> hence VMCOREINFO should be updated to export the offset of
> page.compound_order.
> 
> The fact is, page.compound_order was introduced already in kernel 4.0,
> but the offset of it was the same as page.lru.next until kernel 4.3,
> so this was not actual problem.
> 
> The above can be said also for page.lru.prev and page.compound_dtor,
> it's necessary to detect hugetlbfs pages. Further, the content was
> changed from direct address to the ID which means dtor.

It's unclear which kernels need the patch and why.  I *think* that the
patch is needed in 4.3.x, 4.4.x, 4.5.x and 4.6 in order to make
makedumpfile work correctly.  Is that right?

And it appears that [patch 2/2] is needed in 4.0+?

However in both cases I am uncertain - what are the end-user visible
effects of these regressions?  Why can bugs remain in place for so long
without having been observed?


Please make all these things clear when perparing changelogs for
bugfixes: which kernel versions need fixing and why (ie: what are the
end-user visible effects of the bug).

RE: [PATCH 1/2] kexec: update VMCOREINFO for compound_order/dtor

[Atsushi Kumagai]

>On Tue, 1 Mar 2016 06:14:32 +0000 Atsushi Kumagai <ats-kumagai@wm.jp.nec.com> wrote:
>
>> makedumpfile refers page.lru.next to get the order of compound pages
>> for page filtering. However, now the order is stored in page.compound_order,
>> hence VMCOREINFO should be updated to export the offset of
>> page.compound_order.
>>
>> The fact is, page.compound_order was introduced already in kernel 4.0,
>> but the offset of it was the same as page.lru.next until kernel 4.3,
>> so this was not actual problem.
>>
>> The above can be said also for page.lru.prev and page.compound_dtor,
>> it's necessary to detect hugetlbfs pages. Further, the content was
>> changed from direct address to the ID which means dtor.
>
>It's unclear which kernels need the patch and why.  I *think* that the
>patch is needed in 4.3.x, 4.4.x, 4.5.x and 4.6 in order to make
>makedumpfile work correctly.  Is that right?

The patch is necessary for 4.4.x, 4.5.x and 4.6.
4.3.x don't have the problem.

>And it appears that [patch 2/2] is needed in 4.0+?

[patch 2/2] is for 4.5.x and latter:

  $ git name-rev 1c290f642101e6
  1c290f642101e6 tags/v4.5-rc1~77^2~129
  $

>However in both cases I am uncertain - what are the end-user visible
>effects of these regressions?  Why can bugs remain in place for so long
>without having been observed?

The problem is that unnecessary hugepages wouldn't be removed from
a dump file in the older kernels. This means that extra disk space
would be consumed.
It's a problem, but not critical.

>Please make all these things clear when perparing changelogs for
>bugfixes: which kernel versions need fixing and why (ie: what are the
>end-user visible effects of the bug).

Sure, I will be careful about it.


Thanks,
Atsushi Kumagai