[PATCH] Wrong page protection flags on FreeBSD/PPC

[Hal Finkel]

----- Original Message -----
> From: "Krzysztof Parzyszek" <kparzysz at codeaurora.org>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "Roman Divacky" <rdivacky at freebsd.org>, "LLVM Commits" <llvm-commits at cs.uiuc.edu>
> Sent: Wednesday, February 20, 2013 12:06:31 PM
> Subject: Re: [PATCH] Wrong page protection flags on FreeBSD/PPC
> 
> On 2/20/2013 11:55 AM, Hal Finkel wrote:
> >
> > It is fine by me. I don't know why FreeBSD and Linux differ here,
> > but I suppose this is an empirical matter. Please feel free to
> > commit. Is there a reason that we don't want to remove read
> > permission after the flush?
> 
> I was thinking about it.  I considered temporarily adding PROT_READ
> flag, then flushing the cache, and then removing it.  This would have
> to
> happen inside "Memory::InvalidateInstructionCache", because it is an
> external function.  The problem is that if mprotect was to fail for
> any
> reason, we would be unable to actually invalidate the cache (or to
> remove the PROT_READ flag afterwards), and there is no way to
> indicate
> such a failure to the caller.  If we control the function that
> translates user-level protection flags to OS-specific flags, we could
> ensure that PROT_READ is always present when PROT_EXEC was requested.
> It may not be very elegant, but it should be safe.\

Fair enough.

 -Hal

> 
> -Krzysztof
> 
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> hosted by The Linux Foundation
>