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 2D807C05027 for ; Mon, 23 Jan 2023 16:11:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BCB836B0073; Mon, 23 Jan 2023 11:11:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B7B916B0074; Mon, 23 Jan 2023 11:11:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A1CB06B0075; Mon, 23 Jan 2023 11:11:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 8E6106B0073 for ; Mon, 23 Jan 2023 11:11:18 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 6698F120818 for ; Mon, 23 Jan 2023 16:11:18 +0000 (UTC) X-FDA: 80386553436.02.A511242 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf26.hostedemail.com (Postfix) with ESMTP id 540A9140017 for ; Mon, 23 Jan 2023 16:11:16 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=OjaJjWOM; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=NGI+aSwt; spf=pass (imf26.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=1674490276; 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=8yYf8wXkZ38Zo4et7x7UJVytFRxZegivrpGgXCLUEzE=; b=F3fujnLyNwtws9BVJDTx/hGwxGQWN2vPGldQJBRqcYY4hDrfXKzEiPKjP4r6QDdFu3TJ2k UbQVlJCg8PkKlJdE5ZQAf0uqzIpSBKHGjIcM27NDJSfhVsp+R4lANkIG1h/KaCm3DiLP6h tuwRL7y5fLihlM4G6HrMUlhsB7FABt8= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=OjaJjWOM; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=NGI+aSwt; spf=pass (imf26.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=1674490276; a=rsa-sha256; cv=none; b=W/KORV47WELpsbShgDEIo9PH8PSjzE+O/Kd7Y3ccD73NhBdyME/fsPnsXqfiSJXrzF8JJ+ jjDBHMus+r059tgRPOh8ZsX1HZFW8pHPsBy9tptc4pyfzLsMhSa36l/AbJW3Gnm8ULsrcv mI2/QdKE1q7YiBAdDrxQ6oZWvxXIzaY= 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 03ED134142; Mon, 23 Jan 2023 16:11:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1674490275; 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=8yYf8wXkZ38Zo4et7x7UJVytFRxZegivrpGgXCLUEzE=; b=OjaJjWOMfa0hg31leW1LGDU+0Ur2Xa4pcr/1cTfws0QY+wjl28J7ppK3+B57yYzHMs11WR 1jEHwwpTNHF8LtxJ+SSOpZvDlYk5FW++u93lbPeW04mO0l25VquT9F+WaPJMnh/WQEzd9m Pa3pu7bpwaQGTb2Puu9WhSXQZTvOk/k= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1674490275; 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=8yYf8wXkZ38Zo4et7x7UJVytFRxZegivrpGgXCLUEzE=; b=NGI+aSwtmD7fxvxgKZD0kKf6SuwPMFO33eaGBuSv6+IzKQzxG/cDju0/uoVWrGKk5mUeJ1 yM7OxKxIcpbZG5DQ== 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 DF660134F5; Mon, 23 Jan 2023 16:11:14 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id kZOCNqKxzmMNbgAAMHmgww (envelope-from ); Mon, 23 Jan 2023 16:11:14 +0000 Received: by quack3.suse.cz (Postfix, from userid 1000) id 47543A06B5; Mon, 23 Jan 2023 17:11:14 +0100 (CET) Date: Mon, 23 Jan 2023 17:11:14 +0100 From: Jan Kara To: David Howells Cc: David Hildenbrand , Al Viro , Christoph Hellwig , Matthew Wilcox , Jens Axboe , Jan Kara , Jeff Layton , Logan Gunthorpe , linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, Christoph Hellwig , John Hubbard , linux-mm@kvack.org Subject: Re: [PATCH v7 2/8] iov_iter: Add a function to extract a page list from an iterator Message-ID: <20230123161114.4jv6hnnbckqyrurs@quack3> References: <7bbcccc9-6ebf-ffab-7425-2a12f217ba15@redhat.com> <246ba813-698b-8696-7f4d-400034a3380b@redhat.com> <20230120175556.3556978-1-dhowells@redhat.com> <20230120175556.3556978-3-dhowells@redhat.com> <3814749.1674474663@warthog.procyon.org.uk> <3903251.1674479992@warthog.procyon.org.uk> <3911637.1674481111@warthog.procyon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3911637.1674481111@warthog.procyon.org.uk> X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 540A9140017 X-Stat-Signature: sqtusfp4gu83qb6ietpbuq7dmrptb56g X-Rspam-User: X-HE-Tag: 1674490276-533699 X-HE-Meta: U2FsdGVkX183S+fpP6/OtEPPiOXTEXFawCUYOvkX8N3hEBwD2M0MC57hdRod7yX/fH7baXXIxr3KcvKUA2/wyZxOaeR9GQh6YfBOIjwcDyV3dYU2Egh0I8pzDeT/07NBBkCES6QeWNyowSvWhLZBkSc8y5agG2BjxKpb25NVZrMK+56mh1cC9636QckrnlWME8zzw1fARDJkLjZ/c5ntwraBFLCMWFGAUimiP/Cw4V+U9AgSTy+BXJY9ddJ3FgHQ0wPrUkm6PnYhfo07MIO7vkQVQ+Uxp7ZeSDC7wXllbEYcMeLq+/xakFDSpcSG2p50C1PWtB58EaC4POee9UUIGHUsLtj5f7A8wdkjnGfU79x8QlqyEeyMOpzrmpDFr+xlSQ2YPujXhhif7VPJEGbLPsy4wofXHObfvTyO2ulpDr2zpRVH55p8vqreMA1/MSxlvX9iJZYE5c9XXvHl28YC99S/NSw2UZ3Rdt29tQp7/3mgiWDzFwjSSSs+9qtwAdxTdMPPV4ux7QO4NE+buLrNe2jpwa3BxRETCzvcaMDV6POQCVq6VCxWrnvFUVKPzBUuDdset1GJIrsfFdk+Y+eUftkpQv5yjOlGkBEHDhyRR3u7TFkdrDcmK6n96wKrSKSe4Q5S392f4hjyFWt03lR8kEhp6eSylVSzD8Es/CPeCuppGk7jMenje6khHlH6ZDkk2lyrLMbf+lQjIXecxK7VhJKKZ7oge7pcADJxR2eP0cJ5J+1hj67xrdQ3LmicCYJatShssIlkHKAWZnIAp09T8S52I0A1Fa6PjXLJE43iq+HkUKBK++yIyzgLtVpedhxvn5+LsGnBxQidWlQ7DLtyV/bTv/wGntX8fHmf783T8jz6tQuW2U4FEF5hjKvhR0EQEm/LFFDLGOfaS3VtnE0EottCnKhwCrtapEI9XzRjiKd7UHBwrq0JpnHYqJVPGxlmdNHrThzrjUCeB8wKIbJ 8JtPpzDE onqv/M0IAXjOt4nFhsDTJAXFrDZx4ORTffMBP01PWbWTAAOzhus/B6UZLCULD0QRzpeZbcPoqGc2bWaunsr6GHff3DQRNsBP74WklGZVCF/3fmTW8RjCdjfH0Vimg6IMRHWYDuth/+B1/DI9co+42ZnO5gaHhlYebPag7b4SgQhkvzvith/fMKkt5xR2Jpdq+mgqs1KajDEgG6iKPxAcc/JhEkb7K2x1tdrXnNu2+cRN7aUtvCutfnpulN7BgWi9lPzwjLZ0rQQcCadKBLXhfDbUWp8le7aNo2Eu/Vrm8dBk4bNltG0Oz9Mein5uf/aYCiTvRoyd+hWWxAQk2ORNPvmBMtSogWEZiDb4MbmgEBlnJK+Vge5vBS2J79M/JLr6fuPkFM0ileDaUqIZlfEtcK0bOYQ== 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 23-01-23 13:38:31, David Howells wrote: > David Hildenbrand wrote: > > > That would be the ideal case: whenever intending to access page content, use > > FOLL_PIN instead of FOLL_GET. > > > > The issue that John was trying to sort out was that there are plenty of > > callsites that do a simple put_page() instead of calling > > unpin_user_page(). IIRC, handling that correctly in existing code -- what was > > pinned must be released via unpin_user_page() -- was the biggest workitem. > > > > Not sure how that relates to your work here (that's why I was asking): if you > > could avoid FOLL_GET, that would be great :) > > Well, it simplifies things a bit. > > I can make the new iov_iter_extract_pages() just do "pin" or "don't pin" and > do no ref-getting at all. Things can be converted over to "unpin the pages or > doing nothing" as they're converted over to using iov_iter_extract_pages() > from iov_iter_get_pages*(). > > The block bio code then only needs a single bit of state: pinned or not > pinned. I'm all for using only pin/unpin in the end. But you'd still need to handle the 'put' for the intermediate time when there are still FOLL_GET users of the bio infrastructure, wouldn't you? > For cifs RDMA, do I need to make it pass in FOLL_LONGTERM? And does that need > a special cleanup? FOLL_LONGTERM doesn't need a special cleanup AFAIK. It should be used whenever there isn't reasonably bound time after which the page is unpinned. So in case CIFS sets up RDMA and then it is up to userspace how long the RDMA is going to be running it should be using FOLL_LONGTERM. The thing is that pins can block e.g. truncate for DAX inodes and so longterm pins are not supported for DAX backed pages. Honza -- Jan Kara SUSE Labs, CR