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 411A7C3DA4A for ; Tue, 30 Jul 2024 01:05:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C71E86B0089; Mon, 29 Jul 2024 21:05:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C22426B008A; Mon, 29 Jul 2024 21:05:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AE9A76B008C; Mon, 29 Jul 2024 21:05:46 -0400 (EDT) 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 8F3846B0089 for ; Mon, 29 Jul 2024 21:05:46 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 47DAE1C08CA for ; Tue, 30 Jul 2024 01:05:46 +0000 (UTC) X-FDA: 82394626692.03.D144926 Received: from szxga06-in.huawei.com (szxga06-in.huawei.com [45.249.212.32]) by imf17.hostedemail.com (Postfix) with ESMTP id C4AC740025 for ; Tue, 30 Jul 2024 01:05:42 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf17.hostedemail.com: domain of yangerkun@huawei.com designates 45.249.212.32 as permitted sender) smtp.mailfrom=yangerkun@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722301483; 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; bh=6riTqMvrpAfOvO84wZjlLhruBSrS6cFyeAWTpjfRJF8=; b=fILYVOJEtSaIyindUB9Lsb7C3+P0ay3bXdLV8FBuprJB7pbEokWSFQKCV8LoA3Lv8+GyIl 7UUSy4NS6ssM7yZzyuvF0e6Vc+O6SMZ1WzzAbvgnT2wGfYyO9qTiZbWLL0BWMwYRp1MTGR 8FWa+e5v9sz1YWbr0OT+6kPVUpBib3Y= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722301483; a=rsa-sha256; cv=none; b=71V/NgNc3n67W1qRHWGDgHTGf/wBKind0q6tGdAeZcveqncir3Qfan/P1zSoY0ygy558iP PpjH6qJNdhgmntku6JJ0xChpTGpLaf7wSAW6grW0/Jd2/2lsc+T/1qaN3mcqmKIkh3ZrHt /4oZ3E1Kx4eIagrw7WxS1/wztdRUA+g= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf17.hostedemail.com: domain of yangerkun@huawei.com designates 45.249.212.32 as permitted sender) smtp.mailfrom=yangerkun@huawei.com Received: from mail.maildlp.com (unknown [172.19.163.17]) by szxga06-in.huawei.com (SkyGuard) with ESMTP id 4WXxn44lTpz1xtsg; Tue, 30 Jul 2024 09:03:36 +0800 (CST) Received: from kwepemf100006.china.huawei.com (unknown [7.202.181.220]) by mail.maildlp.com (Postfix) with ESMTPS id 30B651A0188; Tue, 30 Jul 2024 09:05:21 +0800 (CST) Received: from [10.174.177.210] (10.174.177.210) by kwepemf100006.china.huawei.com (7.202.181.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Tue, 30 Jul 2024 09:05:20 +0800 Message-ID: <938ab47e-c68c-ea6e-7a9f-b9080529cf75@huawei.com> Date: Tue, 30 Jul 2024 09:05:19 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1 Subject: Re: [PATCH] generic/736: don't run it on tmpfs To: Filipe Manana CC: Christoph Hellwig , , , , , , , linux-btrfs References: <20240720083538.2999155-1-yangerkun@huawei.com> <4188b7b5-3576-9e5f-6297-794558d7a01e@huawei.com> <9514fd55-4f83-8e43-bdf7-925396ab5e48@huawei.com> From: yangerkun In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.177.210] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To kwepemf100006.china.huawei.com (7.202.181.220) X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: C4AC740025 X-Stat-Signature: hgrg1kw6bx66m4r7wmxaz9zgu5g98u8r X-Rspam-User: X-HE-Tag: 1722301542-721981 X-HE-Meta: U2FsdGVkX19SHafWbMoy/gKfDqy9OFOdCRDs65OyFJHlJzCdZafQIbepqrWzTEAxseQBIf83Zmg2Blxl2qUOwBjTC9i5Bi+k7JTBDCKtcSINp6vBjn1dzmGpEzLKU5OhTTWIKwPAVJnPlshSgmDNW7wk7PfRuzW0LHjU6uYGHpeqHFSIef8LXWV8CgOb9x9WPwXwMXWrJYeE+d8W8+zo9WKweYpq8nPSoTcEhhWDpcc+FIjFrLDNCHcS6QelZ+ITCbYwmZpKASRlKFLwWKmOW9q2gJo+a/n8x1PkZq2ktRsFWCct74Y487HtH2loLQQP+sUV98f6Esnc11SV5wT3QK7vr5rjm6MRUwA8TdWNn3L1yYZJiQ2GqKgsVGoOXXCf4THkAyAwUAgNhQSRHmCSiD35QNt/OnSAxylKLcu99r8ZISQPdS3QzE86K1v07GVnzdaS8+WEs5DIWyueg+9NcsBYaGDiWnPgBH0OqQsHtQaOZOZlj1eOmVYIYxRcKVf49irjR98ORGOlCpPMBIlGrfYluwsV4DEyz7OditW3M1IkHSpK1BgXJQ94AaKt9J/UTXSne6abt4UX3k5BAr+CDcNU64gxx1evJPbLkJ/L5AaqMyKXASylY2qPFkaJ5ww5HM4QreT6q14quCw5+NBMD8nxVmyqVoIAa/Lm3SlXFqegRt3gTFPQC+NDGLxRK7HRlqBizLCKHONBq+kfgd02IW4sZofhTe0hauIMv0tiRmLdzy6TEKTRJHMtYZAXI7+5j73jo/cbvk1rm/fiPa3h3HPTQjzHxnv/lEYqEITY7lXVYZzAxaNlAHd299IiUp7m8n5uFV1pfy7+9SsdDda1EIrupl+GQPhJ1xODCHqV8vMNZsTEyIHqCk8SV2YYDSkJLyJg9DWhR+Ezi1TOXhcbPwtuOp28kIiG9Fo9/bMAKjUWDAgFwlHH7Ran6EmWMJWZT1NaOVB5DYkg36n5Cc4 ICzMtbYQ HslRsDBPZCagJHJGQx7rA84nUPT33w0NfYylwTBrmuEsYTG+Kss1wYVJJHR64TZs7p3uNJTjDnAYGUWXkyBLMvCe6Tj/Ib3o44ECWXOdBaDlVqHUGQ3qIH34BPZJJ9ybuTJBgdM5rvwt1BOvBxiGJbTI1IuS20ixlNPo5cLGXElZk1qDhJBbckZwXaUNt7EheVvFEcXV4/vdLCDQa7hIiGw4prOmiV14fLBA4rnJ0ElmKDZnHzIZV7eQPz4htJtupwvzJrkJMEw0fNelkIkcMySnqjg0zD4pLzRl3sUywDem4A9Q= 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: 在 2024/7/29 22:32, Filipe Manana 写道: > On Mon, Jul 29, 2024 at 2:54 PM yangerkun wrote: >> >> Hi, >> >> 在 2024/7/24 21:30, yangerkun 写道: >>> Hi, All, >>> >>> Sorry for the delay relay(something happened, and cannot use pc >>> before...). >>> >>> 在 2024/7/21 1:26, Filipe Manana 写道: >>>> On Sat, Jul 20, 2024 at 9:38 AM 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-8c7924778c35@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=e60aa5da14d01fed8411202dbe4adf6c44bd2a57 Thanks for your reminder, will change offset_dir_llseek too! > > 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=68b958f5dc4ab13cfd86f7fb82621f9f022b7626 > > > >> >> 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 >>>>> >>>>>