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 9723DC61DA4 for ; Thu, 16 Feb 2023 12:33:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 26D856B0078; Thu, 16 Feb 2023 07:33:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 21D516B007B; Thu, 16 Feb 2023 07:33:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0E5D56B007D; Thu, 16 Feb 2023 07:33:21 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id F39356B0078 for ; Thu, 16 Feb 2023 07:33:20 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id B4E4480C82 for ; Thu, 16 Feb 2023 12:33:20 +0000 (UTC) X-FDA: 80473095360.27.6D97B3F Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf03.hostedemail.com (Postfix) with ESMTP id 9A3CB2000A for ; Thu, 16 Feb 2023 12:33:18 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=3Jd0JGXq; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=yqq9896s; spf=pass (imf03.hostedemail.com: domain of jack@suse.cz designates 195.135.220.28 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=1676550798; 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=EEFjBECoUujr76fxWPlosXBvyHr6ZjAdBgnYwY2gd0Y=; b=sSZba0Cs3eVCMLrLXH4nq3YVP5p/u33o4X8junvkurDDkFIcrtbKKWeJSY2Wqwei0eJEoB Nt38H0rhRn0B4ONjOn30JAo9S6RKilcW0ME+Ho1oaBc8fQ49XALIiSb2FQFBMAUUY4U2t8 0+zSS7BFO8D/9t4jjbquVdVTLdiYY/M= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=3Jd0JGXq; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=yqq9896s; spf=pass (imf03.hostedemail.com: domain of jack@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=jack@suse.cz; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1676550798; a=rsa-sha256; cv=none; b=l2s2yAKxaipgvPS2KPWAB4KQ27MKQi50UBJyW8mPuzu+pPmIezDclZLFpGfasOZJsA/DbF ukBlRQW6zrDbpIyDKDYdI2wlBKvgO1qlyYNpZDprS8UmKPIyFKS0MILvcisCKgDP0ODYjr ydrSAxB/bfcKOXK/W+plpHnSkDMgsUI= 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-out1.suse.de (Postfix) with ESMTPS id 46F69221DB; Thu, 16 Feb 2023 12:33:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1676550797; 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=EEFjBECoUujr76fxWPlosXBvyHr6ZjAdBgnYwY2gd0Y=; b=3Jd0JGXqKmv5jjbXISg82FCjUUIGOVSPlL7CSoQbAqsi6SXRqXVmHLvZ+yRT10XR7aVn9e m+eKkLOnxVHasKBWphBoKwopG/Ou/Nt9IGlHrLSRQg1GLw0Rxiz+DDCT8sSPs3Yi+bXQIT x05yX1rYbI8PxoI3NJ3KPa/9h8mVHQI= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1676550797; 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=EEFjBECoUujr76fxWPlosXBvyHr6ZjAdBgnYwY2gd0Y=; b=yqq9896s/+5dFzrTaV3DTo8raRXR9Y7PeTdFFzflOs3tTpkbMceClRulcHCNhECbh1dwMG hlA4lcTctUBKwNDw== 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 3AC0B131FD; Thu, 16 Feb 2023 12:33:17 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id UFxODo0i7mOzQwAAMHmgww (envelope-from ); Thu, 16 Feb 2023 12:33:17 +0000 Received: by quack3.suse.cz (Postfix, from userid 1000) id B50CEA06E1; Thu, 16 Feb 2023 13:33:16 +0100 (CET) Date: Thu, 16 Feb 2023 13:33:16 +0100 From: Jan Kara To: Christoph Hellwig Cc: Dave Chinner , 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: <20230216123316.vkmtucazg33vidzg@quack3> References: <20230209121046.25360-1-jack@suse.cz> <20230209123206.3548-4-jack@suse.cz> <20230214135604.s5bygnthq7an5eoo@quack3> <20230215045952.GF2825702@dread.disaster.area> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: yibcxsucsn3ticru6hiy6z4876q6d6q4 X-Rspamd-Queue-Id: 9A3CB2000A X-HE-Tag: 1676550798-785694 X-HE-Meta: U2FsdGVkX19880E2lSTIUQ8h3FUfJ6ll132M+n1eQECUOFalf1wpPZZpJNZjghvzyTRR6MVsQ33A1Z5UR6FZpmjbdjcRVTjrmzbJZuvDdBPhDVoho9hRhrziMLj6oQnmoEpsCsjX8V8SMD1hsnhbke6xRA0ZOShvEuESVJwIW+tNil2VD7EDYx+OM2pp6HHHj2LlSoT0qWzPLQdyMHeaEsWPuSO5TCBM2Dxu1W/YmLSyr4vIrSIJpFBUas9yHW6LZHooBeHd3/VoRou+IKnfrXSpGQQJfP9vYtB/q3YPQFlhaUT7ANWXM1kJpbaDMk0M1v+yk7DaDSfs0pwHU/naIklk4tMp0LDBJRY6qJMNWjKUYzZLrR/cU5vTNuMOs7m4ezoDZbrQEOy4zOzbjzejXOmIC7MTDLgH5rKwaNgUOMlK0mHwzO7R/I0qLPytF4xxDWBjLH/pUZFds8YPB6B1IpA7Cz73JUkyyJg4zDk0ZQBQCtdofPEOS09mDeGLJIsZTcPn7w4jIFDseRU4RFoR07IieQLRfypux3yNm1KEON6n8neODeETgNOXXnECPNZd++z6aeGSSBnnIMShdRj/XvTk6oKvUNj4Uvl1hoPC/yDfDWG3xWlLbIS1CNyIS8LoaKL9BojSJNgRxWFo6VmQbTJp1+FQMFN9dNmRly8iIyIHsOCSN+y4ZE2bxa+OYYHAdh6GFpJB4p2K7+EREYgExSFN4RKJUZ9f/uSdneFg244z+VDfrzMmzv0x8Zygqbq8Rkj4FIg5ptbNgWSfGCYNBGVDqkSgtKVekqc+l4De85eRjwdM2br7QmXcVr1akdXWy8LqSBv0tEEVnkzzKJcZufcgfKuVPh8Y+LSAX9fIskFWclgBY05z5TPuJU7/PdsHdHZ7gDzOCQTNbdk6X4pSA6xP6Cz7Oit3CTuNA7CLIZxV6IJuVZFKwsCN0b+CrTGwqhw+Dvo+IKPJADZFPV+ lGwYjtc5 SSNpoxsX0NO5N4kzvF3h5cBqHYqzQia/v1ekd96ywkFKfDOaqCIRdxsBqPMK0CPLlWHfYsW3ABYKKq6AdEVXqr5v4t8ibxkyVeqWv2qR+zghqdXfLPGluf/6SYYhiycu+OfDMAEeE35jQ1o3DjwIT1xp/HaweeUkovScjnCaQ1E3GSzahPS87KVW8pt0EyzdxCL4FDXKm7vkpxj2fy6rvJMXRpAZf8pjCZkV1NSRXz7SNDazZS9xSOy/yIIFxWI6scmaD7nCWo1irRBI= 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 14-02-23 22:24:33, Christoph Hellwig wrote: > On Wed, Feb 15, 2023 at 03:59:52PM +1100, Dave Chinner wrote: > > I don't think this works, especially if the COW mechanism relies on > > delayed allocation to prevent ENOSPC during writeback. That is, we > > need a write() or page fault (to run ->page_mkwrite()) after every > > call to folio_clear_dirty_for_io() in the writeback path to ensure > > that new space is reserved for the allocation that will occur > > during a future writeback of that page. > > > > Hence we can't just leave the page dirty on COW filesystems - it has > > to go through a clean state so that the clean->dirty event can be > > gated on gaining the space reservation that allows it to be written > > back again. > > Exactly. Although if we really want we could do the redirtying without > formally moving to a clean state, but it certainly would require special > new code to the same steps as if we were redirtying. Yes. > Which is another reason why I'd prefer to avoid all that if we can. > For that we probably need an inventory of what long term pins we have > in the kernel tree that can and do operate on shared file mappings, > and what kind of I/O semantics they expect. I'm a bit skeptical we can reasonably assess that (as much as I would love to just not write these pages and be done with it) because a lot of FOLL_LONGTERM users just pin passed userspace address range, then allow userspace to manipulate it with other operations, and finally unpin it with another call. Who knows whether shared pagecache pages are passed in and what userspace is doing with them while they are pinned? We have stuff like io_uring using FOLL_LONGTERM for IO buffers passed from userspace (e.g. IORING_REGISTER_BUFFERS operation), we have V4L2 which similarly pins buffers for video processing (and I vaguely remember one bugreport due to some phone passing shared file pages there to acquire screenshots from a webcam), and we have various infiniband drivers doing this (not all of them are using FOLL_LONGTERM but they should AFAICS). We even have vmsplice(2) that should be arguably using pinning with FOLL_LONGTERM (at least that's the plan AFAIK) and not writing such pages would IMO provide an interesting attack vector... Honza -- Jan Kara SUSE Labs, CR