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

Christophe Leroy
2022-02-18T10:01:53Z

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