On 2013/11/20 15:44:45, kexec <kexec-boun...@lists.infradead.org> wrote: > (2013/11/20 14:27), Atsushi Kumagai wrote: > > On 2013/11/19 18:56:21, kexec <kexec-boun...@lists.infradead.org> wrote: > >> (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. > > > > How about this fail back structure instead of such an extra option ? > > > > I think this logic is useful and should be merged together in this fix. > > However, I still think a kind of --no-mmap option is needed. There could > happen > worse case due to mmap() in the future on some system, of course, I don't know > what the system actually is, but at least it must be behaving differently from > typical systems... Then, option is more flexible than patching. > > It would also be useful for debugging use. read() is simpler than mmap(), and > read() is basic in the sense that initially makedumpfile didn't use mmap(). > There might be a situation where we want to avoid using mmap(); for example, > when makedumpfile works badly and it looks like caused by mmap() code in > kernel > code; Then, we would want to see if makedumpfile works well by disabling > mmap(),
Thanks for your explanation. Additionally, the option to disable mmap() manually will help my test, so I should introduce the option into upstream. Thanks Atsushi Kumagai > -- > Thanks. > HATAYAMA, Daisuke > > > _______________________________________________ > kexec mailing list > ke...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
