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 B887AC4332F for ; Tue, 14 Nov 2023 17:29:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 52DF26B02F6; Tue, 14 Nov 2023 12:29:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4DCE06B02FA; Tue, 14 Nov 2023 12:29:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 37D5E6B02FE; Tue, 14 Nov 2023 12:29:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 25FE76B02F6 for ; Tue, 14 Nov 2023 12:29:27 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id F0E971A0121 for ; Tue, 14 Nov 2023 17:29:26 +0000 (UTC) X-FDA: 81457246332.01.A2AAB01 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf23.hostedemail.com (Postfix) with ESMTP id A3C4B140015 for ; Tue, 14 Nov 2023 17:29:24 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=VKdyNlcT; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf23.hostedemail.com: domain of brauner@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=brauner@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1699982965; 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=WZ/godwacIByQIRBET/EDRREFgRaxV6D8tASyRth+8E=; b=8Cjv/+M+iCXMGjhEEVlWTdBLYLkMQqkQthI5SYpCKVLvH5HmCMDB0exCIIiASas+sS7QhW oMDyD5jmvfwn9X2c4ZPxTyqgPQrJw4vdQ5OcU73Z3QnZLi6Mz5ASd3sSFiZTEG7HGHNR1+ OJyXjGdKHfOsIT+1GaqBYRjPx0yAiiw= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=VKdyNlcT; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf23.hostedemail.com: domain of brauner@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=brauner@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1699982965; a=rsa-sha256; cv=none; b=FYyTnbgRAG9NUtQ6J3snN4intcgcNyl+V4MkL1VWvbAsp1zn0vpWRaadX2gv/PHSxe65sb bxaBVdMRh754rOd80+rB53HnP+n9Lq6EQE7v5YbWr/0xqFcrve2sxTd1H24PbvkbC+WuYV uuSuzLTpCiKBlBdVz6X83plOBtr9KnE= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 9699CCE12A6; Tue, 14 Nov 2023 17:29:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A2874C433C7; Tue, 14 Nov 2023 17:29:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1699982959; bh=g39laiWffI3DPXTx8JHtLQmGV3Kz98YnU4YPFc8UTHc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=VKdyNlcTEbGiW44XiD6StyaS5EvLwTQVS92gDTAHAOaDjDkkwOEDPjx07zrtEn6vf 2PFW6GzaFtgfmLdzO7xbZx8OBIbHTsan93wZjMT8cQc3Q514yHN1FKlN9sNwLOqPAe zgcVc1bq6bGpSXkAJdcSh0Hnt6JyTG/mTUWxmk8Me2AlEuK4vDR/9GX5VGRCFJKyUs OUlr7bmgQFu9CCSszigWf8GQmKlJRxhaCT/ilsfUTSIlmqUiAZihY0QBsyHbSTPH/v /W84IRGBgZwK9WfpXtfEBHgXl3GrIsuTrAd45tx49FXnC3GQWd8PMYdDMF60jBrREW ETTnSIc+SL6Xw== Date: Tue, 14 Nov 2023 18:29:15 +0100 From: Christian Brauner To: Chuck Lever Cc: akpm@linux-foundation.org, hughd@google.com, jlayton@redhat.com, viro@zeniv.linux.org.uk, Tavian Barnes , Chuck Lever , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH RFC] libfs: getdents() should return 0 after reaching EOD Message-ID: <20231114-begleichen-miniatur-3c3a02862c4c@brauner> References: <169997697704.4588.14555611205729567800.stgit@bazille.1015granger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <169997697704.4588.14555611205729567800.stgit@bazille.1015granger.net> X-Rspamd-Queue-Id: A3C4B140015 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: mjonwuxj9t9wh7gpb4afiawxbqwmzyfg X-HE-Tag: 1699982964-348473 X-HE-Meta: U2FsdGVkX18Zde0VniHdcdUbVqd6Q1Dwj8DLRgHAaXDhfOGE1M+cgHhpeR1flOekdbU6mzqV9/+Y7PRL0bZq8mpKwLPgYsvRyj/awL+NX5EZMQngI6nUinN5gYe7ZKVyT5CXTGMTesmzTFMhXSc3L/rdvP0eeNwCNYXZpb7Ls+GcHw2jZDR+i05CmlwxYt3P70nVWuy0pzqP3eiBJ5JO7BZiXjSxyIroO7kIEBbROG/OnELW4PGwJBf0YrKJaehvrl8Www7/Ui3dfaDLz5ZIKkj11wwz8df7nrMB1wCPX+Rbpm3ggSWGNeIG/UxMw3jn3u7PcxFrE/O00UlM7zEAO8zSEE/9AK37gkJ1ckepD0cMpn8bk9EofmBD3Xek2qPjTsLHpTs3AD3HLqJKHhRahGVdC7149xr/b0WHO2SpCJoQ9wF24tKUgssSfs/gI76NzBGqQ2NZyo7hfDMiSjB2KjX9ZERUxOqo53ybXg6sfN4tBk+7i4EgmOZQunnTV58TPf6bwY1IRowwMxe3prC6xjYaOgGaM1O8IOvawRUIF7HCsVlOVE4lV8q5aUNV+7jlxXBvsoui+M6qDax/ckTIDL8P1gtXihkploepwOewj6FY55rv5G/f3sbaOvrekmZyPYAgopMcUEhBUt/VuS/6kS47LEesNbNw4u/KsoG8d8sr5I25b16JePdNIDc6FzBXqhfHv2PD0LPaZHvqY0RrqA1HkSXQ0OxpYC0hx0aapCyP8iD1lhyJ8J+fHdq3+43xxb1AAirFgxvtvOQ61M+qF3PnPwRTBat/mjvyowMFOM+8JHWR6DaJ+zOxxJ5jkKtvuLluGoTrqRvyegUzy6urE/ZUpZh+/Ejw8Vdy7zrdu91H1+q6La1iFJe8JJ7oWFWxb4OND/BXV8clAmJqrEGTTNVtY2sIv2KpwRMR4zoP6ZSpVO3CTFbuuU9NCUHRhpRnxe6wXBA5eqKpidp3SzX fGWSxBub RN3qfeg/pipkgi3dthdCP8LEhInUUcIsszv4hx8SMLte18hxA7CP8xLQcOW4A4n8pI2Yj7PAQlZLHeu3naF3PdiSPUTnXxLqYYaVR6tcZhZpvJt1c0KtZBUXLt0nEr9CHM2bl/Rr+wkixrY5L7e5kGGSq5DzW7VTzkaWBPxBEYZ1maX9x6GHFELSXfR6QtzVqFxbw9wunlgEEyS3mxEiUqrxfivGUrTgLipqEOWanjaZ6GsP2n5BApBvprsiSSTHKOoNPTNVOd40ueJubnA6Eq0KitT11zXJA4jzW4/rclPfDKx+4xylAuCkHvOWj+baV7/jrCdKjdu+gYcs= 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 Tue, Nov 14, 2023 at 10:49:37AM -0500, Chuck Lever wrote: > From: Chuck Lever > > The new directory offset helpers don't conform with the convention > of getdents() returning no more entries once a directory file > descriptor has reached the current end-of-directory. > > To address this, copy the logic from dcache_readdir() to mark the > open directory file descriptor once EOD has been reached. Rewinding > resets the mark. > > Reported-by: Tavian Barnes > Closes: https://lore.kernel.org/linux-fsdevel/20231113180616.2831430-1-tavianator@tavianator.com/ > Fixes: 6faddda69f62 ("libfs: Add directory operations for stable offsets") > Signed-off-by: Chuck Lever > --- > fs/libfs.c | 13 ++++++++++--- > 1 file changed, 10 insertions(+), 3 deletions(-) > > diff --git a/fs/libfs.c b/fs/libfs.c > index e9440d55073c..1c866b087f0c 100644 > --- a/fs/libfs.c > +++ b/fs/libfs.c > @@ -428,7 +428,7 @@ static bool offset_dir_emit(struct dir_context *ctx, struct dentry *dentry) > inode->i_ino, fs_umode_to_dtype(inode->i_mode)); > } > > -static void offset_iterate_dir(struct inode *inode, struct dir_context *ctx) > +static void *offset_iterate_dir(struct inode *inode, struct dir_context *ctx) > { > struct offset_ctx *so_ctx = inode->i_op->get_offset_ctx(inode); > XA_STATE(xas, &so_ctx->xa, ctx->pos); > @@ -437,7 +437,8 @@ static void offset_iterate_dir(struct inode *inode, struct dir_context *ctx) > while (true) { > dentry = offset_find_next(&xas); > if (!dentry) > - break; > + /* readdir has reached the current EOD */ > + return (void *)0x10; > > if (!offset_dir_emit(ctx, dentry)) { > dput(dentry); > @@ -447,6 +448,7 @@ static void offset_iterate_dir(struct inode *inode, struct dir_context *ctx) > dput(dentry); > ctx->pos = xas.xa_index + 1; > } > + return NULL; > } > > /** > @@ -479,7 +481,12 @@ static int offset_readdir(struct file *file, struct dir_context *ctx) > if (!dir_emit_dots(file, ctx)) > return 0; > > - offset_iterate_dir(d_inode(dir), ctx); > + if (ctx->pos == 2) > + file->private_data = NULL; > + else if (file->private_data == (void *)0x10) > + return 0; > + > + file->private_data = offset_iterate_dir(d_inode(dir), ctx); I think it's usually best practice to only modify the file->private_data pointer during f_op->open and f_op->close but not override file->private_data once the file is visible to other threads. I think here it might not matter because access to file->private_data is serialized on f_pos_lock and it's not used by anything else.