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=-2.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 84FC2C2BA1A for ; Wed, 8 Apr 2020 20:26:33 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4408D20753 for ; Wed, 8 Apr 2020 20:26:33 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="wFjIOlDG" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4408D20753 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C89D58E000D; Wed, 8 Apr 2020 16:26:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C3AAE8E0006; Wed, 8 Apr 2020 16:26:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B01E28E000D; Wed, 8 Apr 2020 16:26:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0027.hostedemail.com [216.40.44.27]) by kanga.kvack.org (Postfix) with ESMTP id 9416E8E0006 for ; Wed, 8 Apr 2020 16:26:32 -0400 (EDT) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 5136BB793 for ; Wed, 8 Apr 2020 20:26:32 +0000 (UTC) X-FDA: 76685820624.10.cent15_5622dc48fc647 X-HE-Tag: cent15_5622dc48fc647 X-Filterd-Recvd-Size: 4571 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf38.hostedemail.com (Postfix) with ESMTP for ; Wed, 8 Apr 2020 20:26:31 +0000 (UTC) Received: from paulmck-ThinkPad-P72.home (50-39-105-78.bvtn.or.frontiernet.net [50.39.105.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id EA932206F7; Wed, 8 Apr 2020 20:26:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586377591; bh=Rf///vS7hUQYNaKEa5vTJDy89qODrzFaodSfFgOA/EA=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=wFjIOlDGvPMkug1U0zNPHfrxuIhe5ziZ0z/CBAAOzbM9iy5HZk4DF47NuUuGoxU6b 3t/xZ688gP574PXvZR3OZLOzyTo7XvWH0UZTCmwnBd4CRBG0pdfwhMYKGgVyRLzoVx j9u+J1l7Ie1lJtH2ZUvcqaHTE5YKbamI1R6/5mQk= Received: by paulmck-ThinkPad-P72.home (Postfix, from userid 1000) id BC9D03523234; Wed, 8 Apr 2020 13:26:30 -0700 (PDT) Date: Wed, 8 Apr 2020 13:26:30 -0700 From: "Paul E. McKenney" To: Linus Torvalds Cc: Andrew Morton , Chris Wilson , David Laight , Marco Elver , Linux-MM , Mark Rutland , mm-commits@vger.kernel.org, Randy Dunlap , stable Subject: Re: [patch 125/166] lib/list: prevent compiler reloads inside 'safe' list iteration Message-ID: <20200408202630.GA1666@paulmck-ThinkPad-P72> Reply-To: paulmck@kernel.org References: <20200406200254.a69ebd9e08c4074e41ddebaf@linux-foundation.org> <20200407031042.8o-fYMox-%akpm@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) 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 Tue, Apr 07, 2020 at 08:44:35AM -0700, Linus Torvalds wrote: > On Mon, Apr 6, 2020 at 8:10 PM Andrew Morton wrote: > > From: Chris Wilson > > Subject: lib/list: prevent compiler reloads inside 'safe' list iteration > > > > Instruct the compiler to read the next element in the list iteration > > once, and that it is not allowed to reload the value from the stale > > element later. This is important as during the course of the safe > > iteration, the stale element may be poisoned (unbeknownst to the > > compiler). > > Andrew, Chris, this one looks rather questionable to me. > > How the heck would the ->next pointer be changed without the compiler > being aware of it? That implies a bug to begin with - possibly an > inline asm that changes kernel memory without having a memory clobber. > > Quite fundamentally, the READ_ONCE() doesn't seem to fix anything. If > something else can change the list _concurrently_, it's still > completely broken, and hiding the KASAN report is just hiding a bug. > > What and where was the actual KASAN issue? The commit log doesn't say... OK, it sounds like we need to specify what needs to be present in this sort of commit log. Please accept my apologies for this specification not already being in place. How about the following? o The KCSAN splat, optionally including file/line numbers. o Any non-default Kconfig options that are required to reproduce the problem, along with any other repeat-by information. o Detailed description of the problem this splat identifies, for example, the code might fail to acquire a necessary lock, a plain load might vulnerable to compiler optimizations, and so on. o If available, references to or excerpts from the comments and documentation defining the design rules that the old code violates. o If the commit's effect is to silence the warning with no other algorithmic change, an explanation as to why this is the right thing to do. Continuing the plain-load example above, that load might be controlling a loop and the compiler might choose to hoist the load out of the loop, potentially resulting in an infinite loop. Another example might be diagnostic code where the accesses are not really part of the concurrency design, but where we need KCSAN checking the other code that implements that design. Thoughts? Additions? Subtractions? Thanx, Paul