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 18B2DC47DB3 for ; Mon, 29 Jan 2024 16:04:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9A8046B0087; Mon, 29 Jan 2024 11:04:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 956C76B0088; Mon, 29 Jan 2024 11:04:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 845456B0089; Mon, 29 Jan 2024 11:04:31 -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 77AEE6B0087 for ; Mon, 29 Jan 2024 11:04:31 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id E7730120A88 for ; Mon, 29 Jan 2024 16:04:30 +0000 (UTC) X-FDA: 81732821100.30.DDFDF6F Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by imf24.hostedemail.com (Postfix) with ESMTP id C557618001D for ; Mon, 29 Jan 2024 16:04:27 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf24.hostedemail.com: domain of hch@lst.de designates 213.95.11.211 as permitted sender) smtp.mailfrom=hch@lst.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706544268; 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; bh=U1dO38ZTKHLjuVdXX2dLG+jlYmcq738YGrIac2vGqq4=; b=DQSeoFAIPAP173zq4bqVdmZKFKpPx9eB/XBGx8F1u5/PBDovi71iH/3y6mDL2Fma1dMbJU iOaXUi0YdRwzgXwpjcVAA/jQVP1WQFiYgTtlGQE3ip/3lPM+gWZN1wTU31juWqwzniWo9V 8q7DyIBLpvC1WUr22DfI7h9N76bbFaY= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf24.hostedemail.com: domain of hch@lst.de designates 213.95.11.211 as permitted sender) smtp.mailfrom=hch@lst.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706544268; a=rsa-sha256; cv=none; b=Cb3aWXHw3nh1FX2qgj73zRBkbbWPv1drjmg5UVPGLsu3rlj6jeYBgtKbnQ3ZYat+BmKyDm nvgsQ++qHHs2ILMNmAtFp5OQctJ+K35vzGysdkPVPm3sS2KqvBKcRHUZdWAWlKCh88NKos IgjIo8O+c3gbepWHHDyTbCzMT0rdiFM= Received: by verein.lst.de (Postfix, from userid 2407) id 4E4CC227A8E; Mon, 29 Jan 2024 17:04:22 +0100 (CET) Date: Mon, 29 Jan 2024 17:04:21 +0100 From: Christoph Hellwig To: Matthew Wilcox Cc: Christoph Hellwig , Chandan Babu R , "Darrick J. Wong" , Hugh Dickins , Andrew Morton , linux-xfs@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 07/21] shmem: document how to "persist" data when using shmem_*file_setup Message-ID: <20240129160421.GA3082@lst.de> References: <20240126132903.2700077-1-hch@lst.de> <20240126132903.2700077-8-hch@lst.de> <20240128165434.GA5605@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: C557618001D X-Stat-Signature: wtcwg3cc8mgq58f96fjpzf96n5zpbg4i X-Rspam-User: X-HE-Tag: 1706544267-206993 X-HE-Meta: U2FsdGVkX1+ARhHKMhiP3DH9Cm2NrnTNBQOv/vZZuBFP34Ul0aycXsLYKmwIjQGDmr+b2MzCqaJLOuqDlD1hvcdTVJuYrbSuMbAi6KjtYD30xAB5HYnPR2Q5lrim9wNd96rQ/kQz26FaRoESguwjDnrtrdKVsnjtlKAtsv5GTiuqabvnRakUpv1Xz3e1Qv41Vlw+KJ1N8xAUu6AU5PkMAp7zSfY3JD9y7yS3KkH0WBlu7m362AOoMdnD5KTAHP08pxxGjsG0BiFxoKE1tbVbts+aB0YM/nVStRAzgY1Cw3538NTeBgHFQeEx11YKh/6sMmTRMLfaEx2mWVhdwfDdLGLTP4BfjJxVD3Mh+wofh0q3n+UWkaZdMx6x9lBtV1Qgc3KNfWE2Gjbhh4Qri/kBSJKW8dlNoMcSmfsroQbUyI//MxapfLmgAU9WJHclPkYvwbml58KK0UAMhLYIlb4SA2MTm2iddDAFO/524684kkUBTrEVkQFVA7Hco6ThM/S0adwFXUilPr2Nazoxn6ArtwMfNlZIIOQeswqjH6xlgjd2OcQxMEupl5e7deKsWghhYebypdl1ETAtFDHsxD5+EQeXc2CspTsOsd9N6qvria8NspKP0uNjJOIKxxxFgv4DYbmatLA4L7kqYAN6PDlwTGIEFQzHW8Cq9c4EVLR9fheBiByjy+hPlbqdJ3bhtBAC1r/Ho6bvtFQ6O4dkExfaWDfGrgwsdkaQ2nnH1Lh0SEfJiBjLjWIY+YyrZFkNO+8VYjhZxxt3+HzGs21dRrjXcTK69BS6OsRVlkkVRCwpZdwKKWgIIK8TowBJLVUpqFwmhrG+vGBV5kkXGEGAxi81tyVrVCi6XPE9DtA3H5W8FSYNgLqy4u6N+ukhd6/WrAhNKtnmuknHYknZ2DDK6utolWwa2k73Gxu51ddGtll3sQUaz7dRZHaVXaVzaFwkfTqQvPH67F5+FJalMgWi8r2 hmGs4LwK 4xjXwuC8qOTU0isTykJ3bze5HQjBYHKaSnm+ghgFRm71cyfBYV6GNKR+iXPf6sQcvdYZ62w6uBEDuD17OBmbS0xEA59RWgs9N9pFA7gKVXBwCXDI= 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: List-Subscribe: List-Unsubscribe: On Mon, Jan 29, 2024 at 03:56:58PM +0000, Matthew Wilcox wrote: > Could I trouble you to elaborate on what you'd like to see a filesystem > like ubifs do to replace write_begin/write_end? After my recent patches, > those are the only places in ubifs that have a struct page reference. > I've been holding off on converting those and writepage because we have > plans to eliminate them, but I'm not sure how much longer we can hold off. I think the abstraction is okay for anyone using generic_perform_write. The problem with them is that they are not generic operations called by higher level code, but callbacks that depend on caller context. So in perfect world they would be passed directly to generic_perform_write and the few other users and not go through aops.