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 B467FC5ACB3 for ; Sat, 18 Nov 2023 16:28:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B234744016A; Sat, 18 Nov 2023 11:28:54 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AD422440166; Sat, 18 Nov 2023 11:28:54 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9C31F44016A; Sat, 18 Nov 2023 11:28:54 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 80CE5440166 for ; Sat, 18 Nov 2023 11:28:54 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 4F0A1B57B7 for ; Sat, 18 Nov 2023 16:28:54 +0000 (UTC) X-FDA: 81471608988.10.8754DCA Received: from zeniv.linux.org.uk (zeniv.linux.org.uk [62.89.141.173]) by imf03.hostedemail.com (Postfix) with ESMTP id 41CBB20011 for ; Sat, 18 Nov 2023 16:28:52 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=linux.org.uk header.s=zeniv-20220401 header.b="SvkGV/ka"; spf=none (imf03.hostedemail.com: domain of viro@ftp.linux.org.uk has no SPF policy when checking 62.89.141.173) smtp.mailfrom=viro@ftp.linux.org.uk; dmarc=pass (policy=none) header.from=zeniv.linux.org.uk ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1700324932; h=from:from:sender: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=uDOXa70xfwJLAjXc22jM86hB6FxAhRm2Vpp+9Az3n3M=; b=ihWXphfAo3UqPgBIusbtvc9FwYLHhNmRU/fK2Qxe41kTFj5SgDZEaOp1H4dQv1wJXM3PQI 2Gvee9K38wiTs2HXgGATOHAdE76qAOrd+603ZW4YSL/l8vO5hzD372bDlmsyU/jXjHCOD0 EwMp0bo8+NIkJy7xyVgnU6/ULG5pp/c= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1700324932; a=rsa-sha256; cv=none; b=JlHoHULiiOsyV3R4oEY+5QjJDVaOC2GD7kwSMI5LC7dFZR1BQee57DLXLP7XfM1hR32Fsx i4vVIKWjWXHGNhPEq+m6zH0STcelM33alrbMHH8DpElWRL3iCYiZ/3WbhqjSBwi3Ag//sa noAHHAd3spbEYAF8g5vY7Tcx826mzfU= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=linux.org.uk header.s=zeniv-20220401 header.b="SvkGV/ka"; spf=none (imf03.hostedemail.com: domain of viro@ftp.linux.org.uk has no SPF policy when checking 62.89.141.173) smtp.mailfrom=viro@ftp.linux.org.uk; dmarc=pass (policy=none) header.from=zeniv.linux.org.uk DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=linux.org.uk; s=zeniv-20220401; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=uDOXa70xfwJLAjXc22jM86hB6FxAhRm2Vpp+9Az3n3M=; b=SvkGV/kaMiGVLZYXDX5ucqFFWb K0yjs/a4ieZ79SkQPxk5VPfWbOblJHMNUsXwFjtb2Aymfsfg9PKbY3p/j4+L44pIf5l6bzTz+dKNb SLJyMluHuDXhold5Ld1neCN03Qiiea3UlKttCF4RSqPkpfireEDwaCknfHtwpa+MxOKAKaCfcg/jh tO6VmAvyiaY58Tyn+qfdEQzKhfRLxn2qIYFLwmBdomf8pnr/SntadGuwSSU3i2insjOpqpnOV9qRE ucKETL2lUHFOcNoqouxGh/jEzB7+mEOH+Gt2hR2MWFPLiHcDzbk2mCG4vdOCXPWeq1DGed5iVENDE c/TLRQQA==; Received: from viro by zeniv.linux.org.uk with local (Exim 4.96 #2 (Red Hat Linux)) id 1r4OBS-00HVCA-0A; Sat, 18 Nov 2023 16:28:38 +0000 Date: Sat, 18 Nov 2023 16:28:38 +0000 From: Al Viro To: Chuck Lever Cc: akpm@linux-foundation.org, brauner@kernel.org, hughd@google.com, jlayton@redhat.com, Tavian Barnes , Chuck Lever , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v2] libfs: getdents() should return 0 after reaching EOD Message-ID: <20231118162838.GE1957730@ZenIV> References: <170007970281.4975.12356401645395490640.stgit@bazille.1015granger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <170007970281.4975.12356401645395490640.stgit@bazille.1015granger.net> X-Rspamd-Queue-Id: 41CBB20011 X-Rspam-User: X-Stat-Signature: 5h3hdz4harpswrhxmar9iktmpzd73a9b X-Rspamd-Server: rspam03 X-HE-Tag: 1700324932-79929 X-HE-Meta: U2FsdGVkX18eh6bmEh3XLbUPJLD/rqH0/lVS5Fnlvu51BNkeggVevsK2lLnltekXyTdGMFZhjRZG7qW2qBCGDV/jOgJz+3ib2zWYW1JEy5lWG7/fk1Pke0V4BHTAioac7jcJDK5+wCXvaG0QKhJ2MKGtgKUhup3mt9V/fnhs+9QqbBrGEn8EDQU0xec9o2IKJVl7Q5ChrbZj0L+JBH7B3d0gFlObsQDvYHmVJr4K+Nj71bfhNVcz/lwfTWcnrDOecfh/1j04FNRGUhb0GrBfUWTzG7RETCNyyLKAvyFS/WBL6NmFvi6WymN1nC/sHpLCmWxmqmoCltDyDTyMl9ra++DNC+TzUOKZARN1Zk1+GS4h2FUVs5IvDuAxOhYS3M2t+kBk93BkTMy8YhOfAEFb9mDPHgnqMBJrmzcg4INhH76z6Y8gNXLzQMIHhq0oh7FNad2Nladu7zjE4JEo3SsfiAh1bN3evHCiMitd0PAnaJLF8poRoOUC00srCh/dxN60o9yAqotZlkjA0wLtTpp1o/H+dYRjv5VlwmPVwBFdQdsBneAkEBiTUUwKybfcv0ufkZxrUJQbFOPWwg1YAa42culhrLxz/PmSnJtGs9DjSZlTXfIpoAJbkCE0xlBnNZtiQCJ4eG22UvejEFXpC0HsHimqYvb7MTD8iJahwSSfQzl0WBv1f9nywaklDajRzWuGk8MUjkMjI79y8Rd21d4iejtXhuHXX9gflr2MMUlzReePZlKp7Nm6/wrP4S5w9kKaKAfU28treJ8NNLBxxGW5R4ubcbjiQxQl1feX86JTBV+RtMONCOCe1xqFxPJ7UytewxZkouitmKmVK2ZQY9+roab/ayLZW97bN5n2CuxrhPUZUu4kmoUzoBcdFaLgHvUes5yq+ooV+AaM8WqhJ/PI3+aNgzmId+zx/MeFefInjOqLtwc18b6gweunHNnmPHuPjN4ECHiNYty15976laN GmYs+nMr CidG/sjalLMEx2jvaWAWqI78xam2/X46qngzfVpx7Ye1ygyidRnDaFzHFBnHhodTNT0btMalCZ8A7RmIpyZwn7NZcj4GJnX4VUXKAZTaJdkOlq36X4hue63a+BBGhvJKc6Y+pifp+jKHYn3fua+4gllOiZ/raWGvRmtxyxftn577HKA5bBcJ74qPGLnMXGfbzvluEYVZk7LYaHzJIjIyOWH0r2FZkcY6LfhosxjGfkzkvaYKPxrJkBv6v8ODzh/nc+t5n/jnT9mjb2BlWbSeugj3Xyib4T6Ypk/5WnVZne5WycDlmSiT2csVbg7i1DaTOFWfodVXebrU/AoOOCr4ej0zkgTB0qRQWbBASOQKNsZjDOZ/3m3y+AjRpWKG/6v+3OT61Ug1p5s36LBipAxTdtZiawQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.058847, 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 Wed, Nov 15, 2023 at 03:22:52PM -0500, Chuck Lever wrote: > static int offset_readdir(struct file *file, struct dir_context *ctx) > { > + struct dentry *cursor = file->private_data; > struct dentry *dir = file->f_path.dentry; > > lockdep_assert_held(&d_inode(dir)->i_rwsem); > @@ -479,11 +481,19 @@ 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) > + cursor->d_flags &= ~DCACHE_EOD; > + else if (cursor->d_flags & DCACHE_EOD) > + return 0; > + > + if (offset_iterate_dir(d_inode(dir), ctx)) > + cursor->d_flags |= DCACHE_EOD; This is simply grotesque - "it's better to keep ->private_data constant, so we will allocate a dentry, just to store the one bit of data we need to keep track of; oh, and let's grab a bit out of ->d_flags, while we are at it; we will ignore the usual locking rules for ->d_flags modifications, 'cause it's all serialized on ->f_pos_lock". No. If nothing else, this is harder to follow than the original. It's far easier to verify that these struct file instances only use ->private_data as a flag and these accesses are serialized on ->f_pos_lock as claimed than go through the accesses to ->d_flags, prove that the one above is the only one that can happen to such dentries (while they are live, that is - once they are in __dentry_kill(), there will be modifications of ->d_flags) and that it can't happen to any other instances. NAKed-by: Al Viro