Hi Petr, Thank you for important information. I will wait for the patch. Thanks Tachibana > -----Original Message----- > From: Petr Tesarik [mailto:ptesarik@xxxxxxx] > Sent: Thursday, April 12, 2018 6:02 PM > To: Tachibana Masaki(橘 正樹) <mas-tachibana@xxxxxxxxxxxxx>; Nakayama Takuya(中山 卓也) <tak-nakayama@xxxxxxxxxxxxx>; > kexec-ml <kexec@xxxxxxxxxxxxxxxxxxx> > Subject: makedumpfile filters out wrong pages > > Hello, > > I've just hit a nasty bug in makedumpfile when page cache is filtered > out (dump level bitmap includes 2 or 4). In short, makedumpfile checks > PG_swapcache, but since commit 6326fec1122cde256bd2a8c63f2606e08e44ce1d > this bit is an alias for PG_owner_priv_1. This bit is also used by > filesystem code (PG_checked) and Xen (PG_pinned and PG_foreign). > > FTR I haven't hit an issue with the filsystem usage in practice, but > all my Xen dumps are unusable, because PG_pinned is by design set for > all page table pages. > > Anyway, it appears that PG_swapcache is valid only if PG_swapbacked is > set. I have already submitted a patch to the Linux kernel to export the > value of PG_swapbacked in VMCOREINFO: > > http://ozlabs.org/~akpm/mmotm/broken-out/kexec-export-pg_swapbacked-to-vmcoreinfo.patch > > I plan to make the corresponding makedumpfile change soon. However, it > seems to me that PG_swapbacked alone should determine whether a page > should be kept in the dump file, or filtered out. Why do we check > PG_swapcache instead? PG_swapbacked first appeared in kernel 2.6.28, > i.e. much later than makedumpfile. Is it simply that nobody has > reviewed the logic since then? > > Petr T _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec