lkml.org 
[lkml]   [2013]   [Nov]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] procfs: also fix proc_reg_get_unmapped_area() for !MMU case
>>> On 25.11.13 at 23:13, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Mon, 25 Nov 2013 16:22:31 +0000 "Jan Beulich" <JBeulich@suse.com> wrote:
>
>> Commit fad1a86e ("procfs: call default get_unmapped_area on MMU-present
>> architectures"), as its title says, took care of only the MMU case,
>> leaving the !MMU side still in the regressed state (returning -EIO in
>> all cases where pde->proc_fops->get_unmapped_area is NULL).
>
> The changelog is rather mystifying unless the reader goes off and finds
> the fad1a86e changelog, so let's do that for them by adding this:
>
> From the fad1a86e changelog:
>
> : Commit c4fe24485729 ("sparc: fix PCI device proc file mmap(2)") added
> : proc_reg_get_unmapped_area in proc_reg_file_ops and
> : proc_reg_file_ops_no_compat, by which now mmap always returns EIO if
> : get_unmapped_area method is not defined for the target procfs file, which
> : causes regression of mmap on /proc/vmcore.
> :
> : To address this issue, like get_unmapped_area(), call default
> : current->mm->get_unmapped_area on MMU-present architectures if
> : pde->proc_fops->get_unmapped_area, i.e. the one in actual file operation
> : in the procfs file, is not defined.
>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> Cc: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
>> Cc: Alexey Dobriyan <adobriyan@gmail.com>
>> Cc: David S. Miller <davem@davemloft.net>
>
> I tagged this with
>
> Cc: <stable@vger.kernel.org> [3.12.x]
>
> OK?

Sure. I also see you didn't like the way I coded it, and put a
code restructuring patch on top...

Jan



\
 
 \ /
  Last update: 2013-11-26 08:41    [W:0.051 / U:0.216 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site