lkml.org 
[lkml]   [2021]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v7 05/19] iov_iter: Introduce fault_in_iov_iter_writeable
    On Fri, Aug 27, 2021 at 11:52 AM Al Viro <viro@zeniv.linux.org.uk> wrote:
    >
    > Again, the calling conventions are wrong. Make it success/failure or
    > 0/-EFAULT. And it's inconsistent for iovec and non-iovec cases as it is.

    Al, the 0/-EFAULT thing DOES NOT WORK.

    The whole "success vs failure" model is broken.

    Because "success" for some people is "everything worked".

    And for other people it is "at least _part_ of it worked".

    So no, 0/-EFAULT fundamentally cannot work, because the return needs
    to be able to handle that ternary situation (ie "nothing" vs
    "something" vs "everything").

    This is *literally* the exact same thing that we have for
    copy_to/from_user(). And Andreas' solution (based on my suggestion) is
    the exact same one that we have had for that code since basically day
    #1.

    The whole "0/-EFAULT" is simpler, yes. And it's what
    "{get|put}_user()" uses, yes. And it's more common to a lot of other
    functions that return zero or an error.

    But see above. People *need* that ternary result, and "bytes/pages
    uncopied" is not only the traditional one we use elsewhere in similar
    situations, it's the one that has the easiest error tests for existing
    users (because zero remains "everything worked").

    Andreas originally had that "how many bytes/pages succeeded" return
    value instead, and yes, that's also ternary. But it means that now the
    common "complete success" test ends up being a lot uglier, and the
    semantics of the function changes completely where "0" no longer means
    success, and that messes up much more.

    So I really think you are barking entirely up the wrong tree.

    If there is any inconsistency, maybe we should make _more_ cases use
    that "how many bytes/pages not copied" logic, but in a lot of cases
    you don't actually need the ternary decision value.

    So the inconsistency is EXACTLY the same as the one we have always had
    for get|put_user() vs copy_to|from_user(), and it exists for the EXACT
    same reason.

    IOW, please explain how you'd solve the ternary problem without making
    the code a lot uglier.

    Linus

    \
     
     \ /
      Last update: 2021-08-27 21:06    [W:5.434 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site