On 07/08/2011 02:15 PM, Jan Kiszka wrote:
> On 2011-07-08 13:55, Gilles Chanteperdrix wrote:
>> On 07/07/2011 09:14 PM, Jan Kiszka wrote:
>>> From: Jan Kiszka <jan.kis...@siemens.com>
>>>
>>> Page protection changes issued via mprotect, e.g. to enable executable
>>> stacks, cause spurious minor faults as they remove the write permission
>>> from the modified range again. Avoid this by faking shared pages so that
>>> vm_get_page_prot returns the desired page permissions.
>>
>> This looks dangerous to me. Have you checked that write to private heaps
>> will not end up corrupting shared data?
>
> Can't follow this yet.
>
> If you check the comment on protection_map in mm/mmap.c, the difference
> between private and shared is in real write vs. COW-able write. That's
> what my patch is exploiting to get the proper arch-dependent page
> protection bits.
>
> Are you aware of side effects or do you know a better way to inject
> write permissions into the protection flags?
I would tend to think that shared and private mappings do not react the
same way when we write to them.
In order to avoid the fault on first access, I would trigger a fault for
each page of the mapping, the way we do it in __rthal_arm_fault_range
(in ksrc/arch/arm/hal.c), but in the I-pipe kernel.
--
Gilles.
_______________________________________________
Adeos-main mailing list
Adeos-main@gna.org
https://mail.gna.org/listinfo/adeos-main
