Received: by 2002:a05:6358:700f:b0:131:369:b2a3 with SMTP id 15csp1705318rwo; Wed, 2 Aug 2023 20:25:54 -0700 (PDT) X-Google-Smtp-Source: APBJJlE1MUKhhskLCoVI896xgHcb03NR7CnapgJcZ7g5z8b42/CEOiLMQ/+DNPRVErOJPaB+F/UC X-Received: by 2002:a05:6512:281c:b0:4fb:7559:aea3 with SMTP id cf28-20020a056512281c00b004fb7559aea3mr6709930lfb.39.1691033153769; Wed, 02 Aug 2023 20:25:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1691033153; cv=none; d=google.com; s=arc-20160816; b=H5A8l1IRRon2zPqewLkVYjJE3AQ0RY6RGntoXO8WVtH6KRvaFQJXW4ypTIKoHGYAgw eayIX7NKlh6s/ip8jdB1dPEPPEGOtgVDXm+6sVK3YdVuVFOLLA+mABcQspQoK1G330wG tqFXfTEdxsF0+PzIs57nb2RKoWSgcXq9NGU4aFqMsZOFRr+vFz5R8Fpu6I67q6YF4Cjk jUWm9SH0zmIzgmlnWmamS8r7tkL+3EkSNybWMY9uNqNjQSg0xjwWPWStwcck7Wx8Cp2R n9ARhFhEKvCRYuNsD8FrLVt9+HVgzKtwJAdX4PFa9FSvkM4DEoCQSB2s1+NJdIUzDgz7 +CFQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=LS4ogthG848BQdNPls7rwG6XCAg/4RMrZQQJRi17FLo=; fh=5JK762Kpnko8QyM7CVr1akxosBN3XoMgwRt4laln2IY=; b=TBuqntSwKd9Qn2vU/eytDeUAP4NdcIm+bi10pFmgJ9gIWzs9riWi5DUvStlJWPkrfQ /KPOhXBn9FghpCJOWIsoJiw3+YrRYvdamxukym/+eT6dOZWug3p2PJ8DciEnYoPxDr9J PobUnlJYcwZMWXkcEYCV8nj55BrniW44FIkO8kmwl+Y5j7ODpUFVuq4BPw3cY6CUMZCu MaN8HmYS1X3/mSl+pKXIw6WFyi3kJXC8LrPHegURQETpQRfaEADpapKk4qzYeBm7flYy QkwVTpKDSyvrHcN+HBMy/a2z6P+QKH1E3hANvvHIeoZ8qpWG+GgbA9J1UoJ4SVuXvWyd ntNw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=L7wfC4q+; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id t10-20020a05640203ca00b0052256067f49si9751753edw.414.2023.08.02.20.25.26; Wed, 02 Aug 2023 20:25:53 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=L7wfC4q+; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231732AbjHCDJL (ORCPT + 99 others); Wed, 2 Aug 2023 23:09:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44158 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232324AbjHCDJG (ORCPT ); Wed, 2 Aug 2023 23:09:06 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D11F930DF; Wed, 2 Aug 2023 20:09:04 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 6AC0A61BB3; Thu, 3 Aug 2023 03:09:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C8F3DC433C9; Thu, 3 Aug 2023 03:09:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1691032143; bh=QHLu2qchPO/2FuLK7r/oLQF/9G6LNB8Q8ZEpXXXTkSQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=L7wfC4q+Pl8/vsRZSWIT6fm8MB1uIfYZHRSI6FVw/eDejKD3DoNWc5aV9CWhc7iPK XOiHZGaMuWGeKGLgoLwy+6fkKhNYG4wf+Sbg6HFdRs4Q7lITUkI0VWLOhW47IHc7Hq yRtagflMZTs/Gt0vBkt1mWaFd90FSAgrqI1sXYUUEXMDFt+SprzlkLFhRq72udZfxB la7KgCJPe3b07W3IVfWMfLuvDsBqF+yMs+OUKDsIMjAEXB/4MhqkzAFd57JU46a8Vy 8wYzKobXZL8DhlficQQ8JrUzYBv4NUKnmZECkmFZU+jg11ZYwJ9OpaipCaiT3I3XXk HveiJ93S9MNpQ== Date: Wed, 2 Aug 2023 20:09:03 -0700 From: "Darrick J. Wong" To: Stephen Zhang Cc: Andreas Dilger , Theodore Ts'o , Zhang Yi , Ext4 Developers List , Linux Kernel Mailing List , zhangshida@kylinos.cn, stable@kernel.org Subject: Re: [PATCH v3] ext4: Fix rec_len verify error Message-ID: <20230803030903.GK11377@frogsfrogsfrogs> References: <20230801112337.1856215-1-zhangshida@kylinos.cn> <20230801151828.GB11332@frogsfrogsfrogs> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Thu, Aug 03, 2023 at 09:52:53AM +0800, Stephen Zhang wrote: > Andreas Dilger 于2023年8月2日周三 14:07写道: > > > > Not all of these cases are actual bugs. The ext4_rec_len_from_disk() > > function is only different for rec_len >= 2^16, so if it is comparing > > rec_len against "12" or "sizeof(struct ...)" then the inequality will > > be correct regardless of how it is decoded. > > > > That said, it makes sense to use ext4_rec_len_from_disk() to access > > rec_len consistently throughout the code, since that avoids potential > > bugs in the future. We know the code will eventually will be copied > > some place where rec_len >= 2^16 is actually important, and we may as > > well avoid that bug before it happens. > > > > > > One thing this discussion *does* expose is that ext4_rec_len_from_disk() > > is hard-coded at compile time to differentiate between PAGE_SIZE > 64k > > and PAGE_SIZE = 4K, because it was never possible to have blocksize > > > PAGE_SIZE, so only ARM/PPC ever had filesystems with blocksize=64KiB > > (and the Fujitsu Fugaku SPARC system with blocksize=256KiB). > > > > However, with the recent advent of the VM and IO layers allowing > > blocksize > PAGE_SIZE this function will need to be changed to allow > > the same on x86 PAGE_SIZE=4KiB systems. Instead of checking > > > > #if PAGE_SIZE >= 65536 > > > > it should handle this based on the filesystem blocksize at runtime: > > > > static inline > > unsigned int ext4_rec_len_from_disk(__le16 dlen, unsigned blocksize) > > { > > unsigned len = le16_to_cpu(dlen); > > > > if (blocksize < 65536) > > return len; > > > > if (len == EXT4_MAX_REC_LEN || len == 0) > > return blocksize; > > > > return (len & 65532) | ((len & 3) << 16); > > } > > > > Strictly speaking, ((len & 65532) | ((len & 3) << 16) should equal "len" > > for any filesystem with blocksize < 65536, but IMHO it is more clear if > > the code is written this way. > > > > Similarly, the encoding needs to be changed to handle large records at > > runtime for when we eventually allow ext4 with blocksize > PAGE_SIZE. > > > > static inline __le16 ext4_rec_len_to_disk(unsigned len, unsigned blocksize) > > { > > BUG_ON(len > blocksize); > > BUG_ON(blocksize > (1 << 18)); > > BUG_ON(len & 3); > > > > if (len < 65536) /* always true for blocksize < 65536 */ > > return cpu_to_le16(len); > > > > if (len == blocksize) { > > if (blocksize == 65536) > > return cpu_to_le16(EXT4_MAX_REC_LEN); > > > > return cpu_to_le16(0); > > } > > > > return cpu_to_le16((len & 65532) | ((len >> 16) & 3)); > > } > > > > Hmm, at least it sounds reasonable to me based on my limited > knowledge. However, I am not sure whether you want me to incorporate > these changes into this particular commit or another patch within this > submission. > > By default, I will simply leave it for further discussion. Please let > me know if you have any ideas. ext4 doesn't support blocksize > PAGE_SIZE yet. Don't worry about this for now. --D > Cheers, > Shida > > > > > Cheers, Andreas > > > > > > > > > >