Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp430622pxb; Thu, 31 Mar 2022 08:35:36 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyUFDYJKXzwGzP4YSo6QIxEd6bySLPnE0lF5vfBsUW+OWAbCgoTzL8ACwrTfhNYZCV1NbnE X-Received: by 2002:a17:90b:1e04:b0:1c6:fb36:9d93 with SMTP id pg4-20020a17090b1e0400b001c6fb369d93mr6617297pjb.57.1648740936740; Thu, 31 Mar 2022 08:35:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1648740936; cv=none; d=google.com; s=arc-20160816; b=UA3ic4n8lWCZczQ2TiU+wNm+rh8OBd7Zpwul1T2idLyM3neSKwLUNHj1uO+PnCXKfK z60QcP+w9eLwJ6aBZPWm07JR+qOvlZTHP/BefTejxZUOcGywrBPqJRRZvoSp5xyD83oS UjOzINea73dmUFHTYVm7Uiv3T0FGBBkvostkHscSzKT2LcjN0YHsnc0o/ywaJJLNqjOb sRZcbtV5G5ovJiq3dnDyF/+PsCh6K/2zsw+p3OHYUGge/eqZ97ADfEViiKqrFaKbgodv IqXExKudA5cGiw+z1KGB8D7c6Qf41t5p1bJyGq/ZGMkMq8yun8A6uoHT8HfAkXATsa/I qqmA== 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=U+CJTazR3n6ZLUaABSz4xJrbiz+Tyenf+VTmvsme8V0=; b=KQnWzqGeTt6NQ2ctvKxNTW2kEtX8htqmp7z8bcpCSB2nX/T8C5moH5LcpChEGbl929 DWMbLFEz93gf9jlJI+ReP4poxrs+5Fui/SI1+QXPdzBW2qZKNsVUQeiMlOpHWFl5aFQR XujaznF8ksjKrxQKnzB9nEIaXbUvI8HZqEG3C0ol04zfh2iuocF1O9kglVFCzjqOk3gA BdW5NdPi5yfw43fbS6S4dwTQdLdxDwO1jEiNAdSrA4AahhAnVEHil+o1iFX/+g5UCHDe y/Fd/njMfZg1Ekan4wrapDtaxr48Ivzc8Dzz+lKJr1G+kdPRaxE1VqvbghA2ut3mQjqk T86A== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=mit.edu Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id kb4-20020a17090ae7c400b001bf2eed25aesi4040596pjb.32.2022.03.31.08.35.15; Thu, 31 Mar 2022 08:35:36 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=mit.edu Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233311AbiCaOpB (ORCPT + 99 others); Thu, 31 Mar 2022 10:45:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39272 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232975AbiCaOpA (ORCPT ); Thu, 31 Mar 2022 10:45:00 -0400 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 95612215928; Thu, 31 Mar 2022 07:43:13 -0700 (PDT) Received: from cwcc.thunk.org (pool-108-7-220-252.bstnma.fios.verizon.net [108.7.220.252]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 22VEh4kl015789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 31 Mar 2022 10:43:05 -0400 Received: by cwcc.thunk.org (Postfix, from userid 15806) id 8647215C003E; Thu, 31 Mar 2022 10:43:04 -0400 (EDT) Date: Thu, 31 Mar 2022 10:43:04 -0400 From: "Theodore Ts'o" To: Tadeusz Struk Cc: Andreas Dilger , Ritesh Harjani , linux-ext4@vger.kernel.org, stable@vger.kernel.org, linux-kernel@vger.kernel.org, syzbot+7a806094edd5d07ba029@syzkaller.appspotmail.com Subject: Re: [PATCH v2] ext4: check if offset+length is valid in fallocate Message-ID: References: <20220315215439.269122-1-tadeusz.struk@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220315215439.269122-1-tadeusz.struk@linaro.org> X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,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-ext4@vger.kernel.org On Tue, Mar 15, 2022 at 02:54:39PM -0700, Tadeusz Struk wrote: > @@ -3967,6 +3968,16 @@ int ext4_punch_hole(struct inode *inode, loff_t offset, loff_t length) > offset; > } > > + /* > + * For punch hole the length + offset needs to be at least within > + * one block before last > + */ > + max_length = sbi->s_bitmap_maxbytes - inode->i_sb->s_blocksize; > + if (offset + length >= max_length) { > + ret = -ENOSPC; > + goto out_mutex; > + } I wonder if we would be better off just simply capping length to max_length? If length is set to some large value, such as LONG_MAX, it's pretty clear what the intention should be, which is to simply do the equivalent of truncating the file at offset. Perhaps we should just do that? That being said, we should be consistent with what other file systems do when they are asked to punch a hole starting at offset and extending out to LONG_MAX. Also, if we are going to return an error, I don't think ENOSPC is the correct error to be returning. - Ted