> On Apr 30, 2020, at 5:10 PM, Linus Torvalds <torva...@linux-foundation.org> > wrote: > > On Thu, Apr 30, 2020 at 4:52 PM Dan Williams <dan.j.willi...@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", because >> 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 "can > fault". > > 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" > part. 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 want copy_unreliable_to_user(). 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. _______________________________________________ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
