Le 18/02/2022 à 02:50, Al Viro a écrit :

On Thu, Feb 17, 2022 at 07:20:11AM +0000, Christophe Leroy wrote:

quoted

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