Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2219518pxb; Mon, 8 Mar 2021 18:27:13 -0800 (PST) X-Google-Smtp-Source: ABdhPJzVDwkQ0ldtuPnWmLwDBbyqsJifulzfEaR3TylSQ4KQV8taFi/mET6Ic6MSLsNfXqUApkyE X-Received: by 2002:a17:906:150f:: with SMTP id b15mr9026656ejd.363.1615256833151; Mon, 08 Mar 2021 18:27:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615256833; cv=none; d=google.com; s=arc-20160816; b=QfoiQtLjCsf/Cd54AekOmSepybpyZo11BMW2PxCZ/DnNLj/9BCEpmI0Vw1E4OV16AY 7IEKxxZwopPSrU9SPGuAJPq0fckNWVIPrn/At/0DZ67E3PoiTFOiWmEHm9D+x9Hz/xdU xeevt13xWE60Vyv2y+pbio6xGbFjGk0QAcgbT83thY7zaGesqVnAUN7eWOKeWLlPXGnU ICABEuNn/IUb9INVWC17LBTYygKV2IUPhWEFJeUIV2kW6GH3SHEAC/mzH3lTocud0xHX x18BD4yQIxhwum3Ab0BDdppSPyYjNcG1ReHorzMH/pt8PcGaF1wAs69FXPkF06SM+Ik3 WOpQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=PQNukI0kf8YSF5wDu/Lx5GyQFUYGvH5JwrKWDJR6NiE=; b=lyVAGg0USv/VYez3l1bKJT/DOMGwGGXEnu56QcycfgUPGexpvQVKW6loew32+3YEMF Vmvqob6xUGTmQMcTIAtVQDX7S+DR6mx32X/0J9v5KzGcOvNOD+Lt+N3JXOwqaN0SAA1y sKrYQd99EPcqDEULSKvuSDhjrEPxVytgoD1bLgSEMb4REmcuKurtDsqb9M+1eP27JRH2 TTLPT3EM+kscWEHK+Nyz6WKQP+Mun9INnK4xCHC1KBbb9cNwIZe+tVW+RFmn3EsD+i4u 8wNhc7mFw3kMvtEhstknjQIERnPbdqeamkTjUwDrGCTZA74F6AHIkOSuS2E+j6yDtIDx srhQ== 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 n2si8163940ejy.130.2021.03.08.18.26.50; Mon, 08 Mar 2021 18:27:13 -0800 (PST) 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 S231147AbhCICZj (ORCPT + 99 others); Mon, 8 Mar 2021 21:25:39 -0500 Received: from mail.kingsoft.com ([114.255.44.145]:13960 "EHLO mail.kingsoft.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230391AbhCICZH (ORCPT ); Mon, 8 Mar 2021 21:25:07 -0500 X-AuditID: 0a580157-47bff70000021a79-0a-6046d5e39743 Received: from mail.kingsoft.com (localhost [10.88.1.32]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail.kingsoft.com (SMG-1-NODE-87) with SMTP id 45.13.06777.3E5D6406; Tue, 9 Mar 2021 09:56:51 +0800 (HKT) Received: from alex-virtual-machine (172.16.253.254) by KSBJMAIL2.kingsoft.cn (10.88.1.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Tue, 9 Mar 2021 10:25:03 +0800 Date: Tue, 9 Mar 2021 10:25:02 +0800 From: Aili Yao To: "Luck, Tony" CC: Andy Lutomirski , Andy Lutomirski , HORIGUCHI NAOYA , Dave Hansen , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , X86 ML , "yangfeng1@kingsoft.com" , Linux-MM , LKML , Subject: Re: [PATCH v3] x86/fault: Send a SIGBUS to user process always for hwpoison page access. Message-ID: <20210309102502.27af8da9@alex-virtual-machine> In-Reply-To: <20210309101452.281af49d@alex-virtual-machine> References: <20210308174912.4ac9029a@alex-virtual-machine> <8F3F763F-59CC-4E25-B4DE-89CD0632F754@amacapital.net> <4fc1b4e8f1fb4c8c81f280db09178797@intel.com> <20210309101452.281af49d@alex-virtual-machine> Organization: kingsoft X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [172.16.253.254] X-ClientProxiedBy: KSBJMAIL1.kingsoft.cn (10.88.1.31) To KSBJMAIL2.kingsoft.cn (10.88.1.32) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIIsWRmVeSWpSXmKPExsXCFcGooPv4qluCwZwLPBafN/xjs3ixoZ3R YtpGcYvLu+awWdxb85/VYvXaBlaL87vWslpcOrCAyeJi4wFGi+O9B5gsNm+aymzx5sI9Fosf Gx6zOvB6fG/tY/G4/+Yvi8fmFVoei/e8ZPLYtKqTzWPTp0nsHu/OnWP3mHcy0OPF1Y0sHu/3 XWXz+LxJzuNEyxfWAJ4oLpuU1JzMstQifbsErozOl1IFszkrpkz/wNLA+I+ti5GTQ0LAROLF vyMsXYxcHEIC05kkTh+6zAThvGSUePLxCTNIFYuAisSzTZtZQGw2AVWJXfdmsYLYIgJqEpcW P2AGaWAWaGeRaLv5ih0kISyQLHFm0gNGEJtXwEpi65UPYM2cAtYS0y/cZYfYcIlR4tecX2CT +AXEJHqv/GeCuMleom3LIqhmQYmTM5+ANTML6EicWHWMGcKWl9j+dg6YLSSgKHF4yS92iF4l iSPdM6B+i5VYNu8V6wRG4VlIRs1CMmoWklELGJlXMbIU56YbbmKExGL4DsZ5TR/1DjEycTAe YpTgYFYS4fU77pYgxJuSWFmVWpQfX1Sak1p8iFGag0VJnLfluGuCkEB6YklqdmpqQWoRTJaJ g1OqgSn3RXFEIOt+Pu3iXIaTbrm9IS7xT+czvJQ0tY3TdbMoFvt/y4vR9rukao9AjNC51uqs PR8nm1+rjZr/MTS5bt+THr0Pl5mL/nImRP1ab1dzU7PhT4ZQsdeC1PJPukXhk6Runt8W7yeS waln8n/H7n9eO6e8L/iVqMdYuPl2Wu+E4qd8KyZNPy4Tk8rPvkTracnBI88Ptf4Vnn9LcblY R6Pt48u3etO2q92aOoftjPD/Q7duKHH2Jt3jvXLc34y9bGmQaO9e28On7u00+z6j9tsO1b+X Lfbw2PtKmNz7pn13ZY75TFbzZ0Hz9mewNPgcbtsVFrG37WO3/Dm2O+nZB5bM8OKzy4pztD97 zLh5jxJLcUaioRZzUXEiAKAz7UA0AwAA Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 9 Mar 2021 10:14:52 +0800 Aili Yao wrote: > On Mon, 8 Mar 2021 18:31:07 +0000 > "Luck, Tony" wrote: > > > > Can you point me at that SIGBUS code in a current kernel? > > > > It is in kill_me_maybe(). mce_vaddr is setup when we disassemble whatever get_user() > > or copy from user variant was in use in the kernel when the poison memory was consumed. > > > > if (p->mce_vaddr != (void __user *)-1l) { > > force_sig_mceerr(BUS_MCEERR_AR, p->mce_vaddr, PAGE_SHIFT); > > > > Would it be any better if we used the BUS_MCEERR_AO code that goes into siginfo? > > > > That would make it match up better with what happens when poison is found > > asynchronously by the patrol scrubber. I.e. the semantics are: > > > > AR: You just touched poison at this address and need to do something about that. > > AO: Just letting you know that you have some poison at the address in siginfo. > > > > -Tony > > Is the kill action for this scenario in memory_failure()? Does the current logic kill the process twice for this scenario ? I am confused. -- Thanks! Aili Yao