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 A7D3FC61DA4 for ; Tue, 14 Feb 2023 13:56:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EE2766B0072; Tue, 14 Feb 2023 08:56:09 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E939D6B0073; Tue, 14 Feb 2023 08:56:09 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D33D06B0074; Tue, 14 Feb 2023 08:56:09 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id C16366B0072 for ; Tue, 14 Feb 2023 08:56:09 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 865D5C0CEF for ; Tue, 14 Feb 2023 13:56:09 +0000 (UTC) X-FDA: 80466046458.06.A29753E Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf22.hostedemail.com (Postfix) with ESMTP id 7BB28C0010 for ; Tue, 14 Feb 2023 13:56:06 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=1L1VOwSu; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=XqMBO5ML; spf=pass (imf22.hostedemail.com: domain of jack@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=jack@suse.cz; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1676382966; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=wEcL9ZqDcFReJTdiwk7aAbf7PWmErFH9naF5RkkLE+Y=; b=ZzrpKPcKoRAjjveWefBW7WAMZVt7Y6H2JdNl/KMST02dzRdeMIV5jUWhzBp2cgMQJzMSw8 5m9VRdq1jQIHN/3jHoDe2Krl0ci2xvrzdWu1RcVfGf7uvXhrn7riR6wixpNkWhgragKAfm mQI5YUyo5S9i0QwD28NXFjD1q3BLuXk= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=1L1VOwSu; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=XqMBO5ML; spf=pass (imf22.hostedemail.com: domain of jack@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=jack@suse.cz; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1676382966; a=rsa-sha256; cv=none; b=fIH9aP1rVvdSpNFT69dS6wKZ+SWZBiVUvYiXK6beZ6CAVRB6WFjLv0yALiFUQXACuSPchn 20TvTbQsFWMYu4BEasYH2AQ/57SQjc0tjDxWXTqQUS1yASzGzDFeiUP0JSKekYCdcNjZWS Nni/+jHjuTw/wA3hxFFkoC4z8Tx5yZM= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 168F31FE67; Tue, 14 Feb 2023 13:56:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1676382965; 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=wEcL9ZqDcFReJTdiwk7aAbf7PWmErFH9naF5RkkLE+Y=; b=1L1VOwSuTzy4sqE98fsLQ35bRFPl2Zkt0E1OhCPN0qVtEgYi5BC/ul/22EOcDbiA5pB4/A oPW6+TvceVbc9yypZDxV2L3m1wpsOT+nj5PYCHAzwyq6F4kyxPdIcYM/HVlgTRmtXrDzoN AmUXwmFa6ky1OyB6ys71AVwtfEsIyOk= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1676382965; 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=wEcL9ZqDcFReJTdiwk7aAbf7PWmErFH9naF5RkkLE+Y=; b=XqMBO5MLSMI5MJEF7FlkjGRdicMdFsJjbKPEeq7aYBVzx7OsKfrmUJWNfHbKWD4tC/1JWS cYzBTb3CtC/GQxDg== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 088EF138E3; Tue, 14 Feb 2023 13:56:05 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id h7ISAvWS62NHRAAAMHmgww (envelope-from ); Tue, 14 Feb 2023 13:56:05 +0000 Received: by quack3.suse.cz (Postfix, from userid 1000) id 9386FA06D8; Tue, 14 Feb 2023 14:56:04 +0100 (CET) Date: Tue, 14 Feb 2023 14:56:04 +0100 From: Jan Kara To: Christoph Hellwig Cc: Jan Kara , linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org, linux-mm@kvack.org, John Hubbard , David Howells , David Hildenbrand Subject: Re: [PATCH 4/5] block: Add support for bouncing pinned pages Message-ID: <20230214135604.s5bygnthq7an5eoo@quack3> References: <20230209121046.25360-1-jack@suse.cz> <20230209123206.3548-4-jack@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: if6y7o9c4qca8cwemr8zb77h446yd331 X-Rspam-User: X-Rspamd-Queue-Id: 7BB28C0010 X-Rspamd-Server: rspam06 X-HE-Tag: 1676382966-449805 X-HE-Meta: U2FsdGVkX1+B5tVAnl2IzKZeDVF62BQeRNMc8jHij8t3OnZlmNPVzGZTnVe//pws/I4eNDQGFd7/wmGzob3U9Cv92imHjJthiE0qKwdAKXYTn8qOtiq5CTHzb1zOW48Bkq5OYPq5ui/rU+53Qx+DKeg987X22iyqXMz8qsvNP/DbZdtjBHDQM0E7oHcdl8UH/VRReTuKyEoBPKJIpU6sn5AjfWlLd+KKwnhONYxriumfYDyr9I4OdQn+HiXPB3dBcNzbX8mWZ82QO6+CCfvC3MGJDpy0PO9vz9SIJDyVpF60xXoCngI/fopvihLbOSpJAg5PtmNKaZaF/Ko9gphBJMWiraqJVrxcBhkpi6N3qAe+oUsrQmHLChLPaP7a5cSaLidbpg7twRQKUErNvMqss+bwnUMk3OnLPq8cfroNbSHEtE5wBnsOANtVV2sghVNTW/bh6B29FuH1rc9OaVvAsa4eYlAAZvsw8xzZzjVMuz+nuse6/3uQ7P5tJCaaLBlcMoPLJJ5EoaAQQaioyphE8tAcWBrdnKzhXEb2KXb2gZTAl+g+Q0NUC8PF+TIYmG83bUSfzFWfzdLxLWKUMIZyHcraAYZB7PbFmgcSyDbUf+M4nSg8myuwvD89bgcNl2+ooMMIazprqt6qzuYzHKaeMmadfjcDuch/k8m3exVy32NUDm8Bqfmwk+qmCLE2SRUndisG3flapH48QrqaR+gl2d6jgqKS4t3NSFTk4CrbmEoYeqfU08ekiMZJnfjcLvKGPaPjHRyMvBOar39rVekb64IgeTflD3o4TcK4/jONIqnBBArrtjnB0gtH26mQutwHK1I0kX99U8cALdXdZouFhMeQ8H6LwVPwGYDT8kUgb6O040n4zv7s+iQKOQjfNRyEBNh51ZI/nRnzpa8ahoS4/Iwf8jx3yVpbf5GnnPWcV5a2F5OOcL0o94LNpQR75Uu0zwOtAYXwHYAnVpo4Hgz l17Mtkav doN1+j3ylbRYbmdIx5IpgvwV6QlPuTY/YaZ1tVfd6Ng9crhYhDT68+ejS2Mvx55TGJ9vm02/pT+TLfcPky869zmuXE3KnsPs/KahJHx3+Kf7taW2zjDb8txkfsCFLD9xzB3DwZBpkBI8x8F7fRkxlAmC+HSMiCpznUUGtNH7iHfMuCnWUe3Hii5y/3Gn9Rx4/8CgByxSJS/ZalHUajzs9Mqd0weJ949bdK3zGYMM3E7Mc/AzIrvBoLtORa9GmAyNd1ubUf3goop0VtZ4= 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 Mon 13-02-23 01:59:28, Christoph Hellwig wrote: > Eww. The block bounc code really needs to go away, so a new user > makes me very unhappy. > > But independent of that I don't think this is enough anyway. Just > copying the data out into a new page in the block layer doesn't solve > the problem that this page needs to be tracked as dirtied for fs > accounting. e.g. every time we write this copy it needs space allocated > for COW file systems. Right, I forgot about this in my RFC. My original plan was to not clear the dirty bit in clear_page_dirty_for_io() even for WB_SYNC_ALL writeback when we do writeback the page and perhaps indicate this in the return value of clear_page_dirty_for_io() so that the COW filesystem can keep tracking this page as dirty. > Which brings me back to if and when we do writeback for pinned page. > I don't think doing any I/O for short term pins like direct I/O > make sense. These pins are defined to be unpinned after I/O > completes, so we might as well just wait for the unpin instead of doing > anything complicated. Agreed. For short term pins we could just wait which should be quite simple (although there's some DoS potential of this behavior if somebody runs multiple processes that keep pinning some page with short term pins). > Long term pins are more troublesome, but I really wonder what the > defined semantics for data integrity writeback like fsync on them > is to start with as the content is very much undefined. Should > an fsync on a (partially) long term pinned file simplfy fail? It's > not like we can win in that scenario. Well, we have also cases like sync(2) so one would have to be careful with error propagation and I'm afraid there are enough programs out-there that treat any error return from fsync(2) as catastrophic so I suspect this could lead to some surprises. The case I'm most worried about is if some application sets up RDMA to an mmaped file, runs the transfer and waits for it to complete, doesn't bother to unpin the pages (keeps them for future transfers) and calls fsync(2) to make data stable on local storage. That does seem like quite sensible use and so far it works just fine. And not writing pages with fsync(2) would break such uses. Honza -- Jan Kara SUSE Labs, CR