VERIFY_READ/WRITE in uaccess.h?

VERIFY_READ/WRITE in uaccess.h?

[Richard Weinberger]

Hi!

While cleaning up UML's uaccess code I've noticed that not a single architecture
is using VERIFY_READ/WRITE in access_ok().
One exception is UML, it uses the access type in one check which is in vain anyways.
Also asm-generic/uaccess.h drops the type parameter silently.

Why do we still carry it around?

Is it because we want it for some future architecture which can benefit
from it or just because nobody cared enough to do a tree-wide cleanup?
I fear it is the latter... ;)

Thanks,
//richard

Re: VERIFY_READ/WRITE in uaccess.h?

[H. Peter Anvin]

On 05/10/2015 02:44 AM, Richard Weinberger wrote:
> Hi!
> 
> While cleaning up UML's uaccess code I've noticed that not a single architecture
> is using VERIFY_READ/WRITE in access_ok().
> One exception is UML, it uses the access type in one check which is in vain anyways.
> Also asm-generic/uaccess.h drops the type parameter silently.
> 
> Why do we still carry it around?
> 
> Is it because we want it for some future architecture which can benefit
> from it or just because nobody cared enough to do a tree-wide cleanup?
> I fear it is the latter... ;)
> 

Or, perhaps, nobody noticed?

	-hpa

Re: VERIFY_READ/WRITE in uaccess.h?

[Richard Weinberger]

Am 11.05.2015 um 23:05 schrieb H. Peter Anvin:
> On 05/10/2015 02:44 AM, Richard Weinberger wrote:
>> Hi!
>>
>> While cleaning up UML's uaccess code I've noticed that not a single architecture
>> is using VERIFY_READ/WRITE in access_ok().
>> One exception is UML, it uses the access type in one check which is in vain anyways.
>> Also asm-generic/uaccess.h drops the type parameter silently.
>>
>> Why do we still carry it around?
>>
>> Is it because we want it for some future architecture which can benefit
>> from it or just because nobody cared enough to do a tree-wide cleanup?
>> I fear it is the latter... ;)
>>
> 
> Or, perhaps, nobody noticed?

Also possible.

While we are at it, access_ok() is IMHO a horrible name. Historic?
Today it is used to find out whether an address is in an
architecture defined range and therefore valid.
Maybe valid_address() would be a better name...

Thanks,
//richard

Re: VERIFY_READ/WRITE in uaccess.h?

[Linus Torvalds]

On Mon, May 11, 2015 at 2:05 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 05/10/2015 02:44 AM, Richard Weinberger wrote:
>> Hi!
>>
>> While cleaning up UML's uaccess code I've noticed that not a single architecture
>> is using VERIFY_READ/WRITE in access_ok().
>> One exception is UML, it uses the access type in one check which is in vain anyways.
>> Also asm-generic/uaccess.h drops the type parameter silently.
>>
>> Why do we still carry it around?
>>
>> Is it because we want it for some future architecture which can benefit
>> from it or just because nobody cared enough to do a tree-wide cleanup?
>> I fear it is the latter... ;)
>>
>
> Or, perhaps, nobody noticed?

Not a future architecture. A historical one.

I think the only architecture that needed the VERIFY_READ/WRITE
distinction was the now-dropped i386, where it was used to decide if
we needed to do the manual COW because the 80386 couldn't do COW
correctly in kernel mode.

That one - for the same reasons - also checked the actual accesses,
not just that the range was in user mode. Exactly because it needed to
pre-COW the pages (even if that was then obviously racy in threaded
environments - in practice it worked, and we tried to support the
fundamentally broken i386 hardware protection model for a long time).

                         Linus

Re: VERIFY_READ/WRITE in uaccess.h?

[H. Peter Anvin]

On 05/11/2015 02:42 PM, Linus Torvalds wrote:
> 
> That one - for the same reasons - also checked the actual accesses,
> not just that the range was in user mode. Exactly because it needed to
> pre-COW the pages (even if that was then obviously racy in threaded
> environments - in practice it worked, and we tried to support the
> fundamentally broken i386 hardware protection model for a long time).
> 

It worked in part because we never supported SMP on i386.

	-hpa