> On Apr 30, 2020, at 5:40 PM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Thu, Apr 30, 2020 at 5:23 PM Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: >> >>> 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 > > Maybe I didn't explain. > > "user" already implies faulting. We agree. > > And since we by definition cannot know what the user has mapped into > user space, *every* normal copy_to_user() has to be able to handle > whatever faults that throws at us. > > The reason I dislike "copy_to_user_fallible()" is that the user side > already has that 'fallible". > > If it's the _source_ being "fallible" (it really needs a better name - > I will not call it just "f") then it should be "copy_f_to_user()". > > That would be ok. > > So "copy_f_to_user()" makes sense. But "copy_to_user_f()" does not. > That puts the "f" on the "user", which we already know can fault. > > See what I want in the name? I want the name to say which side can > cause problems! We are in violent agreement. I’m moderately confident that I never suggested copy_from_user_f(). We appear to agree completely.
