Re: [PATCH] procfs: also fix proc_reg_get_unmapped_area() for!MMU case

[Jan Beulich]

>>> On 25.11.13 at 23:13, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Mon, 25 Nov 2013 16:22:31 +0000 "Jan Beulich" <JBeulich@xxxxxxxx> 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@xxxxxxxx>
>> Cc: HATAYAMA Daisuke <d.hatayama@xxxxxxxxxxxxxx>
>> Cc: Alexey Dobriyan <adobriyan@xxxxxxxxx>
>> Cc: David S. Miller <davem@xxxxxxxxxxxxx> 
> 
> I tagged this with
> 
> 	Cc: <stable@xxxxxxxxxxxxxxx>	[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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/