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=-11.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_GIT autolearn=ham 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 D67F9C433C1 for ; Fri, 26 Mar 2021 00:02:51 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6915261A0A for ; Fri, 26 Mar 2021 00:02:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6915261A0A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 52E856B0073; Thu, 25 Mar 2021 20:02:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 504A36B0074; Thu, 25 Mar 2021 20:02:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3CD536B0075; Thu, 25 Mar 2021 20:02:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0077.hostedemail.com [216.40.44.77]) by kanga.kvack.org (Postfix) with ESMTP id 25D036B0073 for ; Thu, 25 Mar 2021 20:02:50 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id E28BD8786 for ; Fri, 26 Mar 2021 00:02:49 +0000 (UTC) X-FDA: 77960074458.03.AA4C16F Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by imf04.hostedemail.com (Postfix) with ESMTP id B2FE43C0 for ; Fri, 26 Mar 2021 00:02:47 +0000 (UTC) IronPort-SDR: v0uFl1zk38XauLymhJT0GZAQATB1JZe+tj75ZkNUy42BXJKrz+FouLQeUS1biu7jNYlH+Fx6tn 8TCcSQKVauwQ== X-IronPort-AV: E=McAfee;i="6000,8403,9934"; a="276171509" X-IronPort-AV: E=Sophos;i="5.81,278,1610438400"; d="scan'208";a="276171509" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Mar 2021 17:02:43 -0700 IronPort-SDR: gLJz0BwHCmgVNDiaqW5MlbUChXZa6AsyEHICSctf/pEvxXIir85Mmm4YXns4B5H9vSKRHWlFju RLAdbzXhES7A== X-IronPort-AV: E=Sophos;i="5.81,278,1610438400"; d="scan'208";a="416265832" Received: from agluck-desk2.sc.intel.com ([10.3.52.146]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Mar 2021 17:02:42 -0700 From: Tony Luck To: Borislav Petkov Cc: Tony Luck , x86@kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andy Lutomirski , Aili Yao , =?UTF-8?q?HORIGUCHI=20NAOYA=28=20=E5=A0=80=E5=8F=A3=E3=80=80=E7=9B=B4=E4=B9=9F=29?= Subject: [RFC 0/4] Fix machine check recovery for copy_from_user Date: Thu, 25 Mar 2021 17:02:31 -0700 Message-Id: <20210326000235.370514-1-tony.luck@intel.com> X-Mailer: git-send-email 2.29.2 MIME-Version: 1.0 X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: B2FE43C0 X-Stat-Signature: wjonha3awdg1s8p3s3e8cbdarfk186ht Received-SPF: none (intel.com>: No applicable sender policy available) receiver=imf04; identity=mailfrom; envelope-from=""; helo=mga05.intel.com; client-ip=192.55.52.43 X-HE-DKIM-Result: none/none X-HE-Tag: 1616716967-5353 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Maybe this is the way forward? I made some poor choices before to treat poison consumption in the kernel when accessing user data (get_user() or copy_from_user()) ... in particular assuming that the right action was sending a SIGBUS to the task as if it had synchronously accessed the poison location. First three patches may need to be combined (or broken up differently) for bisectablilty. But they are presented separately here since they touch separate parts of the problem. Second part is definitley incomplete. But I'd like to check that it is the right approach before expending more brain cells in the maze of nested macros that is lib/iov_iter.c Last part has been posted before. It covers the case where the kernel takes more than one swing at reading poison data before returning to user. Tony Luck (4): x86/mce: Fix copyin code to return -EFAULT on machine check. mce/iter: Check for copyin failure & return error up stack mce/copyin: fix to not SIGBUS when copying from user hits poison x86/mce: Avoid infinite loop for copy from user recovery arch/x86/kernel/cpu/mce/core.c | 63 +++++++++++++++++++++--------- arch/x86/kernel/cpu/mce/severity.c | 2 - arch/x86/lib/copy_user_64.S | 18 +++++---- fs/iomap/buffered-io.c | 8 +++- include/linux/sched.h | 2 +- include/linux/uio.h | 2 +- lib/iov_iter.c | 15 ++++++- 7 files changed, 77 insertions(+), 33 deletions(-) --=20 2.29.2