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
