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 C5916C3DA61 for ; Mon, 29 Jul 2024 14:32:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5BA0F6B0096; Mon, 29 Jul 2024 10:32:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 542F46B009B; Mon, 29 Jul 2024 10:32:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3E34D6B009C; Mon, 29 Jul 2024 10:32:51 -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 1DEDF6B0096 for ; Mon, 29 Jul 2024 10:32:51 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id BCA531C1501 for ; Mon, 29 Jul 2024 14:32:50 +0000 (UTC) X-FDA: 82393031700.23.6DEF5C5 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf26.hostedemail.com (Postfix) with ESMTP id B484B140015 for ; Mon, 29 Jul 2024 14:32:48 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="dM+AGU/m"; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf26.hostedemail.com: domain of fdmanana@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=fdmanana@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722263509; 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=a7Z9mFFuN579Mv9JBcXTcAEtBuPhYwyA+1KOfp0Y/zA=; b=nRLvM5hP9lxAXgwqCdPyASBVLiZ05FQUnUqm/+72AqqP8pkl6RZ7CeSAlHx2AhxXpL83Aw BeZ7QbyCFxO2GS6/5D0kINa/O20z7g3Rr7lcjARXNY3AAKhwZTwJQ3jDuZgruzzRcVPv5n vx5f0dEY9xvJrsP4dx3YXA4R0sVLUdo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722263509; a=rsa-sha256; cv=none; b=W5aBXBesq7T4AV7wVzHn3BAJUseSYLWYDr7AckLmVyC7/F691/P1KWRtUe5iD2l0kfYoNq DXUQGFhr6XIiSsloi8R2AKeG61fGtr564FYLHWaWAiilD+59hN7HLAdYHGD1obq2F+Q+Bz ZA0bEsySvDQKzdEbYW+DBs8jzQmAlzI= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="dM+AGU/m"; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf26.hostedemail.com: domain of fdmanana@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=fdmanana@kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 8CA2961A30 for ; Mon, 29 Jul 2024 14:32:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5F2C5C4AF10 for ; Mon, 29 Jul 2024 14:32:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1722263567; bh=b5F+YCrcadXXbcjYPd2AIJIQa99ZIrMyu2gUHeNNKOk=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=dM+AGU/m8NZciuW5aUPl47IMjOO6gc/P0J8XTpHDY6xFUDCpnsnoTz22Je/U1SStN VCzlChH+1zd1qaazHKpKYgdnE//8Uq33pqTA8eE/kSsnlj+wJTKdh1sGRjqWBUMrVG aQ2/TKVE8lVNdgkrtwSUX+8hB08/Fss+rhDkBhfQnUetqpWSIw0uIfW22r1diD/ZhR 6NRHfAghLhhIHJSt7h3slLq/02E+OnPQlmP/wqROpMtjvJQ5XhHxs/9Q2mWNyYydWF tcRFaphM7vcQjHoYqZsvpD/ci/mbF32oZtAPDntolFFixv7606eKI9m3/Slsv2MgqE 6v9BGTNVNR5pQ== Received: by mail-lf1-f41.google.com with SMTP id 2adb3069b0e04-52efbc57456so3732504e87.1 for ; Mon, 29 Jul 2024 07:32:47 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCXgMG4gQjF9203Nu6YfLU3aFHAsYWN4eAv/PIbsuk4gnUHcUBljO+3It+5WcA1WVplsMINLFHnNqGQhuwEGqPovxb8= X-Gm-Message-State: AOJu0YzEP3qu48+kqZYkLnsjBF4spVK5GxqTHc3WW///h0XcZ5X8eRs2 8A/a96ICclv5JtJnikjn2wxzZOt8KnsqlXJ+mhfVKG7xGNHjl5GRtbnUdDDLTqpDM7g/Egg/VNs JUnOchXru5fkKohHN320XHy9Za6I= X-Google-Smtp-Source: AGHT+IEBVaqgiEOjUvwvwPzx0pvsiskjIhU0DCLh4DVYzArH+IJswZWaUTO6AMY+SU2YQ7e67MpW1vBM8/qsz7fXgeg= X-Received: by 2002:a05:6512:210f:b0:52e:941d:7039 with SMTP id 2adb3069b0e04-5309b2ce6afmr5261071e87.59.1722263565617; Mon, 29 Jul 2024 07:32:45 -0700 (PDT) MIME-Version: 1.0 References: <20240720083538.2999155-1-yangerkun@huawei.com> <4188b7b5-3576-9e5f-6297-794558d7a01e@huawei.com> <9514fd55-4f83-8e43-bdf7-925396ab5e48@huawei.com> In-Reply-To: <9514fd55-4f83-8e43-bdf7-925396ab5e48@huawei.com> From: Filipe Manana Date: Mon, 29 Jul 2024 15:32:08 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] generic/736: don't run it on tmpfs To: yangerkun Cc: Christoph Hellwig , chuck.lever@oracle.com, zlang@kernel.org, fstests@vger.kernel.org, linux-mm@kvack.org, hughd@google.com, akpm@linux-foundation.org, linux-btrfs Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: B484B140015 X-Stat-Signature: 3x5ggk1fr5edjb4shh3q4syaerjyag3t X-Rspam-User: X-HE-Tag: 1722263568-107621 X-HE-Meta: U2FsdGVkX19Z42avnUsLo7vQzYocm7LpKVrSUBCP2YghKO6i52L/HEA5H3NW+bsSzPxdkT0xx8UwadrCZlF0jGIU3jLjOuG1pcEnxXWfpOqljuVCa4dYy4M4ddta2BRQAZD0p9ZFeYAFcKbnwNpIEUgqY6Wj52RM6aNrMbgsgXXtK8LNcSZ6ztuYkbesgNDvcHXyy+BVogek0aO22NRV82c9uVrc/TKyyAY1oQPTNpW09tsV+e61XKWIVFxgNqBPxXGLGAz3V/PJqkHg2gg996auFBAdgNuEcvfJApHg+C7+nujbWAyGa5a+IHnnQUGlPuiA0bm/pl/pdhOAlxQfKPTUIK+x1eBbO74r+PFFjXv/xGR2S92ucOS3Nk3PiMJBrHuwX6X9TsMXUPjCLWq/lhkVq65Nwck+uYOhbD0sKO2YV6RUm16HVDsS70sldQVWVmDHso3rt+dUhkJQxCU2BVZz/GhGCKKBrqg5y5AWRi1t023vioWMTowb+AHZh0CGu3N/P8keGbj7NEUGzvRKEKIp74PIDIhNf1d/fwzQTyQnDvCHnFo5AYLbRGZyDu6WettlpBYintJCF+Zc5U0jmtWsu4zQc/DcCIernoLMDs3XJwy+Qghvyk1YDqtTJmStKgoj7zc6jXKfxyAxH+iT65EvAd14x3O3HtpJOCZMok5qAAZIp4I5Y/YVGbPYuMOoJWFqOcGz46UOWl5kNpwb6d2P5toQRFVEQmBjE3oTpkpDjH3a0Cgw+I3PcoHnrmrmj3XxZAkg9HVYVdJZkTkl+55YSmwam5LQ40WxDhORpaDu/XJs88NzHgXuxI1MjZeHwb2JRqxinP3s0LB1wagck28upXAEuoToKSPoLSeDw4pq9+BkmtIgof7i9FhZwxe2OGEchQ7r8/nWKzD0q4i/5yBedGPcrQq2AzoBuPOnT1r831Rk4i3197SkOSX6yF7xBaU+UlC7YJDBEMJnWxk /GcYDY0U sCGSfVSk4rg249rt1e9zMLS+EWsWVdVX2cGHweHa1III0ZUzCkANVikJZ5zJKklqTPOnjw2UPIqGQ1cFyEW5gTN7WroVZ/GKTLx/b53DiML1Oyn5iSSyDP4lpasZBXBvVajaKw8cI753EQQhqa9Axa5LT858dQQIV/2BpCfL9RH2B3E3aNhdjhEbqQcSfNxEKKzZojDWJNy1sApAa8kCUyuwDmjjoBed/YF24oP23XktkvKOhKfnBRKpzjaEgMvbMxa6ImlaIrtf/iwKFTZeDXXiuhCEOVznkGXTDte2tGMo1sHfQ8fgFO/XOLKZPXrbU3HotEYFCVTHTnvMMBRPvmCPqKGGpC2vQMnAgMSlu2nW4cK9n/jMPWqqfxxvl1qHhPhPr/qQ1b/CYbNY= 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, Jul 29, 2024 at 2:54=E2=80=AFPM yangerkun wr= ote: > > Hi, > > =E5=9C=A8 2024/7/24 21:30, yangerkun =E5=86=99=E9=81=93: > > Hi, All, > > > > Sorry for the delay relay(something happened, and cannot use pc > > before...). > > > > =E5=9C=A8 2024/7/21 1:26, Filipe Manana =E5=86=99=E9=81=93: > >> On Sat, Jul 20, 2024 at 9:38=E2=80=AFAM Yang Erkun wrote: > >>> > >>> We use offset_readdir for tmpfs, and every we call rename, the offset > >>> for the parent dir will increase by 1. So for tmpfs we will always > >>> fail since the infinite readdir. > >> > >> Having an infinite readdir sounds like a bug, or at least an > >> inconvenience and surprising for users. > >> We had that problem in btrfs which affected users/applications, see: > >> > >> https://lore.kernel.org/linux-btrfs/2c8c55ec-04c6-e0dc-9c5c-8c7924778c= 35@landley.net/ > >> > >> which was surprising for them since every other filesystem they > >> used/tested didn't have that problem. > >> Why not fix tmpfs? > > > > Thanks for all your advise, I will give a detail analysis first(maybe > > until last week I can do it), and after we give a conclusion about does > > this behavior a bug or something expected to occur, I will choose the > > next step! > > The case generic/736 do something like below: > > 1. create 5000 files(1 2 3 ...) under one dir(testdir) > 2. call readdir(man 3 readdir) once, and get entry > 3. rename(entry, "TEMPFILE"), then rename("TMPFILE", entry) > 4. loop 2~3, until readdir return nothing of we loop too many times(15000= ) > > For tmpfs before a2e459555c5f("shmem: stable directory offsets"), every > rename called, the new dentry will insert to d_subdirs *head* of parent > dentry, and dcache_readdir won't reenter this dentry if we have already > enter the dentry, so in step 4 we will break the test since readdir > return nothing (I have try to change __d_move the insert to the "tail" > of d_sub_dirs, problem can still happend). > > But after commit a2e459555c5f("shmem: stable directory offsets"), > simple_offset_rename will just add the new dentry to the maple tree of > &SHMEM_I(inode)->dir_offsets->mt with the key always inc by 1(since > simple_offset_add we will find free entry start with octx->newx_offset, > so the entry freed in simple_offset_remove won't be found). And the same > case upper will be break since we loop too many times(we can fall into > infinite readdir without this break). > > I prefer this is really a bug, and for the way to fix it, I think we can > just use the same logic what 9b378f6ad48cf("btrfs: fix infinite > directory reads") has did, introduce a last_index when we open the dir, > and then readdir will not return the entry which index greater than the > last index. Don't forget to reset the index to whatever is the current last index when rewind() is called. We ended up with that bug in btrfs later, see: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?= id=3De60aa5da14d01fed8411202dbe4adf6c44bd2a57 Anyway, if the same mistake is made, it would be caught by a test case for fstests I submitted after: https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/commit/?id=3D68b958f= 5dc4ab13cfd86f7fb82621f9f022b7626 > > Looking forward to your comments! > > Thanks, > Erkun. > > > > > > > Thanks again for all your advise! > > > > > >> > >> Thanks. > >> > >>> > >>> Signed-off-by: Yang Erkun > >>> --- > >>> tests/generic/736 | 2 +- > >>> 1 file changed, 1 insertion(+), 1 deletion(-) > >>> > >>> diff --git a/tests/generic/736 b/tests/generic/736 > >>> index d2432a82..9fafa8df 100755 > >>> --- a/tests/generic/736 > >>> +++ b/tests/generic/736 > >>> @@ -18,7 +18,7 @@ _cleanup() > >>> rm -fr $target_dir > >>> } > >>> > >>> -_supported_fs generic > >>> +_supported_fs generic ^tmpfs > >>> _require_test > >>> _require_test_program readdir-while-renames > >>> > >>> -- > >>> 2.39.2 > >>> > >>>