[PATCH] Wrong page protection flags on FreeBSD/PPC

Krzysztof Parzyszek kparzysz at codeaurora.org
Wed Feb 20 10:06:31 PST 2013


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.

-Krzysztof

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



More information about the llvm-commits mailing list