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 55BCCC47DB3 for ; Mon, 29 Jan 2024 15:57:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AD7AD8D0002; Mon, 29 Jan 2024 10:57:09 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A88368D0001; Mon, 29 Jan 2024 10:57:09 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 979218D0002; Mon, 29 Jan 2024 10:57:09 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 8538F8D0001 for ; Mon, 29 Jan 2024 10:57:09 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 3BAA0C09EA for ; Mon, 29 Jan 2024 15:57:09 +0000 (UTC) X-FDA: 81732802578.12.C8EF8D3 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf27.hostedemail.com (Postfix) with ESMTP id BD1A940005 for ; Mon, 29 Jan 2024 15:57:05 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=aR5nwxXD; spf=none (imf27.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706543826; 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=9Zvh4vkcliPtNLV0y1qfHG2/fyuPefQiACwDTXEpBpo=; b=UsAW9vGlco2EoXxbJMW7h+GSM4MneGyg6OSx6l90NfClrqyrzmDK+4uZVMyU8LvQ6BY5Bl ZvK/JPajLUGkXcfRf+ISIC405AMV5HXCRb4ePjavfCeFPs/zsLbAVey3o/k2pIfqMdHKow hR4ZFuAi+Qli55JMUoQvIFTA0NK2CKo= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=aR5nwxXD; spf=none (imf27.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706543826; a=rsa-sha256; cv=none; b=Y0hBwpQmx16pjGBz+SqFtQcVp6UFPnsBjhHHO2rXOfSSSXJ8+nisEnauu2Wbundpf6k86W LI2orcxdHiOjOYnFni2vVs3Cp5korxLh8AZjX+CVos29YZK7MmScqfFa/VqoMc6hHsWyjc ErT00e7fxCK4OjX/4ImKWOErAV/0V0s= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=9Zvh4vkcliPtNLV0y1qfHG2/fyuPefQiACwDTXEpBpo=; b=aR5nwxXDHasiCj89zb9QYCYzrZ VARb9r5RmuuKpmP1n10WgP2j3VPRSHHsx9ZdTWhosSILb7Ty85vMMV7JMpDuRuT3/beUr/TX7mzlS VuA5ccydrzjAEm5JXJQhSrwItMLNiPeFY474jGV2CwGGBY4FegPW2csiCrB+BLbdr1qbtcRTjJWIf +cjV1PEMNdEWqdvbu46xVtlNlqKOgN/bCJ6X1oQhXWRk+/S//Yd1H52Dr7K8IZlOXF/bmpS9QYAjp XO7POuUNNsGbs9KOZD1JOu9O6kBealfsLLGpJs1OowF9B7iBfe/YTRNn6s+QsDIPe6qDxpSWfC44X qXLwL1ww==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rUU0J-000000072J1-02z5; Mon, 29 Jan 2024 15:56:59 +0000 Date: Mon, 29 Jan 2024 15:56:58 +0000 From: Matthew Wilcox To: Christoph Hellwig Cc: 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: 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: <20240128165434.GA5605@lst.de> X-Rspamd-Queue-Id: BD1A940005 X-Rspam-User: X-Stat-Signature: uu375ofdtcgqd9ho1kziq4eas9jm5skn X-Rspamd-Server: rspam01 X-HE-Tag: 1706543825-572933 X-HE-Meta: U2FsdGVkX1/Q1pFTkmO/6Xsu1Xpr/mSGJXB07wKvtWPIIIngX/pdnJYtFY+k4QZq9cVEjmm5VQ0zLVJZW/C+VPrPIQzIYApXZMCQ/MrHVrh0ENicejcd5iBslSY4OR7V/Ip0JbIh9EwMcNySRjANCn0D4ZS9rMNSJ5QC/NR7RfmnxUgJhnHyXhjxTMcPxNhbX4alhEFWC2UtFDU25eahVBja3nWhj8lNsrW9x6DgZHS6pW6vY4Kuv+sGSUpNY1mDoErR4q23YO8xt+Df4l8BnF/nxEGdZDhSHaBS/iPn8OoyWPngehTMY7SjP9ItdbhTwqiIZL1aKWqpXAoMbGwBr2nVJjs06726HftscUsXYnZgqgpEoImks+eor4HSdl/1uJYGmBE3diaeYtqRUQ2GmhJPZG5T69v1a2TNvBUJQUpQczP1n2MDp2wB6p9YUZNXTlpkYx+AYBG7uBKO9z6UdUgHChE73albquic4rIRXRso9IdZGkElOOKj7ny5KNBUqKYZgj0rqkyBywDw3zazxBJhe2IzCRE5A2/ZAa/3L9ylD2lM3xIR3d1tI+GUQun2HPauFye1VdijTIM6eIU8JPHVz8wTSU4n0pur6O9RCQWqA9IPwMari+UgKFZSchGko586a4Rfd/mtcmAako3y7boSyU5vy7DpF4uMnFArnSEHTh4VVcS/cU9V9IEtP5VT4b/Frf/BdqIQxH0tvOUVJAfQ2WosLgFnCh3l3BOpHIwhYoqiGSP2fJ4LbyzhU7yw8w5QEvSbsUfswu3belVR0FWxxt0Fv3qsqwohsOjwJFJf9qkTG73873y1c8kfu++TtXV1b8pOXICFpdkqkrhguzMB+204tc951tqX/+QKv/Kn6UhQuB7zFmvlHboA3fBtSJiW5oo6CUv5V8eqVI7l/3wUEmM0ewA9vDJsABHcfhL9B2qHsAV1FOP3UjWL18mXlJbLLwz4eDpMoi8zNa1 VagTc1uF xpph9pehpm265KxZhEuTReZDH379A6pRpK8KnOUkQh4LgmHB982PBWDNOP/sqbFZ1fhJi8lPwHredQrNa9ajfLLeyAjEbOxToZMT/+p1SPPWsC8URHDxNuwslwP66sAPnUaj2S+ojMCa9cqd2+3dKak2thfTD2yTKbFrxI35ou5kkxpC/sBB8NHNJHQ== 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 Sun, Jan 28, 2024 at 05:54:34PM +0100, Christoph Hellwig wrote: > On Fri, Jan 26, 2024 at 03:49:30PM +0000, Matthew Wilcox wrote: > > This doesn't quite make sense to me. Do you mean: > > > > * If the caller modifies data in the folio, it must call folio_mark_dirty() > > * before unlocking the folio to ensure that the folio is not reclaimed. > > * There is no equivalent to write_begin/write_end for shmem. > > > > (also this should go before the Return: section; the return section > > should be the last thing in the kernel-doc) > > So the first sentence and moving the section makes total sense. > The second sentence I don't think is very useful. write_begin/write_end > are relaly just a way for generic_perform_write to do the space > reservation and extending i_size and not really methods in the classic > sense. They should go away from a_ops and certainly don't end up > being mentioned in shmem.c. > > What I have now is this: > > If the caller modifies data in the folio, it must call folio_mark_dirty() > before unlocking the folio to ensure that the folio is not reclaimed. > These is no need to reserve space before calling folio_mark_dirty(). That's totally fine with me. 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.