From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1BCC6C432BE for ; Fri, 27 Aug 2021 19:05:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0591660E77 for ; Fri, 27 Aug 2021 19:05:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231301AbhH0TGo (ORCPT ); Fri, 27 Aug 2021 15:06:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56612 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231197AbhH0TGn (ORCPT ); Fri, 27 Aug 2021 15:06:43 -0400 Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BD27CC0613CF for ; Fri, 27 Aug 2021 12:05:53 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id j4so16367101lfg.9 for ; Fri, 27 Aug 2021 12:05:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Xurqpx2HBsUzvPtF9beAd23C15iGKZUtGtKLy9/65Yo=; b=ZCnYGG6oW+yh9/k4bIpx+5YJVuekh5B3BxAXApXeWgjP1VAyaSzCumlVz49LYpRpSt E7SrDcY9aS1dWjIAtv6pOr5SC4ltNzuJ7d7SIZ4uEgXFlv0fGe4/eQXFko1gO9F/7t9W 74SaW+5xX2+Nhbgohi4k/EwOND3nF7mQg6AyE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Xurqpx2HBsUzvPtF9beAd23C15iGKZUtGtKLy9/65Yo=; b=nrQDiK4XecRvB2JfXoN5XurwKNAIp+Uufafxrh1f7tMF7qkIfa6DgAkpOOWi9tmiho 0EMV3vFFP2HKhIUqHM/Yg+O8MyexwrhVqTOkMwX0Ljs2eC7u5ltF3L5nHKFH9inuG0wo UdxjIIleaNF0PfCxXUZqT4GNVFbR4MHfDWrvfVElQpx+F/XOzXD9lIn61OKF6J/iqbzP HwkVZgJHQf0GtTjCZ8FzfM1oqba6XxAoB9COPrs4S7OiEO9XTW9qSi2Zbldgw6j1zylQ MhbgaBcC5+Tc4qQOh0jK9wxUK0Jq+ngFvwyoMTdf9YcYlLWMUmblMKKPqTOZKSg+Swci 5dxw== X-Gm-Message-State: AOAM5319DU9mUmO0C+Uj9dRicKpMMh3LLMfY/UmaS4ZFzFwvuQ5b1WMu 3k2lF3vRnFBynO2NVInLe1/TgPecjipOqM9h X-Google-Smtp-Source: ABdhPJz3wtvfwaa6LwX14sQdHe/QGDW2MvsvAjJiPSjOxcxySmLGgP2PeSDHXqEVB57MsMyVD1IYfg== X-Received: by 2002:a05:6512:3f15:: with SMTP id y21mr7938143lfa.631.1630091151490; Fri, 27 Aug 2021 12:05:51 -0700 (PDT) Received: from mail-lf1-f52.google.com (mail-lf1-f52.google.com. [209.85.167.52]) by smtp.gmail.com with ESMTPSA id t13sm107553lff.46.2021.08.27.12.05.49 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 27 Aug 2021 12:05:49 -0700 (PDT) Received: by mail-lf1-f52.google.com with SMTP id m28so16381938lfj.6 for ; Fri, 27 Aug 2021 12:05:49 -0700 (PDT) X-Received: by 2002:a05:6512:104b:: with SMTP id c11mr7660072lfb.201.1630091149264; Fri, 27 Aug 2021 12:05:49 -0700 (PDT) MIME-Version: 1.0 References: <20210827164926.1726765-1-agruenba@redhat.com> <20210827164926.1726765-6-agruenba@redhat.com> In-Reply-To: From: Linus Torvalds Date: Fri, 27 Aug 2021 12:05:32 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v7 05/19] iov_iter: Introduce fault_in_iov_iter_writeable To: Al Viro Cc: Andreas Gruenbacher , Christoph Hellwig , "Darrick J. Wong" , Jan Kara , Matthew Wilcox , cluster-devel , linux-fsdevel , Linux Kernel Mailing List , ocfs2-devel@oss.oracle.com Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 27, 2021 at 11:52 AM Al Viro 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