Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp2450386pxb; Sat, 28 Aug 2021 15:21:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxvvgqAyBhklqEsKIEdVI/U+bHexHw/Gf8hyDYF8u421pkvYawBJd+4fO2uE/9OO+MaOY2j X-Received: by 2002:a50:fb08:: with SMTP id d8mr10596943edq.160.1630189262756; Sat, 28 Aug 2021 15:21:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1630189262; cv=none; d=google.com; s=arc-20160816; b=Lm6V1KJnDh5dDgIOpS45pExevGJm9WdQfMMyuS6gB1tpitPmOnYeEjowq/omzH0wcr YZ2KFrcKqmlhy/iTFvVa21qc90v4QsLdrk6oC831/yNx1+ECgzBxbxg8H4zvK0p+h4aA 0mugSW7gIYg4lw/rZlttczk/fl2G0SEpN9d3oD3qQcuIo6o3GN1bzzLMItituDm8xu0u U+Gs2sZ3dV19tK9Mzhv0FeZ5IwRf5s/OjZGBerK9gqoX0jHYQ0YnGtJOXdEu0v2ABHFU T5mzyIuv23I3sUh9Shh1kN+RRpBMWpf7sIrpYBx5obeDw1/LszVXrxN3GgzFOUqRUf9P fRgA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=sywAi1lB2FzuRh3GiqI0AH+BNPeio4QBUgRPIfszajE=; b=UKVlWLTSNnzFtWaxE8NAZ7wxpolsePWqJjBrXt1fU0A2sWw6VMql6s82lfT1TC59+7 brFq+BLIe9Ps4MR0BNI5N95Rzj/Zj/i7eTKutti88AqiigyAt0W3qAG7/gloWO0fBtUz eG2ApowrN0DiCa7Armdd12lOflSjRFPBtl3dX/XGbHCJ3sZk8IPqdXrELKhfwC/eSt/Y tKMnLsijxasQn2+MD15O4QV4kj4f1HW0PDZhwUc/ns+3ZeK+OBEZr+L0w5KDjT5yjVJ5 52onVzI0w8SSJyki3PWbzMVgxJbwA1DhibT6aeK7UuTlWEajSQQLdWzVoTFtkQ+MqX/i YKdg== ARC-Authentication-Results: i=1; mx.google.com; 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 ho39si10111371ejc.235.2021.08.28.15.20.37; Sat, 28 Aug 2021 15:21:02 -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; 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 S232561AbhH1WUH (ORCPT + 99 others); Sat, 28 Aug 2021 18:20:07 -0400 Received: from zeniv-ca.linux.org.uk ([142.44.231.140]:35980 "EHLO zeniv-ca.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230253AbhH1WUG (ORCPT ); Sat, 28 Aug 2021 18:20:06 -0400 Received: from viro by zeniv-ca.linux.org.uk with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mK6fI-00Gu1S-6O; Sat, 28 Aug 2021 22:19:04 +0000 Date: Sat, 28 Aug 2021 22:19:04 +0000 From: Al Viro To: Thomas Gleixner Cc: "Luck, Tony" , Linus Torvalds , Andreas Gruenbacher , Christoph Hellwig , "Darrick J. Wong" , Jan Kara , Matthew Wilcox , cluster-devel , linux-fsdevel , Linux Kernel Mailing List , ocfs2-devel@oss.oracle.com, Borislav Petkov , x86@kernel.org Subject: Re: [PATCH v7 05/19] iov_iter: Introduce fault_in_iov_iter_writeable Message-ID: References: <20210827232246.GA1668365@agluck-desk2.amr.corp.intel.com> <87r1edgs2w.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Al Viro Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Aug 28, 2021 at 10:11:36PM +0000, Al Viro wrote: > On Sat, Aug 28, 2021 at 10:04:41PM +0000, Al Viro wrote: > > On Sat, Aug 28, 2021 at 11:47:03PM +0200, Thomas Gleixner wrote: > > > > > /* Try to handle #PF, but anything else is fatal. */ > > > if (ret != -EFAULT) > > > return -EINVAL; > > > > > which all end up in user_insn(). user_insn() returns 0 or the negated > > > trap number, which results in -EFAULT for #PF, but for #MC the negated > > > trap number is -18 i.e. != -EFAULT. IOW, there is no endless loop. > > > > > > This used to be a problem before commit: > > > > > > aee8c67a4faa ("x86/fpu: Return proper error codes from user access functions") > > > > > > and as the changelog says the initial reason for this was #GP going into > > > the fault path, but I'm pretty sure that I also discussed the #MC angle with > > > Borislav back then. Should have added some more comments there > > > obviously. > > > > ... or at least have that check spelled > > > > if (ret != -X86_TRAP_PF) > > return -EINVAL; > > > > Unless I'm misreading your explanation, that is... > > BTW, is #MC triggered on stored to a poisoned cacheline? Existence of CLZERO > would seem to argue against that... How about taking __clear_user() out of copy_fpregs_to_sigframe() and replacing the call of fault_in_pages_writeable() with if (!clear_user(buf_fx, fpu_user_xstate_size)) goto retry; return -EFAULT; in the caller?