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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9EFBAC433F5 for ; Mon, 10 Jan 2022 15:22:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 300F66B0074; Mon, 10 Jan 2022 10:22:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2AED36B0075; Mon, 10 Jan 2022 10:22:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 177106B0078; Mon, 10 Jan 2022 10:22:14 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0233.hostedemail.com [216.40.44.233]) by kanga.kvack.org (Postfix) with ESMTP id 0A5196B0074 for ; Mon, 10 Jan 2022 10:22:14 -0500 (EST) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id A981A95C8F for ; Mon, 10 Jan 2022 15:22:13 +0000 (UTC) X-FDA: 79014743346.18.FDCD8E7 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf05.hostedemail.com (Postfix) with ESMTP id 59506100007 for ; Mon, 10 Jan 2022 15:22:09 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id A6AFF210FF; Mon, 10 Jan 2022 15:22:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1641828128; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=1D0a4aFBcd1E+zPNc9OdjFosbM1C+imloqeoLZ8LxXw=; b=LxdrJZcQZvutS3jC2F1mPD8Gt9PzokHQ3VmTz31vdqa/o5Tjh7gB+YgrL3wwXgUYyuYEdf YeDxg1pad6Y+RTxWC5eKgsgvGJHRHOsmd8TbOYQ1+qf+TowE4LvYouVCFU94VgVAeBeN+T 9uP96v9dp4xnNaj84LaTr5G7oKh6AFU= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1641828128; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=1D0a4aFBcd1E+zPNc9OdjFosbM1C+imloqeoLZ8LxXw=; b=U/3q/J8SKm8cEsj9KSqt/CK7f0vnrD8l0goATB0mZQclWAbUu9iJC6jEPN47L7KN1m9iVl u09+EGj/6uSmonAA== Received: from quack3.suse.cz (unknown [10.100.224.230]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 93B04A3B83; Mon, 10 Jan 2022 15:22:08 +0000 (UTC) Received: by quack3.suse.cz (Postfix, from userid 1000) id 53777A05B4; Mon, 10 Jan 2022 16:22:08 +0100 (CET) Date: Mon, 10 Jan 2022 16:22:08 +0100 From: Jan Kara To: John Hubbard Cc: Matthew Wilcox , linux-mm@kvack.org, Andrew Morton , Christoph Hellwig , Jan Kara Subject: Re: [PATCH 14/17] gup: Convert for_each_compound_head() to gup_for_each_folio() Message-ID: <20220110152208.w3tj5hjnbwjd6n2l@quack3.lan> References: <20220102215729.2943705-1-willy@infradead.org> <20220102215729.2943705-15-willy@infradead.org> <20c2d9d3-bbbe-2f11-f6bf-a0e3578c6a71@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20c2d9d3-bbbe-2f11-f6bf-a0e3578c6a71@nvidia.com> Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=LxdrJZcQ; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b="U/3q/J8S"; dmarc=none; spf=pass (imf05.hostedemail.com: domain of jack@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=jack@suse.cz X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 59506100007 X-Stat-Signature: 78xbyea5q7gqa83qojg9bfre1b8cfj9b X-HE-Tag: 1641828129-753231 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 Sun 09-01-22 00:01:49, John Hubbard wrote: > On 1/8/22 20:39, Matthew Wilcox wrote: > > On Wed, Jan 05, 2022 at 12:17:46AM -0800, John Hubbard wrote: > > > > + if (!folio_test_dirty(folio)) { > > > > + folio_lock(folio); > > > > + folio_mark_dirty(folio); > > > > + folio_unlock(folio); > > > > > > At some point, maybe even here, I suspect that creating the folio > > > version of set_page_dirty_lock() would help. I'm sure you have > > > a better feel for whether it helps, after doing all of this conversion > > > work, but it just sort of jumped out at me as surprising to see it > > > in this form. > > > > I really hate set_page_dirty_lock(). It smacks of "there is a locking > > rule here which we're violating, so we'll just take the lock to fix it" > > without understanding why there's a locking problem here. > > > > As far as I can tell, originally, the intent was that you would lock > > the page before modifying any of the data in the page. ie you would > > do: > > > > gup() > > lock_page() > > addr = kmap_page() > > *addr = 1; > > kunmap_page() > > set_page_dirty() > > unlock_page() > > put_page() > > > > and that would prevent races between modifying the page and (starting) > > writeback, not to mention truncate() and various other operations. > > > > Clearly we can't do that for DMA-pinned pages. There's only one lock > > bit. But do we even need to take the lock if we have the page pinned? > > What are we protecting against? > > This is a fun question, because you're asking it at a point when the > overall problem remains unsolved. That is, the interaction between > file-backed pages and gup/pup is still completely broken. > > And I don't have an answer for you: it does seem like lock_page() is > completely pointless here. Looking back, there are some 25 callers of > unpin_user_pages_dirty_lock(), and during all those patch reviews, no > one noticed this point! I'd say it is underdocumented but not obviously pointless :) AFAIR (and Christoph or Andrew may well correct me) the page lock in set_page_dirty_lock() is there to protect metadata associated with the page through page->private. Otherwise truncate could free these (e.g. block_invalidatepage()) while ->set_page_dirty() callback (e.g. __set_page_dirty_buffers()) works on this metadata. Honza -- Jan Kara SUSE Labs, CR