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=-4.1 required=3.0 tests=BAYES_00,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 91D98C433DF for ; Sat, 15 Aug 2020 00:59:26 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4EC4A22E01 for ; Sat, 15 Aug 2020 00:59:26 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="GViAih0/" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4EC4A22E01 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 CE53B8D0002; Fri, 14 Aug 2020 20:59:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C96488D0001; Fri, 14 Aug 2020 20:59:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B84718D0002; Fri, 14 Aug 2020 20:59:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0250.hostedemail.com [216.40.44.250]) by kanga.kvack.org (Postfix) with ESMTP id A13458D0001 for ; Fri, 14 Aug 2020 20:59:25 -0400 (EDT) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 5C79C75AA for ; Sat, 15 Aug 2020 00:59:25 +0000 (UTC) X-FDA: 77150994690.01.baby96_52058f527001 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin01.hostedemail.com (Postfix) with ESMTP id 2C985101DF89A for ; Sat, 15 Aug 2020 00:59:25 +0000 (UTC) X-HE-Tag: baby96_52058f527001 X-Filterd-Recvd-Size: 7098 Received: from mail-lj1-f194.google.com (mail-lj1-f194.google.com [209.85.208.194]) by imf05.hostedemail.com (Postfix) with ESMTP for ; Sat, 15 Aug 2020 00:59:24 +0000 (UTC) Received: by mail-lj1-f194.google.com with SMTP id v9so11756546ljk.6 for ; Fri, 14 Aug 2020 17:59:24 -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=x5V/+PBSBblwToTAxIaWCU/QUA1O6ispz0B5966qT9o=; b=GViAih0/p9oLbkxsH0zRUETk2BWc6utJvJ2zieuBFpItMZ5Q/d+XoOIJE3UmtmDW9d PfB7oAxIVJBUbDF/z38G7nHCI1AuDI/Wa5eZncLuwEofl1Tgh5gbUZms7q6RUinORQm5 atVm6Nom3LD276TzkMMR7WITDnfy6UtyUb83E= 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=x5V/+PBSBblwToTAxIaWCU/QUA1O6ispz0B5966qT9o=; b=MtR2UdCEnbY9X4yKzunag/LDRuQ5rN4N7fe8n7BG3KWoWa8tN1Y9R6zMgUR/tRt1ZZ blJ0dqWRj1UaukhBsVNy4TMPvEw3M/4nwX+3OFBOPbstL3o9ASLLnTBoju5igVXKd9Ct F7nM4HoQvy5t2UON2kFbxLI+zFGuQh1jhwbapd+oHeQsdmmd8fcri9KNQAGRmcX7BxIt 8uI8ksTeaOk/ANffpkyR/J1SZ/iba+GhEFLSv3pjPHdHikFe1spG9uRcquE/5qyLdqK8 PJRiCMAQvGr3nVlpCmE/z/LZUMSAH8bVmQ4CRcKOnQmWJ2/CIUKTyYAnYq1s0bzH+3r7 TihQ== X-Gm-Message-State: AOAM530LCuSGojVnqxyhFk94KdCBfiKnDF0Xz7Fp9u0sD2JYYdw0ZDQW BSL+2JYuQN6+G7LvhQkiDgto1ankeljZOQ== X-Google-Smtp-Source: ABdhPJyA24n1FucMnY6HOwSf5KVSc3GAR4nlhveUEtuUU0bVwPtcC6j0nFyI7vz+EgRRKkLW6q770A== X-Received: by 2002:a2e:87cd:: with SMTP id v13mr2618092ljj.180.1597453162147; Fri, 14 Aug 2020 17:59:22 -0700 (PDT) Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com. [209.85.167.47]) by smtp.gmail.com with ESMTPSA id o24sm2059131ljg.69.2020.08.14.17.59.20 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 14 Aug 2020 17:59:21 -0700 (PDT) Received: by mail-lf1-f47.google.com with SMTP id b11so5685583lfe.10 for ; Fri, 14 Aug 2020 17:59:20 -0700 (PDT) X-Received: by 2002:a05:6512:3b7:: with SMTP id v23mr2382329lfp.10.1597453160630; Fri, 14 Aug 2020 17:59:20 -0700 (PDT) MIME-Version: 1.0 References: <20200814054241.GA719@lst.de> In-Reply-To: From: Linus Torvalds Date: Fri, 14 Aug 2020 17:59:04 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] dma-debug: fix debug_dma_assert_idle(), use rcu_read_lock() To: Hugh Dickins Cc: Christoph Hellwig , Andrew Morton , Dan Williams , Eric Dumazet , iommu , Linux Kernel Mailing List , Linux-MM Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 2C985101DF89A X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam02 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, Aug 14, 2020 at 5:26 PM Hugh Dickins wrote: > > We used to rely on page count there, and on trylock_page() only; but > there was at least one user whose app went wrong when occasionally we > COWed the page, just because something else momentarily took a reference > to it, or locked it. Around 2006, bug report from 2004: I did look up > the history a week ago, but was interrupted before taking notes. I actually think you may be talking about the exact problem that that debug patch from Dan was originally created for: 0abdd7a81b7e dma-debug: introduce debug_dma_assert_idle() 77873803363c net_dma: mark broken and your memory sounds exactly like that net_dma case (and the timing matches roughly too - the NET_DMA code was merged in 2006, but I think people had been playing trial games with it before that). IOW, net_dma was horribly broken, and just couldn't deal with COW because it did things wrong. The thing is, doing extra COW's really shouldn't matter in _any_ half-way correct situation. There's a few cases: - user space writing to it, so we COW. This is the "simple" case that is obvious and we've always done the same thing. User space will get the new copy, and there's no possible situation when that can be wrong. - get_user_pages() for reading. This is the one we actually used to get wrong, and when another user *didn't* cow, the data that was read might not match what the original get_uiser_pages() case expected. But in this case, the bug only happened when we didn't cow aggressively enough. - get_user_pages() for writing This is another 'simple" case, because it does the COW at get_user_pages() time and gets it's own copy (which is also installed in the thread that does the GUP, of course, so a subsequent fork an danother write can obviously cause *further* COW action). But in no case should an extra COW matter. Except if somebody uses get_user_pages() to write to the page, and the COW "hides" that write by giving a new copy to whoever expected to see it, but that's exactly the case that Dan's patch was supposed to notice. And since it never triggered outside of that invalid net_dma case, I don't think any other case really ever existed. Yes, I can well imagine that some people loved the concept of that TCP receive copy offload, but it really was broken, and was removed entirely by Dan in commit 7bced397510a ("net_dma: simple removal") a year after being marked broken (the author date makes it look like it's just a couple of weeks after being marked broken, but the commit date for that removal is September 2014). So I don't think that the trylock and checking page counts is a correctness issue. It had better not be, because anybody that writes to a shared-cow page without breaking COW is simply broken. No, I really think that the real worry about doing more aggressive copying is that it doesn't steal back the KSM page or the swap cache page, so it will leave those pages around, and while they should then be really easy for the VM to reclaim, I really worry that we have a couple of decades of VM reclaim tuning with that swap cache reuse behavior (KSM, not so much). And while it works fine on my machine, I currently have 40GB or RAM free, because honestly, the stuff I do doesn't need all that much memory, and I ridiculously overspecced my new machine RAM'wise. So nothing I will do would show any problems. Linus