On Fri, Jul 9, 2021 at 12:26 PM Michael Schmitz <schmitzmic@xxxxxxxxx> wrote:
WARNING: CPU: 0 PID: 854 at ./arch/m68k/include/asm/uaccess.h:303
vt_do_kdsk_ioctl+0x38/0x28a
It's apparently the
if (copy_from_user(&kbe, user_kbe, sizeof(struct kbentry)))
which is 4 bytes in size.
Honestly, it could be done with a get_user(), but it could also just
be ignored. We're not talking performance-sensitive code here.
x86 got rid of the constant-sized user copy games not because they
don't exist, but because they just weren't worth the pain.
If somebody really wants to do it, then I suspect it would be better
to special-case the 1/2/4/8 byte case in generic code, than have
architectures special-case the odd sizes.
But it really shouldn't matter.
On x86, we found that
(a) inlining get_user() was bad, because it just caused lots of
duplicated code for the range checks.
(b) turning copy_to_user() into get_user() didn't really matter and
caused tons of duplicated code
(c) the (few) places that cared about performance should use neither,
and should use "uaccess_begin() + unsafe_get_user() + uaccess_end()"
because the reason they mattered was that they ended up doing multiple
accesses and the overhead was elsewhere.
Of course, on x86, the big reason for (c) is that the biggest cost
often ends up being the "enable/disable user space accesses" overhead,
which is about security and a feature that m68k doesn't have.
So the trace-offs are certainly a bit different on x86, but on the
whole I suspect the lessons from x86 are not wrong.
Linus
