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=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 B2542C43460 for ; Tue, 20 Apr 2021 10:17:05 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D384F613B0 for ; Tue, 20 Apr 2021 10:17:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D384F613B0 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=alien8.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 212926B0036; Tue, 20 Apr 2021 06:17:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1C2776B006E; Tue, 20 Apr 2021 06:17:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 062D46B0070; Tue, 20 Apr 2021 06:17:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0163.hostedemail.com [216.40.44.163]) by kanga.kvack.org (Postfix) with ESMTP id D60196B0036 for ; Tue, 20 Apr 2021 06:17:03 -0400 (EDT) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 49C82181AEF2A for ; Tue, 20 Apr 2021 10:17:03 +0000 (UTC) X-FDA: 78052342326.25.AEF58C6 Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) by imf22.hostedemail.com (Postfix) with ESMTP id 6A84FC0007DB for ; Tue, 20 Apr 2021 10:16:56 +0000 (UTC) Received: from zn.tnic (p200300ec2f0e52003145dfcc247b909a.dip0.t-ipconnect.de [IPv6:2003:ec:2f0e:5200:3145:dfcc:247b:909a]) (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 BE7571EC0347; Tue, 20 Apr 2021 12:16:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1618913819; 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=OHKWCU6z/Def+S0XFUqT3Jd+HhaFJheSWWNeZEIUM0I=; b=eGLMA1y4e9m6z6KXY6CN1sEVnvAOCxsMIzgZjG1nnbCQ62afOenS42QnvgPnXkrLoHQa6l mLqj70tomCM8s8K3igeg8uWtQP4d/SbjVOQS3CDY5K4aVM+UrKxHG0ehl6NAAVdRKzBwjD 8B3QPAfNkUMO5O6h3aIHy98f0FWyOZU= Date: Tue, 20 Apr 2021 12:16:57 +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 , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v1 1/3] mm/memory-failure: Use a mutex to avoid memory_failure() races Message-ID: <20210420101657.GF5029@zn.tnic> References: <20210412224320.1747638-1-nao.horiguchi@gmail.com> <20210412224320.1747638-2-nao.horiguchi@gmail.com> <20210419170538.GG9093@zn.tnic> <20210420074625.GA24451@hori.linux.bs1.fc.nec.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20210420074625.GA24451@hori.linux.bs1.fc.nec.co.jp> X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 6A84FC0007DB X-Stat-Signature: rpjk3uy3ibz4zy8mitc1zzpxsq33achd Received-SPF: none (alien8.de>: No applicable sender policy available) receiver=imf22; identity=mailfrom; envelope-from=""; helo=mail.skyhub.de; client-ip=5.9.137.197 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1618913816-831878 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: On Tue, Apr 20, 2021 at 07:46:26AM +0000, HORIGUCHI NAOYA(=E5=A0=80=E5=8F= =A3 =E7=9B=B4=E4=B9=9F) wrote: > If you have any other suggestion, please let me know. Looks almost ok... > From: Tony Luck > Date: Tue, 20 Apr 2021 16:42:01 +0900 > Subject: [PATCH 1/3] mm/memory-failure: Use a mutex to avoid memory_fai= lure() > races >=20 > There can be races when multiple CPUs consume poison from the same > page. The first into memory_failure() atomically sets the HWPoison > page flag and begins hunting for tasks that map this page. Eventually > it invalidates those mappings and may send a SIGBUS to the affected > tasks. >=20 > But while all that work is going on, other CPUs see a "success" > return code from memory_failure() and so they believe the error > has been handled and continue executing. >=20 > Fix by wrapping most of the internal parts of memory_failure() in > a mutex. >=20 > Along with introducing an additional goto label, this patch also ... avoid having "This patch" or "This commit" in the commit message. It is tautologically useless. Also, you don't have to explain what the patch does - that's visible hopefully. :-) Other than that, it makes sense and the "sandwitching" looks correct: mutex_lock lock_page ... unlock_page mutex_unlock Thx. --=20 Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette