On Apr 30, 2020, at 5:10 PM, Linus Torvalds
On Thu, Apr 30, 2020 at 4:52 PM Dan Williams <dan.j.williams(a)intel.com> wrote:
> You had me until here. Up to this point I was grokking that Andy's
> "_fallible" suggestion does help explain better than "_safe",
> the copy is doing extra safety checks. copy_to_user() and
> copy_to_user_fallible() mean *something* where copy_to_user_safe()
> does not.
It's a horrible word, btw. The word doesn't actually mean what Andy
means it to mean. "fallible" means "can make mistakes", not
So "fallible" is a horrible name.
What I was trying to get at was not “can fault” but “can malfunction”. Maybe
“unreliable”? Better words welcome.
But anyway, I don't hate something like "copy_to_user_fallible()"
conceptually. The naming needs to be fixed, in that "user" can always
take a fault, so it's the _source_ that can fault, not the "user"
I don’t like this. “user” already implied that basically anything can be wrong with the
memory — it can be unmapped entirely, it can have the wrong permissions, it can have the
wrong protection key, it can have an ECC error, etc. If the operation you want is “copy
from unreliable kernel memory (but with a definitely valid pointer) to user memory”, you
Now maybe copy_to_user() should *always* work this way, but I’m not convinced. Certainly
put_user() shouldn’t — the result wouldn’t even be well defined. And I’m unconvinced that
it makes much sense for the majority of copy_to_user() callers that are also directly
accessing the source structure.
I also tend to think that the probe_kernel stuff should just stay separate. Those are
really for two totally separate types of use: either the kernel is trying its best to
print an errr message without exploding worse, or it’s involved in eBPF or trading hacks
in which address is arbitrary and essentially untrusted.