Received: by 2002:a05:6358:489b:b0:bb:da1:e618 with SMTP id x27csp4597324rwn; Sun, 11 Sep 2022 16:24:21 -0700 (PDT) X-Google-Smtp-Source: AA6agR5sDc5w9cUfaIMTrEy1rS57IEMKqYKfPdoZ5lRSaTKSeXMg5A16f99aMW3YuGdLEmJfBobn X-Received: by 2002:a65:6693:0:b0:434:a2ca:2330 with SMTP id b19-20020a656693000000b00434a2ca2330mr20929071pgw.227.1662938661048; Sun, 11 Sep 2022 16:24:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662938661; cv=none; d=google.com; s=arc-20160816; b=NlkYznNJlhxe6DwNCeO5HgSH4rhPrfMxf22Iu16LflF9NkQYdPZenRKUSDRl+VM4Lm R1AQfi4Akmxo/bpGeNrEaRJCG/hZn0TqrRKzd8FyP0pSUHfIWy1nwkD8EUpQwm0xclcX sNBFxtxl3LHaxTcnTL75KGZ1EFo60IrGBVHa2AXQnsqMDAscy18GXY+uYOkm9UG1CqSz BCYHYxSVY3ABHwIjwCeL9I6zE4Qa9y9fK1K1DdvW+AWFpT1z0DmR/0l0ylslUrdcyAZ6 jIpG1e0fOxTSuofYyy7DbLTjSP5ckw8i6Q1+aBp0WHi/OGdWKM02KFxbBngrJ4ANVO3x GM6w== 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-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=SQvGFKTKdiPAgGzDPBt9vT8K4Vo8WEDfKqa97d5d/Pk=; b=XOyzNttICHhtXzGParBztdVWoL5vYjN6lKe9kddXlCdcbS0NgEtHhGW+uDtatHOH40 mK3J3oz4rF29cbD9gQhX7u2Jmw+fsD11RMu4UEbBpoSp9cCMfUqCDsbszjjohV48aTCj NPnlHP9KItLh0EGWU2MWNHVkM0+vKf7eevUPJmDOrVsVnse03OvBXcgZZK/+YrZshECw 3vafda7ikBHlqD57ZEiswq/rhZzCrNZexvyTX5brYcqPRuUryuw049H24csFNo0L/j7a a/LXIYVzXBsTZsTZhblmoN1J6g/u3J6cfmy/djVJFuw+MyN0lFc7gKsOo2wkBUZLEYYU DEkA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i186-20020a6254c3000000b00540c66456b7si6416508pfb.153.2022.09.11.16.24.07; Sun, 11 Sep 2022 16:24:21 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-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; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229446AbiIKXM5 (ORCPT + 99 others); Sun, 11 Sep 2022 19:12:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57832 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229533AbiIKXM4 (ORCPT ); Sun, 11 Sep 2022 19:12:56 -0400 Received: from mail105.syd.optusnet.com.au (mail105.syd.optusnet.com.au [211.29.132.249]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 83F1B24097; Sun, 11 Sep 2022 16:12:55 -0700 (PDT) Received: from dread.disaster.area (pa49-186-149-49.pa.vic.optusnet.com.au [49.186.149.49]) by mail105.syd.optusnet.com.au (Postfix) with ESMTPS id 6F34E110063D; Mon, 12 Sep 2022 09:12:53 +1000 (AEST) Received: from dave by dread.disaster.area with local (Exim 4.92.3) (envelope-from ) id 1oXW8B-006d0R-W2; Mon, 12 Sep 2022 09:12:52 +1000 Date: Mon, 12 Sep 2022 09:12:51 +1000 From: Dave Chinner To: Stephen Zhang Cc: djwong@kernel.org, dchinner@redhat.com, chandan.babu@oracle.com, zhangshida@kylinos.cn, linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org Subject: Re: [PATCH] xfs: remove the redundant check in xfs_bmap_first_unused Message-ID: <20220911231251.GA3600936@dread.disaster.area> References: <20220909030756.3916297-1-zhangshida@kylinos.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220909030756.3916297-1-zhangshida@kylinos.cn> X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.4 cv=OJNEYQWB c=1 sm=1 tr=0 ts=631e6b76 a=XTRC1Ovx3SkpaCW1YxGVGA==:117 a=XTRC1Ovx3SkpaCW1YxGVGA==:17 a=kj9zAlcOel0A:10 a=xOM3xZuef0cA:10 a=7-415B0cAAAA:8 a=d4ToVRSH_LyJE6_9r9cA:9 a=CjuIK1q_8ugA:10 a=biEYGPWJfzWAr4FL6Ov7:22 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE,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-kernel@vger.kernel.org On Fri, Sep 09, 2022 at 11:07:56AM +0800, Stephen Zhang wrote: > Given that > max >= lowest, > hence if > got.br_startoff >= max + len, > then, at the same time, > got.br_startoff >= lowest + len, > > So the check here is redundant, remove it. Check your types: what happens when *first_unused = XFS_DIR2_LEAF_OFFSET? > Signed-off-by: Shida Zhang > --- > fs/xfs/libxfs/xfs_bmap.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/fs/xfs/libxfs/xfs_bmap.c b/fs/xfs/libxfs/xfs_bmap.c > index e56723dc9cd5..f8a984c41b01 100644 > --- a/fs/xfs/libxfs/xfs_bmap.c > +++ b/fs/xfs/libxfs/xfs_bmap.c > @@ -1230,8 +1230,7 @@ xfs_bmap_first_unused( > /* > * See if the hole before this extent will work. > */ > - if (got.br_startoff >= lowest + len && > - got.br_startoff - max >= len) > + if (got.br_startoff - max >= len) > break; > lastaddr = got.br_startoff + got.br_blockcount; > max = XFS_FILEOFF_MAX(lastaddr, lowest); This loop does a linear scan of the extent list, so it starts at extent index zero which will be got.br_startoff = 0 for the first directory data block. When we are called from xfs_da_grow_inode_int(), we're trying to add blocks in the directory leaf btree segment here. Hence the lowest file offset we want to search for a hole is XFS_DIR2_LEAF_OFFSET. Given that all the types and comparisons involved are 64 bit unsigned: typedef uint64_t xfs_fileoff_t; /* block number in a file */ #define XFS_FILEOFF_MAX(a,b) max_t(xfs_fileoff_t, (a), (b)) xfs_fileoff_t br_startoff; xfs_fileoff_t lastaddr = 0; xfs_fileoff_t lowest, max; We end up with the following calculations (in FSBs, not bytes): lowest + len = 0x800000ULL + 1 = 0x800001ULL got.br_startoff - max = 0ULL - 0x800000 = 0xffffffffff800000ULL and so the existing check is: if (0 >= 0x800001ULL && 0xffffffffff800000 >= 1) which evaluates as false because the extent that was found is not beyond the initial offset (first_unused) that we need to start searching at. With your modification, this would now evaluate as: if (0xffffffffff800000 >= 1) Because of the underflow, this would then evaluate as true and we'd return 0 as the first unused offset. This is incorrect as we do not have a hole at offset 0, nor is it within the correct directory offset segment, nor is it within the search bounds we have specified. If these were all signed types, then your proposed code might be correct. But they are unsigned and hence we have to ensure that we handle overflow/underflow appropriately. Which leads me to ask: did you test this change before you send it to the list? Cheers, Dave. -- Dave Chinner david@fromorbit.com