Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()

[Andy Lutomirski]

> On Sep 28, 2020, at 1:20 PM, Jarkko Sakkinen <jarkko.sakkinen@xxxxxxxxxxxxxxx> wrote:
> 
> On Mon, Sep 28, 2020 at 12:45:27PM -0700, Dave Hansen wrote:
>>> On 9/28/20 12:32 PM, Jarkko Sakkinen wrote:
>>> My problem is that I fully agree what you say in your description but
>>> disagree on that EMODPE should not be mentioned.
>> 
>> I'll just be very clear: I'm not willing to ack any patch with a
>> changelog that has more than a passing mention of EMODPE.
>> 
>> Do what you think is best, but if sticking to your guns may deplete the
>> pool of folks willing to ack your patch.
> 
> I do see it mentioned in other responses too in this thread, and not
> just mine.
> 
> And here is even a request to get it to the changelog:
> 
> https://lore.kernel.org/linux-sgx/1B23E216-0229-4BDD-8B09-807256A54AF5@xxxxxxxxxxxxxx/
> 
> I'm absolutely fine not to mention EMODPE but after re-reading the
> thread, it is not like there is one voice on it. I don't really
> care all that much whether it is mentioned or not but there should
> be some reasonable logic behind the decision.

I don’t personally care that much about EMODPE but, you could probably get the point across with something like:

SGX’s EPCM permission bits do not obviate the need to enforce these rules in the PTEs because enclaves can freely modify the EPCM permissions using EMODPE.

IOW, EMODPE is not really special here; rather, EMODPE’s existence demonstrates that EADD / EEXTEND are not special.