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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id F31B6C433F5 for ; Fri, 21 Jan 2022 22:35:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2219B6B0080; Fri, 21 Jan 2022 17:35:49 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1D1516B0083; Fri, 21 Jan 2022 17:35:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0C0DA6B0085; Fri, 21 Jan 2022 17:35:49 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay039.a.hostedemail.com [64.99.140.39]) by kanga.kvack.org (Postfix) with ESMTP id F410A6B0080 for ; Fri, 21 Jan 2022 17:35:48 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id C201A4C8 for ; Fri, 21 Jan 2022 22:35:48 +0000 (UTC) X-FDA: 79055752776.02.AE3EC55 Received: from mail-ua1-f47.google.com (mail-ua1-f47.google.com [209.85.222.47]) by imf29.hostedemail.com (Postfix) with ESMTP id 549F0120022 for ; Fri, 21 Jan 2022 22:35:48 +0000 (UTC) Received: by mail-ua1-f47.google.com with SMTP id l1so17617633uap.8 for ; Fri, 21 Jan 2022 14:35:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0lPulDTNyk1tT0uyWXBSfXERYQLBy2175ie9JUMp2N4=; b=irAoru8GAZzoUOxiaEjcHP1bv4tmeWLyRhmRZkD+NLtC5XfBtuYM52oRoGamnEloZW 3tFevZbNyl4g+rfx0hO92ibSsoodiQRcMgGk6X2mh4m2NMGU4wqJ0yKqMov8F11cNDN9 tj7ClcGH1afsoCIXopKvub9otzw5KmYm+hoDNR9iEBc+e+q0+QWDnTQ3c7DjS4Czjjzj nYum5NyaKP9vkCAJVY1ivd2drT2ahKYnDJktGh/lREw2y5+aE/U+e5Pdhr7FaR/ou/To 3ek+vQsYWrxfhEPi53onAfsGziGiMYXK4ksZL6ua4tGNY8ZguMhg7q3RqGoii+f3kIZB oreQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0lPulDTNyk1tT0uyWXBSfXERYQLBy2175ie9JUMp2N4=; b=GcaRDOwxLBOQy6Q6GBbVy7CbIIJDQaxyEeWciUUG4yvbmiDJuLN+yWkpZG635CBQGJ 04j/ZrBoUeB458mnTqUGh3wMMhLvwvHc/9nQOCcezaf83SU5/Uk9FlfrrNLUwiVo1FWA FGAH23+PlAK9nvYGpkqJolL7Z118vk2PMIzSwI2Y86oTBk0M1MkFWeVl65XTzAAYTooS T0dgOv+JkZxJOmP1qnqmRgVUUKLHj6KeCmWzMe5x/1L496/5Q9t9FBIMu3NqU42a6rCx +7AjmZ/0Nd8tRikWVxmeBJXBs4rBpyBVJDait1qCECkAxePzEBOPUlAblcEicYYYDENG NRbw== X-Gm-Message-State: AOAM531WC60UJepVU3zH8nNfhH9npmz52TOeMabPuDwYVJWtdwVSujwV ppnMZliqaxkciarJbxT3wN9WBXuLILKdWFsKofOusg== X-Google-Smtp-Source: ABdhPJxlLDGonXr/zA+7Qq2vhDQVOTU+DxKYdIj2cT/2wRs3d4deZjRDmJhaFVt1P3ia7qc093ayBfk1bAlK536/8Is= X-Received: by 2002:a67:c48e:: with SMTP id d14mr2674726vsk.67.1642804547204; Fri, 21 Jan 2022 14:35:47 -0800 (PST) MIME-Version: 1.0 References: <20220118230539.323058-1-pcc@google.com> In-Reply-To: From: Peter Collingbourne Date: Fri, 21 Jan 2022 14:35:36 -0800 Message-ID: Subject: Re: [PATCH] mm/mmzone.c: fix page_cpupid_xchg_last() to READ_ONCE() the page flags To: Peter Zijlstra Cc: Andrey Konovalov , Andrew Morton , Linux Memory Management List , Linux Kernel Mailing List , Mel Gorman , "# 3.4.x" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 549F0120022 X-Stat-Signature: gwcptg7utuzfgc6rxuipud8w8akb9jts Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=irAoru8G; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf29.hostedemail.com: domain of pcc@google.com designates 209.85.222.47 as permitted sender) smtp.mailfrom=pcc@google.com X-Rspamd-Server: rspam08 X-HE-Tag: 1642804548-705467 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 Thu, Jan 20, 2022 at 2:43 AM Peter Zijlstra wrote: > > On Wed, Jan 19, 2022 at 03:28:32PM -0800, Peter Collingbourne wrote: > > On Wed, Jan 19, 2022 at 2:03 AM Peter Zijlstra wrote: > > > > > > On Tue, Jan 18, 2022 at 03:05:39PM -0800, Peter Collingbourne wrote: > > > > After submitting a patch with a compare-exchange loop similar to this > > > > one to set the KASAN tag in the page flags, Andrey Konovalov pointed > > > > out that we should be using READ_ONCE() to read the page flags. Fix > > > > it here. > > > > > > What does it actually fix? If it manages to split the read and read > > > garbage the cmpxchg will fail and we go another round, no harm done. > > > > What I wasn't sure about was whether the compiler would be allowed to > > break this code by hoisting the read of page->flags out of the loop > > (because nothing in the loop actually writes to page->flags aside from > > the compare-exchange, and if that succeeds we're *leaving* the loop). > > The cmpxchg is a barrier() and as such I don't think it's allowed to > hoist anything out of the loop. Yes it looks like it's at least as powerful as a barrier() because the implementations I looked at (arm64 and x86) use inline asm with memory operand (i.e. same as barrier()). > The bigger problem is I think that page_cpuid_last() usage which does a > second load of page->flags, and given sufficient races that could > actually load a different value and then things would be screwy. But > that's not actually fixed. Right, the patch you provided (which I posted as v2) inlines the page_cpuid_last() and should resolve this. > > > > Signed-off-by: Peter Collingbourne > > > > Link: https://linux-review.googlesource.com/id/I2e1f5b5b080ac9c4e0eb7f98768dba6fd7821693 > > > > > > That's that doing here? > > > > I upload my changes to Gerrit and link to them here so that I (and > > others) can see the progression of the patch via the web UI. > > What's the life-time guarantee for that URL existing? Because if it > becomes part of the git commit, it had better stay around 'forever' > etc.. I'd be surprised if it went away any time soon, the same hosting is used for projects like Android and Chromium which have been using it for years and have a long track record of stability. Also note that the link is useful independent of the host continuing to be up, it means that you can also do a search of the mailing list archive like so: https://lore.kernel.org/all/?q=I2e1f5b5b080ac9c4e0eb7f98768dba6fd7821693 (or the equivalent link on a different mailing list archive if lore.kernel.org ever gets shut down) and find the progression of the patch that way. This is particularly useful if (as in this case) the subject line of the patch changes. Peter