(2013/11/18 9:51), Atsushi Kumagai wrote: > (2013/11/15 23:26), Vivek Goyal wrote: >> On Fri, Nov 15, 2013 at 06:41:52PM +0900, HATAYAMA Daisuke wrote: >> >> [..] >>>> Given the fact that hpa does not like fixing it in kernel. We are left >>>> with option of fixing it in following places. >>>> >>>> - Drop partial pages in kexec-tools >>>> - Drop partial pages in makeudmpfile. >>>> - Read partial pages using read() interface in makedumpfile >>>> - Modify /proc/vmcore to copy partial pages in second kernel's memory. >>>> >>>> It is not clear to me that partial pages are really useful. So I want >>>> to avoid modifying /proc/vmcore to deal with partial pages and increase >>>> complexity. >>>> >>>> So fixing makedumpfile (either option2 or option 3) seems least risky >>>> to me. In fact I would say let us keep it simple and truncate partial >>>> pages in makedumpfile to keep it simple. And look at option 3 once we >>>> have a strong use case for partial pages. >>>> >>>> What do you think? >>>> >>> >>> As you say, it's not clear that partial pages are really useful, but on >>> the other hand, it seems to me not clear that they are really useless. >>> I think we should get them as long as we have access to them. >>> >>> It seems best to me the option 3). Switching between read and mmap would >>> be not so complex and also it's by far flexible in makedumpfile than in >>> kernel. >> >> Ok, I am fine with option 3. It is more complicated option but safe >> option. > > It sounds reasonable also to me. > >> Is there any chance that you could look into fixing this. I have no >> experience writing code for makedumpfile. > > I'll send a patch to fix this soon. > Thanks. BTW, now the following patch has been applied on top of makedumpfile in kexec-tools package on fedora in order to avoid the issue. https://lists.fedoraproject.org/pipermail/kexec/2013-November/000254.html I remember prototype version of mmap patch implemented a kind of --no-mmap option and we could use it to disable mmap() use and use read() instead, I think which is useful when we face this kind of issue. -- Thanks. HATAYAMA, Daisuke
