Received: by 2002:a05:6a10:a841:0:0:0:0 with SMTP id d1csp1289752pxy; Fri, 23 Apr 2021 04:59:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyN9wJ9EXzudiO9Bt9z4hI+mss2giEjr9pcnVhvtwN7pJLlQjN9GNnHFmLwQj9bvcQFBVws X-Received: by 2002:a17:906:590b:: with SMTP id h11mr3802140ejq.83.1619179144879; Fri, 23 Apr 2021 04:59:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1619179144; cv=none; d=google.com; s=arc-20160816; b=U4qfoPqe1GMGamM21ppnKyN4Ne6rMNoQsbNBodV3b4CJNtTRqw8qKo5+P597MTSmcl FPZtpcOYyvwjcd0vO60Vyqg4B9fHXUhpBjF7zNbRbiupBRy+uRZUpO19Sbj2J7UpkF4p F+MQuL+fT81DabxxWTFp0/uKhZHunTkml+hlsYn+BoGR0RyEIk00XRGU5v4EtmEGJNx4 tvYxCwLxhWSX9SUn/Ec38XX3pkpnT+fl0FC2Y1lJGagjdGDtXMb6j9M9MUEn/92CjrMU le5j0yVvfq/qLcTmNLZApOu1//4zI7bAc8QZzAArqtnNiGE5tnEjjjpUK8jL4UWdHBzJ E6Fw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=Hl4owIygIiuL+Uo1VjLb8yx5rvDHEvzCcFzwABb5PYo=; b=VpPfYYhzRW9R4hq1ohD0WrTwArdspYmmJkDw4zBjo+MkGRd0AEppWkYSUUwdQW7tLJ qz1+SiuGzxUV+xPaDfiFaRG1nFeKniIxumJVCA0Amk+YPOUtQWwKSNPWzutxqsGR9h69 +D73iOmWgEV/ie8wJ7I3j7cEJBZG5DwGDUIqodCk9wLnsUOxp0tn89Ygux4+5D5BFewF Fete4K8VnMd5YdAt7Nl71lK7epGuEXdkw6DANlUIV/WFZYUR+1COKtYLybHXMukASO71 AiVnbCDj/w5FroT5x/DZHG3MDV/3yQmp3FQv8M+acn8E0dP9UJluE2diuA//kYfijXmw XEjw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b=cGIDsJuf; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bx11si4894513edb.156.2021.04.23.04.58.38; Fri, 23 Apr 2021 04:59:04 -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; dkim=pass header.i=@alien8.de header.s=dkim header.b=cGIDsJuf; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242270AbhDWL6J (ORCPT + 99 others); Fri, 23 Apr 2021 07:58:09 -0400 Received: from mail.skyhub.de ([5.9.137.197]:53326 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242260AbhDWL6G (ORCPT ); Fri, 23 Apr 2021 07:58:06 -0400 Received: from zn.tnic (p200300ec2f0cb100de1b78f3b91faa58.dip0.t-ipconnect.de [IPv6:2003:ec:2f0c:b100:de1b:78f3:b91f:aa58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 7B5301EC0118; Fri, 23 Apr 2021 13:57:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1619179049; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Hl4owIygIiuL+Uo1VjLb8yx5rvDHEvzCcFzwABb5PYo=; b=cGIDsJufxJejr6m5pU81tTIT5Zyyt/2m8sYjxfkATzMh/3QXpk/K/n8xkzuQocNbCoqnl9 6d8orgS8F0w3utnveodjRJL4h4MBQ6mAb3318hEQ3HyHAWpVgMjvVvq8hjFsTAlSkRFQjT tzlIChMkDT5sk7sIhm7GSvd/E9pb8js= Date: Fri, 23 Apr 2021 13:57:25 +0200 From: Borislav Petkov To: HORIGUCHI =?utf-8?B?TkFPWUEo5aCA5Y+j44CA55u05LmfKQ==?= Cc: Naoya Horiguchi , "linux-mm@kvack.org" , Tony Luck , Aili Yao , Andrew Morton , Oscar Salvador , David Hildenbrand , Andy Lutomirski , Jue Wang , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v3 3/3] mm,hwpoison: add kill_accessing_process() to find error virtual address Message-ID: <20210423115725.GB18085@zn.tnic> References: <20210421005728.1994268-1-nao.horiguchi@gmail.com> <20210421005728.1994268-4-nao.horiguchi@gmail.com> <20210422170213.GE7021@zn.tnic> <20210423021833.GB68967@hori.linux.bs1.fc.nec.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210423021833.GB68967@hori.linux.bs1.fc.nec.co.jp> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 23, 2021 at 02:18:34AM +0000, HORIGUCHI NAOYA(堀口 直也) wrote: > I don't know exactly. MCE subsystem seems to have code extracting linear > address, so I wonder that that could be used as a hint to memory_failure() > to find the proper virtual address. See "Table 15-3. Address Mode in IA32_MCi_MISC[8:6]" in the SDM - apparently it can report all kinds of address types, depending on the hw incarnation or MCA bank type or whatnot. Tony knows :) > The situation in question is caused by action required MCE, so > we know which process we should send SIGBUS to. So if we choose > to send SIGBUS to all, no innocent bystanders would be affected. > But when the process have multiple virtual addresses associated > with the error physical address, the process receives multiple > SIGBUSs and all but one have wrong value in si_addr in siginfo_t, > so that's confusing. Is that scenario real or hypothetical? Because I'd expect that if we send it a SIGBUS and we poison that page, then all the VAs mapping it will have to handle the situation that that page has been poisoned and pulled from under them. So from a hw perspective, there won't be any more accesses to the faulty physical page. In a perfect world, that is... -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette