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 77D54C3DA7F for ; Wed, 31 Jul 2024 13:04:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0E9346B0082; Wed, 31 Jul 2024 09:04:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 099016B0083; Wed, 31 Jul 2024 09:04:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E7C1B6B0085; Wed, 31 Jul 2024 09:04:30 -0400 (EDT) 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 CA5B86B0082 for ; Wed, 31 Jul 2024 09:04:30 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 6537180273 for ; Wed, 31 Jul 2024 13:04:30 +0000 (UTC) X-FDA: 82400066700.15.6CAAB3D Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf28.hostedemail.com (Postfix) with ESMTP id E0734C001A for ; Wed, 31 Jul 2024 13:04:26 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=HOWoLdAn; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b="GfLIaFt/"; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=cH62HwFj; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=wAkuxeSP; spf=pass (imf28.hostedemail.com: domain of jack@suse.cz designates 195.135.223.131 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=1722431011; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ivJaimO/MuIX0nZIv/LV5ejuL6aUSpF1ANU8xkUs+w8=; b=KnANSxrlcP5r6R8cqcLWIxE0XUUuto1G4zSKODbMuOuNRVq2sThf5JlLLZFP66kLZO5xFu BSg0UZCj41YNmfWx/maFoNLwuthBqZDQQMx9VLN0oqoaCjgpLJ3nFVJO0J4d2t+7rUv8IY zlYBel4QxxCG38InPY5XU1T2ujvvd8Q= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722431011; a=rsa-sha256; cv=none; b=MjbvUxLI0A2EeAlPcylgD8675a5lr/oV+h0Z5qHHXr4Chc+VrvxcEaHFK3cXSuHtDgMCq2 oiKgNCG0ADY7kLJ6BP34Mk6nJman9E0Vgyy4TEDeM4ICu81K7rp0R1SJpXaEmbqbH4M+TC 3bY38jQoPpm7xVnH6GNJJpAgVQlguUI= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=HOWoLdAn; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b="GfLIaFt/"; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=cH62HwFj; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=wAkuxeSP; spf=pass (imf28.hostedemail.com: domain of jack@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=jack@suse.cz; dmarc=none Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 082A21F810; Wed, 31 Jul 2024 13:04:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1722431065; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ivJaimO/MuIX0nZIv/LV5ejuL6aUSpF1ANU8xkUs+w8=; b=HOWoLdAnpBjqNzQ9aqEpgsGhMMgI4djSP7YYcSEMeV6g3NBJIm7W1LT7bcnmySOwiRP5V9 epp4nMPoy4Uy7tm3ep9dlU4E32Kr2MwHt2SkoYve6M7Dk0B+Cf7DkfQMyisQjsAG6SlmYV TjbMM1to28Ft4O2y5TCi27AtaaivU9I= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1722431065; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ivJaimO/MuIX0nZIv/LV5ejuL6aUSpF1ANU8xkUs+w8=; b=GfLIaFt/Q95HscvhSiZkp67yQO8QDoGbZ3uDsvRpIdpp+dgjVGUFvaWFuj4rSyhvhMg9dw NLxNUjEFV5hkArDg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1722431064; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ivJaimO/MuIX0nZIv/LV5ejuL6aUSpF1ANU8xkUs+w8=; b=cH62HwFjA+oSbPzm9DCKN3cLz78HNKeJKUsHHf2e5hs6SMAN5uC4JB5Va52WOhCBYC4gGL wdo/sNWnW8a+8lL3vp6T7NSIK0QNI1TOeVUJ80yyJn3g/sKolRdBQ4CQpfL6UVpkBD68M7 gy/6o4coPo9tjnC16r/x58gohHA5Uxo= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1722431064; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ivJaimO/MuIX0nZIv/LV5ejuL6aUSpF1ANU8xkUs+w8=; b=wAkuxeSPLgY1xnbjtJ7THDlWHjRre/C3WneFjo1K0ji4n19l1gtY0twVT/5EEXKEQQSIEY fJbzIL9OVCObKoCg== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id EAAB113297; Wed, 31 Jul 2024 13:04:23 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id GdRFOVc2qmYGWgAAD6G6ig (envelope-from ); Wed, 31 Jul 2024 13:04:23 +0000 Received: by quack3.suse.cz (Postfix, from userid 1000) id 59684A099C; Wed, 31 Jul 2024 15:04:23 +0200 (CEST) Date: Wed, 31 Jul 2024 15:04:23 +0200 From: Jan Kara To: yangerkun Cc: Jan Kara , yangerkun , hch@infradead.org, chuck.lever@oracle.com, brauner@kernel.org, viro@zeniv.linux.org.uk, hughd@google.com, zlang@kernel.org, fdmanana@suse.com, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH] libfs: fix infinite directory reads for offset dir Message-ID: <20240731130423.wztpcevyzm4cnkjg@quack3> References: <20240731043835.1828697-1-yangerkun@huawei.com> <20240731115134.tkiklyu72lwnhbxg@quack3> <57de6354-f53d-d106-aed8-9dff3e88efa6@huaweicloud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <57de6354-f53d-d106-aed8-9dff3e88efa6@huaweicloud.com> X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: E0734C001A X-Stat-Signature: mmo8d8dpopo8i7xpjncxyorekfsy1kc6 X-HE-Tag: 1722431066-767860 X-HE-Meta: U2FsdGVkX1+p5mf2YvoZwYUZuysQ+Zo1p0swCJDpacL6G7SYSJMjhiPvxKOVKxUbw06gl+sHzQR7I4ZGcJRAn8pMMqn3HXnT6wUj9esRTb/CpqDh44ddJfcjkXCiqjF1WtVYWbrqsTZdtgMypG21MgogdF0Ih98vh8Yi7nPrmAgFpgFszERR+clavVBC7l5yJ8pDrKbB4KITX5a8wgpv70li2kobPRD2Yb+nCTzNsCRVJp02qAkt0lxI080uSXU7Okek4M66SGMaxyvArBv6bA1Sj4Q04oIF2kES6F3JsDr8MsYmCKNcUL10yZrZ7hH5W3xA9+ZYHcC2fSaXZQ13wY4p3yrMq0afRo2yrjya+aP0DFLUShLSXztntnwU3FUjl4wytH5vkalu0dmkdZWrWhYazuvUi8BUZaKReplk1Ys69aCBzszOIKlm0Bof0ojc2jQmPCkWv89DX2BfaIyiMUuKepF5umR7/iat0b+uJT5iqf9YdnxWq3netAr9+nplfFc9xvoccGg8SEctJ/cDRwc70cOPfFJ/utxT3hlnE1r9sHuYg0HBKfcTq98uSjvhR+TSlYArsghpVTEmCr8sJxj+DBdlPexIAXcapYMHcmpK6K/lqTHRRkNU95c0pEDZPap/QSbAsOUfYHnNbgcnHsoyG9esbxkYZxaE4iSfpaS55LAZTCKuxYTK0GQTmmazZA08jw9wRruJhraNIja8PN7XbSq+0K3lAfOxI/n9RbwvhgpO+HBmNa6V6vJyu10cz0c05tyBXU0OMbf40TaiiszSL/mKmWM6Cg2Z4EfCheRGzGH2Iu4/b5uIEgdVayuogQkDvu0cvM/SWDXDXYJG99fhsZsGvIC0j3eE8YonyGzXeZh5jt43BrlhOi0bWIE7xW11ZkS/+3NU1Q5L1eqLq7n5e2lTf/DMcZJYS2q3zgW2YSP1xZm+IIJr55+yx67rF9fDxK5cVT+LqBicOvL Nzp7fD/V 3ZcrsazW6Dd71SCVfea7Tu8oDf2wQLqURgNrFmDgwhNU9hGeNALyWEVzMg8IZQjHJfrju4OYlpJmRB4CilmrcTczDVVOtzJBE9VR95nR8M5Vb4ersiAjLif+JHQzmIjEYjYvg/tYHPC4OubtNrTXtSuW1f+1OuijxAtQDmyRH0M0Wdr7JcczjIMll1b8NP3+fAaPn0SrJUsGjxPPzNba3S4vCnsij6wzDXfZ22QHxgNuTIsFF7+n542kCIFKlCMk2aCDdXKx3EAeK60zf2pHVOVShJiTAvdTkid9B+PYLCk0ZqeGQlaShkdR8XJni1TFCcz89oQM76DN9ayx1DASmxLfvsQ== 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 Wed 31-07-24 20:51:05, yangerkun wrote: > 在 2024/7/31 19:51, Jan Kara 写道: > > On Wed 31-07-24 12:38:35, yangerkun wrote: > > > After we switch tmpfs dir operations from simple_dir_operations to > > > simple_offset_dir_operations, every rename happened will fill new dentry > > > to dest dir's maple tree(&SHMEM_I(inode)->dir_offsets->mt) with a free > > > key starting with octx->newx_offset, and then set newx_offset equals to > > > free key + 1. This will lead to infinite readdir combine with rename > > > happened at the same time, which fail generic/736 in xfstests(detail show > > > as below). > > > > > > 1. create 5000 files(1 2 3...) under one dir > > > 2. call readdir(man 3 readdir) once, and get one entry > > > 3. rename(entry, "TEMPFILE"), then rename("TEMPFILE", entry) > > > 4. loop 2~3, until readdir return nothing or we loop too many > > > times(tmpfs break test with the second condition) > > > > > > We choose the same logic what commit 9b378f6ad48cf ("btrfs: fix infinite > > > directory reads") to fix it, record the last_index when we open dir, and > > > do not emit the entry which index >= last_index. The file->private_data > > > now used in offset dir can use directly to do this, and we also update > > > the last_index when we llseek the dir file. > > > > The patch looks good! Just I'm not sure about the llseek part. As far as I > > understand it was added due to this sentence in the standard: > > > > "If a file is removed from or added to the directory after the most recent > > call to opendir() or rewinddir(), whether a subsequent call to readdir() > > returns an entry for that file is unspecified." > > > > So if the offset used in offset_dir_llseek() is 0, then we should update > > last_index. But otherwise I'd leave it alone because IMHO it would do more > > harm than good. > > IIUC, what you means is that we should only reset the private_data to > new last_index when we call rewinddir(which will call lseek to set > offset of dir file to 0)? Yes, exactly. Sorry for being a bit vague. Honza -- Jan Kara SUSE Labs, CR