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=-4.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,HK_RANDOM_FROM,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_2 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 6DF0DC433DB for ; Mon, 8 Mar 2021 09:49:24 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A4CA1651B9 for ; Mon, 8 Mar 2021 09:49:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A4CA1651B9 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kingsoft.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id AF0E06B00B8; Mon, 8 Mar 2021 04:49:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AA1356B00B9; Mon, 8 Mar 2021 04:49:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 91A756B00BA; Mon, 8 Mar 2021 04:49:22 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0161.hostedemail.com [216.40.44.161]) by kanga.kvack.org (Postfix) with ESMTP id 72EF26B00B8 for ; Mon, 8 Mar 2021 04:49:22 -0500 (EST) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 1AAD8180AD83E for ; Mon, 8 Mar 2021 09:49:22 +0000 (UTC) X-FDA: 77896234164.12.7543818 Received: from mail.kingsoft.com (unknown [114.255.44.146]) by imf18.hostedemail.com (Postfix) with ESMTP id BE048200038B for ; Mon, 8 Mar 2021 09:49:16 +0000 (UTC) X-AuditID: 0a580155-713ff700000550c6-67-6045ebaa5450 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-2-NODE-85) with SMTP id 7E.F0.20678.AABE5406; Mon, 8 Mar 2021 17:17:30 +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.1979.3; Mon, 8 Mar 2021 17:49:12 +0800 Date: Mon, 8 Mar 2021 17:49:12 +0800 From: Aili Yao To: Andy Lutomirski CC: "Luck, Tony" , Andy Lutomirski , HORIGUCHI NAOYA , Dave Hansen , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , X86 ML , , Linux-MM , LKML , Subject: Re: [PATCH v3] x86/fault: Send a SIGBUS to user process always for hwpoison page access. Message-ID: <20210308174912.4ac9029a@alex-virtual-machine> In-Reply-To: References: <8d0c76f97f35499f91a2b82d3e7c024d@intel.com> <59469ECC-5316-4074-98EF-52FFF7940818@amacapital.net> <20210303202402.384265a3@alex-virtual-machine> <20210303205129.0a66f7a7@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="UTF-8" Content-Transfer-Encoding: quoted-printable 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+NgFlrAIsWRmVeSWpSXmKPExsXCFcGooLvqtWuCwfLvQhafN/xjs3ixoZ3R YtpGcYvLu+awWdxb85/VYvXaBlaL87vWslpcOrCAyeJi4wFGi+O9B5gsNm+aymzx5sI9Fosf Gx6zOvB6fG/tY/G4/+Yvi8fmFVoei/e8ZPLYtKqTzWPTp0nsHu/OnWP3mHcy0OPF1Y0sHu/3 XWXz+LxJzuNEyxfWAJ4oLpuU1JzMstQifbsEroyew+0sBacEKiZfPcnewPiQp4uRk0NCwESi /fYWpi5GLg4hgelMEm1HfrGAJIQEXjJK/Jok2MXIwcEioCKx5T0TSJhNQFVi171ZrCC2iICm xMsp81lAepkFXjJLbHszixkkISyQLHFm0gNGEJtXwEpi/eFrYHFOgUCJTdtesEAsm8kk0f/q H1iCX0BMovfKfyaIi+wl2rYsgmoWlDg58wnYQcxA21q3/2aHsLUlli18zQxxqKLE4SW/2CF6 lSSOdM9gg7BjJZbNe8U6gVF4FpJRs5CMmoVk1AJG5lWMLMW56UabGCGRGLqDcUbTR71DjEwc jIcYJTiYlUR4e3ucE4R4UxIrq1KL8uOLSnNSiw8xSnOwKInz7j3mmiAkkJ5YkpqdmlqQWgST ZeLglGpgcrI5oHCji3d3+PtvHBVLN10+stnkmb2xzSOnu6o7oj49lFG/t+6giOcytRvz/C54 al4tunCjfFPIyrsL450tvggfZd89pSi5/d3x5xMn/7ju9HKd3u9l+y4pvxI6Z50xX1zr+Jy9 H3cVff5+6apD4hPBSc2bM+TKLb44HxLfumya9xmT66u4f2+NUUldPztVMNTzts+BuVPvr6tN 2rW3OGrHG8PDbKHPLYO3XZvcMuP4L3573dXJnCanUtNXyRnW8+Q2Pn1h/27G7psz7+7b0vd9 +W8N422x7tui5F3YW/jj11sKCWyyFL1dzarOwjf/9ZwX7/pm3n13qIbxTLXAIX4z9uCpfvfl hAUz3Y60rYpTYinOSDTUYi4qTgQA81gYLDMDAAA= X-Stat-Signature: fi6xmrxnpyckx3bim8qijhqk1rabso18 X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: BE048200038B Received-SPF: none (kingsoft.com>: No applicable sender policy available) receiver=imf18; identity=mailfrom; envelope-from=""; helo=mail.kingsoft.com; client-ip=114.255.44.146 X-HE-DKIM-Result: none/none X-HE-Tag: 1615196956-955136 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: On Sun, 7 Mar 2021 11:16:24 -0800 Andy Lutomirski wrote: > > > > >> Some programs may use read(2), write(2), etc as ways to check if > > > > >> memory is valid without getting a signal. They might not want > > > > >> signals, which means that this feature might need to be configur= able. =20 > > > > > > > > > > That sounds like an appalling hack. If users need such a mechanism > > > > > we should create some better way to do that. > > > > > =20 > > > > > > > > Appalling hack or not, it works. So, if we=E2=80=99re going to send= a signal to user code that looks like it originated from a bina fide archi= tectural recoverable fault, it needs to be recoverable. A load from a fail= ed NVDIMM page is such a fault. A *kernel* load is not. So we need to disti= nguish it somehow. =20 > > > > > > Sorry for my previous mis-understanding, and i have some questions: > > > if programs use read,write to check if if memory is valid, does it re= ally want to cover the poison case? =20 >=20 > I don't know. >=20 > > > When for such a case, an error is returned, can the program realize = it's hwposion issue not other software error and process correctly? =20 >=20 > Again, I don't know. But changing the API like this seems potentialy > dangerous and needs to be done with care. >=20 > > > > > > if this is the proper action, the original posion flow in current cod= e from read and write need to change too. > > > =20 > > > > Sorry, another question: > > When programs use read(2), write(2) as ways to check if memory is val= id, does it really want to check if the user page the program provided is v= alid, not the destination or disk space valid? =20 >=20 > They may well be trying to see if their memory is valid. Thanks for your reply, and I don't know what to do. For current code, if user program write to a block device(maybe a test try)= and if its user copy page corrupt when in kernel copy, the process is kill= ed with a SIGBUS. And for the page fault case in this thread, the process is error returned. --=20 Thanks! Aili Yao