Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp1741593pxa; Thu, 13 Aug 2020 16:41:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyugFIwMpc/XBOpt9DQJZWxfhTptJFL815CUT5MrC4Z9mllRp9j62Cz0w1JCcNwdSFB5x69 X-Received: by 2002:a17:906:4e57:: with SMTP id g23mr6834507ejw.92.1597362108687; Thu, 13 Aug 2020 16:41:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597362108; cv=none; d=google.com; s=arc-20160816; b=LeIJZx6xL9YY+HIY5MtulEsFsUanTLqijOBen2tDs39oBp3LmXGS7GNarj/3Cw1h+2 d0ubsbjZN6yQ1qxuJNPLBezZ2AzurrglAI9qBM2tfIm70VWpqYDYDznZmZq42HJwD240 H8DLu6hiHaez8EO6mPOsWyeYsJaV1+OQJmNe8uUNZOPX8cOPmIRjEIZdytkHT11C7kqp Ddi8tgMSXfIXNeQfT5ONvkWOHajqmDE0u4ll+1AvjlpmZJrpnyXFaXQ7hWHGhnU6uzZM iI2WBt5bvrKgO3+Fq3bW4dR6S9HwJLF6Mrg6DycX5tUvr0KyP5LhakO0cgbDS2WYe1W4 oliA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=608qNLHC5/4osjXyTeWl015DQW4m7Dc2t3DShU7YJe0=; b=YFbf+RGxsJHdWRCFgGaHE3jTUZmD1M0ZZyEKHRYecqEtoyZg9tBiWrNIwhn3hZn5kH /NpDW6/ajk4CavhwiqpSEj25nYhdrqbr0WalvB83ojFXes5lQHJ2KYpY9mFp4tZhMBdC h89ZuZFlgC6yX/fdJ8LGMleFzU6SQlC8VYkg8lBvdXb/uA5d7i8K1Ze5hKEx3xSQBeTB D4itBj6wbOWng8s+OoiUBT/sxThL5iNQhjtYOlHa8sV8ZVKBhXR2F+YAAVtLWgjU8zgK G/DK5DPAvh8BeQ0es706P0Np1sGzWASdwfztWCcDj+Vh0YC59/l1EYzcqZZNbqyuS/NQ 0WDw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=wT9av0mb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id 90si4643075edr.528.2020.08.13.16.41.10; Thu, 13 Aug 2020 16:41:48 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=wT9av0mb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726567AbgHMXhm (ORCPT + 99 others); Thu, 13 Aug 2020 19:37:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42132 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726526AbgHMXhm (ORCPT ); Thu, 13 Aug 2020 19:37:42 -0400 Received: from mail-ej1-x644.google.com (mail-ej1-x644.google.com [IPv6:2a00:1450:4864:20::644]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A6A34C061757 for ; Thu, 13 Aug 2020 16:37:41 -0700 (PDT) Received: by mail-ej1-x644.google.com with SMTP id kq25so8058676ejb.3 for ; Thu, 13 Aug 2020 16:37:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=608qNLHC5/4osjXyTeWl015DQW4m7Dc2t3DShU7YJe0=; b=wT9av0mbZ1q5xaMLNh0532iGn6upLZ8tbnSY+oa8bj1AUaRnxl4mj2HgbqZ9zzCL/q WXU14AgUuY89PCDZzKvDXTsX9uMR1mr9Fl2fKh1kOu+rBKwk2UKaxZOdTfeP32iYuQyG vpqjlVk+8245L7AmSDXKv3dpb7pTpGa/qY5GNElF+ggw60/QodN15ToWL19U1GsUk2N9 QODItuWKoDQXNuQ+nvxhzcQJxnazMa2b1+1TlQ1Xk60piGbGRcXskOkeqA2Ysep3tmxq xF5HuCDuslwRdKXMQA1NcKB2KYzJSsMGBKQBjmvugFSduD7M6Zl2ZlFrzIVouseF8sum J4nA== 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=608qNLHC5/4osjXyTeWl015DQW4m7Dc2t3DShU7YJe0=; b=K2/I/OmnlMnQ3ze4rr8R3H/Sa4BNMZJ4rS1qKHAAx4Mcb5ULgi2vuyJvlUfUm/ttG7 cSQ+BneQAL46HcQSE0+ncDGIlxFhfhOAa94TDSmqr0iMVLKrHa8nzLP6hJFHMMgFm2s3 /hOlECa+sbliMBmlMA9Bp/ME5VVP7O/3Vl7tSCYuiLFLWBue2FXjPkzXNVvyUoeOHjli 86Olss+fZggxUiCLE6HDAICuTUMhSjJCtQrCCJ/URyW+c/NZL2zSEAqI72BKUmi2n3iM /t8N3RDfRef1YZxPi26IxjJRmovSGz1qcDVyhcoRgZK/ZKyxbeTfGvmGar1eTeF6erqs YvlQ== X-Gm-Message-State: AOAM53061X4N9AJ2zGNv1EZMvtM00RM5j3HqkcKe3GaJ/4CgqhQasb3C 8lw2Py/b1ceumv9g4rw0k3k7K4W9eVmc9QPQqt6QYw== X-Received: by 2002:a17:906:413:: with SMTP id d19mr7407867eja.523.1597361859855; Thu, 13 Aug 2020 16:37:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dan Williams Date: Thu, 13 Aug 2020 16:37:28 -0700 Message-ID: Subject: Re: [PATCH] dma-debug: fix debug_dma_assert_idle(), use rcu_read_lock() To: Linus Torvalds Cc: Hugh Dickins , Christoph Hellwig , Andrew Morton , Eric Dumazet , iommu , Linux Kernel Mailing List , Linux-MM Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 13, 2020 at 12:03 PM Linus Torvalds wrote: > > On Wed, Aug 12, 2020 at 8:17 PM Hugh Dickins wrote: > > > > Since commit 2a9127fcf229 ("mm: rewrite wait_on_page_bit_common() logic") > > improved unlock_page(), it has become more noticeable how cow_user_page() > > in a kernel with CONFIG_DMA_API_DEBUG=y can create and suffer from heavy > > contention on DMA debug's radix_lock in debug_dma_assert_idle(). > > Ooh. > > Yeah, that's ridiculously expensive, and serializes things for no good reason. > > Your patch looks obviously correct to me (Christoph?), but it also > makes me go "why are we doing this in the first place"? > > Because it looks to me like > (a) the debug check is wrong > (b) this is left-over from early debugging > > In particular, I don't see why we couldn't do a COW on a page that is > under writeback at the same time. We're not changing the page that is > doing DMA. > > In fact, the whole "COW with DMA" makes me feel like the real bug may > have been due that whole "ambiguous COW" thing, which was fixed in > 17839856fd58 ("gup: document and work around "COW can break either > way" issue") > > That debug thing goes back almost 7 years, and I don't think it has > caught anything in those seven years, but I could be wrong. > > The commit that adds it does talk about a bug, but that code was > removed entirely eventually. And google shows no hits for > debug_dma_assert_idle() since - until your email. > > So my gut feel is that we should remove the check entirely, although > your patch does seem like a big improvement. > > Christoph? > > (And Dan too, of course, in case he happens to be relaxing in front of > the computer away from a newborn baby ;) > I can at least confirm that it has not caught anything in a long while except a false positive that needed a fix up. https://lore.kernel.org/lkml/CAPcyv4hy_nNe8G0o8sMrz9A8HcdRzAuKgXmvdjKusAAA3Fow4g@mail.gmail.com/ Part of me says it's not doing anything worthwhile upstream, but I wonder if it is keeping some people from submitting patches that play these page reference shenanigans? I know they're out there. The land of gup and truncate is where questionable kernel changes go to die. Outside of that, Hugh's patch looks like a definite improvement so I'd be inclined to run with that, but rip the whole facility out at the next sign of a false positive.