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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 41386C2D0BF for ; Tue, 10 Dec 2019 10:20:06 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id EBE4D2053B for ; Tue, 10 Dec 2019 10:20:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EBE4D2053B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 47XGK004xBzDqXY for ; Tue, 10 Dec 2019 21:20:04 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=suse.cz (client-ip=195.135.220.15; helo=mx1.suse.de; envelope-from=jack@suse.cz; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=suse.cz Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 47XGGN55DKzDqXv for ; Tue, 10 Dec 2019 21:17:47 +1100 (AEDT) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 99CB6AD4A; Tue, 10 Dec 2019 10:17:42 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 8681F1E0B23; Tue, 10 Dec 2019 11:17:38 +0100 (CET) Date: Tue, 10 Dec 2019 11:17:38 +0100 From: Jan Kara To: Andrew Morton Subject: Re: [PATCH v8 17/26] media/v4l2-core: set pages dirty upon releasing DMA buffers Message-ID: <20191210101738.GE1551@quack2.suse.cz> References: <20191209225344.99740-1-jhubbard@nvidia.com> <20191209225344.99740-18-jhubbard@nvidia.com> <20191209165627.bf657cb8fdf660e8f91e966c@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191209165627.bf657cb8fdf660e8f91e966c@linux-foundation.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Michal Hocko , Jan Kara , kvm@vger.kernel.org, linux-doc@vger.kernel.org, David Airlie , Dave Chinner , dri-devel@lists.freedesktop.org, LKML , linux-mm@kvack.org, Paul Mackerras , linux-kselftest@vger.kernel.org, Ira Weiny , Christoph Hellwig , Jonathan Corbet , linux-rdma@vger.kernel.org, Christoph Hellwig , Jason Gunthorpe , Vlastimil Babka , =?iso-8859-1?Q?Bj=F6rn_T=F6pel?= , linux-media@vger.kernel.org, Shuah Khan , John Hubbard , linux-block@vger.kernel.org, Hans Verkuil , =?iso-8859-1?B?Suly9G1l?= Glisse , Al Viro , Dan Williams , Mauro Carvalho Chehab , Magnus Karlsson , Jens Axboe , netdev@vger.kernel.org, Alex Williamson , stable@vger.kernel.org, Daniel Vetter , linux-fsdevel@vger.kernel.org, bpf@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, "David S . Miller" , Mike Kravetz Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Mon 09-12-19 16:56:27, Andrew Morton wrote: > On Mon, 9 Dec 2019 14:53:35 -0800 John Hubbard wrote: > > > After DMA is complete, and the device and CPU caches are synchronized, > > it's still required to mark the CPU pages as dirty, if the data was > > coming from the device. However, this driver was just issuing a > > bare put_page() call, without any set_page_dirty*() call. > > > > Fix the problem, by calling set_page_dirty_lock() if the CPU pages > > were potentially receiving data from the device. > > > > Reviewed-by: Christoph Hellwig > > Acked-by: Hans Verkuil > > Cc: Mauro Carvalho Chehab > > Cc: > > What are the user-visible effects of this change? Presumably loss of captured video data if the page writeback hits in the wrong moment (i.e., after the page was faulted in but before the video HW stored data in the page) and the page then gets evicted from the page cache. Honza -- Jan Kara SUSE Labs, CR