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 265B4C2BA1A for ; Tue, 7 Apr 2020 17:40:03 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D0E292076E for ; Tue, 7 Apr 2020 17:40:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="QOrZewsD" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D0E292076E 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 6DF218E0005; Tue, 7 Apr 2020 13:40:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 66AAA8E0001; Tue, 7 Apr 2020 13:40:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 508888E0005; Tue, 7 Apr 2020 13:40:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0118.hostedemail.com [216.40.44.118]) by kanga.kvack.org (Postfix) with ESMTP id 347AE8E0001 for ; Tue, 7 Apr 2020 13:40:02 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id EEEA42C89 for ; Tue, 7 Apr 2020 17:40:01 +0000 (UTC) X-FDA: 76681772202.14.girl43_1d5058e68ee52 X-HE-Tag: girl43_1d5058e68ee52 X-Filterd-Recvd-Size: 5620 Received: from mail-lf1-f65.google.com (mail-lf1-f65.google.com [209.85.167.65]) by imf49.hostedemail.com (Postfix) with ESMTP for ; Tue, 7 Apr 2020 17:40:01 +0000 (UTC) Received: by mail-lf1-f65.google.com with SMTP id 131so3022178lfh.11 for ; Tue, 07 Apr 2020 10:40:01 -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=Ex03nfQpPCZeA5+yn7tSblnxDu6ASBCOFJtNAPyZWrM=; b=QOrZewsDVgAhhR0NNMGT6ZzX6PUyBuqHSlmSqH9UdRXoM3m03w5yTICDKyAVbPwqQQ 99crxFriNn197nfvF7GUfYQJ1jLRgRuOcN5ENFuMnI4E37VyA4O+Ve1f8JFqOeCIM15W 8p40DbVI2SvKuc1+5O3tfXMav7+0XIUi5G4JA= 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=Ex03nfQpPCZeA5+yn7tSblnxDu6ASBCOFJtNAPyZWrM=; b=MrjFnuWuzoHv42K3A/bwqiPH7WzmUCnqKvr9FPFiOwR/4EKisNfDPGK9v9jF8Ir0Ft O/P79StcKdCWHuYVqEVyqA+myRAih4448Aa/97BZeMcA+5qYLw8mVnEBoCHfGVViNLsP VS09iDRguAMpHcMq2oni3V2Mh0rVj7adQtqg+PHb6VhnQ0HP2o9gIUEXdkqjXMyulawz jWnPnH8nYBP2/52Ok3LvfTEVlCrGuiagjR4xZ5rb4VQESZt4fBRRwwHMytDoFbkeTGSs yF2s0I/N0AecN6RZVzNzFDWjUjsK1m7oEoCtOK9+TDIoww55GmdHOmrYd003RwgueBPB kA/w== X-Gm-Message-State: AGi0PuZtzSFKt12Y789oJRScfXzmj2qANrXUWADQDI3MIKLKWR/IseZn Qkenzg9piDa8/n5jR1t/1aRcyurfkWo= X-Google-Smtp-Source: APiQypIIZxNK5YzdwnYY045a3Lz2OD2T5rKwOxCg0jBNTgKoDqkVjxEgdElRftHZONXL/AoMrkcdvw== X-Received: by 2002:a19:f614:: with SMTP id x20mr2140462lfe.84.1586281199243; Tue, 07 Apr 2020 10:39:59 -0700 (PDT) Received: from mail-lj1-f182.google.com (mail-lj1-f182.google.com. [209.85.208.182]) by smtp.gmail.com with ESMTPSA id y20sm12331886ljd.35.2020.04.07.10.39.57 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Apr 2020 10:39:58 -0700 (PDT) Received: by mail-lj1-f182.google.com with SMTP id r7so4642364ljg.13 for ; Tue, 07 Apr 2020 10:39:57 -0700 (PDT) X-Received: by 2002:a2e:b4cb:: with SMTP id r11mr2493242ljm.201.1586281196972; Tue, 07 Apr 2020 10:39:56 -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> In-Reply-To: From: Linus Torvalds Date: Tue, 7 Apr 2020 10:39:39 -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 10:28 AM Linus Torvalds wrote: > > There may be something really subtle going on, but it really smells > like "two threads are modifying the same list at the same time". > > And there's no way that the READ_ONCE() will fix that bug, it will > only make KASAN shut up about it. [ And by KASAN I obviously meant KCSAN every time ] An alternative is that it's just a KCSAN bug or false positive for some other reason. Which is possible. But the more I look at this, the more I think you really have a bug in your list handling. I'm just not convinced the whole "we have a race where we randomly add a tail object" in another thread is a valid reason for making those "safe" list accessors use READ_ONCE. The thing is, they were never designed to be safe wrt concurrent accesses. They are safe from the _same_ thread removing the current entry, not from other threads changing the entries - whether it be the last one or not. Because if _another_ thread removes (or adds) an entry, you have a whole new set of issues. READ_ONCE() isn't sufficient. You need to have memory ordering guarantees etc. For example, the thread that adds another entry that might - or might not - be visible without locking, would have to fully initialize the entry, and set the ->next pointer on it, before it adds it to the list. I suspect you could use the RCU list walkers for a use-case like this. So __list_add_rcu() for example uses the proper rcu_assign_pointer() (which uses smp_store_release()) to make sure that the newly added entry is actually _ordered_ wrt the stores to the entry. But the "safe" list functions simply do not have those kinds of ordering guarantees, and doing concurrent list_add() simply *CANNOT* be right. Adding a READ_ONCE() does not in any way make it right (although it might work in practice on x86). Linus