To handle that case, I think we need to handle range.len(-1) differently. When range.len is -1, we need to find out every block belongs to the inode regardless of i_size and discard it.
2020년 7월 10일 (금) 오후 12:52, Jaegeuk Kim <jaeg...@kernel.org>님이 작성: > > On 07/10, Chao Yu wrote: > > On 2020/7/10 11:31, Jaegeuk Kim wrote: > > > On 07/10, Chao Yu wrote: > > >> On 2020/7/10 11:02, Jaegeuk Kim wrote: > > >>> On 07/10, Daeho Jeong wrote: > > >>>> From: Daeho Jeong <daehoje...@google.com> > > >>>> > > >>>> 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 <daehoje...@google.com> > > >>>> --- > > >>>> 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 >= 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; > > >>>> - } > > >>>> - end_addr = range.start + range.len; > > >>>> + if (range.len == (u64)-1 || inode->i_size - range.start < > > >>>> range.len) > > >>>> + end_addr = inode->i_size; > > >> > > >> We can remove 'range.len == (u64)-1' condition since later condition can > > >> cover > > >> this? > > >> > > >>> > > >>> Hmm, what if there are blocks beyond i_size? Do we need to check > > >>> i_blocks for > > >> > > >> The blocks beyond i_size will never be written, there won't be any valid > > >> message > > >> there, so we don't need to worry about that. > > > > > > I don't think we have a way to guarantee the order of i_size and block > > > allocation in f2fs. See f2fs_write_begin and f2fs_write_end. > > > > However, write_begin & write_end are covered by inode_lock, it could not be > > racy with inode size check in f2fs_sec_trim_file() as it hold inode_lock as > > well? > > Like Daeho said, write_begin -> checkpoint -> power-cut can give bigger > i_blocks > than i_size. > > > > > > > > >> > > >> Thanks, > > >> > > >>> ending criteria? > > >>> > > >>>> + else > > >>>> + end_addr = range.start + range.len; > > >>>> > > >>>> to_end = (end_addr == inode->i_size); > > >>>> if (!IS_ALIGNED(range.start, F2FS_BLKSIZE) || > > >>>> -- > > >>>> 2.27.0.383.g050319c2ae-goog > > >>>> > > >>>> > > >>>> > > >>>> _______________________________________________ > > >>>> Linux-f2fs-devel mailing list > > >>>> linux-f2fs-de...@lists.sourceforge.net > > >>>> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel > > >>> > > >>> > > >>> _______________________________________________ > > >>> Linux-f2fs-devel mailing list > > >>> linux-f2fs-de...@lists.sourceforge.net > > >>> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel > > >>> . > > >>> > > > . > > >