On 2019/1/21 11:37, Jaegeuk Kim wrote:
> On 01/09, Chao Yu wrote:
>> On 2019/1/9 12:42, Jaegeuk Kim wrote:
>>> On 01/09, Chao Yu wrote:
On 2019/1/9 7:46, Jaegeuk Kim wrote:
> On 12/10, Chao Yu wrote:
>> stat() can fail due to a lot of reasons, let f2fs_dev_is_umounted()
>> detect s
Thread AThread B
- __fput
- f2fs_release_file
- drop_inmem_pages
- mutex_lock(&fi->inmem_lock)
- __revoke_inmem_pages
- lock_page(page)
- open
- f2fs_setattr
The following race could lead to data block override node segment by mistake.
Task A|Task B | Task C|Task D
=== | |== | =
open file | ||
white file
On Fri, 2019-01-18 at 09:19 +0100, Greg Kroah-Hartman wrote:
> On Thu, Jan 17, 2019 at 07:28:47PM +, Ben Hutchings wrote:
> > I've backported fixes for several security issues involving
> > filesystem
> > validation in f2fs. All of these are already fixed in the later
> > stable
> > branches.
On 01/14, Chao Yu wrote:
> As reported by Aravind:
>
> I built f2fs tools from source (at tag v1.12.0) and was able to get this
> backtrace in gdb:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x77f8eb54 in f2fs_set_bit (nr=1041170432,
> addr=0x7f621010 0x7f621
When we umount f2fs, we need to avoid long delay due to discard commands, which
is actually taking tens of seconds, if storage is very slow on UNMAP. So, this
patch introduces timeout-based work on it.
By default, let me give 5 seconds for discard.
Signed-off-by: Jaegeuk Kim
---
Documentation/A
Some works after roll-forward recovery can get an error which will release
all the data structures. Let's flush them in order to make it clean.
One possible corruption came from:
[ 90.400500] list_del corruption. prev->next should be ffed1f566208, but
was (null)
[ 90.675349] Call trace:
From: Eric Biggers
Currently, trying to rename or link a regular file, directory, or
symlink into an encrypted directory fails with EPERM when the source
file is unencrypted or is encrypted with a different encryption policy,
and is on the same mountpoint. It is correct for the operation to fail
On 2019/1/22 22:01, zhengliang wrote:
> The following race could lead to data block override node segment by mistake.
>
> Task A|Task B | Task C|Task D
> === | |== | =
> open file |
On 2019/1/23 7:59, Jaegeuk Kim wrote:
> On 01/14, Chao Yu wrote:
>> As reported by Aravind:
>>
>> I built f2fs tools from source (at tag v1.12.0) and was able to get this
>> backtrace in gdb:
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x77f8eb54 in f2fs_set_bit (nr=10411
Apologies for the delay in getting responding; I've been on vacation
last week.
On Tue, Jan 15, 2019 at 10:41:01AM +1100, Dave Chinner wrote:
> > int ioctl(fd, FS_IOC_ENABLE_VERITY, struct fsverity_arg *arg);
> >
> > struct fsverity_arg {
> >int fsv_donor_fd;
> >u64 fsv_offset;
>
On 2019/1/21 8:54, Phillip Potter wrote:
> Deduplicate the f2fs file type conversion implementation and remove
> F2FS_FT_* definitions - file systems that use the same file types
> as defined by POSIX do not need to define their own versions and can
> use the common helper functions decared in fs_t
When sb->s_root is NULL dput() will do nothing,
so jump to label 'free_node_inode' instead of lable
'free_root_inode' when failing from d_make_root().
Signed-off-by: Chengguang Xu
---
fs/f2fs/super.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/f2fs/super.c b/fs/f2fs/su
13 matches
Mail list logo