Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp168775pxb; Wed, 27 Oct 2021 00:17:04 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzsT65M9UWf6amN1lY0JXRsViq1c9bOMLI0cdjDMkW8PAMdzTbm/IVcaCUAS/q+k0Iyk8Eu X-Received: by 2002:a05:6a00:1901:b0:44b:e041:f07f with SMTP id y1-20020a056a00190100b0044be041f07fmr30913059pfi.52.1635319024022; Wed, 27 Oct 2021 00:17:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635319024; cv=none; d=google.com; s=arc-20160816; b=cQPMhicAgC7I8Ctyr72ggX2GT2vBSvtXcXCiyVtOr1P4JPJ69DuSfz+6C2XBLBXoDN kFgwCK+yaMbIb/UwPO1ETNrYXjPJG0HbCEiuMdBAGTeNQqsjOoIDyZnFxy+B8r/Tx93k FemqFsPNDJ76TFTMw790b1fWZCEXZo1eE5KpeovDSqwQIMUl+in69zx34jEZp6B+7SFh /Vpao413BG7vPLP/I8lYh8iOpk+NLRM0l3B9QLQ85Lhq108GphGY9VwB3GsHc+ntjkdb cPfQ0GNHHiwR7D3hewwhlvV+tfZhsHdKapXp0+BRiFKiD2Q9vT8UR8mg9v/iGA7Atg+Y jQYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=r5Cx2RnmHPH+SxoKka0sJEz3NkssP3YCqbiSsqzadkQ=; b=H4czAl0BllZ+a6MiXNGzTkyK0s1ckYn//98Vtha5W7je4//nDOWvxqrOgC43B+bKb6 pCnYkFg5IgnNICUZ9PX1qyRnpOu4Bx2CG7ToyT4R2VQtNdkyDYkjCdKYyRwUGlGpYzM1 WQ4qhFtEk+LjDWOaxF/dtYd1Fqj3AxucFmDPZYDx0F+JyAoMuNc5GQaTjtKxpADrvzhr yxQ2ng/j6eW8SDIbL2rLzjU+UYNChDpYEubP7ItEyCc+gi3Cqan6bappzgtFbIlzXp4G 9XKBzrDFs4q38O04XllmF7yaBHQbc13ORms8AdTlBH34k56vO9l+b+uCxqA2yqKlOcFc tvMA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=XWmvXqx6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id pc18si4424567pjb.176.2021.10.27.00.16.51; Wed, 27 Oct 2021 00:17:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=XWmvXqx6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236747AbhJZSwu (ORCPT + 99 others); Tue, 26 Oct 2021 14:52:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59880 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235198AbhJZSwt (ORCPT ); Tue, 26 Oct 2021 14:52:49 -0400 Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CDBF1C061767 for ; Tue, 26 Oct 2021 11:50:24 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id 188so488114ljj.4 for ; Tue, 26 Oct 2021 11:50:24 -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=r5Cx2RnmHPH+SxoKka0sJEz3NkssP3YCqbiSsqzadkQ=; b=XWmvXqx6E/lnwqgDlacsJYsSx9OK8zrlmcuZe075Kg2Q7afYrlM28LUphtMnNWBBss 19rtrgtkK+y60H9M3H213OTzx4KlKQs5vTnOVoJ7FFgOi4799TI0MlAwQR64ujeGGpUF Ec975XRObLADp1do89z7xhEJGw/WNDenswDZ0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=r5Cx2RnmHPH+SxoKka0sJEz3NkssP3YCqbiSsqzadkQ=; b=bB2z0g/4XTVAuXr4RxfumTzkUqOApoJkTQtA2AxRmD1tSn7cn9gkW1EMDk0rfOtHMv tw6+d4fO9wj1fVCYojT7BNH4BmiZiJdkeo56DkKsEKGM7e9/XCIB9eMWPXNxplIw8WUN MpxDBRjrDyn50u4Vj7SD79M7vNNcdYRgWaftsu8q/Fs3aA3ZxWZw2YvZXdRqaC8joBYC toKkHj6x0LNufEgC24IHlWIv9jJ5UE9Ocrj4EQLexj2xTcWvJZwHI5x8Dh594NO5/X9P xr1X16Be7IT/mWKxdynFxpeRkKUxiR+vwSeZ5KmrYxzIVHUYiFcBUT1aBvMBohMpR7vT CAxw== X-Gm-Message-State: AOAM533XCscjoNymr0c5mi0iUe/jIkVfHIVkZQJnxewRtAfLRY01jd2r Y7cZqgYoiUZM9HI5/l26FkaWSNtednytatOE X-Received: by 2002:a05:651c:889:: with SMTP id d9mr28706877ljq.198.1635274222426; Tue, 26 Oct 2021 11:50:22 -0700 (PDT) Received: from mail-lj1-f179.google.com (mail-lj1-f179.google.com. [209.85.208.179]) by smtp.gmail.com with ESMTPSA id m6sm1057446lfu.82.2021.10.26.11.50.21 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 Oct 2021 11:50:21 -0700 (PDT) Received: by mail-lj1-f179.google.com with SMTP id o11so427574ljg.10 for ; Tue, 26 Oct 2021 11:50:21 -0700 (PDT) X-Received: by 2002:a2e:9e13:: with SMTP id e19mr4519488ljk.494.1635274221013; Tue, 26 Oct 2021 11:50:21 -0700 (PDT) MIME-Version: 1.0 References: <20211019134204.3382645-1-agruenba@redhat.com> In-Reply-To: From: Linus Torvalds Date: Tue, 26 Oct 2021 11:50:04 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v8 00/17] gfs2: Fix mmap + page fault deadlocks To: Catalin Marinas Cc: Andreas Gruenbacher , Paul Mackerras , Alexander Viro , Christoph Hellwig , "Darrick J. Wong" , Jan Kara , Matthew Wilcox , cluster-devel , linux-fsdevel , Linux Kernel Mailing List , ocfs2-devel@oss.oracle.com, kvm-ppc@vger.kernel.org, linux-btrfs Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 26, 2021 at 11:24 AM Catalin Marinas wrote: > > While more intrusive, I'd rather change copy_page_from_iter_atomic() > etc. to take a pointer where to write back an error code. I absolutely hate this model. The thing is, going down that rat-hole, you'll find that you'll need to add it to *all* the "copy_to/from_user()" cases, which isn't acceptable. So then you start doing some duplicate versions with different calling conventions, just because of things like this. So no, I really don't want a "pass down a reference to an extra error code" kind of horror. That said, the fact that these sub-page faults are always non-recoverable might be a hint to a solution to the problem: maybe we could extend the existing return code with actual negative error numbers. Because for _most_ cases of "copy_to/from_user()" and friends by far, the only thing we look for is "zero for success". We could extend the "number of bytes _not_ copied" semantics to say "negative means fatal", and because there are fairly few places that actually look at non-zero values, we could have a coccinelle script that actually marks those places. End result: no change in calling conventions, no change to most users, and the (relatively few) cases where we look at the "what about partial results", we just add a .. existing code .. ret = copy_from_user(..); + if (ret < 0) + break; // or whatever "fatal error" situation .. existing code .. kind of thing that just stops the re-try. (The coccinelle script couldn't actually do that, but it could add some comment marker or something so that it's easy to find and then manually fix up the places it finds). Linus