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 0C77CC0015E for ; Fri, 28 Jul 2023 18:18:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3F3A66B0071; Fri, 28 Jul 2023 14:18:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3A3CD6B0074; Fri, 28 Jul 2023 14:18:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 26B418D0001; Fri, 28 Jul 2023 14:18:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 1798D6B0071 for ; Fri, 28 Jul 2023 14:18:28 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id CFEB71A07A4 for ; Fri, 28 Jul 2023 18:18:27 +0000 (UTC) X-FDA: 81061830654.09.6ADE07B Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf21.hostedemail.com (Postfix) with ESMTP id EEE871C0012 for ; Fri, 28 Jul 2023 18:18:24 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=uoKmSpJA; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf21.hostedemail.com: domain of "SRS0=yspX=DO=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=yspX=DO=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1690568305; a=rsa-sha256; cv=none; b=3vnZ1fBEXajqT02e5ap8pWLWlOEN/rgfgOplhL8He+hzGSGLyWPLxS8jgRSitkVsYS7f+V OHlMAn7AA58LnKvbFVJpD7LjAGN1ubjR36fCvS3TG19K8VJG/PDVmLUWusPhsMH5Lkm8cl OCilKDXkSXOs3eM+anZYr0DJ+fO0DfQ= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=uoKmSpJA; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf21.hostedemail.com: domain of "SRS0=yspX=DO=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=yspX=DO=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1690568305; h=from:from:sender:reply-to: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:dkim-signature; bh=1f6alwL0CTIe/o6BqYy7IE7KP/G2AurTgYLUsjAg8F4=; b=iMXYr8PYGZkl7xsxTI75U0c0k7veEnySAWyxfDnZ+Vgnsa4+XZJjSjwcXMPFU91440DoLv glzxXlbLrHIS/gXDN82hOGDHKhy7OOrB4pPjIIRtInvlpme5bLgSG8es22PpLJo2enaEz7 k4X6V2SBPs29ZNB6Zatxts4Wff4+l2E= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 257AB621B3; Fri, 28 Jul 2023 18:18:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7A71BC433C7; Fri, 28 Jul 2023 18:18:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1690568303; bh=xS3JH0ac4EOyWddaobfJi6wjfpgQcUOBaFzhfO9ijNM=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=uoKmSpJAM7WBqZwGvJ5UKdxWqkplEHHF10EqOUebYlT33zKsGvrkUN+FJxnBhwVIB gid1Zh8gd6vhJ3zyV7hZyJrf9PKGOEy3Cf2CdILd2svD727hN0iP6kxUWtEHgTzX0l hgBgjoQpdxN6/D7D5EiexQwUMTbraQFoYZse6bSs6EvPZzfp76zNIKz3iZt5xSkQ1z MvZK4CJw8kSFTh0lUEPgVOfa+zej+JgCXMI+KpQ3I+E9dVbGi6DouFIN8zVjrY1aV6 cUJHSOPxohUTcqBmhIaElpBlDodClnhw9QE08WeMZZWdnee8+UF+7CukZW/iDfdc0Q GykyDSaHTMc5w== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id F1ABBCE0B66; Fri, 28 Jul 2023 11:18:22 -0700 (PDT) Date: Fri, 28 Jul 2023 11:18:22 -0700 From: "Paul E. McKenney" To: Joel Fernandes Cc: Alan Stern , Will Deacon , Jann Horn , Andrew Morton , Linus Torvalds , Peter Zijlstra , Suren Baghdasaryan , Matthew Wilcox , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrea Parri , Boqun Feng , Nicholas Piggin , David Howells , Jade Alglave , Luc Maranget , Akira Yokosawa , Daniel Lustig Subject: Re: [PATCH 0/2] fix vma->anon_vma check for per-VMA locking; fix anon_vma memory ordering Message-ID: Reply-To: paulmck@kernel.org References: <20230728124412.GA21303@willie-the-truck> <9fd99405-a3ff-4ab7-b6b7-e74849f1d334@rowland.harvard.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: EEE871C0012 X-Stat-Signature: ouqzc493h6xwqxaadckt5fe93zw6e8xn X-HE-Tag: 1690568304-427643 X-HE-Meta: U2FsdGVkX1+Ac1FnbTVjJ/036xS0dvBOjiwayR23el3fRVd6ZbebcBu5SGb5HlRQaqMrPfOYrXTLs5J60L2ILYJWYuJNo5lTPOsAp3xqETXQkgCMV6NOdsZ8IjKZt77n1+RwNnPvG9+BebXY0J8MDglds4ZKfubfluuT3lTIUHD2T7o/IHFC9oAQyt0kysFiaJE/oBZyGxdJZXxFOiQccbwTb5vjjV/ZgAxri1lec8lVMo8bqB+bl7pInmONb8X6cF1t/qAreaKDICQH2WLiRPf8LPF0OSNQwMDpfUHmadgfxba4lNY2AH158Iat0u2tCjBMm3YDg1+QOFTp3Md/sIxlHQS5O1m/vg1Opat90o0Q0KzhLIryXH3ci2wqmaUexvnSQ2kQRMFeBUFgp+aQnt3qUYDfhxg+6EEi/W0Jjw3cnIZL8EmjCUWLbXpE/Bjzm6QBtVYUguFDf0ljbo/DMH0v3pHFolAePfN3BnsUyADmMTXkkPKVv2U8biKJR0SU8LNU88VxsWiDfEXUZcPhzJ0ykSJOJcPnqFDvin2vkh1ZoPURXY0IX9c5G3Kq2Kuj68he+iZsS49dbB6LQDr9CfI9wT5ML6DDtHo9GdwbHyoSd65J0pKoRC2vPzpVmY22qtgaDnaQYUOeUP53FCxZ6ik/Oy82yhkFO4/peHMxRPNknss3cS/piyPF3QwMYF88mSCMk7wlPTcQiamUNtRfjTwvMBgk/yZp0qBdvomz6uB5epZKXYsXGQ59ZKl9OalI3BOKJnbC8RteJc+HzZjeIGDkvf3xtkalliYpDDqc7EaQmcEBAKVMR3Zt1VPRx/aXUMjwBt+BfTcleayzSUocY3EUUV917uq2eFnhfDXePSTBMBIiVSU9Tawc4L9QwRFr/P7Ok5vovqgWx7EclHcUCvv9m3oYlBdbC2H6ZLcJHyPRMHm+tFo55xxQeyw9y3n4egwe6RY9PSYrwh9bjhL eWnXZO/h txVORVkY0EkyiFH3XEwMNhX/OWklwJfOdqPNsqR68OywsQWSJcrrDGkRAeYBb8bVTaX6FD9jV73HcUE0ror1+N9tvOHyWbF3rKaZj8w6BMl7UMtvWjXTsg10ItOm0LblsfbPOf/qglE3QcSB7+5f3/gNHEwavndHfC3ixQYYTLqima0/K0d5ZwMSaY0NtHhfEVdC+8v4JjiTqdrE3Rbx6lj0DzcIPpKlZCfv3r+idgoN1ta4JO2gjNDKSfYSHkdrDkKVeljLhUXXfTur1qu2PRT1utnwDHHYz0+Ftm/kyi544wNWYadW6x25LORO4zsGiNgTNae9+atqY1x5VDKX5yTl78jChguDb+UTsqzSj3NFZ3ljTn7CX4PHB65XR6+HeVAFLis1y9s34pTInD9P/7ToXUx+Jq0I97oDZm1URCQDizaZTaJZ1d9J07cxGTXHe0Tqnomv7tpMMj4azJ43LhqqbILGZUh8ZtQQ+/UPEKli6V95GFsPYp0B0UXl0AHthzmVZe69xzHWOsukZGWaUKrdu0c2VAEqvYUtUqEWnUCodQQmOHDIDL+IY+//6guP8XvIYYF1xOcThV/oUKSDP9HhuUX9bfj0lZcszGObZPtIai+TxZBxto1IMcaB0hDtcQT1ztXoxQwk0eYHSkeANakddNyljAZ/6hEyiAyS6PhdR7Ki6m6P4xH2DU/6AcFfQYDzkz7pPOq80WAqv1pBGUEPEUa5A+yI5XAyE3uXpr6I5lIr6pyylt2y4+l6ckRio3wqx9WNZZvCKO2VOop4xC2ZopLxRDZHx7CFfxcGMmUeqZbqWkxqko+THFg== 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 Fri, Jul 28, 2023 at 02:03:09PM -0400, Joel Fernandes wrote: > On Fri, Jul 28, 2023 at 1:51 PM Alan Stern wrote: > > > > On Fri, Jul 28, 2023 at 01:35:43PM -0400, Joel Fernandes wrote: > > > On Fri, Jul 28, 2023 at 8:44 AM Will Deacon wrote: > > > > > > > > On Thu, Jul 27, 2023 at 12:34:44PM -0400, Joel Fernandes wrote: > > > > > > On Jul 27, 2023, at 10:57 AM, Will Deacon wrote: > > > > > > On Thu, Jul 27, 2023 at 04:39:34PM +0200, Jann Horn wrote: > > > > > >> if (READ_ONCE(vma->anon_vma) != NULL) { > > > > > >> // we now know that vma->anon_vma cannot change anymore > > > > > >> > > > > > >> // access the same memory location again with a plain load > > > > > >> struct anon_vma *a = vma->anon_vma; > > > > > >> > > > > > >> // this needs to be address-dependency-ordered against one of > > > > > >> // the loads from vma->anon_vma > > > > > >> struct anon_vma *root = a->root; > > > > > >> } > > > > > >> > > > > > >> > > > > > >> Is this fine? If it is not fine just because the compiler might > > > > > >> reorder the plain load of vma->anon_vma before the READ_ONCE() load, > > > > > >> would it be fine after adding a barrier() directly after the > > > > > >> READ_ONCE()? > > > > > > > > > > > > I'm _very_ wary of mixing READ_ONCE() and plain loads to the same variable, > > > > > > as I've run into cases where you have sequences such as: > > > > > > > > > > > > // Assume *ptr is initially 0 and somebody else writes it to 1 > > > > > > // concurrently > > > > > > > > > > > > foo = *ptr; > > > > > > bar = READ_ONCE(*ptr); > > > > > > baz = *ptr; > > > > > > > > > > > > and you can get foo == baz == 0 but bar == 1 because the compiler only > > > > > > ends up reading from memory twice. > > > > > > > > > > > > That was the root cause behind f069faba6887 ("arm64: mm: Use READ_ONCE > > > > > > when dereferencing pointer to pte table"), which was very unpleasant to > > > > > > debug. > > > > > > > > > > Will, Unless I am missing something fundamental, this case is different though. > > > > > This case does not care about fewer reads. As long as the first read is volatile, the subsequent loads (even plain) > > > > > should work fine, no? > > > > > I am not seeing how the compiler can screw that up, so please do enlighten :). > > > > > > > > I guess the thing I'm worried about is if there is some previous read of > > > > 'vma->anon_vma' which didn't use READ_ONCE() and the compiler kept the > > > > result around in a register. In that case, 'a' could be NULL, even if > > > > the READ_ONCE(vma->anon_vma) returned non-NULL. > > > > > > If I can be a bit brave enough to say -- that appears to be a compiler > > > bug to me. It seems that the compiler in such an instance violates the > > > "Sequential Consistency Per Variable" rule? I mean if it can't even > > > keep SCPV true for a same memory-location load (plain or not) for a > > > sequence of code, how can it expect the hardware to. > > > > It's not a compiler bug. In this example, some other thread performs a > > write that changes vma->anon_vma from NULL to non-NULL. This write > > races with the plain reads, and compilers are not required to obey the > > "Sequential Consistency Per Variable" rule (or indeed, any rule) when > > there is a data race. > > So you're saying the following code behavior is OK? > > /* Say anon_vma can only ever transition from NULL to non-NULL values */ > a = vma->anon_vma; // Reads NULL > b = READ_ONCE(vma->anon_vma); // Reads non-NULL > c = vma->anon_vma; // Reads NULL!!! > if (b) { > c->some_attribute++; // Oopsie > } Is there some way to obtain (a && !b) that does not involve a data race, and they carte blanche for the compiler to do whatever it pleases? I am not seeing one. What am I missing? Thanx, Paul