Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp212847ybt; Thu, 9 Jul 2020 20:21:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzQmfZd5urN8zjC5dJG8RPsA9SoShb+9SaPxZ+rRaDBTGMAW/P8TZouzB97lPJy0ZMzLVVv X-Received: by 2002:a05:6402:2cb:: with SMTP id b11mr70812418edx.66.1594351268728; Thu, 09 Jul 2020 20:21:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594351268; cv=none; d=google.com; s=arc-20160816; b=gWl0z287Gj1dqZDgBwtPP/udq+FnzC2aXcQtVphMR5ypmzx9biCZL4YTNvQJQBT38a 5pKMVvo/zTUefQG9Smf0zdTpkWIALuEXnVQ8j/EeuRDg5Dg6sgKdbICq5rV7TMqxzkF8 z6EGAU/9CY3c32mic12o2qaVIJFrInlEnjnNltkcKeQSUh1LGKNyHOQOhvzfMotEmAoM H6ShyxfHkc0UxL4JMrjkPh2VUDbeAaVFG/czv4HMLArVMEGO/XoKmhMicsV14DSCASQ6 S4KiZ3AF/Q5NYPgeBgJ4ZB5LRVGxROWBvSY0Qz027Mc6ffBZ1fal83etnUjaQc3DOQqg l0JA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=TLUcgfD3vzj9e3+8HCJonIEbZ+/i+9gPCbAcc/AaAoA=; b=cBAfhUR7r8DZLOEJukwXmxrjm9QhBpbeglr6Bjgfo0rKdAxShHvDEWsI1CBu19Gf1s t6ijHGiP/AmmL/cVwd9LvZ8CqVD7AvukkvXfgW2jcJu0WE5nkly8NgRCNLHSUxP7Np04 FIxDwkrsdLG7EBtAy9pkjT8kdAduQOQzEUAbWi54G0BzmGDbufrUsDdEk6lFZcRqEphr zn7YFR34/OPWSxSFQ5DvZxQ8biK3LgvsU+G/9C9Fxyn7Hsa0HQUbfMOVjAIWVAz7iXGO 9p+f3xfrTRz7ZKU2UrlFmOJOgKEn8alHSYr2DFLoyGuSJdB9YWJ3n3LXpY8kDGvm2owJ DBYA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=OiLdpIIC; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n7si3183437ejk.154.2020.07.09.20.20.45; Thu, 09 Jul 2020 20:21:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=OiLdpIIC; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726989AbgGJDR7 (ORCPT + 99 others); Thu, 9 Jul 2020 23:17:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53214 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726560AbgGJDR7 (ORCPT ); Thu, 9 Jul 2020 23:17:59 -0400 Received: from mail-lj1-x241.google.com (mail-lj1-x241.google.com [IPv6:2a00:1450:4864:20::241]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F2D6FC08C5CE for ; Thu, 9 Jul 2020 20:17:58 -0700 (PDT) Received: by mail-lj1-x241.google.com with SMTP id r19so4734786ljn.12 for ; Thu, 09 Jul 2020 20:17:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=TLUcgfD3vzj9e3+8HCJonIEbZ+/i+9gPCbAcc/AaAoA=; b=OiLdpIICkkdCExTqxehNMdW0XGdYvLF283Yg/MiIIyL6LH6V/AF3qDNbEGFpM4BgEL THMtJENwHsN5Xkl3lVtkh+XrShOrvqGvhLo1/CIGqWi9Im8FPgaYdrw1+uap0axzIbWb t5kjTyXP9yOdStfM+G0kzZpBOzXx4S0YG/bYM/VooVLvLLl1UJmw1FwlDv9sN+xz/v+3 g17yc9mJURCJ7zpvsU+LBr/ku0k6gk11bR0x8iVYQTwhsJjsImi8M1WqhxFI1RXpes3r zsklDNjVE+8dfs9DymIY5ddzL337f2pFAqgszwLG7STArcA1wH6LZzpJ+D/NR8L2QevP ZGnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=TLUcgfD3vzj9e3+8HCJonIEbZ+/i+9gPCbAcc/AaAoA=; b=D84GwlhB8nj39sf++SyIO7T6jNLMUjby3AkjOnEhGBuFm8ucmkXS8FDNCzZXI7Lv1i m1JKJ7mvz1nCJsRm2aNsqWmfpk+d4WTPSdDLf269B7L29gJLOXI5pMWPLmzn3mT2Aoy2 mc7W0rvzjzIyoJvVNe7CIrJxt0chguRTuXnelxgWBxK2p0LJEIN4sf0NGKnwvpFx39Fw vZu9mlc4GY08BFuv3XlqnyTYvM1GVkjPw0sVLEOzZ3FXZNAqnvl6mjUA++bqWvdW7sMR pUfU+BRHf2Wh/2hIH1ze3KLfpEqnciLAzJAgYN4J80JvZlZh7e9SJOCytdeCbY/j/yYL 6efw== X-Gm-Message-State: AOAM531ldeZfgH58kFpf99RK98WqVktSz+hzs/dQ2mX0jmfr8/U/1cii EYCFHn+YrOe8xEmztNjRe/HF9ro3deO21pPvK2VoYkffmpPmDg== X-Received: by 2002:a2e:7c07:: with SMTP id x7mr28142677ljc.166.1594351077346; Thu, 09 Jul 2020 20:17:57 -0700 (PDT) MIME-Version: 1.0 References: <20200710021505.2405872-1-daeho43@gmail.com> <20200710030246.GA545837@google.com> In-Reply-To: <20200710030246.GA545837@google.com> From: Daeho Jeong Date: Fri, 10 Jul 2020 12:17:46 +0900 Message-ID: Subject: Re: [f2fs-dev] [PATCH] f2fs: change the way of handling range.len in F2FS_IOC_SEC_TRIM_FILE To: Jaegeuk Kim Cc: linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, kernel-team@android.com, Daeho Jeong Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 1. The valid data will be within i_size. 2. All the trim operations will be done in a unit of block, even if i_size is not aligned with BLKSIZE like the below. index =3D F2FS_BYTES_TO_BLK(range.start); pg_end =3D DIV_ROUND_UP(end_addr, F2FS_BLKSIZE); <=3D BLKSIZE a= ligned Are you worried about the case that sudden power-off occurs while a file is being truncated? ex) 1GB file is being truncated to 4KB -> sudden power-off -> i_size(4KB), i_blocks(maybe somewhere between 4KB and 1GB) 2020=EB=85=84 7=EC=9B=94 10=EC=9D=BC (=EA=B8=88) =EC=98=A4=ED=9B=84 12:02, = Jaegeuk Kim =EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1: > > On 07/10, Daeho Jeong wrote: > > From: Daeho Jeong > > > > Changed the way of handling range.len of F2FS_IOC_SEC_TRIM_FILE. > > 1. Added -1 value support for range.len to signify the end of file. > > 2. If the end of the range passes over the end of file, it means until > > the end of file. > > 3. ignored the case of that range.len is zero to prevent the function > > from making end_addr zero and triggering different behaviour of > > the function. > > > > Signed-off-by: Daeho Jeong > > --- > > fs/f2fs/file.c | 16 +++++++--------- > > 1 file changed, 7 insertions(+), 9 deletions(-) > > > > diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c > > index 368c80f8e2a1..1c4601f99326 100644 > > --- a/fs/f2fs/file.c > > +++ b/fs/f2fs/file.c > > @@ -3813,21 +3813,19 @@ static int f2fs_sec_trim_file(struct file *filp= , unsigned long arg) > > file_start_write(filp); > > inode_lock(inode); > > > > - if (f2fs_is_atomic_file(inode) || f2fs_compressed_file(inode)) { > > + if (f2fs_is_atomic_file(inode) || f2fs_compressed_file(inode) || > > + range.start >=3D inode->i_size) { > > ret =3D -EINVAL; > > goto err; > > } > > > > - if (range.start >=3D inode->i_size) { > > - ret =3D -EINVAL; > > + if (range.len =3D=3D 0) > > goto err; > > - } > > > > - if (inode->i_size - range.start < range.len) { > > - ret =3D -E2BIG; > > - goto err; > > - } > > - end_addr =3D range.start + range.len; > > + if (range.len =3D=3D (u64)-1 || inode->i_size - range.start < ran= ge.len) > > + end_addr =3D inode->i_size; > > Hmm, what if there are blocks beyond i_size? Do we need to check i_blocks= for > ending criteria? > > > + else > > + end_addr =3D range.start + range.len; > > > > to_end =3D (end_addr =3D=3D inode->i_size); > > if (!IS_ALIGNED(range.start, F2FS_BLKSIZE) || > > -- > > 2.27.0.383.g050319c2ae-goog > > > > > > > > _______________________________________________ > > Linux-f2fs-devel mailing list > > Linux-f2fs-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel