On Thu, Apr 30, 2020 at 10:17 AM Linus Torvalds torvalds@linux-foundation.org wrote:
On Thu, Apr 30, 2020 at 9:52 AM Andy Lutomirski luto@kernel.org wrote:
If I'm going to copy from memory that might be bad but is at least a valid pointer, I want a function to do this. If I'm going to copy from memory that might be entirely bogus, that's a different operation. In other words, if I'm writing e.g. filesystem that is touching get_user_pages()'d persistent memory, I don't want to panic if the memory fails, but I do want at least a very loud warning if I follow a wild pointer.
So I think that probe_kernel_copy() is not a valid replacement for memcpy_mcsafe().
Fair enough.
That said, the part I do like about probe_kernel_read/write() is that it does indicate which part we think is possibly the one that needs more care.
Sure, it _might_ be both sides, but honestly, that's likely the much less common case. Kind of like "copy_{to,from}_user()" vs "copy_in_user()".
Yes, the "copy_in_user()" case exists, but it's the odd and unusual case.
I suppose there could be a consistent naming like this:
copy_from_user() copy_to_user()
copy_from_unchecked_kernel_address() [what probe_kernel_read() is] copy_to_unchecked_kernel_address() [what probe_kernel_write() is]
copy_from_fallible() [from a kernel address that can fail to a kernel address that can't fail] copy_to_fallible() [the opposite, but hopefully identical to memcpy() on x86]
copy_from_fallible_to_user() copy_from_user_to_fallible()
These names are fairly verbose and could probably be improved.