On 2011-07-12 08:48, Gilles Chanteperdrix wrote: > 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 <[email protected]> >>>> >>>> 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.
Yes, private mappings can undergo COW. > > 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. That sounds like overkill, and it's potentially racy (mprotect may open a short window where the active PTEs do not allow writes for concurrently running threads). Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Adeos-main mailing list [email protected] https://mail.gna.org/listinfo/adeos-main
