[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130715142059.GA23772@redhat.com>
Date: Mon, 15 Jul 2013 10:20:59 -0400
From: Vivek Goyal <vgoyal@...hat.com>
To: HATAYAMA Daisuke <d.hatayama@...fujitsu.com>
Cc: Michael Holzheu <holzheu@...ux.vnet.ibm.com>,
Martin Schwidefsky <schwidefsky@...ibm.com>,
kexec@...ts.infradead.org,
Heiko Carstens <heiko.carstens@...ibm.com>,
Jan Willeke <willeke@...ibm.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 3/5] vmcore: Introduce remap_oldmem_pfn_range()
On Fri, Jul 12, 2013 at 08:05:31PM +0900, HATAYAMA Daisuke wrote:
[..]
> How about
>
> static int mmap_vmcore_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
> {
> ...
> char *buf;
> int rc;
>
> #ifndef CONFIG_S390
> return VM_FAULT_SIGBUS;
> #endif
> page = find_or_create_page(mapping, index, GFP_KERNEL);
>
> Considering again, I don't think WARN_ONCE() is good now. The fact that fault occurs on
> mmap() region indicates some kind of buggy situation occurs on the process. The process
> should be killed as soon as possible. If user still wants to get crash dump, he should
> try again in another process.
I don't understand that. Process should be killed only if there was no
mapping created for the region process is trying to access.
If there is a mapping but we are trying to fault in the actual contents,
then it is not a problem of process. Process is accessing a region of
memory which it is supposed to access.
Potential problem here is that remap_pfn_range() did not map everything
it was expected to so we have to resort on page fault handler to read
that in. So it is more of a kernel issue and not process issue and for
that WARN_ONCE() sounds better?
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists