Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp1716371ybh; Tue, 14 Jul 2020 05:37:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzuEStJCIl66daWEd16jnI5GHyd1w9Y9XJANRA7W3oPKi6ossfzLujJFH10hUZS/VrU7LNU X-Received: by 2002:a50:cd53:: with SMTP id d19mr4354409edj.300.1594730257596; Tue, 14 Jul 2020 05:37:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594730257; cv=none; d=google.com; s=arc-20160816; b=fOx8nResIgvh/JzlYKAeo0w2UlhKgLr1tvsZ91X0kVfYgNwPgWm5zZIIfn0jGXBVq6 DspvOC+bQ5VByw0DoT0D4GPK76kVjhGuwwrQseESXc9ybqpCEGFXxa0O83a0Hee9HT3H 4XlY327frDI0169RAUkKGAu9Jh2EZL78b4D+KnbkkqZHDOueP0jOo4MRhrEInzTa4D3t ANxl8g4y9tYRStl9ZMFsF8nbIOES4EcpwTQT+fCWT5ukNW/ttpmsE/HhCcIrPfwRdqu6 /JRRsYf2OmQBBE7aLOM0qcvPTtOdVhtIUOySuhlR66IM4A83BjJBW+yyXIXgulqXI7qz t5BQ== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=2zIfUcj9fz85h6yvWkycPud2ao6ImmQdV5ODS2b6af8=; b=Y9nsT8AFDpvVR+vjjFB4h87DUF+6A2OyyBeLD1C3sfPr/SaTniPMLRFUXiH+wwNMoE oU6euSvskWjt+O7rNBOEV9Cg4ChR19KasI8TbHBfRAiCo6qlR0nBKZiL2QelmGjAL6W9 hq3L7vy86IaLi4nRovZHxYtvFQX5K1zx7ebBF89tDnaYsEEtZI0aQRg0+K9kYe7ehNRR Tq/783lVZOHubZ44EBljJ+3CT3LulhzPzrFrOdAaI++e1wrBQJfdU079zp2H6QeQ/0op t1DN0F25OwCiAPANove1+6BfAA84QtHoV1JdOfM1omQ/QJTgbkxfBJPDFWqhe9ke44Gv FkYQ== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l23si11144055ejq.14.2020.07.14.05.37.15; Tue, 14 Jul 2020 05:37:37 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728276AbgGNMgm (ORCPT + 99 others); Tue, 14 Jul 2020 08:36:42 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:7850 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726889AbgGNMgk (ORCPT ); Tue, 14 Jul 2020 08:36:40 -0400 Received: from DGGEMS402-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id E489B6DA7482A55E837A; Tue, 14 Jul 2020 20:36:37 +0800 (CST) Received: from [10.134.22.195] (10.134.22.195) by smtp.huawei.com (10.3.19.202) with Microsoft SMTP Server (TLS) id 14.3.487.0; Tue, 14 Jul 2020 20:36:32 +0800 Subject: Re: [f2fs-dev] [PATCH v2] f2fs: change the way of handling range.len in F2FS_IOC_SEC_TRIM_FILE To: Jaegeuk Kim , Daeho Jeong CC: Daeho Jeong , , , References: <20200713031252.3873546-1-daeho43@gmail.com> <20200713181152.GC2910046@google.com> From: Chao Yu Message-ID: <3b02263d-a5e1-136c-40ed-514d34e4c895@huawei.com> Date: Tue, 14 Jul 2020 20:36:31 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20200713181152.GC2910046@google.com> Content-Type: text/plain; charset="windows-1252" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.134.22.195] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020/7/14 2:11, Jaegeuk Kim wrote: > Hi Daeho, > > Please take a look at this. > > https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git/commit/?h=dev&id=35245180459aebf6d70fde88a538f0400a794aa6 I'm curious about what will happen if we call sec_trim_file(F2FS_TRIM_FILE_ZEROOUT) on an encrypted file, will it use zero bits covering encrypted data on disk? Thanks, > > Thanks, > > On 07/13, 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 secure trim the whole blocks >> starting from range.start regardless of i_size. >> 2. If the end of the range passes over the end of file, it means until >> the end of file (i_size). >> 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 >> --- >> Changes in v2: >> - Changed -1 range.len option to mean the whole blocks starting from >> range.start regardless of i_size >> --- >> fs/f2fs/file.c | 23 ++++++++++++----------- >> 1 file changed, 12 insertions(+), 11 deletions(-) >> >> diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c >> index 368c80f8e2a1..2485841e3b2d 100644 >> --- a/fs/f2fs/file.c >> +++ b/fs/f2fs/file.c >> @@ -3792,7 +3792,7 @@ static int f2fs_sec_trim_file(struct file *filp, unsigned long arg) >> pgoff_t index, pg_end; >> block_t prev_block = 0, len = 0; >> loff_t end_addr; >> - bool to_end; >> + bool to_end = false; >> int ret = 0; >> >> if (!(filp->f_mode & FMODE_WRITE)) >> @@ -3813,23 +3813,23 @@ 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 >= inode->i_size) { >> ret = -EINVAL; >> goto err; >> } >> >> - if (range.start >= inode->i_size) { >> - ret = -EINVAL; >> + if (range.len == 0) >> goto err; >> - } >> >> - if (inode->i_size - range.start < range.len) { >> - ret = -E2BIG; >> - goto err; >> + if (inode->i_size - range.start > range.len) { >> + end_addr = range.start + range.len; >> + } else { >> + end_addr = range.len == (u64)-1 ? >> + sbi->sb->s_maxbytes : inode->i_size; >> + to_end = true; >> } >> - end_addr = range.start + range.len; >> >> - to_end = (end_addr == inode->i_size); >> if (!IS_ALIGNED(range.start, F2FS_BLKSIZE) || >> (!to_end && !IS_ALIGNED(end_addr, F2FS_BLKSIZE))) { >> ret = -EINVAL; >> @@ -3846,7 +3846,8 @@ static int f2fs_sec_trim_file(struct file *filp, unsigned long arg) >> down_write(&F2FS_I(inode)->i_gc_rwsem[WRITE]); >> down_write(&F2FS_I(inode)->i_mmap_sem); >> >> - ret = filemap_write_and_wait_range(mapping, range.start, end_addr - 1); >> + ret = filemap_write_and_wait_range(mapping, range.start, >> + to_end ? LLONG_MAX : end_addr - 1); >> if (ret) >> goto out; >> >> -- >> 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 > . >