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=1.7 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,URIBL_DBL_ABUSE_MALW 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 A74A7C35240 for ; Fri, 31 Jan 2020 02:22:09 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 46C92214D8 for ; Fri, 31 Jan 2020 02:22:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lca.pw header.i=@lca.pw header.b="ZAGlDzEg" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 46C92214D8 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lca.pw Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id BE7716B04A2; Thu, 30 Jan 2020 21:22:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B9AB46B04A3; Thu, 30 Jan 2020 21:22:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A5FBB6B04A4; Thu, 30 Jan 2020 21:22:08 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0001.hostedemail.com [216.40.44.1]) by kanga.kvack.org (Postfix) with ESMTP id 8E1DF6B04A2 for ; Thu, 30 Jan 2020 21:22:08 -0500 (EST) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 3611E8248047 for ; Fri, 31 Jan 2020 02:22:08 +0000 (UTC) X-FDA: 76436329536.15.wax03_2faf8e0a29462 X-HE-Tag: wax03_2faf8e0a29462 X-Filterd-Recvd-Size: 5724 Received: from mail-qk1-f195.google.com (mail-qk1-f195.google.com [209.85.222.195]) by imf24.hostedemail.com (Postfix) with ESMTP for ; Fri, 31 Jan 2020 02:22:07 +0000 (UTC) Received: by mail-qk1-f195.google.com with SMTP id w15so5137778qkf.6 for ; Thu, 30 Jan 2020 18:22:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lca.pw; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WL0FLgSacIAqtCGMkthh4uOIeyhw7X/ubIyKLP7UcMQ=; b=ZAGlDzEgoEB6R7NedCVOXEjZKZzovnmhhKhJX7mrctCT0WxPjz2pT7AYk70aYaUSXV YOLsGZRFqCjyLeHfBbb+3oTJ5bhG+C5v9YugT1VlbFlVKRIJizIsRgHHbVX8zl+Yo1nK TGkAjNH48Wtqm+0e4kmJN+vtnce23YuHP0G4rns0WRLERVJhRs6UOLYeeBrBzVv16ftN DP0JQkV0BkkFYMpHG9+WC11jTS7Aq+t7RJmkoMrrlVOQdREPeYQfbbk0L22wmclJIUrt 1HnmuAsOqFI1dzq24676j4PRVcC/32mqTtjhlKJQgsWQd7VG4tsbDqzqPvFCYsQ0GsLQ U2FA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WL0FLgSacIAqtCGMkthh4uOIeyhw7X/ubIyKLP7UcMQ=; b=XDensBpDsI/8B6uH1iXRb/26aUpILPkXSzmL58XBa9VcyQT8r5PKh5P4ZSdv4+92vW 4kWy31jgbVztnbw7cut0SFxSxeL1TlNM0NYiZtBY2nzSPFl7aUTimhXD5t4YL297FJ/g 1g+X17OA8dTgkpO80EpSfx1goTMwafhAWYUc94v/EHyNObE/8OvtIeN4COEv3f+J3Kof hlSbRU+A/g1uHu7cQ9uP3l2uPOw9dTA8v0ZRv+Nc03fnn9BB6/8EItQb9S/TFrJLlFw3 wzgqa0l430CPo0rSU59UIOnTRv2mp7PBDLpgNXUvZtinndvAWnOWsVIKp+l2dnDsVgpW Zudw== X-Gm-Message-State: APjAAAVh0rUHzO3acEclDFscKNYIdnapSD0QyJZ10DCnhXVw36Ii/GzJ roUvsyoz/hy7NBk0RZJ0/8dGkg== X-Google-Smtp-Source: APXvYqx8JQk+90y2rl6YQE+bmI4aQ+EhMYsBcxfyUMLozcHF1DtPAe1VuWEJhRflwNMVLcMDnCXtYA== X-Received: by 2002:a37:308:: with SMTP id 8mr8346060qkd.98.1580437326892; Thu, 30 Jan 2020 18:22:06 -0800 (PST) Received: from [192.168.1.153] (pool-71-184-117-43.bstnma.fios.verizon.net. [71.184.117.43]) by smtp.gmail.com with ESMTPSA id x3sm3934273qts.35.2020.01.30.18.22.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Jan 2020 18:22:06 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Subject: Re: [PATCH] mm/util: fix a data race in __vm_enough_memory() From: Qian Cai In-Reply-To: <20200130181834.633c201c7d0a2638aacbc7ba@linux-foundation.org> Date: Thu, 30 Jan 2020 21:22:05 -0500 Cc: Marco Elver , Matthew Wilcox , dennis@kernel.org, tj@kernel.org, Christoph Lameter , Linux Memory Management List , LKML Content-Transfer-Encoding: quoted-printable Message-Id: <9B86F7FF-C892-4F58-A24E-E0728D2637BC@lca.pw> References: <20200130042011.GI6615@bombadil.infradead.org> <1135BD67-4CCB-4700-8150-44E7E323D385@lca.pw> <20200130181834.633c201c7d0a2638aacbc7ba@linux-foundation.org> To: Andrew Morton X-Mailer: Apple Mail (2.3608.40.2.2.4) 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 Jan 30, 2020, at 9:18 PM, Andrew Morton = wrote: >=20 > On Thu, 30 Jan 2020 13:35:18 +0100 Marco Elver = wrote: >=20 >> On Thu, 30 Jan 2020 at 12:50, Qian Cai wrote: >>>=20 >>>> On Jan 29, 2020, at 11:20 PM, Matthew Wilcox = wrote: >>>>=20 >>>> I'm really not a fan of exposing the internals of a percpu_counter = outside >>>> the percpu_counter.h file. Why shouldn't this be fixed by putting = the >>>> READ_ONCE() inside percpu_counter_read()? >>>=20 >>> It is because not all places suffer from a data race. For example, = in __wb_update_bandwidth(), it was protected by a lock. I was a bit = worry about blindly adding READ_ONCE() inside percpu_counter_read() = might has unexpected side-effect. For example, it is unnecessary to have = READ_ONCE() for a volatile variable. So, I thought just to keep the = change minimal with a trade off by exposing a bit internal details as = you mentioned. >>>=20 >>> However, I had also copied the percpu maintainers to see if they = have any preferences? >>=20 >> I would not add READ_ONCE to percpu_counter_read(), given the writes >> (increments) are not atomic either, so not much is gained. >>=20 >> Notice that this is inside a WARN_ONCE, so you may argue that a data >> race here doesn't matter to the correct behaviour of the system >> (except if you have panic_on_warn on). >>=20 >> For the warning to trigger, vm_committed_as must decrease. Assume = that >> a data race (assuming bad compiler optimizations) can somehow >> accomplish this, then the load or write must cause a transient value >> to somehow be less than a stable value. My hypothesis is this is very >> unlikely. >>=20 >> Given the fact this is a WARN_ONCE, and the fact that a transient >> decrease in the value is unlikely, you may consider >> 'VM_WARN_ONCE(data_race(percpu_counter_read(&vm_committed_as)) < >> ...)'. That way you won't modify percpu_counter_read and still catch >> unintended races elsewhere. >>=20 >=20 > That, or add an alternative version of per_cpu_counter_read() to the > percpu API. A very carefully commented version! I send a patch to use data_race() which should be sufficient, https://lore.kernel.org/linux-mm/20200130145649.1240-1-cai@lca.pw/=