Re: [GIT PULL] ext4 fixes for v5.12

On 2021/3/22 6:23, Linus Torvalds wrote: > On Sun, Mar 21, 2021 at 11:31 AM Theodore Ts'o wrote: >> >> zhangyi (F) (3): >> ext4: find old entry again if failed to rename whiteout >> ext4: do not iput inode under running transaction in ext4_rename() >&

Re: [PATCH 4.9 15/39] jbd2: add the missing unlock_buffer() in the error path of jbd2_write_superblock()

Fixes: 742b06b5628f ("jbd2: check superblock mapped prior to committing") > Signed-off-by: zhangyi (F) > Reviewed-by: Ritesh Harjani > Cc: sta...@kernel.org > Link: https://lore.kernel.org/r/20200620061948.2049579-1-yi.zh...@huawei.com > Signed-off-by: Theodore Ts'o >

Re: [PATCH v2] aio: add timeout validity check for io_[p]getevents

On 2019/7/30 15:11, Arnd Bergmann Wrote: > On Tue, Jul 30, 2019 at 3:46 AM zhangyi (F) wrote: > >> { >> - ktime_t until = ts ? timespec64_to_ktime(*ts) : KTIME_MAX; >> - struct kioctx *ioctx = lookup_ioctx(ctx_id); >> + ktime_t until = KTIME

[PATCH v2] aio: add timeout validity check for io_[p]getevents

io_[p]getevents syscall should return -EINVAL if timeout is out of range, add this validity check. Signed-off-by: zhangyi (F) Reviewed-by: Jeff Moyer Cc: Jeff Moyer Cc: Arnd Bergmann Cc: Deepa Dinamani --- Changes since v1: - add Reviewed-by and Cc tags. fs/aio.c | 11 +-- 1 file

Re: [PATCH] aio: add timeout validity check for io_[p]getevents

On 2019/7/29 23:59, Jeff Moyer Wrote: > Al Viro writes: > >> On Mon, Jul 29, 2019 at 10:57:41AM -0400, Jeff Moyer wrote: >>> Al, can you take this through your tree? >> >> Umm... Can do, but I had an impression that Arnd and Deepa >> had a tree for timespec-related work. OTOH, it had been >>

[PATCH] aio: add timeout validity check for io_[p]getevents

io_[p]getevents syscall should return -EINVAL if if timeout is out of range, add this validity check. Signed-off-by: zhangyi (F) --- fs/aio.c | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/fs/aio.c b/fs/aio.c index 01e0fb9..dd967a0 100644 --- a/fs/aio.c +++ b/fs

Re: ext3 file system livelock and file system corruption, 4.9.166 stable kernel

Hi Jari, Sorry about introduce this livelocks bug. The patch 674a2b272 ("ext4: brelse all indirect buffer in ext4_ind_remove_space()") want to fix a buffer leak problem. The follow-up patch 5e86bdda415 ("ext4: cleanup bh release code in ext4_ind_remove_space()") was just want to do some cleanup

Re: [PATCH] tracing: fix incorrect tracer freeing when opening tracing pipe

On 2019/2/13 21:36, Steven Rostedt Wrote: > On Wed, 13 Feb 2019 20:29:06 +0800 > "zhangyi (F)" wrote: > >> Commit d716ff71dd12 ("tracing: Remove taking of trace_types_lock in >> pipe files") use the current tracer instead of the copy in >> tracing_o

[PATCH] tracing: fix incorrect tracer freeing when opening tracing pipe

k in pipe files") Signed-off-by: zhangyi (F) --- kernel/trace/trace.c | 1 - 1 file changed, 1 deletion(-) diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index c521b73..b583ff7 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -5624,7 +5624,6 @@ static int tracing_open_pipe

Re: xattr hash error in 4.13-rc with overlayfs over ext4

On 2017/8/3 19:10, Miklos Szeredi Wrote: On Tue, Aug 1, 2017 at 12:34 PM, Amir Goldstein wrote: On Mon, Jul 31, 2017 at 7:08 PM, Miklos Szeredi wrote: On Thu, Jul 27, 2017 at 10:54 PM, Tahsin Erdogan wrote: Still no luck reproducing

Re: xattr hash error in 4.13-rc with overlayfs over ext4

On 2017/8/3 19:10, Miklos Szeredi Wrote: On Tue, Aug 1, 2017 at 12:34 PM, Amir Goldstein wrote: On Mon, Jul 31, 2017 at 7:08 PM, Miklos Szeredi wrote: On Thu, Jul 27, 2017 at 10:54 PM, Tahsin Erdogan wrote: Still no luck reproducing the error. I am using the test script below at v4.13-rc2.

Re: [PATCH 4/9] vfs: intercept reads to overlay files

On 2017/2/18 00:10, Miklos Szeredi wrote: > diff --git a/fs/open.c b/fs/open.c > index 9921f70bc5ca..4916ccff29f5 100644 > --- a/fs/open.c > +++ b/fs/open.c > @@ -762,6 +762,8 @@ static int do_dentry_open(struct file *f, > if ((f->f_mode & FMODE_WRITE) && >likely(f->f_op->write

Re: [PATCH 4/9] vfs: intercept reads to overlay files

On 2017/2/18 00:10, Miklos Szeredi wrote: > diff --git a/fs/open.c b/fs/open.c > index 9921f70bc5ca..4916ccff29f5 100644 > --- a/fs/open.c > +++ b/fs/open.c > @@ -762,6 +762,8 @@ static int do_dentry_open(struct file *f, > if ((f->f_mode & FMODE_WRITE) && >likely(f->f_op->write

Re: [PATCH] fs: ext3/ext4: increase the protection of nlink dec and inode destroy

please ignore this, sorry. on 2017/2/6 20:35, yi zhang said: > From: zhangyi > > Because of the disk and hardware issue, the ext3/4 filesystem have > many errors, the inode->i_nlink of ext3/4 becomes zero abnormally > but the dentry is still positive, it will cause memory

Re: [PATCH] fs: ext3/ext4: increase the protection of nlink dec and inode destroy

please ignore this, sorry. on 2017/2/6 20:35, yi zhang said: > From: zhangyi > > Because of the disk and hardware issue, the ext3/4 filesystem have > many errors, the inode->i_nlink of ext3/4 becomes zero abnormally > but the dentry is still positive, it will cause memory corruption > after the

Re: [RFC PATCH] ext4: increase the protection of drop nlink and ext4 inode destroy

on 2017/1/11 23:34, Theodore Ts'o wrote: > On Wed, Jan 11, 2017 at 05:07:29PM +0800, zhangyi (F) wrote: >> >> (1) The file we want to unlink have many hard links, but only one dcache >> entry in memory. >> (2) open this file, but it's inode->i_nlink read from dis

Re: [RFC PATCH] ext4: increase the protection of drop nlink and ext4 inode destroy

on 2017/1/11 23:34, Theodore Ts'o wrote: > On Wed, Jan 11, 2017 at 05:07:29PM +0800, zhangyi (F) wrote: >> >> (1) The file we want to unlink have many hard links, but only one dcache >> entry in memory. >> (2) open this file, but it's inode->i_nlink read from dis

Re: [RFC PATCH] ext4: increase the protection of drop nlink and ext4 inode destroy

on 2017/1/11 23:34, Theodore Ts'o wrote: > On Wed, Jan 11, 2017 at 05:07:29PM +0800, zhangyi (F) wrote: >> >> (1) The file we want to unlink have many hard links, but only one dcache >> entry in memory. >> (2) open this file, but it's inode->i_nlink read from dis

Re: [RFC PATCH] ext4: increase the protection of drop nlink and ext4 inode destroy

on 2017/1/11 23:34, Theodore Ts'o wrote: > On Wed, Jan 11, 2017 at 05:07:29PM +0800, zhangyi (F) wrote: >> >> (1) The file we want to unlink have many hard links, but only one dcache >> entry in memory. >> (2) open this file, but it's inode->i_nlink read from dis

Re: [RFC PATCH] ext4: increase the protection of drop nlink and ext4 inode destroy

on 2017/1/5 7:35, Theodore Ts'o wrote: > On Wed, Jan 04, 2017 at 01:54:24PM -0800, Darrick J. Wong wrote: >> >> if (inode->i_nlink == 0) { >> ext4_warning_inode(inode, "nlink is already 0"); >> return; >> } > > We can't do that because the place where Zhangyi is proposing to > change

Re: [RFC PATCH] ext4: increase the protection of drop nlink and ext4 inode destroy

on 2017/1/5 7:35, Theodore Ts'o wrote: > On Wed, Jan 04, 2017 at 01:54:24PM -0800, Darrick J. Wong wrote: >> >> if (inode->i_nlink == 0) { >> ext4_warning_inode(inode, "nlink is already 0"); >> return; >> } > > We can't do that because the place where Zhangyi is proposing to > change

Re: [RFC PATCH] ext4: increase the protection of drop nlink and ext4 inode destroy

On 2017/1/5 7:35, Theodore Ts'o wrote: > > So how exactly how did we get into this state? When we read the inode > into memory, if i_nlink is zero, we declare the file system as > corrupted immediately. > > So I assume this is happening the on-disk i_links_count (which is read > into

Re: [RFC PATCH] ext4: increase the protection of drop nlink and ext4 inode destroy

On 2017/1/5 7:35, Theodore Ts'o wrote: > > So how exactly how did we get into this state? When we read the inode > into memory, if i_nlink is zero, we declare the file system as > corrupted immediately. > > So I assume this is happening the on-disk i_links_count (which is read > into

Re: [RFC PATCH] ext4: increase the protection of drop nlink and ext4 inode destroy

On 2017/1/1 6:59, valdis.kletni...@vt.edu said: > On Mon, 26 Dec 2016 20:34:17 +0800, yi zhang said: >> Because of the disk and hardware issue, the ext4 filesystem have >> many errors, the inode->i_nlink of ext4 becomes zero abnormally >> but the dentry is still positive, it will cause memory

Re: [RFC PATCH] ext4: increase the protection of drop nlink and ext4 inode destroy

On 2017/1/1 6:59, valdis.kletni...@vt.edu said: > On Mon, 26 Dec 2016 20:34:17 +0800, yi zhang said: >> Because of the disk and hardware issue, the ext4 filesystem have >> many errors, the inode->i_nlink of ext4 becomes zero abnormally >> but the dentry is still positive, it will cause memory