From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-98.freemail.mail.aliyun.com (out30-98.freemail.mail.aliyun.com [115.124.30.98]) (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 3007815382E for ; Mon, 17 Mar 2025 06:43:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.98 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742193836; cv=none; b=FaUuxXtfQZxzhq/2ugxBvHZjFlXlOGb5LmFMLRRn2O5CDMKralkuXkfq6gZHMIWMCn25Hevt/EX5m796fCawXkUACpJjRZgELD1bznvUYbwYOqqMHsknM3kHMFLjGspr221mMN1p08VkAn7Bam1inkiGP7VRSSAODEYmOOCs2jU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742193836; c=relaxed/simple; bh=36XU+XIOvR7E4JpcsQXt4dNNvaUHhARX8J9KFlmF1EQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=tzXrpYdSn17ygxkPCdaNsbH4Z4A9EqxrHeqKML8wciQf5UqCHtjmsXcmqgbMPLLcbiB/827yKBOUc+QnP+Zh2qVeEU+EBn57HtbeGQIPJjhPv9JPwW7YeUWt79iXFl43U+Qh7kAmsbUe/bPWf27ZsRYPlfCVyBpoTqwX+lB6L0w= 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=oLcBLC8P; arc=none smtp.client-ip=115.124.30.98 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="oLcBLC8P" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1742193829; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=cToQKYVimXAGyTQXffRJDfzXmpyvPuy5zS8wqsPtAj0=; b=oLcBLC8Pa3BUMdzgqw8dKiNaESvoS56ltiu6j/qwu26li0lyvD8f0H7G81j8MavU4aWnokzyylmKvwAqI4JW5O9HP/2CGiHWq66Xt/0K7qv+2g14t99FE0uNMj1yR77pjualC4Ujb+kGj556fxfNl8h5qxqIVdUepxn69wTKfhE= Received: from 30.74.130.1(mailfrom:hsiangkao@linux.alibaba.com fp:SMTPD_---0WRa37lF_1742193828 cluster:ay36) by smtp.aliyun-inc.com; Mon, 17 Mar 2025 14:43:48 +0800 Message-ID: <7b4a204e-5cb5-411a-bcb6-99e281fdc470@linux.alibaba.com> Date: Mon, 17 Mar 2025 14:43:48 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5] erofs: use Z_EROFS_LCLUSTER_TYPE_MAX to simplify switches To: Chao Yu Cc: linux-kernel@vger.kernel.org, Hongzhen Luo , linux-erofs mailing list References: <20250210032923.3382136-1-hongzhen@linux.alibaba.com> <511c5fd9-307e-4c56-9d20-796dd06f775c@kernel.org> <489be3d1-a755-4756-ba82-a8f5a0dc9156@linux.alibaba.com> <04050888-7abf-40fa-98d6-6215b8ba989e@kernel.org> <18767765-53b5-4e78-b50d-9305fe1cb2d0@linux.alibaba.com> <1dd3b2a6-5431-4a2a-bccb-2a3672f5d1bd@kernel.org> From: Gao Xiang In-Reply-To: <1dd3b2a6-5431-4a2a-bccb-2a3672f5d1bd@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2025/3/17 14:42, Chao Yu wrote: > On 3/17/25 14:15, Gao Xiang wrote: >> Hi Chao, >> >> On 2025/3/17 14:03, Chao Yu wrote: >>> On 3/17/25 01:17, Gao Xiang wrote: >>>> Hi Chao, >>>> >> >> ... >> >>>> >>>> Previously, it was useful before Z_EROFS_LCLUSTER_TYPE_HEAD2 was >>>> introduced, but the `default:` case is already deadcode now. >>> >>> Xiang, thanks for the explanation. >>> >>> So seems it can happen when mounting last image w/ old kernel which can not >>> support newly introduced Z_EROFS_LCLUSTER_TYPE_* type, then it makes sense to >>> return EOPNOTSUPP. >> >> Yeah. >> >>> >>>> >>>>> >>>>> Btw, we'd better to do sanity check for m->type in z_erofs_load_full_lcluster(), >>>>> then we can treat m->type as reliable variable later. >>>>> >>>>>       advise = le16_to_cpu(di->di_advise); >>>>>       m->type = advise & Z_EROFS_LI_LCLUSTER_TYPE_MASK; >>>>>       if (m->type >= Z_EROFS_LCLUSTER_TYPE_MAX) { >>>> >>>> It's always false here. >>> >>> So, what do you think of this? >>> >>>  From af584b2eacd468f145e9ee31ccdeedb7355d5afd Mon Sep 17 00:00:00 2001 >>> From: Chao Yu >>> Date: Mon, 17 Mar 2025 13:57:55 +0800 >>> Subject: [PATCH] erofs: remove dead codes for cleanup >>> >>> z_erofs_extent_lookback() and z_erofs_get_extent_decompressedlen() tries >>> to do sanity check on m->type, however their caller z_erofs_map_blocks_fo() >>> has already checked that, so let's remove those dead codes. >> >> z_erofs_extent_lookback() will (lookback) read new lcn in >> z_erofs_load_lcluster_from_disk() so it won't be covered by >> the original z_erofs_map_blocks_fo(). > > Xiang, > > Oh, I see, changed here: > > - z_erofs_extent_lookback > - z_erofs_load_lcluster_from_disk > - z_erofs_load_full_lcluster > : m->type = advise & Z_EROFS_LI_LCLUSTER_TYPE_MASK; > - z_erofs_load_compact_lcluster > : m->type = type; Yeah, we'd better to move all checks into z_erofs_load_lcluster_from_disk() later. > >> >> I think this check can be resolved in >> z_erofs_load_lcluster_from_disk() instead but maybe address >> for the next cycle? since there are already enough features >> for this cycle and I have to make sure no major issues.... > > Yeah, it's fine to check the cleanup later, let's keep focusing > on improving patches in dev now. Yes. Thanks, Gao Xiang > > Thanks, > >> >> Thanks, >> Gao Xiang >>