On Sun, Oct 6, 2019 at 6:24 PM Al Viro <v...@zeniv.linux.org.uk> wrote:
>
> Ugh... I wonder if it would be better to lift STAC/CLAC out of
> raw_copy_to_user(), rather than trying to reinvent its guts
> in readdir.c...
Yeah, I suspect that's the best option.
Do something like
- lift STAC/CLAC out of raw_copy_to_user
- rename it to unsafe_copy_to_user
- create a new raw_copy_to_user that is just unsafe_copy_to_user()
with the STAC/CLAC around it.
and the end result would actually be cleanert than what we have now
(which duplicates that STAC/CLAC for each size case etc).
And then for the "architecture doesn't have user_access_begin/end()"
fallback case, we just do
#define unsafe_copy_to_user raw_copy_to_user
and the only slight painpoint is that we need to deal with that
copy_user_generic() case too.
We'd have to mark it uaccess_safe in objtool (but we already have that
__memcpy_mcsafe and csum_partial_copy_generic, os it all makes sense),
and we'd have to make all the other copy_user_generic() cases then do
the CLAC/STAC dance too or something.
ANYWAY. As mentioned, I'm not actually all that worried about this all.
I could easily also just see the filldir() copy do an extra
#ifndef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
if (len && (1 & (uint_ptr_t)dst)) .. copy byte ..
if (len > 1 && (2 & (uint_ptr_t)dst)) .. copy word ..
if (len > 3 && (4 & (uint_ptr_t)dst) && sizeof(unsigned long) > 4)
.. copy dword ..
#endif
at the start to align the destination.
The filldir code is actually somewhat unusual in that it deals with
pretty small strings on average, so just doing this might be more
efficient anyway.
So that doesn't worry me. Multiple ways to solve that part.
The "uhhuh, unaligned accesses cause more than performance problems" -
that's what worries me.
Linus
