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=-16.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 045DAC433E0 for ; Sat, 27 Feb 2021 03:40:52 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 89E9E64F22 for ; Sat, 27 Feb 2021 03:40:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 89E9E64F22 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 240C88D0013; Fri, 26 Feb 2021 22:40:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1CB7D8D0001; Fri, 26 Feb 2021 22:40:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 094488D0013; Fri, 26 Feb 2021 22:40:51 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0218.hostedemail.com [216.40.44.218]) by kanga.kvack.org (Postfix) with ESMTP id E2F5A8D0001 for ; Fri, 26 Feb 2021 22:40:50 -0500 (EST) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id B460152A3 for ; Sat, 27 Feb 2021 03:40:50 +0000 (UTC) X-FDA: 77862646260.12.4D63EAB Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf30.hostedemail.com (Postfix) with ESMTP id 25567E0001B4 for ; Sat, 27 Feb 2021 03:40:50 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id F1D4D64F22 for ; Sat, 27 Feb 2021 03:40:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1614397249; bh=GaYBKNg2FYle2ONdxwZhRkedGU09PcAZdiKDMRmBPLQ=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=XyYvUGJY7Wkxu5qH4nylRf/R5eP6PHeOZFS+5TuNBjYLmZB/zVjMYp7YSuy/NFfqG nW+HTGQoIRhUTCfIy7LzMLuINFnacalY9DEZOIESRzNP32m+ItFpwIBBaUfLNxknVv cIo/k7esJNeeKJNMMETnsFcASUHwpHugySCaqWetz1raXtqZLDy3/0oEuAKIo45wXY xZnDmvRI9g/qYm7BwkBhCWh8kkU7Pmdx736XnX3PFvV6MADsRjO1YgNk7CJwDZ2d+6 nzjTE7qzpBEzgVEMbUTO7RS4Z5+hxm5baZdpSZor2j0qfmqXkI3RgeukSeEUtANtRU kvQ5nXENLPZXQ== Received: by mail-ej1-f41.google.com with SMTP id k13so18022234ejs.10 for ; Fri, 26 Feb 2021 19:40:48 -0800 (PST) X-Gm-Message-State: AOAM530iWYEOxCBLHBmYl8rg0AiIrtIl8pr0W73b+K+boyfJNJrD+zGS KnjCF3vj0AybERyE2oFQ6/sjLpgUiLrRmfzAssD6/A== X-Google-Smtp-Source: ABdhPJygujS8ZtS7FU8BxyTMB+/C3ogJJ/OAQ3TpUmTEIh+cFM/x9j3E1yMzqckCSAyuA83Ngvx8oU/kL9mcMtkQ+UA= X-Received: by 2002:a17:906:a44:: with SMTP id x4mr6400087ejf.101.1614397247562; Fri, 26 Feb 2021 19:40:47 -0800 (PST) MIME-Version: 1.0 References: <20210223204436.1df73153@alex-virtual-machine> <788DFBA0-903F-4548-9C2F-B1A1543EE770@amacapital.net> <20210223164259.GA166727@agluck-desk2.amr.corp.intel.com> <20210225124711.35b31965@alex-virtual-machine> In-Reply-To: <20210225124711.35b31965@alex-virtual-machine> From: Andy Lutomirski Date: Fri, 26 Feb 2021 19:40:35 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3] x86/fault: Send a SIGBUS to user process always for hwpoison page access. To: Aili Yao Cc: "Luck, Tony" , =?UTF-8?B?SE9SSUdVQ0hJIE5BT1lBKCDloIDlj6Mg55u05LmfKQ==?= , Dave Hansen , Andrew Lutomirski , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , X86 ML , yangfeng1@kingsoft.com, Linux-MM , LKML Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 25567E0001B4 X-Stat-Signature: i7q8dbwkpny7xm8r5stnwo58oy14cxg6 Received-SPF: none (kernel.org>: No applicable sender policy available) receiver=imf30; identity=mailfrom; envelope-from=""; helo=mail.kernel.org; client-ip=198.145.29.99 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1614397250-58509 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 Wed, Feb 24, 2021 at 8:47 PM Aili Yao wrote: > > On Tue, 23 Feb 2021 08:42:59 -0800 > "Luck, Tony" wrote: > > > On Tue, Feb 23, 2021 at 07:33:46AM -0800, Andy Lutomirski wrote: > > > > > > > On Feb 23, 2021, at 4:44 AM, Aili Yao wrote: > > > > > > > > =EF=BB=BFOn Fri, 5 Feb 2021 17:01:35 +0800 > > > > Aili Yao wrote: > > > > > > > >> When one page is already hwpoisoned by MCE AO action, processes ma= y not > > > >> be killed, processes mapping this page may make a syscall include = this > > > >> page and result to trigger a VM_FAULT_HWPOISON fault, as it's in k= ernel > > > >> mode it may be fixed by fixup_exception, current code will just re= turn > > > >> error code to user code. > > > >> > > > >> This is not sufficient, we should send a SIGBUS to the process and= log > > > >> the info to console, as we can't trust the process will handle the= error > > > >> correctly. > > > >> > > > >> Suggested-by: Feng Yang > > > >> Signed-off-by: Aili Yao > > > >> --- > > > >> arch/x86/mm/fault.c | 62 +++++++++++++++++++++++++++++------------= ---- > > > >> 1 file changed, 40 insertions(+), 22 deletions(-) > > > >> > > > > Hi luto; > > > > Is there any feedback? > > > > > > At the very least, this needs a clear explanation of why your propose= d behavior is better than the existing behavior. > > > > The explanation is buried in that "can't trust the process" line. > > > > E.g. user space isn't good about checking for failed write(2) syscalls. > > So if the poison was in a user buffer passed to write(fd, buffer, count= ) > > sending a SIGBUS would be the action if they read the poison directly, > > so it seems reasonable to send the same signal if the kernel read their > > poison for them. > > > > It would avoid users that didn't check the return value merrily proceed= ing > > as if everything was ok. > > Hi luto: > I will add more infomation: > Even if the process will check return value of syscall like write, I d= on't think > process will take proper action for this. > In test example, the return value will be errno is 14 (Bad Address), t= he process may not realize > this is a hw issue, and may take wrong action not as expected. > And totally, A hw error will rarely happen, and the hw error hitting t= his branch will be > more unlikely, the impaction without this patch is quite minor, but this = is still not good enough, we should > make it better, right? There are a few issues I can imagine: 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 configurable. It's worth making sure that this doesn't end up sending duplicate signals. If nothing else, this would impact the vsyscall emulation code. Programs that get a signal might expect that the RIP that the signal frame points to is the instruction that caused the signal and that the instruction faulted without side effects. For SIGSEGV, I would be especially nervous about this. Maybe SIGBUS is safer. For SIGSEGV, it's entirely valid to look at CR2 / si_fault_addr, fix it up, and return. This would be completely *invalid* with your patch. I'm not sure what to do about this. --Andy