Hi, On Tue, 13 Mar 2018 09:18:54 +0000 Masaki Tachibana <mas-tachib...@vf.jp.nec.com> wrote:
> Hi Petr, > > Sorry for the late reply. Never mind. I was on vacation, anyway. ;-) > > -----Original Message----- > > From: kexec [mailto:kexec-boun...@lists.infradead.org] On Behalf Of Petr > > Tesarik > > Sent: Friday, February 02, 2018 5:19 PM > > To: kexec mailing list <kexec@lists.infradead.org>; Tachibana Masaki() > > <mas-tachib...@vf.jp.nec.com>; Nakayama > > Takuya() <tak-nakay...@tg.jp.nec.com>; Nishimura Daisuke() > > <dai-nishim...@rc.jp.nec.com> > > Subject: [makedumpfile PATCH] Always use bigger SECTION_MAP_MASK > > > > It is not necessary to distinguish between different kernel > > versions. Kernel commit 2d070eab2e82 merely reuses a previously > > unused bit (see clarification in kernel commit def9b71ee651a). The > > bit was always zero even before that commit, so it is safe to mask > > it off even for kernel versions before 4.13, removing some of the > > complexity. > > > > More importantly, makedumpfile fails on kernels which backport the > > patch on top of an older version (for example SLES15). > > I understand circumstances of SLES. > However I am worried; > - Is it good that we correct the following specified code for the > particular distribution? No, absolutely not. That's why I'm not trying to fix a particular distribution, but rather make it work for all distributions (including my own). > - Is it good that makedumpfile ignores the bit because the kernel > isn't using it? I've given it a serious thought before writing my patch. Let me explain. First, what happens if the bit is set? A. If the kernel version is at least 4.13.0, then my patch does not change makedumpfile's behaviour. B. If the kernel version is older than 4.13.0, then I have verified that the bit must not be set. If it is set, then this is a bug in the kernel or random memory corruption. The kernel would then use an incorrect memmap address, probably crashing in short time. Without my patch, makedumpfile will most likely fail to produce any output. With my patch, it may produce some output. Second, my patch simplifies makedumpfile code, which is good in itself, because it reduces the maintenance burden going forward. A few years from now everybody will be too afraid of regressions to do such cleanup. The only downside is that in case B above, makedumpfile may silently produce incorrect output instead of failing mysteriously with an error message such as: "Can't convert a virtual address (f000000001000000) to physical address". Just my two cents, Petr Tesarik _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
