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 93BC7C3DA49 for ; Tue, 23 Jul 2024 05:51:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1287E6B0085; Tue, 23 Jul 2024 01:51:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 100166B0088; Tue, 23 Jul 2024 01:51:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F0A696B0089; Tue, 23 Jul 2024 01:51:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id D34926B0085 for ; Tue, 23 Jul 2024 01:51:02 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 57256141BCA for ; Tue, 23 Jul 2024 05:51:00 +0000 (UTC) X-FDA: 82369943880.05.3203DFF Received: from mail-pl1-f177.google.com (mail-pl1-f177.google.com [209.85.214.177]) by imf18.hostedemail.com (Postfix) with ESMTP id 8E55B1C001F for ; Tue, 23 Jul 2024 05:50:58 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=kernel.org (policy=none); spf=pass (imf18.hostedemail.com: domain of dennisszhou@gmail.com designates 209.85.214.177 as permitted sender) smtp.mailfrom=dennisszhou@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721713813; h=from:from:sender: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: in-reply-to:in-reply-to:references:references; bh=HAi76Fbb14aLD72KSDP4ZLSN99eyDyIsZtCeNe0d2u8=; b=V/dlYhJp28P4ar4sn9X/Dk82VAe+VhbGiJW2/Ot80vCARkEGoEsKN1aNStJn6/cfmHog12 BFBaolQk7MKAZN4BxX49LRx6CMYTOLVZDAMDHIXkN4GnsrFapoiheZx5aVlwiebD0X0hH+ RYPl8rtAMkkXcnLk2a3blOyhm78p8Hw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721713813; a=rsa-sha256; cv=none; b=48KE1xw+kAMqHrv73PGc2nUWoDwFw7h/hA8l3rQWsIuLPXjsfa3zHCSsrvqmI+v6I31n8Z YChq4g+dQ/pW5QuMr7iu9KFE9XQaGwKuhcqHL7Hs7xHsO6FfGrQFp9nq4r/TfVTIRDo4Q4 1p1E3GGtU+ly3FYyTeZ5OrSDprAXc9c= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=kernel.org (policy=none); spf=pass (imf18.hostedemail.com: domain of dennisszhou@gmail.com designates 209.85.214.177 as permitted sender) smtp.mailfrom=dennisszhou@gmail.com Received: by mail-pl1-f177.google.com with SMTP id d9443c01a7336-1fc611a0f8cso29358435ad.2 for ; Mon, 22 Jul 2024 22:50:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721713857; x=1722318657; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=HAi76Fbb14aLD72KSDP4ZLSN99eyDyIsZtCeNe0d2u8=; b=B0RuMnrq5eKsFj56Z/GK/YuwbhhSjMwghFNMSa315su8l0nozexLlTY8CRQO993n4s ubI9m8pjbVk0fo7FudUswxpSIvqZGpwLikE1HZqCLk8BLJAayZcR48zDOOxDGkQFV3l8 iYsnRTA+o70u4QvVjS3HnbOYrJmEtvc2C+EJgVjr1tvbdqFrkUgQj7clKuBzMg5gRzXK oIkjvOZCoSnCuBocrfJlWVAJX420Yv5X8Y6+/ZdBfw8575QIHI3PDWbLGmHVboIjAca+ typAEQGx94QJXmz32eYVCOeIdG+yy62M4Rw1oTbHGX0/Ee2pY2O/4XyXJd0WwQ1ZcNzD 9c5A== X-Forwarded-Encrypted: i=1; AJvYcCWUQZPfuGFPyeXiuTSIrPiLTmgMhOBKPFqRoyjghXAjbcgeshKIMSV9H0H3sDQ2sEFtDjYFgF4Zs4tWm85f0W5UQhw= X-Gm-Message-State: AOJu0YzSarTYXl1ijfWkjAYI6Cko3X5fWOuz9rmtf2x3zP0QpJQGkAX3 z4vbfcH6b8RE67ptpzPGS/mLFeGV78V8MYE8S2Y3aef1v4PH6N6Q X-Google-Smtp-Source: AGHT+IGI5WT7ey25jg4G2dYdrX/Y37jBH63oL83DdgNLhILixfslqS9am3ee4OUjXlB4bSi2bGXT2Q== X-Received: by 2002:a17:903:2448:b0:1fd:6677:69b4 with SMTP id d9443c01a7336-1fd74660a7dmr64169625ad.49.1721713857175; Mon, 22 Jul 2024 22:50:57 -0700 (PDT) Received: from snowbird ([136.25.84.117]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-1fd6f48ca81sm65316435ad.299.2024.07.22.22.50.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Jul 2024 22:50:56 -0700 (PDT) Date: Mon, 22 Jul 2024 22:50:53 -0700 From: Dennis Zhou To: Boqun Feng Cc: Tejun Heo , kernel test robot , Suren Baghdasaryan , oe-lkp@lists.linux.dev, lkp@intel.com, linux-kernel@vger.kernel.org, Andrew Morton , Kent Overstreet , Kees Cook , Alexander Viro , Alex Gaynor , Alice Ryhl , Andreas Hindborg , Benno Lossin , =?iso-8859-1?Q?Bj=F6rn?= Roy Baron , Christoph Lameter , Gary Guo , Miguel Ojeda , Pasha Tatashin , Peter Zijlstra , Vlastimil Babka , Wedson Almeida Filho , linux-mm@kvack.org, lkmm@lists.linux.dev Subject: Re: [linus:master] [mm] 24e44cc22a: BUG:KCSAN:data-race_in_pcpu_alloc_noprof/pcpu_block_update_hint_alloc Message-ID: References: <202407191651.f24e499d-oliver.sang@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 8E55B1C001F X-Stat-Signature: m4tyqnfpp3suunbo59son67bd6pkfemt X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1721713858-152022 X-HE-Meta: U2FsdGVkX1+GagGWo9Xm8fjhDeNFp8cb0asczDsKZ1t/knJGUpmlT5XlDr/rhliuEMOMuA81wH878RxyboWtVDn+i/3L1erYXPsO/8U/kUBTMCuP5K35kd4HfnXXmdwJpN8XPrbZ72jC5On1R1oZhm3oKKsNTRpZHOmLTdmETtLLHZvbaf7/0AGxA66lqlZ62KAOtpWmMUGfDMFNlNO5lPru3ZQ+5knkx6E6nfxTVNaLYeMkhK0b6eLdurpOq0ZnqWOxlZFsOMvdZl6R+a5G7A5Brbt/p6g5IzshZOAJHXfe+wThZkgDTH+tUYgdA4ljm+wwzwu13jWzip3T+6WPdeyJMgvqxE4Vm4heHljiU0163qqe2frI3OaITOVQ2WBbgS0tw1nbtGRs5VmavpxTeIFqqvjYc9HNlgeUoJbc5mShutUU0Q5KDAYlhWcc4KaxYL4Hd6kr1PJrOF66le3zLM+SJDUOG+y38xaTjgTZurLqFeMiPJdFY55ET1UznvLvBaC7+ELGNmjkfjzehIsuoi32nmtGyKjQXfu8LKGz9aAR1cZouBuiH/cEjrsHq+kC/yGMFjhNcAGP9zrBm0ZR2rTXpKTMOlMSMSFbIo1OO6iQjw5nD4gjegVLPGf3ZiMMCzqPpzEgGXQV3u+P/UCBna5vC/VvoxRsKZxYv2anzjkh1qGvNPbLAQq0GqEQOFKXpgJ7a6W4PGHyxWBIkdqtEGnwRnUNujyDdaouABNerZXBGJ1dggk4p2wNhR0y7JvO43dxqncSszD7PJn/AqpOWRF/K5JRxDoizdT+aJyfiAg4RU78V5rx8svWPVp+CQVK0s5Fy6GOex0Zn9Vh63TMSfSYoStBxnhhZ+JHfR3yjMWAFN2PzRou8orA4+j+x+59FUS0zzN00UX5aRPdyftx3/P252xPl2CexwBSwxNF+TdT2udDvQQ8OFf0kJhpyvJ2i2xKoo9BaT4KDuHQS7g YFCuJKwu D8L5jiD4bytqhpsUK1qI/2i669YvaVV39L/Z6ma05I3hHrotgkN+pVxbPr/QRIxWNzCSNgEQffjANRiITBpfLFOjv/ZXehnuMRIpFNcRHUzm0Ddtp6iyaqNYyl6L4FHbloCWzPz+9kW3VyLVuI7pkzyqB05KO5j0ay5TkctrwlgiicZeWOhwBaIC45Yv4aytV7d2rrY0eJXxuaDQHrmea3cXcQObaxsCx5X7mp7NVVnF2u9FkJzmlJE+WDFvZBxMH2GFHrtihtnIVgvKeIHWb4eKzW//aURbt2/i8CgKrcv2rw2Y+EAiSR2/m7tvriQAN7sCPPM0u0gZ7mLvA1XfeI+qCutNDYFTIav1rHttDu+69ABH1/Ur4W8eouSC3tFJ+KhyaGPli9Clvj+zSnnhPC8IKrn/rP5/m/BZ0Kb40565JMiSuJzoG7D5VCQPEASMyu6ZadFmsE9PbNohfyc6IYNKoTMaAJ2usykIw7g/FklNCSMlT2jZ/ykmx7E2lmhTOtQdtpDyCx1S99YP2IOMK/hl3Yw== 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: List-Subscribe: List-Unsubscribe: On Mon, Jul 22, 2024 at 01:53:52PM -0700, Boqun Feng wrote: > On Mon, Jul 22, 2024 at 11:27:48AM -0700, Dennis Zhou wrote: > > Hello, > > > > On Mon, Jul 22, 2024 at 11:03:00AM -0700, Boqun Feng wrote: > > > On Mon, Jul 22, 2024 at 07:52:22AM -1000, Tejun Heo wrote: > > > > On Mon, Jul 22, 2024 at 10:47:30AM -0700, Boqun Feng wrote: > > > > > This looks like a data race because we read pcpu_nr_empty_pop_pages out > > > > > of the lock for a best effort checking, @Tejun, maybe you could confirm > > > > > on this? > > > > > > > > That does sound plausible. > > > > > > > > > - if (pcpu_nr_empty_pop_pages < PCPU_EMPTY_POP_PAGES_LOW) > > > > > + /* > > > > > + * Checks pcpu_nr_empty_pop_pages out of the pcpu_lock, data races may > > > > > + * occur but this is just a best-effort checking, everything is synced > > > > > + * in pcpu_balance_work. > > > > > + */ > > > > > + if (data_race(pcpu_nr_empty_pop_pages) < PCPU_EMPTY_POP_PAGES_LOW) > > > > > pcpu_schedule_balance_work(); > > > > > > > > Would it be better to use READ/WRITE_ONCE() for the variable? > > > > > > > > > > For READ/WRITE_ONCE(), we will need to replace all write accesses and > > > all out-of-lock read accesses to pcpu_nr_empty_pop_pages, like below. > > > It's better in the sense that it doesn't rely on compiler behaviors on > > > data races, not sure about the performance impact though. > > > > > > > I think a better alternative is we can move it up into the lock under > > area_found. The value gets updated as part of pcpu_alloc_area() as the > > code above populates percpu memory that is already allocated. > > > > Not sure I followed what exactly you suggested here because I'm not > familiar with the logic, but a simpler version would be: > > I believe that's the only naked access of pcpu_nr_empty_pop_pages. So I was thinking this'll fix this problem. I also don't know how to rerun this CI tho.. --- diff --git a/mm/percpu.c b/mm/percpu.c index 20d91af8c033..325fb8412e90 100644 --- a/mm/percpu.c +++ b/mm/percpu.c @@ -1864,6 +1864,10 @@ void __percpu *pcpu_alloc_noprof(size_t size, size_t align, bool reserved, area_found: pcpu_stats_area_alloc(chunk, size); + + if (pcpu_nr_empty_pop_pages < PCPU_EMPTY_POP_PAGES_LOW) + pcpu_schedule_balance_work(); + spin_unlock_irqrestore(&pcpu_lock, flags); /* populate if not all pages are already there */ @@ -1891,9 +1895,6 @@ void __percpu *pcpu_alloc_noprof(size_t size, size_t align, bool reserved, mutex_unlock(&pcpu_alloc_mutex); } - if (pcpu_nr_empty_pop_pages < PCPU_EMPTY_POP_PAGES_LOW) - pcpu_schedule_balance_work(); - /* clear the areas and return address relative to base address */ for_each_possible_cpu(cpu) memset((void *)pcpu_chunk_addr(chunk, cpu, 0) + off, 0, size);