discard commands to be issued.
2. In the issue_discard_thread() path when there are no pending discard
commands, it fails to reset the wait_ms to max timeout value.
Signed-off-by: Sahitya Tummala
---
v2:
- Fix the second scenario mentioned above in commit text
fs/f2fs/segment.c | 21
Hi Jaegeuk,
This latest v3 patch needs to be updated in f2fs tree.
The f2fs tree currently points to older version of patch.
Please make a note of it.
Thanks,
Sahitya.
On Tue, Mar 16, 2021 at 07:08:58PM +0800, Chao Yu wrote:
> On 2021/3/16 17:29, Sahitya Tummala wrote:
> >With th
/15 17:45, Sahitya Tummala wrote:
> >Hi Chao,
> >
> >On Mon, Mar 15, 2021 at 04:10:22PM +0800, Chao Yu wrote:
> >>Hi Sahitya,
> >>
> >>On 2021/3/15 15:46, Sahitya Tummala wrote:
> >>>Hi Chao,
> >>>
> >>>On Mon, Mar 15, 2021 a
pending discard cmds by changing the policy to DPOLICY_FORCE
based on the nm_i->ram_thresh configured.
Signed-off-by: Sahitya Tummala
---
v3:
Fix sporadic null pointer dereference issue when accessing NM_I(sbi)
in f2fs_available_free_memory(). It is because this function can be
called by disc
Hi Chao,
On Mon, Mar 15, 2021 at 04:10:22PM +0800, Chao Yu wrote:
> Hi Sahitya,
>
> On 2021/3/15 15:46, Sahitya Tummala wrote:
> >Hi Chao,
> >
> >On Mon, Mar 15, 2021 at 02:12:44PM +0800, Chao Yu wrote:
> >>Sahitya,
> >>
> >>On 2021/3/15 1
Hi Chao,
On Mon, Mar 15, 2021 at 02:12:44PM +0800, Chao Yu wrote:
> Sahitya,
>
> On 2021/3/15 12:56, Sahitya Tummala wrote:
> >When f2fs is heavily utilized over 80%, the current discard policy
> >sets the max sleep timeout of discard thread as 50ms
> >
of the discard thread.
This patch adds check for pending discard commands in addition
to heavy utilization condition to prevent those wake ups.
Signed-off-by: Sahitya Tummala
---
fs/f2fs/segment.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fs/f2fs/segment.c b/fs/f2fs
pending discard cmds by changing the policy to DPOLICY_FORCE
based on the nm_i->ram_thresh configured.
Signed-off-by: Sahitya Tummala
---
v2:
- by mistake the last else condition was modified, fix it now.
fs/f2fs/node.c| 5 +
fs/f2fs/node.h| 1 +
fs/f2fs/segment.c | 3 ++-
3 fi
pending discard cmds by changing the policy to DPOLICY_FORCE
based on the nm_i->ram_thresh configured.
Signed-off-by: Sahitya Tummala
---
fs/f2fs/node.c| 7 ++-
fs/f2fs/node.h| 1 +
fs/f2fs/segment.c | 3 ++-
3 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/fs/f2fs/nod
Hi David,
On Tue, Nov 24, 2020 at 09:12:12AM +, David Laight wrote:
> From: Chao Yu
> > Sent: 24 November 2020 03:12
> >
> > On 2020/11/24 1:05, David Laight wrote:
> > > From: Sahitya Tummala
> > >> Sent: 23 November 2020 05:29
> > >>
&
Use rwsem to ensure serialization of the callers and to avoid
starvation of high priority tasks, when the system is under
heavy IO workload.
Signed-off-by: Sahitya Tummala
---
fs/f2fs/checkpoint.c | 8
fs/f2fs/f2fs.h | 2 +-
fs/f2fs/gc.c | 4 ++--
fs/f2fs/recovery.c | 4
not zero but nm_i->free_nid_count of that partially scanned
NAT block is zero.
Fix this to align the nm_i->next_scan_nid to the first nid of the
corresponding NAT block.
Signed-off-by: Sahitya Tummala
---
v2:
- address Chao's comments to move the check to beginning of function
and to add unlike
On Tue, Aug 18, 2020 at 03:25:47PM +0530, Sahitya Tummala wrote:
> On Tue, Aug 18, 2020 at 04:29:05PM +0800, Chao Yu wrote:
> > On 2020/8/14 16:05, Sahitya Tummala wrote:
> > >If the sbi->ckpt->next_free_nid is not NAT block aligned and if there
> > >are fr
On Tue, Aug 18, 2020 at 04:29:05PM +0800, Chao Yu wrote:
> On 2020/8/14 16:05, Sahitya Tummala wrote:
> >If the sbi->ckpt->next_free_nid is not NAT block aligned and if there
> >are free nids in that NAT block between the start of the block and
> >next_fre
not zero but nm_i->free_nid_count of that partially scanned
NAT block is zero.
Fix this to align the nm_i->next_scan_nid to the first nid of the
corresponding NAT block.
Signed-off-by: Sahitya Tummala
---
fs/f2fs/node.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/f2fs/node.c b/fs/f
On Mon, Jun 15, 2020 at 08:47:20AM -0700, Eric Biggers wrote:
> On Mon, Jun 15, 2020 at 03:23:16PM +0530, Sahitya Tummala wrote:
> > >
> > > Should I fold this change into the original patch? Or keep it as a
> > > separate patch when I send out the fscrypt/f2fs i
->bio_uninit
->bio_crypt_free_ctx
->use-after-free issue
Fix this by moving f2fs_crypt_mergeable_bio() check within
add_ipu_page() so that it's done under bio_list_lock to prevent
the above race.
Fixes: 15e76ad23e72 ("f2fs: add inline encryp
->bio_uninit
->bio_crypt_free_ctx
->use-after-free issue
Fix this by moving f2fs_crypt_mergeable_bio() check within
add_ipu_page() so that it's done under bio_list_lock to prevent
the above race.
Fixes: 15e76ad23e72 ("f2fs: add inline encryp
Hi Satya,
On Mon, Jun 15, 2020 at 06:16:33AM +, Satya Tangirala wrote:
> On Sun, Jun 14, 2020 at 10:00:19PM -0700, Eric Biggers wrote:
> > On Mon, Jun 15, 2020 at 09:29:48AM +0530, Sahitya Tummala wrote:
> > > There could be a potential race between these two paths below,
&g
Hi Eric,
On Sun, Jun 14, 2020 at 10:00:19PM -0700, Eric Biggers wrote:
> On Mon, Jun 15, 2020 at 09:29:48AM +0530, Sahitya Tummala wrote:
> > There could be a potential race between these two paths below,
> > leading to use-after-free when accessing bio-&g
to the change -
<64081362e8ff>("mm/page-writeback.c: fix range_cyclic writeback vs
writepages deadlock").
Signed-off-by: Sahitya Tummala
---
v2:
- Align the code to <64081362e8ff>("mm/page-writeback.c: fix range_cyclic
writeback vs writepages deadlock") and adjust the
Hi Chao,
Can you please help review the diff given by Jaegeuk below?
If it looks good, I can post a v2.
Thanks,
On Thu, May 28, 2020 at 12:18:39PM -0700, Jaegeuk Kim wrote:
> On 05/28, Chao Yu wrote:
> > On 2020/5/28 10:45, Chao Yu wrote:
> > > On 2020/5/27 10:20, Sah
Hi Chao,
Can you please help review below diff given by Jaegeuk?
If it looks good, I can send a v2.
Thanks,
On Thu, May 28, 2020 at 12:18:39PM -0700, Jaegeuk Kim wrote:
> On 05/28, Chao Yu wrote:
> > On 2020/5/28 10:45, Chao Yu wrote:
> > > On 2020/5/27 10:20, Sah
compression. Fix this by allowing writeback to
be retried for the current page as well (in case of compressed page
getting retried due to index mismatch with cluster index). So that
this cluster can be written compressed in case of overwrite.
Signed-off-by: Sahitya Tummala
---
fs/f2fs/data.c | 2
when switching work profiles.
Signed-off-by: Sahitya Tummala
---
mm/vmscan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index d96c547..b48926f 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -730,7 +730,7 @@ void drop_slab_node(int nid
On Fri, May 17, 2019 at 10:23:12AM +0200, Christoph Hellwig wrote:
> On Thu, May 16, 2019 at 06:27:53PM +0530, stumm...@codeaurora.org wrote:
> > Hi Christoph, Al,
> >
> > Can you please consider this patch for merging?
>
> I've been sitting on this for a while, mostly because I can't convince
>
off-by: Sahitya Tummala
---
v2:
add a comment in dx_release()
fs/ext4/namei.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
index 980166a..5d9ffa8 100644
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -871,12 +871,15 @@ static void dx_rele
On Wed, May 08, 2019 at 01:09:47AM -0600, Andreas Dilger wrote:
> On May 8, 2019, at 12:13 AM, Sahitya Tummala wrote:
> >
> > The buffer_head (frames[0].bh) and it's corresping page can be
> > potentially free'd once brelse() is done inside the for loop
> > bu
off-by: Sahitya Tummala
---
fs/ext4/namei.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
index 4181c9c..7e6c298 100644
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -871,12 +871,14 @@ static void dx_release(struct dx_frame *fra
On Fri, Mar 01, 2019 at 03:38:05PM +0800, Chao Yu wrote:
> As Paul Bandha reported in bugzilla:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=202709
>
> When I run the poc on the mounted f2fs img I get a buffer overflow in
> read_inline_xattr due to there being no sanity check on the value of
On Tue, Feb 19, 2019 at 02:53:02PM +0100, Jan Kara wrote:
> Hi!
>
> On Tue 19-02-19 15:50:23, stumm...@codeaurora.org wrote:
> > I am observing huge fsync latencies for a small file under the below test
> > scenario -
> >
> > process A -
> > Issue async write of 4GB using dd command (say
On Wed, Feb 13, 2019 at 11:25:31AM +0800, Chao Yu wrote:
> On 2019/2/4 16:06, Sahitya Tummala wrote:
> > Fix below warning coming because of using mutex lock in atomic context.
> >
> > BUG: sleeping function called from invalid context at
> > kernel/locking/mu
-by: Sahitya Tummala
---
fs/f2fs/trace.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/fs/f2fs/trace.c b/fs/f2fs/trace.c
index ce2a5eb..d0ab533 100644
--- a/fs/f2fs/trace.c
+++ b/fs/f2fs/trace.c
@@ -14,7 +14,7 @@
#include "trace.h"
static RADIX
Al,
Can we merge this patch, if there are no further comments?
Thanks,
Sahitya.
On Thu, Jan 03, 2019 at 04:48:15PM +0530, Sahitya Tummala wrote:
> In the vfs_statx() context, during path lookup, the dentry gets
> added to sd->s_dentry via configfs_attach_attr(). In the end,
> vfs_s
On Wed, Jan 09, 2019 at 02:13:02PM +0800, Chao Yu wrote:
> On 2019/1/9 12:38, Jaegeuk Kim wrote:
> > On 01/07, Chao Yu wrote:
> >> On 2019/1/5 4:33, Jaegeuk Kim wrote:
> >>> On 01/04, Sahitya Tummala wrote:
> >>>> On Mon, Nov 26, 2018 at 10:17:20
On Mon, Nov 26, 2018 at 10:17:20AM +0530, Sahitya Tummala wrote:
> When there is a failure in f2fs_fill_super() after/during
> the recovery of fsync'd nodes, it frees the current sbi and
> retries again. This time the mount is successful, but the files
> that got recovered before
LTP test case -
sh fs_racer_file_list.sh /config
(https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/fs/racer/fs_racer_file_list.sh)
Fixes: 76ae281f6307 ('configfs: fix race between dentry put and lookup')
Signed-off-by: Sahitya Tummala
---
v2:
- update comments relevant
LTP test case -
sh fs_racer_file_list.sh /config
(https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/fs/racer/fs_racer_file_list.sh)
Signed-off-by: Sahitya Tummala
---
fs/configfs/dir.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/configfs/dir.c b
n
both f2fs_put_super() and f2fs_fill_super() paths.
Signed-off-by: Sahitya Tummala
---
v2:
- cover f2fs_fill_super() also, as pointed out by Chao.
fs/f2fs/super.c | 27 +++
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
On Tue, Dec 25, 2018 at 11:06:45AM +0800, Chao Yu wrote:
> On 2018/12/24 21:06, Sahitya Tummala wrote:
> > iput() on sbi->node_inode can update sbi->stat_info
> > in the below context, if the f2fs_write_checkpoint()
> > has failed with error.
> >
&
Signed-off-by: Sahitya Tummala
---
fs/f2fs/super.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index e184ad4e..df41a3a 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -1058,9 +1058,6 @@ static void f2fs_put_super(struct super
is by not creating extents for those recovered files if shrinker is
not registered yet. Once mount is successful and shrinker is registered,
those files can have extents again.
Signed-off-by: Sahitya Tummala
---
v3:
-do not create extents itself in the first place for those recovered files,
instead
On Wed, Dec 12, 2018 at 11:36:08AM +0800, Chao Yu wrote:
> On 2018/12/12 11:17, Sahitya Tummala wrote:
> > On Fri, Dec 07, 2018 at 05:47:31PM +0800, Chao Yu wrote:
> >> On 2018/12/1 4:33, Jaegeuk Kim wrote:
> >>> On 11/29, Sahitya Tummala wrote:
> >>>&
On Fri, Dec 07, 2018 at 05:47:31PM +0800, Chao Yu wrote:
> On 2018/12/1 4:33, Jaegeuk Kim wrote:
> > On 11/29, Sahitya Tummala wrote:
> >>
> >> On Tue, Nov 27, 2018 at 09:42:39AM +0800, Chao Yu wrote:
> >>> On 2018/11/27 8:30, Jaegeuk Kim wrote:
> >>
On Wed, Oct 10, 2018 at 08:05:44PM -0700, Jaegeuk Kim wrote:
> On 10/10, Jaegeuk Kim wrote:
> > On 10/11, Sahitya Tummala wrote:
> > > On Wed, Oct 10, 2018 at 02:34:02PM -0700, Jaegeuk Kim wrote:
> > > > On 10/10, Sahitya Tummala wrote:
> > > > &
On Wed, Oct 10, 2018 at 08:05:44PM -0700, Jaegeuk Kim wrote:
> On 10/10, Jaegeuk Kim wrote:
> > On 10/11, Sahitya Tummala wrote:
> > > On Wed, Oct 10, 2018 at 02:34:02PM -0700, Jaegeuk Kim wrote:
> > > > On 10/10, Sahitya Tummala wrote:
> > > > &
On Thu, May 17, 2018 at 06:08:26PM -0700, Jaegeuk Kim wrote:
>
> if (in == F2FS_GOING_DOWN_FULLSYNC) {
> sb = freeze_bdev();
> if (IS_ERR(sb))
> return PTR_ERR(sb);
> if (unlikely(!sb))
> return -EINVAL;
> }
>
> ret = mnt_want_write_file();
It will
On Thu, May 17, 2018 at 06:08:26PM -0700, Jaegeuk Kim wrote:
>
> if (in == F2FS_GOING_DOWN_FULLSYNC) {
> sb = freeze_bdev();
> if (IS_ERR(sb))
> return PTR_ERR(sb);
> if (unlikely(!sb))
> return -EINVAL;
> }
>
> ret = mnt_want_write_file();
It will
f2fs_ioc_shutdown() ioctl gets stuck in the below path
when issued with F2FS_GOING_DOWN_FULLSYNC option.
__switch_to+0x90/0xc4
percpu_down_write+0x8c/0xc0
freeze_super+0xec/0x1e4
freeze_bdev+0xc4/0xcc
f2fs_ioctl+0xc0c/0x1ce0
f2fs_compat_ioctl+0x98/0x1f0
Signed-off-by: Sahitya Tummala <st
f2fs_ioc_shutdown() ioctl gets stuck in the below path
when issued with F2FS_GOING_DOWN_FULLSYNC option.
__switch_to+0x90/0xc4
percpu_down_write+0x8c/0xc0
freeze_super+0xec/0x1e4
freeze_bdev+0xc4/0xcc
f2fs_ioctl+0xc0c/0x1ce0
f2fs_compat_ioctl+0x98/0x1f0
Signed-off-by: Sahitya Tummala
---
fs
f2fs_ioc_shutdown() ioctl gets stuck in the below path
when issued with F2FS_GOING_DOWN_FULLSYNC option.
__switch_to+0x90/0xc4
percpu_down_write+0x8c/0xc0
freeze_super+0xec/0x1e4
freeze_bdev+0xc4/0xcc
f2fs_ioctl+0xc0c/0x1ce0
f2fs_compat_ioctl+0x98/0x1f0
Signed-off-by: Sahitya Tummala <st
f2fs_ioc_shutdown() ioctl gets stuck in the below path
when issued with F2FS_GOING_DOWN_FULLSYNC option.
__switch_to+0x90/0xc4
percpu_down_write+0x8c/0xc0
freeze_super+0xec/0x1e4
freeze_bdev+0xc4/0xcc
f2fs_ioctl+0xc0c/0x1ce0
f2fs_compat_ioctl+0x98/0x1f0
Signed-off-by: Sahitya Tummala
---
v2
On Wed, May 16, 2018 at 02:48:42PM +0800, Chao Yu wrote:
> >
> > Thanks, I thought about it too but then I checked that XFS shutdown ioctl is
> > not taking any lock for this ioctl. Hence, I followed the same in F2FS.
> > Do you know why XFS is not taking any lock?
>
> I don't know. :(
No
On Wed, May 16, 2018 at 02:48:42PM +0800, Chao Yu wrote:
> >
> > Thanks, I thought about it too but then I checked that XFS shutdown ioctl is
> > not taking any lock for this ioctl. Hence, I followed the same in F2FS.
> > Do you know why XFS is not taking any lock?
>
> I don't know. :(
No
On Mon, May 14, 2018 at 11:39:42AM +0800, Chao Yu wrote:
> On 2018/5/10 21:20, Sahitya Tummala wrote:
> > f2fs_ioc_shutdown() ioctl gets stuck in the below path
> > when going down with full sync (F2FS_GOING_DOWN_FULLSYNC)
> > option.
> >
> > __switch_to+0x90/0xc
On Mon, May 14, 2018 at 11:39:42AM +0800, Chao Yu wrote:
> On 2018/5/10 21:20, Sahitya Tummala wrote:
> > f2fs_ioc_shutdown() ioctl gets stuck in the below path
> > when going down with full sync (F2FS_GOING_DOWN_FULLSYNC)
> > option.
> >
> > __switch_to+0x90/0xc
write access during this ioctl.
Signed-off-by: Sahitya Tummala <stumm...@codeaurora.org>
---
fs/f2fs/file.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index b926df7..2c2e61b 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -1835,10 +1835,6 @@
write access during this ioctl.
Signed-off-by: Sahitya Tummala
---
fs/f2fs/file.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index b926df7..2c2e61b 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -1835,10 +1835,6 @@ static int f2fs_ioc_shutdown
On 6/30/2017 4:18 AM, Andrew Morton wrote:
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -1133,11 +1133,12 @@ void shrink_dcache_sb(struct super_block *sb)
LIST_HEAD(dispose);
freed = list_lru_walk(>s_dentry_lru,
- dentry_lru_isolate_shrink, , UINT_MAX);
On 6/30/2017 4:18 AM, Andrew Morton wrote:
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -1133,11 +1133,12 @@ void shrink_dcache_sb(struct super_block *sb)
LIST_HEAD(dispose);
freed = list_lru_walk(>s_dentry_lru,
- dentry_lru_isolate_shrink, , UINT_MAX);
-by: Jan kara <j...@suse.cz>
Fix-suggested-by: Vladimir Davydov <vdavydov@gmail.com>
Signed-off-by: Sahitya Tummala <stumm...@codeaurora.org>
---
fs/dcache.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/fs/dcache.c b/fs/dcache.c
index a9f995f..1161390
y: Jan kara
Fix-suggested-by: Vladimir Davydov
Signed-off-by: Sahitya Tummala
---
fs/dcache.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/fs/dcache.c b/fs/dcache.c
index a9f995f..1161390 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -1133,11 +1133,12 @@ void shrink_
track of entries per node and simply return
it in list_lru_count_node().
Signed-off-by: Sahitya Tummala <stumm...@codeaurora.org>
---
include/linux/list_lru.h | 1 +
mm/list_lru.c| 14 ++
2 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/include/linux/list
track of entries per node and simply return
it in list_lru_count_node().
Signed-off-by: Sahitya Tummala
---
include/linux/list_lru.h | 1 +
mm/list_lru.c| 14 ++
2 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/include/linux/list_lru.h b/include/linux
-by: Jan kara <j...@suse.cz>
Fix-suggested-by: Vladimir Davydov <vdavydov@gmail.com>
Signed-off-by: Sahitya Tummala <stumm...@codeaurora.org>
---
v3: use list_lru_count() instead of freed in while loop to
cover an extreme case where a single invocation of list_lru_walk()
can ski
y: Jan kara
Fix-suggested-by: Vladimir Davydov
Signed-off-by: Sahitya Tummala
---
v3: use list_lru_count() instead of freed in while loop to
cover an extreme case where a single invocation of list_lru_walk()
can skip all 1024 dentries, in which case 'freed' will be 0 forcing
us to break the loop p
track of entries per node and simply return
it in list_lru_count_node().
Signed-off-by: Sahitya Tummala <stumm...@codeaurora.org>
---
include/linux/list_lru.h | 1 +
mm/list_lru.c| 14 ++
2 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/include/linux/list
track of entries per node and simply return
it in list_lru_count_node().
Signed-off-by: Sahitya Tummala
---
include/linux/list_lru.h | 1 +
mm/list_lru.c| 14 ++
2 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/include/linux/list_lru.h b/include/linux
On 6/21/2017 10:01 PM, Vladimir Davydov wrote:
index cddf397..c8ca150 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -1133,10 +1133,11 @@ void shrink_dcache_sb(struct super_block *sb)
LIST_HEAD(dispose);
freed = list_lru_walk(>s_dentry_lru,
-
On 6/21/2017 10:01 PM, Vladimir Davydov wrote:
index cddf397..c8ca150 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -1133,10 +1133,11 @@ void shrink_dcache_sb(struct super_block *sb)
LIST_HEAD(dispose);
freed = list_lru_walk(>s_dentry_lru,
-
-by: Jan kara <j...@suse.cz>
Fix-suggested-by: Vladimir Davydov <vdavydov@gmail.com>
Signed-off-by: Sahitya Tummala <stumm...@codeaurora.org>
---
v2: patch shrink_dcache_sb() instead of list_lru_walk()
---
fs/dcache.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff
y: Jan kara
Fix-suggested-by: Vladimir Davydov
Signed-off-by: Sahitya Tummala
---
v2: patch shrink_dcache_sb() instead of list_lru_walk()
---
fs/dcache.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/dcache.c b/fs/dcache.c
index cddf397..c8ca150 100644
--- a/fs/d
Hello,
On 6/17/2017 4:44 PM, Vladimir Davydov wrote:
That said, I think it would be better to patch shrink_dcache_sb() or
dentry_lru_isolate_shrink() instead of list_lru_walk() in order to fix
this lockup.
Thanks for the review. I will enhance the patch as per your suggestion.
--
Qualcomm
Hello,
On 6/17/2017 4:44 PM, Vladimir Davydov wrote:
That said, I think it would be better to patch shrink_dcache_sb() or
dentry_lru_isolate_shrink() instead of list_lru_walk() in order to fix
this lockup.
Thanks for the review. I will enhance the patch as per your suggestion.
--
Qualcomm
On 6/16/2017 2:35 AM, Andrew Morton wrote:
diff --git a/mm/list_lru.c b/mm/list_lru.c
index 5d8dffd..1af0709 100644
--- a/mm/list_lru.c
+++ b/mm/list_lru.c
@@ -249,6 +249,8 @@ restart:
default:
BUG();
}
+ if
On 6/16/2017 2:35 AM, Andrew Morton wrote:
diff --git a/mm/list_lru.c b/mm/list_lru.c
index 5d8dffd..1af0709 100644
--- a/mm/list_lru.c
+++ b/mm/list_lru.c
@@ -249,6 +249,8 @@ restart:
default:
BUG();
}
+ if
e.cz>
Signed-off-by: Sahitya Tummala <stumm...@codeaurora.org>
---
mm/list_lru.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/list_lru.c b/mm/list_lru.c
index 5d8dffd..1af0709 100644
--- a/mm/list_lru.c
+++ b/mm/list_lru.c
@@ -249,6 +249,8 @@ restart:
default:
e_shrink+0x48
[] __list_lru_walk_one.isra.10+0x94
[] list_lru_walk_node+0x40
[] shrink_dcache_sb+0x60
[] do_remount_sb+0xbc
[] do_emergency_remount+0xb0
[] process_one_work+0x228
[] worker_thread+0x2e0
[] kthread+0xf4
[] ret_from_fork+0x10
Link: http://marc.info/?t=14951151482=1=2
Fix-suggested-by: Jan kara
Signed-of
Hi,
We are seeing a soft lock up where a RT task is tight looping in
d_invalidate(). The corresponding dentries are claimed by a low priority
normal task, but this task is scheduled out. The cond_resched() in
d_invalidate() is not taking into effect as this RT task is the highest
priority
Hi,
We are seeing a soft lock up where a RT task is tight looping in
d_invalidate(). The corresponding dentries are claimed by a low priority
normal task, but this task is scheduled out. The cond_resched() in
d_invalidate() is not taking into effect as this RT task is the highest
priority
HED bit is set before deleting the intr_entry with input
queue lock in request completion path, do the testing of this flag and
queueing atomically with the same lock in queue_interrupt().
Signed-off-by: Sahitya Tummala <stumm...@codeaurora.org>
---
fs/fuse/dev.c | 4
1 file changed, 4 ins
HED bit is set before deleting the intr_entry with input
queue lock in request completion path, do the testing of this flag and
queueing atomically with the same lock in queue_interrupt().
Signed-off-by: Sahitya Tummala
---
fs/fuse/dev.c | 4
1 file changed, 4 insertions(+)
diff --git a/fs
now results into use
after free issue.
}
Signed-off-by: Sahitya Tummala <stumm...@codeaurora.org>
---
fs/jbd2/journal.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c
index a097048..85d1
now results into use
after free issue.
}
Signed-off-by: Sahitya Tummala
---
fs/jbd2/journal.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c
index a097048..85d1483 100644
--- a/fs/jbd2/journal.c
now results into use
after free issue.
}
Signed-off-by: Sahitya Tummala <stumm...@codeaurora.org>
---
fs/jbd2/journal.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c
index a097048..f5cd3c0 100644
now results into use
after free issue.
}
Signed-off-by: Sahitya Tummala
---
fs/jbd2/journal.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c
index a097048..f5cd3c0 100644
--- a/fs/jbd2/journal.c
+++ b/fs/jbd2
by
updating the async_error before notifying the child's completion.
Signed-off-by: Sahitya Tummala <stumm...@codeaurora.org>
---
drivers/base/power/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index e44944
by
updating the async_error before notifying the child's completion.
Signed-off-by: Sahitya Tummala
---
drivers/base/power/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index e44944f4be77..f733f50f8321 100644
88 matches
Mail list logo
