> >
> > Thanks for helping to test this patch.
>
> Was this patch applied? I do not see it in mainline (unless
> miss-checked).
Not yet. Queue for next merge window.
https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git/commit/?h=dev&id=b862676e371715456c9dade7990c8004996d0d9e
>
> Regards,
> Salvatore
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->allo
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.
>
> Signed-off-b
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 5a342a8f332a1b328
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 bloc
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..c1
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,
> S
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 source secti
> return segno;
> @@ -2643,6 +2643,26 @@ static void __refresh_next_blkoff(struct f2fs_sb_info
> *sbi,
> seg->next_blkoff++;
> }
>
> +bool segment_has_free_slot(struct f2fs_sb_info *sbi, int segno)
> +{
> + struct sit_info
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 thou
7;s block could
> > be migrated to other place, however user won't be aware of such
> > condition, and then old obsolete block address may be readed/written
> > incorrectly.
> >
> > To avoid such condition, let's try to allocate pinned file's bloc
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 sta
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
e selected 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
> > > >
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 during checkpoint=disable
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 f2fs_att
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 isn
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 be
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
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:
&g
“flexible array members”[1] for these cases. The older
> > style of one-element or zero-length arrays should no longer be used[2].
>
> I proposal to do the similar cleanup, and I've no objection on doing this.
>
> https://lore.kernel.org/patchwork/patch/869440/
>
> Let
ble in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git
tags/f2fs-for-5.12-rc1
for you to fetch changes up to 092af2eb180062f5bafe02a75da9856676eb4f89:
Documentation: f2fs: fix typo s/automaic/automatic (2021-02-16 07:5
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..30
__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
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.
>
> Signed-off-by:
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 result
;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
fshcd_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 chang
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 t
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:
> > > >
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 c
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
> >
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:
> > > > &g
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
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+0x
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 to
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+0x
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, Cha
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
> - f2fs_ioc_commi
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 to
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 to
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
On 01/05, Martin K. Petersen wrote:
>
> Jaegeuk,
>
> > When gate_work/ungate_work gets an error during hibern8_enter or exit,
> > ufshcd_err_handler()
> >ufshcd_scsi_block_requests()
> >ufshcd_reset_and_restore()
> >
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 a
1 - 100 of 1261 matches
Mail list logo
