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 0BEA2C3DA4A for ; Mon, 29 Jul 2024 14:26:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 937C16B0098; Mon, 29 Jul 2024 10:26:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8E88D6B0099; Mon, 29 Jul 2024 10:26:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7D5E86B009A; Mon, 29 Jul 2024 10:26:51 -0400 (EDT) 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 5E3D56B0098 for ; Mon, 29 Jul 2024 10:26:51 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 15495140359 for ; Mon, 29 Jul 2024 14:26:51 +0000 (UTC) X-FDA: 82393016622.02.F4BF68A Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by imf01.hostedemail.com (Postfix) with ESMTP id 26BD44000D for ; Mon, 29 Jul 2024 14:26:46 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=none; spf=pass (imf01.hostedemail.com: domain of yangerkun@huawei.com designates 45.249.212.189 as permitted sender) smtp.mailfrom=yangerkun@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722263155; 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=rQU9lvA/imonzuKaVz0mtH7ZzM37QS+tK736ArRt7Eg=; b=xuhgwhD+K/7grSKyT/p6DF+oqxmb7xsrN2S4tBiN9SdI/Pha/wfZcE0hfqWPCbImcVlstC 4mNg9Zek7oAVPO2HBvYpO7gjnaP8X2/7NssHctb521HoXv/I8gdBAW6ub5iAQX09fG198R k0u1uI49YYdOO0C7IM/td5L0YgbqecQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722263155; a=rsa-sha256; cv=none; b=uz71bZH7jrL0l1UiVsItHVTeba2n7s3CaNW2UN1SI+3rl65hKveiQJvzuO/iRiaFwMkKcF KPAxTVm4b5nI7w24R7OnW5Cdc6PL/LBgmRGKzcZ5ELcgYeLKPo72WvoEy4sWc2VsqTBAuZ eTGUX5lrI/hGtUdHXb+KEJceFru+nYc= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=none; spf=pass (imf01.hostedemail.com: domain of yangerkun@huawei.com designates 45.249.212.189 as permitted sender) smtp.mailfrom=yangerkun@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com Received: from mail.maildlp.com (unknown [172.19.162.254]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4WXgYF0qrzzPtKM; Mon, 29 Jul 2024 22:22:25 +0800 (CST) Received: from kwepemf100006.china.huawei.com (unknown [7.202.181.220]) by mail.maildlp.com (Postfix) with ESMTPS id 0A9D2180100; Mon, 29 Jul 2024 22:26:42 +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; Mon, 29 Jul 2024 22:26:41 +0800 Message-ID: <1a8ac690-e48a-324c-a006-42fcf29d52be@huawei.com> Date: Mon, 29 Jul 2024 22:26:40 +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: Christoph Hellwig CC: Filipe Manana , , , , , , , 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: dggems706-chm.china.huawei.com (10.3.19.183) To kwepemf100006.china.huawei.com (7.202.181.220) X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 26BD44000D X-Stat-Signature: kedq4ohmcxohk4aiwj8wxmzti5t1op4j X-HE-Tag: 1722263206-467517 X-HE-Meta: U2FsdGVkX1+v82oWmFFgFGnwDhtFXrbTd6fWEC2DCV75P5nqfnsyM2GUzb2Q0fa0/+uxGZasFGlCnPwEgY0LLTOywn6Paf6XFdV0DyOA3j1dyk+HPtgkkgNj8jhIt7b18olQvn3hquyezV/2tMH2O6qUvo6WWQkPRqVSC5JauLa07kK2Rkcsjd1K73ZrRonYSqmfZ7rm4bIeE57F8rH+p0l0vveTHQwQ+hmJOJM9ztZ9q2j1a1YbwvyEZv6ruBLvFSBnhkZBK9TPSgE+pRw9n/RMWLJ5Ya520oJsILkpbrbSG9xciFKNz5QS6CM96kI1oYttmqQJN+kjBgIb9NGTCORRffbFWw0ZkukeykELYzzrk2fKA2eWT+1OCskYHyALIl1avB7zi9lV024/vtScyMFAB13Y6ipCQEhbA2oi1DwV8C15skbpUFLhVqcDLPC/3WDxV33bizc47/ai+xf0+3sFmxGC7n6TVdqszxU2XWQVZjSDwsd30ZbRSKo2nqSBRGXraibLMJRK3byy91faDZiuUJbnNs8YxFq4T2i2lAs/b45QiK7F1cw3WOJP4xmrF4vlhLw9HwZTIyzgwXFSuKGd07W9idAK1uGwb4NrcweRGYcQRyBVGAOnZp0sazp1r6FsqhFpoWIl8G+ENWjLJGAVOXwYFeFMm9JCcv60/0Nw6PHdG7spp+pUO9OxWtE4PHix5joWW2uSHJsxtQln25bqUTPXfWi81oke52lBggPqmS7CLtVoGITYZiIZu9oK/4XSeCNiQaq/v2i5wIEUUC3wdTCHbjOLygg2prTQhCGVjlhs3HpVFDsRwP2bl6NA/EXMISqiGZ3WvY568u8t7Rc29h6EI8UoDMDYgPm95TapgrGAFjz3aUob0mHVipZK3H5zuC4hbBDjNHocIzeonjr7HkD5lq/oTOGxsVNrgcq5kddiK330mabveiXIp+N8PLaFuYfod+6aWxr5JFf svZ+ZPEW 4e9Og45eVEfmW5veroRjvRlX3V2rqkgcqA9wrAshavJCwO7IXhjJJ4170aDPXnfMNYjx7nyY6YzFrmaESc/lDtvkMd/zk5ENVBknBstJ2EyhT9OKHl1hlH8Xg2e/F+PZ7rvHvO5+qfibODI5en1SJzD2vcm4LZX1mzaY4 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:21, Christoph Hellwig 写道: > On Mon, Jul 29, 2024 at 09:53:52PM +0800, yangerkun wrote: >> 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. >> >> Looking forward to your comments! > > I agree to all of the above. > Thanks, I will try to write a patch for this!