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=-6.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS autolearn=ham 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 717D3C43215 for ; Wed, 20 Nov 2019 00:02:22 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1BB2422419 for ; Wed, 20 Nov 2019 00:02:21 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Dqbh8o1j" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1BB2422419 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 6E8236B0003; Tue, 19 Nov 2019 19:02:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 698496B0006; Tue, 19 Nov 2019 19:02:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5AE6C6B0007; Tue, 19 Nov 2019 19:02:21 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0061.hostedemail.com [216.40.44.61]) by kanga.kvack.org (Postfix) with ESMTP id 45BD16B0003 for ; Tue, 19 Nov 2019 19:02:21 -0500 (EST) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id 00CAB181AEF1A for ; Wed, 20 Nov 2019 00:02:21 +0000 (UTC) X-FDA: 76174703682.25.sleet69_14766ee043d19 X-HE-Tag: sleet69_14766ee043d19 X-Filterd-Recvd-Size: 4948 Received: from mail-il1-f196.google.com (mail-il1-f196.google.com [209.85.166.196]) by imf39.hostedemail.com (Postfix) with ESMTP for ; Wed, 20 Nov 2019 00:02:20 +0000 (UTC) Received: by mail-il1-f196.google.com with SMTP id q15so21618991ils.8 for ; Tue, 19 Nov 2019 16:02:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XRuRyFkUCUOdWjwJNkpxkVE1L+haL5tEbBGbuI6HeJc=; b=Dqbh8o1j67JQZPE49aQOSNgQranyZAi7jBL5zHRpSSRxfSbmz/uv/Mvo3ujDaEmaKc pJgBKlY2K3rA9dkFyNw5iW23GHEibQA/isdNIWVDDxsF5qmYQkxtWwwTnmJ+H+oOqBET 6R2wkSZToOd7C25l1QyosTQs7j7ZhYE8FGNeQDR5HHQIucNWp21rM9edY73fTBuxVclA WR4ucWcGN3CWcIlcnUnrjtvzzBsrClHF9HEwcpUXOMjOl/Oj3EIElvOH9HpwVZ5fsIRH j4spZ0MsAbXKZTIyx4xr2Un0QSx2EXd5Rp4SyqJBYcfiyzf9gkXod++7v5I0tJUFlagU 7p3w== 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=XRuRyFkUCUOdWjwJNkpxkVE1L+haL5tEbBGbuI6HeJc=; b=VjDDevIILgeHGRlkb3tF9sN62CvXMR9zYAnjoXM28JnLAGN6l2/V5BJ5ueuDKAw5hm pOF2PcHxt3wwKajdreqIbnnjoe5XieOSis2mq5USXRyUk3pCw907yLb9fCa7ARhycznW AuaBxq/oRRKSnl+DgckhjDC2pY+2tOdERCyyYtYjc5gQn5MIlO9EuyQgORiVqfzbdvjv XcmjAfcjljl1k4T1D1Ev9fEphiaBroTIa59OfprmdHAMOdX9uk0F9zGWI+iTHX14TfeB MnAbHtYBS5fPPgPVNa8J7VuPIlOf+Ob6Fhglp9JxzRvh5EIXvNOtqwWJEstxJsHruoVn +gzw== X-Gm-Message-State: APjAAAUZct83eRRXnegb0AwP3IiLBx1C90vn3/EmkYipPGYg5fRZasAy 9A32LQh4/kywIpNSUXkDCPCWgrXQZXQaOrivl8I= X-Google-Smtp-Source: APXvYqzllv9hd/SyZA8krBsksyfbdkhS7M7f8nY7mdQHtRo/mS4gY+0ta4t4ecyCyC9LyDUdaLBbuqY5kZQWez+0iXg= X-Received: by 2002:a92:9e90:: with SMTP id s16mr464341ilk.237.1574208139514; Tue, 19 Nov 2019 16:02:19 -0800 (PST) MIME-Version: 1.0 References: <157418493888.1639105.6922809760655305210.stgit@dwillia2-desk3.amr.corp.intel.com> In-Reply-To: <157418493888.1639105.6922809760655305210.stgit@dwillia2-desk3.amr.corp.intel.com> From: Alexander Duyck Date: Tue, 19 Nov 2019 16:02:07 -0800 Message-ID: Subject: Re: [PATCH] dma/debug: Fix dma vs cow-page collision detection To: Dan Williams Cc: Christoph Hellwig , Russell King , Don Dutile , stable@vger.kernel.org, Marek Szyprowski , Robin Murphy , LKML , linux-mm 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, Nov 19, 2019 at 9:49 AM Dan Williams wrote: > > The debug_dma_assert_idle() infrastructure was put in place to catch a > data corruption scenario first identified by the now defunct NET_DMA > receive offload feature. It caught cases where dma was in flight to a > stale page because the dma raced the cpu writing the page, and the cpu > write triggered cow_user_page(). > > However, the dma-debug tracking is overeager and also triggers in cases > where the dma device is reading from a page that is also undergoing > cow_user_page(). > > The fix proposed was originally posted in 2016, and Russell reported > "Yes, that seems to avoid the warning for me from an initial test", and > now Don is also reporting that this fix is addressing a similar false > positive report that he is seeing. > > Link: https://lore.kernel.org/r/CAPcyv4j8fWqwAaX5oCdg5atc+vmp57HoAGT6AfBFwaCiv0RbAQ@mail.gmail.com > Reported-by: Russell King > Reported-by: Don Dutile > Fixes: 0abdd7a81b7e ("dma-debug: introduce debug_dma_assert_idle()") > Cc: > Cc: Christoph Hellwig > Cc: Marek Szyprowski > Cc: Robin Murphy > Signed-off-by: Dan Williams > --- > kernel/dma/debug.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/dma/debug.c b/kernel/dma/debug.c > index 099002d84f46..11a6db53d193 100644 > --- a/kernel/dma/debug.c > +++ b/kernel/dma/debug.c > @@ -587,7 +587,7 @@ void debug_dma_assert_idle(struct page *page) > } > spin_unlock_irqrestore(&radix_lock, flags); > > - if (!entry) > + if (!entry || entry->direction != DMA_FROM_DEVICE) > return; > > cln = to_cacheline_number(entry); If I am understanding right DMA_TO_DEVICE is fine, but won't you also need to cover the DMA_BIDIRECTIONAL case since it is possible for a device to also write the memory in that case?