Hi,
On 04/20, Salvatore Bonaccorso wrote:
> Hi,
>
> On Tue, Mar 23, 2021 at 02:43:29PM +0800, Chao Yu wrote:
> > Hi butt3rflyh4ck,
> >
> > On 2021/3/23 13:48, butt3rflyh4ck wrote:
> > > Hi, I have tested the patch on 5.12.0-rc4+, it seems to fix the problem.
> >
> > Thanks for helping to test
On 04/20, Chao Yu wrote:
> On 2021/4/20 0:57, Jaegeuk Kim wrote:
> > On 04/14, Chao Yu wrote:
> > > As we did for other cases, in fix_curseg_write_pointer(), let's
> > > change as below:
> > > - use callback function s_ops->allocate_
On 04/14, Chao Yu wrote:
> As we did for other cases, in fix_curseg_write_pointer(), let's
> change as below:
> - use callback function s_ops->allocate_segment() instead of
> raw function allocate_segment_by_default();
> - cover allocate_segment() with curseg_lock and sentry_lock.
>
>
From: Jaegeuk Kim
commit df7b59ba9245 ("dm verity: fix FEC for RS roots unaligned to block size")
made dm_bufio->block_size 1024, if f->roots is 2. But, that gives the below EIO
if the logical block size of the device is 4096, given
v->data_dev_block_bits=12.
E sd 0:
On 04/12, Jaegeuk Kim wrote:
> From: Jaegeuk Kim
>
> commit df7b59ba9245 ("dm verity: fix FEC for RS roots unaligned to block
> size")
> made dm_bufio->block_size 1024, if f->roots is 2. But, that gives the below
> EIO
> if the logical block s
On 04/13, Chao Yu wrote:
> On 2021/4/13 11:27, Jaegeuk Kim wrote:
> > On 04/12, Chao Yu wrote:
> > > As Yi Chen reported, there is a potential race case described as below:
> > >
> > > Thread A Thread B
> > > - f2fs_ioc_start_atomic_wr
On 04/12, Chao Yu wrote:
> As Yi Chen reported, there is a potential race case described as below:
>
> Thread A Thread B
> - f2fs_ioc_start_atomic_write
> - mkwrite
>- set_page_dirty
>
On 04/11, Chao Yu wrote:
> Hi Jaegeuk,
>
> Could you please help to merge below cleanup diff into original patch?
> or merge this separately if it is too late since it is near rc7.
I didn't review this tho, this gives an error in xfstests/083.
>
> From 5a342a8f332a1b3281ec0e2b4d41b5287689c8ed
From: Jaegeuk Kim
commit df7b59ba9245 ("dm verity: fix FEC for RS roots unaligned to block size")
made dm_bufio->block_size 1024, if f->roots is 2. But, that gives the below EIO
if the logical block size of the device is 4096, given
v->data_dev_block_bits=12.
E sd 0:
Sorry, this patch is totally wrong. Let me dig out more.
On 04/10, Jaegeuk Kim wrote:
> From: Jaegeuk Kim
>
> When f->roots is 2 and block size is 4096, it will gives unaligned block size
> length in the scsi command like below. Let's allocate dm_bufio to set the
> block
>
From: Jaegeuk Kim
When f->roots is 2 and block size is 4096, it will gives unaligned block size
length in the scsi command like below. Let's allocate dm_bufio to set the block
size length to match IO chunk size.
E sd 0: 0:0:0: [sda] tag#30 request not aligned to the logical block siz
Once we introduced checkpoint_merge, we've seen some contention w/o the option.
In order to avoid it, let's set it by default.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/super.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index 14239e2b7ae7..c15800c3cdb1
On 03/27, Chao Yu wrote:
> On 2021/3/27 9:52, Chao Yu wrote:
> > On 2021/3/27 1:30, Jaegeuk Kim wrote:
> > > On 03/26, Chao Yu wrote:
> > > > On 2021/3/26 9:19, Jaegeuk Kim wrote:
> > > > > On 03/26, Chao Yu wrote:
> > > > > > On
On 03/26, Chao Yu wrote:
> On 2021/3/26 9:19, Jaegeuk Kim wrote:
> > On 03/26, Chao Yu wrote:
> > > On 2021/3/25 9:59, Chao Yu wrote:
> > > > On 2021/3/25 6:44, Jaegeuk Kim wrote:
> > > > > On 03/24, Chao Yu wrote:
> > > > > > On 2021
On 03/26, Sahitya Tummala wrote:
> 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.
Ha, need more coffee. Thanks for pointing it out. :)
>
> Thanks,
> Sahitya.
>
> On Tue, Mar 16,
On 03/26, Chao Yu wrote:
> On 2021/3/25 9:59, Chao Yu wrote:
> > On 2021/3/25 6:44, Jaegeuk Kim wrote:
> > > On 03/24, Chao Yu wrote:
> > > > On 2021/3/24 12:22, Jaegeuk Kim wrote:
> > > > > On 03/24, Chao Yu wrote:
> > > > > > On 202
On 03/25, Chao Yu wrote:
> On 2021/3/25 7:49, Jaegeuk Kim wrote:
> > On 03/24, Chao Yu wrote:
> > > In CP disabling mode, there are two issues when using LFS or SSR | AT_SSR
> > > mode to select victim:
> > >
> > > 1. LFS is set to find sou
On 03/24, Chao Yu wrote:
> In CP disabling mode, there are two issues when using LFS or SSR | AT_SSR
> mode to select victim:
>
> 1. LFS is set to find source section during GC, the victim should have
> no checkpointed data, since after GC, section could not be set free for
> reuse.
>
>
On 03/24, Chao Yu wrote:
> On 2021/3/24 12:22, Jaegeuk Kim wrote:
> > On 03/24, Chao Yu wrote:
> > > On 2021/3/24 2:39, Jaegeuk Kim wrote:
> > > > On 03/23, Chao Yu wrote:
> > > > > This reverts commit 938a184265d75ea474f1c6fe1da96a5196163789.
> >
On 03/24, Chao Yu wrote:
> On 2021/3/24 2:39, Jaegeuk Kim wrote:
> > On 03/23, Chao Yu wrote:
> > > This reverts commit 938a184265d75ea474f1c6fe1da96a5196163789.
> > >
> > > Because that commit fails generic/050 testcase which expect failure
> > >
On 03/19, Chao Yu wrote:
> On 2021/3/19 1:17, Jaegeuk Kim wrote:
> > On 02/20, Chao Yu wrote:
> > > In cp disabling mode, there could be a condition
> > > - target segment has 128 ckpt valid blocks
> > > - GC migrates 128 valid blocks to other segment (
On 03/23, Chao Yu wrote:
> This reverts commit 938a184265d75ea474f1c6fe1da96a5196163789.
>
> Because that commit fails generic/050 testcase which expect failure
> during mount a recoverable readonly partition.
I think we need to change generic/050, since f2fs can recover this partition,
even
On 03/23, Chao Yu wrote:
> On 2021/3/5 17:56, Chao Yu wrote:
> > Now, fallocate() on a pinned file only allocates blocks which aligns
> > to segment rather than section, so GC may try to migrate pinned file's
> > block, and after several times of failure, pinned file's block could
> > be migrated
On 02/20, Chao Yu wrote:
> In cp disabling mode, there could be a condition
> - target segment has 128 ckpt valid blocks
> - GC migrates 128 valid blocks to other segment (segment is still in
> dirty list)
> - GC migrates 384 blocks to target segment (segment has 128 cp_vblocks
> and 384 vblocks)
On 03/11, Asutosh Das wrote:
> During runtime-suspend of ufs host, the scsi devices are
> already suspended and so are the queues associated with them.
> But the ufs host sends SSU to wlun during its runtime-suspend.
> During the process blk_queue_enter checks if the queue is not in
> suspended
On 03/09, Chao Yu wrote:
> On 2021/3/9 8:01, Jaegeuk Kim wrote:
> > On 03/05, Chao Yu wrote:
> > > On 2021/3/5 4:20, Jaegeuk Kim wrote:
> > > > On 02/27, Jaegeuk Kim wrote:
> > > > > On 02/04, Chao Yu wrote:
> > > > > > Jae
by f2fs gc.
> > > > > When
> > > > > gc_pin_file_threshold is reached, the address of swapfile may
> > > > > change,
> > > > > but won't be synchronized to swap_extent, so swap will write to
> > > > > wrong
On 03/05, Chao Yu wrote:
> On 2021/3/5 1:50, Jaegeuk Kim wrote:
> > On 03/04, Chao Yu wrote:
> > > On 2021/3/3 2:44, Jaegeuk Kim wrote:
> > > > On 03/02, Jaegeuk Kim wrote:
> > > > > On 03/02, Chao Yu wrote:
> > > > > > On 2021/
On 03/05, Chao Yu wrote:
> On 2021/3/5 4:20, Jaegeuk Kim wrote:
> > On 02/27, Jaegeuk Kim wrote:
> > > On 02/04, Chao Yu wrote:
> > > > Jaegeuk,
> > > >
> > > > On 2021/2/2 16:00, Chao Yu wrote:
> > > > > - for (i = 0; i &
On 02/27, Jaegeuk Kim wrote:
> On 02/04, Chao Yu wrote:
> > Jaegeuk,
> >
> > On 2021/2/2 16:00, Chao Yu wrote:
> > > - for (i = 0; i < dic->nr_cpages; i++) {
> > > + for (i = 0; i < cc->nr_cpages; i++) {
> > > struct p
On 03/04, Chao Yu wrote:
> On 2021/3/3 2:44, Jaegeuk Kim wrote:
> > On 03/02, Jaegeuk Kim wrote:
> > > On 03/02, Chao Yu wrote:
> > > > On 2021/3/2 13:42, Jaegeuk Kim wrote:
> > > > > This is useful when checking conditions du
On 03/03, Colin Ian King wrote:
> On 03/03/2021 19:44, Jaegeuk Kim wrote:
> > On 03/02, Colin Ian King wrote:
> >> Hi,
> >>
> >> Static analysis on linux-next detected a potential uninitialized
> >> variable dn.node_changed that does not get set w
This is useful when checking conditions during checkpoint=disable in Android.
Signed-off-by: Jaegeuk Kim
---
Documentation/ABI/testing/sysfs-fs-f2fs | 5 +
fs/f2fs/sysfs.c | 9 +
2 files changed, 14 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs
On 03/03, Stephen Rothwell wrote:
> Hi all,
>
> After merging the f2fs tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> fs/f2fs/sysfs.c:576:25: warning: 'f2fs_attr_ovp_segments' defined but not
> used [-Wunused-variable]
> 576 | static struct f2fs_attr
hat may or not may not balances dirty node
> and dentry pages depending on the uninitialized state of the variable.
>
> I believe the issue was introduced by commit:
>
> commit 2a3407607028f7c780f1c20faa4e922bf631d340
> Author: Jaegeuk Kim
> Date: Tue Dec 22 13:23:35 2015 -0800
&
On 03/02, Jaegeuk Kim wrote:
> On 03/02, Chao Yu wrote:
> > On 2021/3/2 13:42, Jaegeuk Kim wrote:
> > > This is useful when checking conditions during checkpoint=disable in
> > > Android.
> >
> > This sysfs entry is readonly, how about putting this at
&g
On 03/02, Chao Yu wrote:
> On 2021/3/2 13:42, Jaegeuk Kim wrote:
> > This is useful when checking conditions during checkpoint=disable in
> > Android.
>
> This sysfs entry is readonly, how about putting this at
> /sys/fs/f2fs//stat/?
Urg.. "stat" is a bit c
This is useful when checking conditions during checkpoint=disable in Android.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/sysfs.c | 8
1 file changed, 8 insertions(+)
diff --git a/fs/f2fs/sysfs.c b/fs/f2fs/sysfs.c
index e38a7f6921dd..254b6fa17406 100644
--- a/fs/f2fs/sysfs.c
+++ b/fs/f2fs
On 03/01, Jaegeuk Kim wrote:
> On 03/01, Chao Yu wrote:
> > Hi Jianan,
>
> Merged 1/3 and 2/3, so please post v2 on 3/3.
NVM. Found v2.
>
> Thanks,
>
> >
> > On 2021/2/27 20:02, Huang Jianan via Linux-f2fs-devel wrote:
> > > If the swapfile
On 03/01, Chao Yu wrote:
> Hi Jianan,
Merged 1/3 and 2/3, so please post v2 on 3/3.
Thanks,
>
> On 2021/2/27 20:02, Huang Jianan via Linux-f2fs-devel wrote:
> > If the swapfile isn't created by pin and fallocate, it cann't be
>
> Typo:
>
> can't
>
> > guaranteed section-aligned, so it may
On 02/04, Chao Yu wrote:
> Jaegeuk,
>
> On 2021/2/2 16:00, Chao Yu wrote:
> > - for (i = 0; i < dic->nr_cpages; i++) {
> > + for (i = 0; i < cc->nr_cpages; i++) {
> > struct page *page = dic->cpages[i];
>
> por_fsstress still hang in this line?
I'm stuck on testing the patches,
On 02/23, Chao Yu wrote:
> Jaegeuk,
>
> Could you please help to review this patch? since I doubt that this
> issue can happen in real world... :(
Let me take a look as soon as I have some time. Sorry for the delay.
>
> Thanks,
>
> On 2021/2/22 21:43, Chao Yu wrote:
> > Ping,
> >
> > On
On 02/25, Chao Yu wrote:
> Hello, Gustavo,
>
> On 2021/2/25 3:03, Gustavo A. R. Silva wrote:
> > There is a regular need in the kernel to provide a way to declare having
> > a dynamically sized set of trailing elements in a structure. Kernel code
> > should always use “flexible array members”[1]
processing
libfs: unexport generic_ci_d_compare() and generic_ci_d_hash()
Jack Qiu (1):
f2fs: remove unused stat_{inc, dec}_atomic_write
Jaegeuk Kim (5):
f2fs: handle unallocated section and zone on pinned/atgc
f2fs: deprecate f2fs_trace_io
f2fs: flush data when
Let's allow mounting readonly partition. We're able to recovery later once we
have it as read-write back.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/super.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index 4aa533cb4340..30d5abef4361
__percpu_down_read+0x56/0x70
issue_checkpoint_thread+0x12c/0x160 [f2fs]
? wait_woken+0x80/0x80
kthread+0x114/0x150
? __checkpoint_and_complete_reqs+0x110/0x110 [f2fs]
? kthread_park+0x90/0x90
ret_from_fork+0x22/0x30
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/checkpoint.c | 4
fs/f2fs
On 02/02, Daeho Jeong wrote:
> From: Daeho Jeong
>
> As checkpoint=merge comes in, mount option setting related to checkpoint
> had been mixed up and it became hard to understand. So, I separated
> this option from "checkpoint=" and made another mount option
> "checkpoint_merge" for this.
Thanks.
Merged into the original patch.
On 02/01, Daeho Jeong wrote:
> From: Daeho Jeong
>
> It causes a crash to change the ioprio of checkpoint thread not in
> checkpoint=merge. I fixed that to prevent setting the ioprio of the
> thread when checkpoint=merge is not enabled.
>
>
On 02/01, Daeho Jeong wrote:
> Actually, I think we need to select one among them, disable, enable
> and merge. I realized my previous understanding about that was wrong.
> In that case of "checkpoint=merge,checkpoint=enable", the last option
> will override the ones before that.
> This is how the
On 01/20, Chao Yu wrote:
> On 2021/1/20 3:06, Jaegeuk Kim wrote:
> > On 01/15, Chao Yu wrote:
> > > On 2021/1/15 5:53, Jaegeuk Kim wrote:
> > > > On 12/30, Chao Yu wrote:
> > > > > ThreadA ThreadB
> > &g
On 01/28, Chao Yu wrote:
> On 2021/1/22 10:17, Chao Yu wrote:
> > > No, it seems this is not the case.
> > Oops, could you please help to remove all below codes and do the test again
> > to check whether they are the buggy codes? as I doubt there is
> > use-after-free
> > bug.
>
> Any test
;f2fs: checkpoint disabling")
Cc: sta...@vger.kernel.org
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/super.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index 359cc5a2f8f5..073b51af62c8 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -1887
On 01/21, Daeho Jeong wrote:
> From: Daeho Jeong
>
> We've added a new mount option "checkpoint=merge", which creates a
> kernel daemon and makes it to merge concurrent checkpoint requests as
> much as possible to eliminate redundant checkpoint issues. Plus, we
> can eliminate the sluggish issue
In __ufshcd_issue_tm_cmd(), it is not right to use hba->nutrs +
> req->tag as the Task Tag in one TMR UPIU.
> Fix: Directly use req->tag as Task Tag.
>
> Cc: Jaegeuk Kim
> Signed-off-by: Can Guo
>
> ---
>
> This change is based on Jaegeuk's change -
On 01/16, Chao Yu wrote:
> On 2021/1/15 22:59, Jaegeuk Kim wrote:
> > On 01/15, Chao Yu wrote:
> > > On 2021/1/14 12:06, Jaegeuk Kim wrote:
> > > > On 01/14, Chao Yu wrote:
> > > > > On 2021/1/13 23:41, Jaegeuk Kim wrote:
> > >
On 01/15, Chao Yu wrote:
> On 2021/1/15 5:53, Jaegeuk Kim wrote:
> > On 12/30, Chao Yu wrote:
> > > ThreadA ThreadB
> > > - f2fs_ioc_start_atomic_write
> > > - write
> > > - f2fs_ioc_commit_a
Is there v4 2/2?
On 01/19, Daeho Jeong wrote:
> From: Daeho Jeong
>
> We've added a new mount option "checkpoint=merge", which creates a
> kernel daemon and makes it to merge concurrent checkpoint requests as
> much as possible to eliminate redundant checkpoint issues. Plus, we
> can eliminate
On 01/15, Chao Yu wrote:
> On 2021/1/14 12:06, Jaegeuk Kim wrote:
> > On 01/14, Chao Yu wrote:
> > > On 2021/1/13 23:41, Jaegeuk Kim wrote:
> > > > [58690.961685] F2FS-fs (vdb) : inject page get in
> > > > f2fs_pagecache_get_page of f2fs_quota_write+0x15
This patch deprecates f2fs_trace_io, since f2fs uses page->private more broadly,
resulting in more buggy cases.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/Kconfig | 10 ---
fs/f2fs/Makefile | 1 -
fs/f2fs/checkpoint.c | 3 -
fs/f2fs/data.c | 4 --
fs/f2fs/file.c |
On 12/30, Chao Yu wrote:
> ThreadA ThreadB
> - f2fs_ioc_start_atomic_write
> - write
> - f2fs_ioc_commit_atomic_write
> - f2fs_commit_inmem_pages
> - f2fs_drop_inmem_pages
> - f2fs_drop_inmem_pages
> - __revoke_inmem_pages
>
On 01/14, Chao Yu wrote:
> On 2021/1/13 23:41, Jaegeuk Kim wrote:
> > [58690.961685] F2FS-fs (vdb) : inject page get in f2fs_pagecache_get_page
> > of f2fs_quota_write+0x150/0x1f0 [f2fs]
> > [58691.071481] F2FS-fs (vdb): Inconsistent error blkaddr:31058, sit bitma
On 01/13, Chao Yu wrote:
> On 2021/1/13 6:36, Jaegeuk Kim wrote:
> > On 01/12, Chao Yu wrote:
> > > On 2021/1/12 10:04, Jaegeuk Kim wrote:
> > > > On 01/12, Chao Yu wrote:
> > > > > On 2021/1/11 19:45, Chao Yu wrote:
> > > > > > On 2
On 01/12, Chao Yu wrote:
> On 2021/1/12 10:04, Jaegeuk Kim wrote:
> > On 01/12, Chao Yu wrote:
> > > On 2021/1/11 19:45, Chao Yu wrote:
> > > > On 2021/1/11 18:31, Chao Yu wrote:
> > > > > On 2021/1/11 17:48, Jaegeuk Kim wrote:
> > > &g
On 01/12, Chao Yu wrote:
> On 2021/1/12 0:32, Jaegeuk Kim wrote:
> > On 01/06, Jaegeuk Kim wrote:
> > > On 01/06, Jaegeuk Kim wrote:
> > > > Hi Chao,
> > > >
> > > > With a quick test, this patch causes down_write failure resulting in
> &
On 01/12, Chao Yu wrote:
> On 2021/1/11 19:45, Chao Yu wrote:
> > On 2021/1/11 18:31, Chao Yu wrote:
> > > On 2021/1/11 17:48, Jaegeuk Kim wrote:
> > > > Hi Chao,
> > > >
> > > > After quick test of fsstress w/ fault injection, it gave wrong b
On 01/06, Jaegeuk Kim wrote:
> On 01/06, Jaegeuk Kim wrote:
> > Hi Chao,
> >
> > With a quick test, this patch causes down_write failure resulting in
> > blocking
> > process. I didn't dig in the bug so, please check the code again. :P
>
> nvm. I can se
From: Jaegeuk Kim
Kernel stack violation when getting unit_descriptor/wb_buf_alloc_units from
rpmb lun. The reason is the unit descriptor length is different per LU.
The lengh of Normal LU is 45, while the one of rpmb LU is 35.
int ufshcd_read_desc_param(struct ufs_hba *hba
On 01/11, Avri Altman wrote:
> > static inline bool ufs_is_valid_unit_desc_lun(struct ufs_dev_info
> > *dev_info,
> > - u8 lun)
> > + u8 lun, u8 param_offset)
> > {
> > if (!dev_info || !dev_info->max_lu_supported) {
> > pr_err("Max General LU
On 01/11, Daeho Jeong wrote:
> From: Daeho Jeong
>
> We've added a new mount option "checkpoint=merge", which creates a
> kernel daemon and makes it to merge concurrent checkpoint requests as
> much as possible to eliminate redundant checkpoint issues. Plus, we
> can eliminate the sluggish issue
Hi Chao,
After quick test of fsstress w/ fault injection, it gave wrong block address
errors. Could you please run the test a bit?
Thanks,
On 01/07, Chao Yu wrote:
> Support to use address space of inner inode to cache compressed block,
> in order to improve cache hit ratio of random read.
>
>
On 01/11, Daeho Jeong wrote:
> From: Daeho Jeong
>
> We've added a new mount option "checkpoint=merge", which creates a
> kernel daemon and makes it to merge concurrent checkpoint requests as
> much as possible to eliminate redundant checkpoint issues. Plus, we
> can eliminate the sluggish issue
From: Jaegeuk Kim
Kernel stack violation when getting unit_descriptor/wb_buf_alloc_units from
rpmb lun. The reason is the unit descriptor length is different per LU.
The lengh of Normal LU is 45, while the one of rpmb LU is 35.
int ufshcd_read_desc_param(struct ufs_hba *hba
On 01/11, Can Guo wrote:
> On 2021-01-11 16:15, Avri Altman wrote:
> > >
> > > Sorry, typo corrected.
> > >
> > > Hi Jaegeuk,
> > >
> > > I think the problem is that func ufshcd_read_desc_param() is not
> > > expecting
> > > one access unsupported descriptors on RPMB LU.
> > Correct.
> > This
From: Jaegeuk Kim
Kernel stack violation when getting unit_descriptor/wb_buf_alloc_units from
rpmb lun. The reason is the unit descriptor length is different per LU.
The lengh of Normal LU is 45, while the one of rpmb LU is 35.
int ufshcd_read_desc_param(struct ufs_hba *hba
On 01/07, Can Guo wrote:
> On 2021-01-07 16:46, Jaegeuk Kim wrote:
> > On 01/07, Can Guo wrote:
> > > On 2021-01-07 16:07, Jaegeuk Kim wrote:
> > > > On 01/07, Can Guo wrote:
> > > > > On 2021-01-07 15:47, Jaegeuk Kim wrote:
> > > >
From: Jaegeuk Kim
When non-fatal error like line-reset happens, ufshcd_err_handler() starts to
abort tasks by ufshcd_try_to_abort_task(). When it tries to issue tm request,
we've hit two warnings.
WARNING: CPU: 7 PID: 7 at block/blk-core.c:630 blk_get_request+0x68/0x70
WARNING: CPU: 4 PID: 157
Change log from v4:
- remove RESERVE tag for tm command
- remove waiting IOs and let full reset handle it
- avoid verbose error log which causes cpu lock up
per recovery flows
such as suspend/resume, link_recovery, and error_handler.
Fixes: 1918651f2d7e ("scsi: ufs: Clear UAC for RPMB after ufshcd resets")
Signed-off-by: Jaegeuk Kim
Reviewed-by: Can Guo
---
drivers/scsi/ufs/ufshcd.c | 19 ---
1 file changed, 12 insertions(+)
On 01/07, Can Guo wrote:
> On 2021-01-07 16:07, Jaegeuk Kim wrote:
> > On 01/07, Can Guo wrote:
> > > On 2021-01-07 15:47, Jaegeuk Kim wrote:
> > > > From: Jaegeuk Kim
> > > >
> > > > This fixes a warning caused by wrong reserve tag usage in
On 01/07, Can Guo wrote:
> On 2021-01-07 15:47, Jaegeuk Kim wrote:
> > From: Jaegeuk Kim
> >
> > This fixes a warning caused by wrong reserve tag usage in
> > __ufshcd_issue_tm_cmd.
> >
> > WARNING: CPU: 7 PID: 7 at block/blk-core.c:630 blk_get_request
From: Jaegeuk Kim
This fixes a warning caused by wrong reserve tag usage in __ufshcd_issue_tm_cmd.
WARNING: CPU: 7 PID: 7 at block/blk-core.c:630 blk_get_request+0x68/0x70
WARNING: CPU: 4 PID: 157 at block/blk-mq-tag.c:82 blk_mq_get_tag+0x438/0x46c
And, in ufshcd_err_handler(), we can avoid
per recovery flows
such as suspend/resume, link_recovery, and error_handler.
Fixes: 1918651f2d7e ("scsi: ufs: Clear UAC for RPMB after ufshcd resets")
Signed-off-by: Jaegeuk Kim
---
drivers/scsi/ufs/ufshcd.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --
Change log from v3:
- move ufshcd_clear_ua_wluns() after ufshcd_scsi_add_wlus()
- remove BLK_MQ_REQ_RESERVED for tm tag
- move IO wait to cover all the non-fatal errors
On 01/07, Can Guo wrote:
> On 2021-01-07 14:57, Jaegeuk Kim wrote:
> > On 01/07, Can Guo wrote:
> > > On 2021-01-07 05:41, Jaegeuk Kim wrote:
> > > > When gate_work/ungate_work gets an error during hibern8_enter or exit,
> > > > ufshcd_err_handl
On 01/07, Can Guo wrote:
> On 2021-01-07 14:51, Jaegeuk Kim wrote:
> > On 01/07, Can Guo wrote:
> > > On 2021-01-07 05:41, Jaegeuk Kim wrote:
> > > > From: Jaegeuk Kim
> > > >
> > > > This fixes a warning caused by wrong reserve tag usage in
On 01/07, Can Guo wrote:
> On 2021-01-07 05:41, Jaegeuk Kim wrote:
> > When gate_work/ungate_work gets an error during hibern8_enter or exit,
> > ufshcd_err_handler()
> >ufshcd_scsi_block_requests()
> >ufshcd_reset_and_restore()
> >
On 01/07, Can Guo wrote:
> On 2021-01-07 05:41, Jaegeuk Kim wrote:
> > From: Jaegeuk Kim
> >
> > This fixes a warning caused by wrong reserve tag usage in
> > __ufshcd_issue_tm_cmd.
> >
> > WARNING: CPU: 7 PID: 7 at block/blk-core.c:630 blk_get_request
On 01/07, Can Guo wrote:
> Hi Jaegeuk,
>
> On 2021-01-07 05:41, Jaegeuk Kim wrote:
> > From: Jaegeuk Kim
> >
> > This fixes a warning caused by wrong reserve tag usage in
> > __ufshcd_issue_tm_cmd.
> >
> > WARNING: CPU: 7 PID: 7 at block/blk-cor
On 01/06, Jaegeuk Kim wrote:
> Hi Chao,
>
> With a quick test, this patch causes down_write failure resulting in blocking
> process. I didn't dig in the bug so, please check the code again. :P
nvm. I can see it works now.
>
> On 12/30, Chao Yu
Hi Chao,
With a quick test, this patch causes down_write failure resulting in blocking
process. I didn't dig in the bug so, please check the code again. :P
On 12/30, Chao Yu wrote:
> ThreadA ThreadB
> - f2fs_ioc_start_atomic_write
> - write
> -
From: Jaegeuk Kim
This fixes a warning caused by wrong reserve tag usage in __ufshcd_issue_tm_cmd.
WARNING: CPU: 7 PID: 7 at block/blk-core.c:630 blk_get_request+0x68/0x70
WARNING: CPU: 4 PID: 157 at block/blk-mq-tag.c:82 blk_mq_get_tag+0x438/0x46c
And, in ufshcd_err_handler(), we can avoid
per recovery flows
such as suspend/resume, link_recovery, and error_handler.
Fixes: 1918651f2d7e ("scsi: ufs: Clear UAC for RPMB after ufshcd resets")
Signed-off-by: Jaegeuk Kim
---
drivers/scsi/ufs/ufshcd.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a
Change log from v2:
- fix build warning
On 12/09, Jaegeuk Kim wrote:
> On 12/10, Chao Yu wrote:
> > Hi Daeho, Jaegeuk
> >
> > I found one missing place in this patch which should adapt
> > "compress vs verity race bugfix"
> >
> > Could you please check and apply below diff?
>
>
From: Jaegeuk Kim
This fixes a warning caused by wrong reserve tag usage in __ufshcd_issue_tm_cmd.
WARNING: CPU: 7 PID: 7 at block/blk-core.c:630 blk_get_request+0x68/0x70
WARNING: CPU: 4 PID: 157 at block/blk-mq-tag.c:82 blk_mq_get_tag+0x438/0x46c
And, in ufshcd_err_handler(), we can avoid
per recovery flows
such as suspend/resume, link_recovery, and error_handler.
Fixes: 1918651f2d7e ("scsi: ufs: Clear UAC for RPMB after ufshcd resets")
Signed-off-by: Jaegeuk Kim
---
drivers/scsi/ufs/ufshcd.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a
per recovery flows
such as suspend/resume, link_recovery, and error_handler.
Fixes: 1918651f2d7e ("scsi: ufs: Clear UAC for RPMB after ufshcd resets")
Signed-off-by: Jaegeuk Kim
---
drivers/scsi/ufs/ufshcd.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a
; ufshcd_clear_ua_wluns() -> stuck
> >ufshcd_scsi_unblock_requests()
> >
> > In order to avoid it, ufshcd_clear_ua_wluns() can be called per recovery
> > flows
> > such as suspend/resume, link_recovery, and error_handler.
> >
> > Fixes: 1918651f2d7e ("scsi: ufs: Clea
per recovery flows
such as suspend/resume, link_recovery, and error_handler.
Fixes: 1918651f2d7e ("scsi: ufs: Clear UAC for RPMB after ufshcd resets")
Signed-off-by: Jaegeuk Kim
---
drivers/scsi/ufs/ufshcd.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a
If we have large section/zone, unallocated segment makes them corrupted.
E.g.,
- Pinned file: -1 119304647 119304647
- ATGC data: -1 119304647 119304647
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/segment.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
1 - 100 of 4753 matches
Mail list logo
