[PATCH] Wrong page protection flags on FreeBSD/PPC

[Hal Finkel]

----- Original Message -----
> From: "Hal Finkel" <hfinkel at anl.gov>
> To: "Krzysztof Parzyszek" <kparzysz at codeaurora.org>
> Cc: "LLVM Commits" <llvm-commits at cs.uiuc.edu>
> Sent: Wednesday, February 20, 2013 12:14:04 PM
> Subject: Re: [PATCH] Wrong page protection flags on FreeBSD/PPC
> 
> ----- 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.

I'm not familiar with the call path; would it be feasible to return an error from this function? Regardless, I'm in favor of fixing it this way for now and discussing API changes in a separate thread.

 -Hal

> 
>  -Hal
> 
> > 
> > -Krzysztof
> > 
> > --
> > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> > hosted by The Linux Foundation
> > 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>