[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <52552C9F.2030404@jp.fujitsu.com>
Date: Wed, 09 Oct 2013 19:14:55 +0900
From: HATAYAMA Daisuke <d.hatayama@...fujitsu.com>
To: Alexey Dobriyan <adobriyan@...il.com>
CC: Michael Holzheu <holzheu@...ux.vnet.ibm.com>,
"David S. Miller" <davem@...emloft.net>,
Vivek Goyal <vgoyal@...hat.com>,
Jan Willeke <willeke@...ibm.com>,
Linux Kernel <linux-kernel@...r.kernel.org>,
kexec@...ts.infradead.org
Subject: Re: mmap for /proc/vmcore broken since 3.12-rc1
Hello,
(2013/10/08 21:49), Alexey Dobriyan wrote:
> On Mon, Oct 7, 2013 at 5:42 AM, HATAYAMA Daisuke
> <d.hatayama@...fujitsu.com> wrote:
>
>> +static unsigned long
>> +get_unmapped_area_vmcore(struct file *filp, unsigned long addr,
>> + unsigned long len, unsigned long pgoff,
>> + unsigned long flags)
>> +{
>> +#ifdef CONFIG_MMU
>> + return current->mm->get_unmapped_area(filp, addr, len, pgoff,
>> flags);
>> +#else
>> + return -EIO;
>> +#endif
>> +}
>> +
>> static const struct file_operations proc_vmcore_operations = {
>> .read = read_vmcore,
>> .llseek = default_llseek,
>> .mmap = mmap_vmcore,
>> + .get_unmapped_area = get_unmapped_area_vmcore,
>
> I think current->mm->get_unmapped_area should be used by core proc code.
What do you actually suggest here? You mean moving this code in proc code?
I don't think you suggest so.
> ENOMEM bug looks unrelated though.
>
Next step I'll do is to look into vm_unmapped_region() that looks for
for a region fit to a given mmap request and returns its address.
In particular, I'll focus on when vm_unmapped_region() could return
kernel-space address.
--
Thanks.
HATAYAMA, Daisuke
--
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