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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 8C344C35FF1 for ; Tue, 17 Sep 2024 08:07:15 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4X7DsF5wcsz2yVt for ; Tue, 17 Sep 2024 18:07:13 +1000 (AEST) Authentication-Results: lists.ozlabs.org; arc=none smtp.remote-ip=115.124.30.112 ARC-Seal: i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1726560430; cv=none; b=DWbcCOs3sXyH1d981irxBZuLvKnwixYZuP/4rE8Ca/rvcBnVpNVUFRzFfkHLvihSABqL91MkMPYHfK5mgFLPu3f/CFvh4e13kWqlEoO8hCjRSP4nGO1ox/0WW5NjO5HC6fnG2TrcZIjQuVRu4pqBqv4FPfBS19cOsVEcLkoibn8YnvWtmZwZGkV7wfYWJFfklMnzlmPGVAe5IXm0itPYq5B8uFunqvUu6F8Yo/RFTvIDT5B4p8uc3BQzJGQNS12z0YMbvjklOISh4u9qUewpQCBoqeMLtXH7QBnQHh/xxIwY2FDnmiMmjoyjfTdxff7guMJK4y+V4b/gAqi6gxWiSA== ARC-Message-Signature: i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1726560430; c=relaxed/relaxed; bh=zD8A7S8NSOoYTS0UIC1YFPPNS2TblfcXM5xymSmNV04=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Ssu+nwh0cp0EjjZeDWSdtK1Oq/GMvedI76QOGsbJS1/iWOnkWGUCftbOzVMnkKtb29XtdDPhUPfOMK0yjoxG2LghnUrJuENT3MjXR8DgQ7fewYMRh/Lh/6BGFXyjU8SEfnALPXyzkNVIM+yjqTXE+MfM+aKRngOm33Qyg3R2J/v6akTCcorrtl3H3PNlNHCW7/1qSFIgaQXQWcsb7yYF/tfuNonxvBav9inZ04KHsavQZQJ+3NV2AybVDdWSIZhfDe0avnl3fDJTPkPVmwxlLINgGef9gi0JDLvQtwbrJRdfYiYzMp5ewLIZJYnG0dqzZIk1ehx61fjO+WrALf4BRg== ARC-Authentication-Results: i=1; lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; dkim=pass (1024-bit key; unprotected) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.a=rsa-sha256 header.s=default header.b=d+H2VHso; dkim-atps=neutral; spf=pass (client-ip=115.124.30.112; helo=out30-112.freemail.mail.aliyun.com; envelope-from=hsiangkao@linux.alibaba.com; receiver=lists.ozlabs.org) smtp.mailfrom=linux.alibaba.com Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: lists.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.a=rsa-sha256 header.s=default header.b=d+H2VHso; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=linux.alibaba.com (client-ip=115.124.30.112; helo=out30-112.freemail.mail.aliyun.com; envelope-from=hsiangkao@linux.alibaba.com; receiver=lists.ozlabs.org) Received: from out30-112.freemail.mail.aliyun.com (out30-112.freemail.mail.aliyun.com [115.124.30.112]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4X7Ds81MNkz2xb9 for ; Tue, 17 Sep 2024 18:07:05 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1726560422; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=zD8A7S8NSOoYTS0UIC1YFPPNS2TblfcXM5xymSmNV04=; b=d+H2VHso7gqLttcwhVqPO1QZ5SbKF9Dj/abm8/bnfq7Hmmo8HMnOLm+dcxHYKKiW7cr/x+Oe0If8kyXjIf+NMzXbnRvVN7D3jdE1CngMwwxl+I1rRbBswbNTgJHM4JXZ0qhlgn58PEVOy9oVqDTKrjOzi/+b3Mz1o2lAikaS8yU= Received: from 30.244.95.26(mailfrom:hsiangkao@linux.alibaba.com fp:SMTPD_---0WFARaTY_1726560417) by smtp.aliyun-inc.com; Tue, 17 Sep 2024 16:06:59 +0800 Message-ID: Date: Tue, 17 Sep 2024 16:06:56 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 19/24] erofs: introduce namei alternative to C To: Al Viro References: <20240916135634.98554-1-toolmanp@tlmp.cc> <20240916135634.98554-20-toolmanp@tlmp.cc> <20240916170801.GO2825852@ZenIV> <1edf9fe3-5e39-463b-8825-67b4d1ad01be@linux.alibaba.com> <20240917073149.GD3107530@ZenIV> From: Gao Xiang In-Reply-To: <20240917073149.GD3107530@ZenIV> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: linux-erofs@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development of Linux EROFS file system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-fsdevel@vger.kernel.org, linux-erofs@lists.ozlabs.org, LKML , rust-for-linux@vger.kernel.org Errors-To: linux-erofs-bounces+linux-erofs=archiver.kernel.org@lists.ozlabs.org Sender: "Linux-erofs" On 2024/9/17 15:31, Al Viro wrote: > On Tue, Sep 17, 2024 at 03:14:58PM +0800, Gao Xiang wrote: > >>> Sorry for my ignorance. >>> I mean i just borrowed the code from the fs/erofs/namei.c and i directly >>> translated that into Rust code. That might be a problem that also >>> exists in original working C code. >> >> As for EROFS (an immutable fs), I think after d_splice_alias(), d_name is >> still stable (since we don't have rename semantics likewise for now). > > Even on corrupted images? If you have two directories with entries that > act as hardlinks to the same subdirectory, and keep hitting them on lookups, > it will have to transplant the subtree between the parents. Oh, I missed unexpected directory hardlink corrupted cases. > >> But as the generic filesystem POV, d_name access is actually tricky under >> RCU walk path indeed. > > ->lookup() is never called in RCU mode. I know, I just said d_name access is tricky in RCU walk. ->lookup() is for real lookup, not search dcache as fast cached lookup in the RCU context. Thanks, Gao Xiang From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-132.freemail.mail.aliyun.com (out30-132.freemail.mail.aliyun.com [115.124.30.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 541E512F399; Tue, 17 Sep 2024 08:07:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.132 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1726560431; cv=none; b=RD7hG/WO2xFKB/CYMRMpNaJ4csw7AnMVVxqMDvPs29USve2FNxd86urtzVZkphaD9qZnMOanhejGwKo7kCY69ovrVpncaknWYR92gapvrLX49OH4erN25TjokEdOPGSaO7oyFa7URVzSIk0IXsMo/zFPDCsGBXlLiejWMRyXXAA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1726560431; c=relaxed/simple; bh=tqJo6nTksgHuGMYt5OCVWCVWQ61LgmqMjoGYJo/l1Ew=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=XDXZZwKqqvQjyZBtEQdxtCAaaQQS1pZAW6xGTycNW3BIZuDscXBvAgZkGfcA1Z+wpF7HLjYXSx1ntOKqOwjKs99T3tU39x55dduxLNCbVOucbvBt/MCrQziDzIbGwgoeuIk342/ZJHh12Ta5kqYIPeByyfRAE9kvz9JTvtEIyeo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=lniaXijO; arc=none smtp.client-ip=115.124.30.132 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="lniaXijO" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1726560420; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=zD8A7S8NSOoYTS0UIC1YFPPNS2TblfcXM5xymSmNV04=; b=lniaXijOp+SP5SOHzvc81qVzN3WCkHEsaj0ZFM+JZqFz3y4h2+Vh5sunmdEjwr9ajQ3M8YrSzcXaIOxBbj+gkoG3Xm4QeJAaqu92qGmKCb5izSdl296nwgGBifhcxLyW9RNqVxLtl0OreZXngfIyN5c/UIOA3Grz6bXxb/2wp/I= Received: from 30.244.95.26(mailfrom:hsiangkao@linux.alibaba.com fp:SMTPD_---0WFARaTY_1726560417) by smtp.aliyun-inc.com; Tue, 17 Sep 2024 16:06:59 +0800 Message-ID: Date: Tue, 17 Sep 2024 16:06:56 +0800 Precedence: bulk X-Mailing-List: rust-for-linux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 19/24] erofs: introduce namei alternative to C To: Al Viro Cc: Yiyang Wu , linux-erofs@lists.ozlabs.org, rust-for-linux@vger.kernel.org, linux-fsdevel@vger.kernel.org, LKML References: <20240916135634.98554-1-toolmanp@tlmp.cc> <20240916135634.98554-20-toolmanp@tlmp.cc> <20240916170801.GO2825852@ZenIV> <1edf9fe3-5e39-463b-8825-67b4d1ad01be@linux.alibaba.com> <20240917073149.GD3107530@ZenIV> From: Gao Xiang In-Reply-To: <20240917073149.GD3107530@ZenIV> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2024/9/17 15:31, Al Viro wrote: > On Tue, Sep 17, 2024 at 03:14:58PM +0800, Gao Xiang wrote: > >>> Sorry for my ignorance. >>> I mean i just borrowed the code from the fs/erofs/namei.c and i directly >>> translated that into Rust code. That might be a problem that also >>> exists in original working C code. >> >> As for EROFS (an immutable fs), I think after d_splice_alias(), d_name is >> still stable (since we don't have rename semantics likewise for now). > > Even on corrupted images? If you have two directories with entries that > act as hardlinks to the same subdirectory, and keep hitting them on lookups, > it will have to transplant the subtree between the parents. Oh, I missed unexpected directory hardlink corrupted cases. > >> But as the generic filesystem POV, d_name access is actually tricky under >> RCU walk path indeed. > > ->lookup() is never called in RCU mode. I know, I just said d_name access is tricky in RCU walk. ->lookup() is for real lookup, not search dcache as fast cached lookup in the RCU context. Thanks, Gao Xiang