On 06/03/2016 12:35 PM, Michael Kerrisk (man-pages) wrote:
>> > So, I have a suggestion. How about tightening the constraint here, so
>> > that only one of these flags is allowed for now. (EINVAL if both
>> > are specified.) That constraint could always be relaxed later , if
>> > desired, and adding it now may allow some wriggle room later in terms
>> > of modifying the API or allowing for different architectural choices.
> Another reason to give an error for this case: if the user does
> this, they were probably confused. An error let's them know
> they did something nonsensical...
The real benefit of doing it this way is that it allows applications to
add or remove write or access permissions independently of what the
previous permissions were.
For instance, I would expect code to be structured with pairs of
enable/disable operations, like:
int read_something(void)
{
int ret;
pkey_access_enable(pkey);
ret = *some_pkey_memory; // Is this readable or writable?
pkey_access_disable(pkey);
return ret;
}
If we do what you suggest, we need to have the program keep extra state
about whether the 'some_pkey_memory' should be write-disabled once
access-enabled. If we leave it as-is, we get the benefit of the
PKRU[].WD disable bit to do this for us.
In other words, if an application does a pkey_write_disable(), the app
can reasonably expect that *no* writes will be allowed until the app
does a pkey_write_enable().
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
