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 9B91EC433FE for ; Fri, 14 Jan 2022 21:58:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9A96B6B0071; Fri, 14 Jan 2022 16:58:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 959616B0073; Fri, 14 Jan 2022 16:58:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 820FA6B0074; Fri, 14 Jan 2022 16:58:57 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0205.hostedemail.com [216.40.44.205]) by kanga.kvack.org (Postfix) with ESMTP id 706686B0071 for ; Fri, 14 Jan 2022 16:58:57 -0500 (EST) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 2523398C3B for ; Fri, 14 Jan 2022 21:58:57 +0000 (UTC) X-FDA: 79030258314.07.50ED56E Received: from mail-il1-f172.google.com (mail-il1-f172.google.com [209.85.166.172]) by imf21.hostedemail.com (Postfix) with ESMTP id C802D1C0004 for ; Fri, 14 Jan 2022 21:58:56 +0000 (UTC) Received: by mail-il1-f172.google.com with SMTP id v17so1813338ilg.4 for ; Fri, 14 Jan 2022 13:58:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gmfAhubjEyaVBPWv1g0ex2hEpije68c3WmxI7HlJuIk=; b=QnmdCE3NJISxA+/1AWG4v/lMA6X1fAvApupya0G6ju2+yMwnUKhXgkISyblOky7wCH Iawa8V9VAsNgx7S12bZLNY6lIb2W7w9QALKSGmIeeDreHrmlrikiu3u5BRvdhqJ/6/Jo 9xXq6H4H1OaymlUbwKpuC0Ak27BK0BjWEQNSuOnL4s0wNNsAVbkErr42oLIC4obma8EK SD+CzfoXgDV6Ckt2IPEvXWoMtxq/tE/IfTBCZM+JeocTf7KLSeXDK1GCPWowiCK9HmyK 4HeERsvOmOvdEmNj2k2Tz2D3aXW35vtBPVw0DbFiTyBWSR018gqvECgwFQa9qLjl9bx7 NEMw== 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=gmfAhubjEyaVBPWv1g0ex2hEpije68c3WmxI7HlJuIk=; b=I89wp1C+iKCMC6hImIBYHpbiF1pfBvZ1MDum7S+qfn65p1skw4PuDaA6fE18vLqw60 RbegshijFKqhqnmdH3T5qIiWUTXYSgaofmYhEAfy59paY2hpM1UtTY6zHAOszKRVPzVq rMaF056hVmVzgmDU5FqMQUdcl6V1zRItd0klYgHxDopib8XNviogrw9AJ1T6NqGkA8qS 9qrqpCiULJ3vco5BF00XXr7ZGlpGAosGQjo7GpQNsx84obh3UIZ3PuP8ALuKGmMip03+ yqwMXOmbj+rWpIN/PO0Em3hPzdj7iGo7kYT+ytOTv1tS4kECVVtwluDOHf8DV/TkGsxC ppvg== X-Gm-Message-State: AOAM533pYdl56jrE0a2FyM/hPlD0/n9WZTns/le6A7LQVauCMBCqp9Q9 9QQ2DQfRCC0kzaLJ6pkknRe20o3PdO9KH5nr3Vg= X-Google-Smtp-Source: ABdhPJyEqWk4kGHWNUxv/NqZeg5vXP4u/CwmwuwfG3M0oC96dClS8SejOQ80vW+AxDbzi+M3FzZQrmnQm0Ct0B6rL1U= X-Received: by 2002:a92:1e0a:: with SMTP id e10mr5942316ile.28.1642197535952; Fri, 14 Jan 2022 13:58:55 -0800 (PST) MIME-Version: 1.0 References: <20220113031434.464992-1-pcc@google.com> In-Reply-To: <20220113031434.464992-1-pcc@google.com> From: Andrey Konovalov Date: Sat, 15 Jan 2022 00:58:44 +0300 Message-ID: Subject: Re: [PATCH] mm: use compare-exchange operation to set KASAN page tag To: Peter Collingbourne Cc: Andrew Morton , Linux Memory Management List , LKML , stable@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: C802D1C0004 X-Stat-Signature: bn4d44tcm7o9ydhakbsgfnen53e9ghfu Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=QnmdCE3N; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf21.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.166.172 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com X-Rspamd-Server: rspam02 X-HE-Tag: 1642197536-964835 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 13, 2022 at 6:14 AM Peter Collingbourne wrote: > > It has been reported that the tag setting operation on newly-allocated > pages can cause the page flags to be corrupted when performed > concurrently with other flag updates as a result of the use of > non-atomic operations. Is it know how exactly this race happens? Why are flags for a newly allocated page being accessed concurrently? > Fix the problem by using a compare-exchange > loop to update the tag. > > Signed-off-by: Peter Collingbourne > Link: https://linux-review.googlesource.com/id/I456b24a2b9067d93968d43b4bb3351c0cec63101 > Fixes: 2813b9c02962 ("kasan, mm, arm64: tag non slab memory allocated via pagealloc") > Cc: stable@vger.kernel.org > --- > include/linux/mm.h | 16 +++++++++++----- > 1 file changed, 11 insertions(+), 5 deletions(-) > > diff --git a/include/linux/mm.h b/include/linux/mm.h > index c768a7c81b0b..b544b0a9f537 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -1531,11 +1531,17 @@ static inline u8 page_kasan_tag(const struct page *page) > > static inline void page_kasan_tag_set(struct page *page, u8 tag) > { > - if (kasan_enabled()) { > - tag ^= 0xff; > - page->flags &= ~(KASAN_TAG_MASK << KASAN_TAG_PGSHIFT); > - page->flags |= (tag & KASAN_TAG_MASK) << KASAN_TAG_PGSHIFT; > - } > + unsigned long old_flags, flags; > + > + if (!kasan_enabled()) > + return; > + > + tag ^= 0xff; > + do { > + old_flags = flags = page->flags; I guess this should be at least READ_ONCE(page->flags) if we care about concurrency. > + flags &= ~(KASAN_TAG_MASK << KASAN_TAG_PGSHIFT); > + flags |= (tag & KASAN_TAG_MASK) << KASAN_TAG_PGSHIFT; > + } while (unlikely(cmpxchg(&page->flags, old_flags, flags) != old_flags)); > } > > static inline void page_kasan_tag_reset(struct page *page) > -- > 2.34.1.575.g55b058a8bb-goog >