From: piliu <piliu@redhat.com>
To: kexec@lists.infradead.org, Kazuhito Hagio <k-hagio@ab.jp.nec.com>
Subject: Re: [PATCH] makedumpfile: assign bitmap2 fd for sub process during refiltering
Date: Thu, 12 Dec 2019 09:40:51 +0800 [thread overview]
Message-ID: <9d5b162e-8d7e-1f2f-92a9-676476398e91@redhat.com> (raw)
In-Reply-To: <4AE2DC15AC0B8543882A74EA0D43DBEC03597DC4@BPXM09GP.gisp.nec.co.jp>
On 12/12/2019 01:44 AM, Kazuhito Hagio wrote:
> Hi Pingfan,
>
>> -----Original Message-----
>>> Reading the code, I think
>>> - the issue might occur not only in refiltering, but also the first filtering
>>> with --split and --work-dir option (forced non-cyclic mode).
>>> - pefer to gather things for --split option into writeout_multiple_dumpfiles()
>>> if we can, for readability.
>> Yes, all of the cases suffer from sharing fd across processes
>>>
>>> So does the following patch work for you and your test?
>>> I could not have reproduced the issue yet.
>> I tried to fetch a machine to test. It pass 50 times test with your
>> patch. While if without this patch, it failed about 1 out of 4 times.
>
> Good. Thank you for testing.
>
>>> BTW, what do you see when the issue occurs? an error or broken dump?
>> The test case is refiltering, "makedumpfile --split -d 31
>> /root/vmcore-p9b-21 dumpfile_{1,2,3} 2>&1"
>> And it can not complete the dump.
>
> Ah, I got it. I probably could reproduce the issue:
> ---
> Excluding unnecessary pages : [100.0 %] \
> readpage_kdump_compressed: pfn(2fc1000) is excluded from vmcore.
> readmem: type_addr: 1, addr:2fc1000000, size:4096
> read_pfn: Can't get the page data.
> ...
> writeout_multiple_dumpfiles: Child process(30993) finished incompletely.(256)
>
> makedumpfile Failed.
> ---
>
> Refiltering was the factor that makedumpfile failed, but I think this bug
> also can break the dumpfile silently by excluding pages wrongly even in
> first filtering.
Yes, you are right.
>
> I guess this bug was hard to debug. Thank you so much for working on this!
Yeah, it took me some time. I had thought it should be a kernel bug
about the file{}.
> Modified your patch and pushed.
> https://sourceforge.net/p/makedumpfile/code/ci/5519b3eba68544dc484d85e9540d440d93f8c924/
>
Thanks,
Pingfan
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
prev parent reply other threads:[~2019-12-12 1:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-03 7:37 [PATCH] makedumpfile: assign bitmap2 fd for sub process during refiltering Pingfan Liu
2019-12-06 22:11 ` Kazuhito Hagio
2019-12-09 6:05 ` piliu
2019-12-09 20:10 ` Kazuhito Hagio
2019-12-11 7:41 ` piliu
2019-12-11 17:44 ` Kazuhito Hagio
2019-12-12 1:40 ` piliu [this message]
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=9d5b162e-8d7e-1f2f-92a9-676476398e91@redhat.com \
--to=piliu@redhat.com \
--cc=k-hagio@ab.jp.nec.com \
--cc=kexec@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox