Re: [PATCH v2 00/18] clean up asm/uaccess.h, kill set_fs for good

[Christophe Leroy]

Le 18/02/2022 à 02:50, Al Viro a écrit :
> On Thu, Feb 17, 2022 at 07:20:11AM +0000, Christophe Leroy wrote:
> 
>> And we have also
>> user_access_begin()/user_read_access_begin()/user_write_access_begin()
>> which call access_ok() then do the real work. Could be made generic with
>> call to some arch specific __user_access_begin() and friends after the
>> access_ok() and eventually the might_fault().
> 
> Not a good idea, considering the fact that we do not want to invite
> uses of "faster" variants...

I'm not sure I understand your concern.

Today in powerpc we have:

	static __must_check inline bool
	user_read_access_begin(const void __user *ptr, size_t len)
	{
		if (unlikely(!access_ok(ptr, len)))
			return false;

		might_fault();

		allow_read_from_user(ptr, len);
		return true;
	}

We could instead have a generic

	static __must_check inline bool
	user_read_access_begin(const void __user *ptr, size_t len)
	{
		if (unlikely(!access_ok(ptr, len)))
			return false;

		might_fault();

		return arch_user_read_access_begin(ptr, len);
	}

And then a powerpc specific

	static __must_check __always_inline bool
	arch_user_read_access_begin(const void __user *ptr, size_t len)
	{
		allow_read_from_user(ptr, len);
		return true;
	}
	#define arch_user_read_access_begin arch_user_read_access_begin

And a generic fallback for arch_user_read_access_begin() that does 
nothing at all.

Do you mean that in that case people might be tempted to use 
arch_user_read_access_begin() instead of using user_read_access_begin() ?

If that's the case isn't it something we could verify via checkpatch.pl ?

Today it seems to be problematic that functions in asm/uaccess.h use 
access_ok(). Such an approach would allow to get rid of access_ok() use 
in architecture's uaccess.h

Christophe