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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 A6238C2BA80 for ; Tue, 7 Apr 2020 20:04:45 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 56C4C20719 for ; Tue, 7 Apr 2020 20:04:45 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="PtNK8HAC" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 56C4C20719 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id F23A68E000F; Tue, 7 Apr 2020 16:04:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EFBA98E0001; Tue, 7 Apr 2020 16:04:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E11208E000F; Tue, 7 Apr 2020 16:04:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0044.hostedemail.com [216.40.44.44]) by kanga.kvack.org (Postfix) with ESMTP id C8BB18E0001 for ; Tue, 7 Apr 2020 16:04:44 -0400 (EDT) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 8EC62180AD804 for ; Tue, 7 Apr 2020 20:04:44 +0000 (UTC) X-FDA: 76682136888.16.pie10_80a97deff6329 X-HE-Tag: pie10_80a97deff6329 X-Filterd-Recvd-Size: 5208 Received: from mail-lj1-f193.google.com (mail-lj1-f193.google.com [209.85.208.193]) by imf05.hostedemail.com (Postfix) with ESMTP for ; Tue, 7 Apr 2020 20:04:44 +0000 (UTC) Received: by mail-lj1-f193.google.com with SMTP id p10so5197622ljn.1 for ; Tue, 07 Apr 2020 13:04:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wkftfDZ88z74IMrEpi4bLp+mSOTuhVJsLPyxO6YFQQY=; b=PtNK8HACtoVIgsmxwYUTR+Aieqcw4+DsYktfEMrpftyDy/JCtdcK+xAcrtkS5OtIS8 iAfRqDo6l7Jsft0L0hK4UNgNJriH8zF7FQAQGln2z36HWakUUW7XGWz9KQqFzWzqwgoL 3byFgErfhA2uq8lHnVO/9GCldYYCBqoFrQheg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wkftfDZ88z74IMrEpi4bLp+mSOTuhVJsLPyxO6YFQQY=; b=TjxpxQS06Qo93zAL9eCx0szRsOuB380/ia/cshglxQBawtv5XD2Fd1WBU1TdCJ4ZsW bsbavpc0MoIG3lzQpicaQLrI5gxLmHwWLIY8AK4OV/8V086WOyD2rfJM/bB1wnazoarp VOT+4AIqq1UM0N2wBXHIAQAg2n2oofiJwmQDmLbNBHTdevagRb151xzBirvdStGf7TBE ubMvUm/6X1B3SwBh+QM1AYm/tmJ+th8kzuqMn5yW5/MK2MAaxXz98Gmu6Ph7TVJq4VRh CifEA2UMvgfwfNlrp2K9zl8PzCfATdaYTeMZddnGSPKXIy+4H+5EZdpmkVzTHNJWtA+z mKbw== X-Gm-Message-State: AGi0PuY5yEPeH+rl/XmSS0thjjX/6hA/GXOwZmHhJFGdoGv6B0wdN7EP e0yI/yHqLmRq0sQzrXdZHd1n+BRUbTE= X-Google-Smtp-Source: APiQypJNRnqxtTAzEtsQc5l1wuJiB0B/tX5ZOzrYLKas0nojFr58pGha9ptApF2rwjvGvNnG7W2LbA== X-Received: by 2002:a2e:9e8f:: with SMTP id f15mr2682938ljk.172.1586289881383; Tue, 07 Apr 2020 13:04:41 -0700 (PDT) Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com. [209.85.167.53]) by smtp.gmail.com with ESMTPSA id g4sm7758662ljn.105.2020.04.07.13.04.40 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Apr 2020 13:04:40 -0700 (PDT) Received: by mail-lf1-f53.google.com with SMTP id t11so3388835lfe.4 for ; Tue, 07 Apr 2020 13:04:40 -0700 (PDT) X-Received: by 2002:a19:9109:: with SMTP id t9mr2487716lfd.10.1586289879733; Tue, 07 Apr 2020 13:04:39 -0700 (PDT) MIME-Version: 1.0 References: <20200406200254.a69ebd9e08c4074e41ddebaf@linux-foundation.org> <20200407031042.8o-fYMox-%akpm@linux-foundation.org> <158627540139.8918.10102358634447361335@build.alporthouse.com> <158628265081.8918.1825514020221532657@build.alporthouse.com> In-Reply-To: <158628265081.8918.1825514020221532657@build.alporthouse.com> From: Linus Torvalds Date: Tue, 7 Apr 2020 13:04:23 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [patch 125/166] lib/list: prevent compiler reloads inside 'safe' list iteration To: Chris Wilson Cc: Andrew Morton , David Laight , Marco Elver , Linux-MM , Mark Rutland , mm-commits@vger.kernel.org, "Paul E. McKenney" , Randy Dunlap , stable Content-Type: text/plain; charset="UTF-8" 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 7, 2020 at 11:04 AM Chris Wilson wrote: > > That submission can run concurrently to the list iteration, but only > _after_ the final list_del. There is no such thing, Chris. Not without locks and memory ordering. The "list_del()" is already ordered on the CPU it happens. And _there_ it's already ordered with the list_for_each_entry_safe() by the compiler. > > There may be something really subtle going on, but it really smells > > like "two threads are modifying the same list at the same time". > > In strict succession. See above. There is no such thing as strict succession across two CPU's unless you have memory barriers, locks, or things like release/acquire operations. So a "strict succession from list_del()" only makes sense on the _local_ CPU. Not across threads. You may be relying on some very subtle consistency guarantee that is true on x86. For example, x86 does guarantee "causality". Not everybody else does that. > There's some more shutting up required for KCSAN to bring the noise down > to usable levels which I hope has been done so I don't have to argue for > it, such as Stop using KCSAN if you can't deal with the problems it introduces. I do NOT want to see bogus patches in the kernel that are introduced by bad infrastructure. That READ_ONCE() is _wrong_. File a bug with the KCSAN people, don't send garbage upstream. Linus