[f2fs-dev] [PATCH] f2fs: use unlikely for release case

Since the variable release is only nonzero when another unlikely case occurs, use unlikely() on it seems logical. Signed-off-by: Fan li --- fs/f2fs/f2fs.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h index

[f2fs-dev] [PATCH] f2fs: use unlikely for release case

Since the variable release is only nonzero when another unlikely case occurs, use unlikely() on it seems logical. Signed-off-by: Fan li --- fs/f2fs/f2fs.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h index 71fbba96..0f01af0 100644 ---

[f2fs-dev] [PATCH] f2fs: release reserved blocks for quota

Quota has been modified during inc_valid_block_count(), but not in truncate process. This patch adds it. Signed-off-by: Fan li --- fs/f2fs/f2fs.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h index 82f1dc3..71fbba96 100644 ---

[f2fs-dev] [PATCH] f2fs: release reserved blocks for quota

Quota has been modified during inc_valid_block_count(), but not in truncate process. This patch adds it. Signed-off-by: Fan li --- fs/f2fs/f2fs.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h index 82f1dc3..71fbba96 100644 --- a/fs/f2fs/f2fs.h +++

[f2fs-dev] [PATCH] f2fs: remove a redundant conditional expression

Avoid checking is_inode repeatedly, and make the logic a little bit clearer. Signed-off-by: Fan li --- fs/f2fs/f2fs.h | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h index 4acdca4..95cc4ef 100644 ---

[f2fs-dev] [PATCH] f2fs: remove a redundant conditional expression

Avoid checking is_inode repeatedly, and make the logic a little bit clearer. Signed-off-by: Fan li --- fs/f2fs/f2fs.h | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h index 4acdca4..95cc4ef 100644 --- a/fs/f2fs/f2fs.h +++

[f2fs-dev] [PATCH] f2fs: remove an excess variable

Remove the variable page_idx which no one would miss. Signed-off-by: Fan li --- fs/f2fs/data.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c index b0781ed..1a9 100644 --- a/fs/f2fs/data.c +++ b/fs/f2fs/data.c

[f2fs-dev] [PATCH] f2fs: remove an excess variable

Remove the variable page_idx which no one would miss. Signed-off-by: Fan li --- fs/f2fs/data.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c index b0781ed..1a9 100644 --- a/fs/f2fs/data.c +++ b/fs/f2fs/data.c @@ -1198,7 +1198,6 @@

[f2fs-dev] [PATCH RESEND v3] f2fs: fix concurrent problem for updating free bitmap

alloc_nid_failed and scan_nat_page can be called at the same time, and we haven't protected add_free_nid and update_free_nid_bitmap with the same nid_list_lock. That could lead to Thread AThread B - __build_free_nids - scan_nat_page

[f2fs-dev] [PATCH RESEND v3] f2fs: fix concurrent problem for updating free bitmap

alloc_nid_failed and scan_nat_page can be called at the same time, and we haven't protected add_free_nid and update_free_nid_bitmap with the same nid_list_lock. That could lead to Thread AThread B - __build_free_nids - scan_nat_page

[f2fs-dev] [PATCH RESEND v2] f2fs: fix concurrent problem for updating free bitmap

alloc_nid_failed and scan_nat_page can be called at the same time, and we haven't protected add_free_nid and update_free_nid_bitmap with the same nid_list_lock. That could lead to Thread AThread B - __build_free_nids - scan_nat_page

[f2fs-dev] [PATCH RESEND v2] f2fs: fix concurrent problem for updating free bitmap

alloc_nid_failed and scan_nat_page can be called at the same time, and we haven't protected add_free_nid and update_free_nid_bitmap with the same nid_list_lock. That could lead to Thread AThread B - __build_free_nids - scan_nat_page

RE: [f2fs-dev] [PATCH RESEND] f2fs: fix concurrent problem for updating free bitmap

> -Original Message- > From: Chao Yu [mailto:yuch...@huawei.com] > Sent: Monday, November 20, 2017 11:00 AM > To: LiFan; 'Chao Yu'; 'Jaegeuk Kim' > Cc: linux-kernel@vger.kernel.org; linux-f2fs-de...@lists.sourceforge.net > Subject: Re: [f2fs-dev] [PATCH RESEND] f2

RE: [f2fs-dev] [PATCH RESEND] f2fs: fix concurrent problem for updating free bitmap

> -Original Message- > From: Chao Yu [mailto:yuch...@huawei.com] > Sent: Monday, November 20, 2017 11:00 AM > To: LiFan; 'Chao Yu'; 'Jaegeuk Kim' > Cc: linux-kernel@vger.kernel.org; linux-f2fs-de...@lists.sourceforge.net > Subject: Re: [f2fs-dev] [PATCH RESEND] f2

[f2fs-dev] [PATCH RESEND] f2fs: fix concurrent problem for updating free bitmap

alloc_nid_failed and scan_nat_page can be called at the same time, and we haven't protected add_free_nid and update_free_nid_bitmap with the same nid_list_lock. That could lead to Thread AThread B - __build_free_nids - scan_nat_page

[f2fs-dev] [PATCH RESEND] f2fs: fix concurrent problem for updating free bitmap

alloc_nid_failed and scan_nat_page can be called at the same time, and we haven't protected add_free_nid and update_free_nid_bitmap with the same nid_list_lock. That could lead to Thread AThread B - __build_free_nids - scan_nat_page

[f2fs-dev] [PATCH RESEND v2] f2fs: validate before set/clear free nat bitmap

In flush_nat_entries, all dirty nats will be flushed and if their new address isn't NULL_ADDR, their bitmaps will be updated, the free_nid_count of the bitmaps will be increased regardless of whether the nats have already been occupied before. This could lead to wrong free_nid_count. So this patch

[f2fs-dev] [PATCH RESEND v2] f2fs: validate before set/clear free nat bitmap

In flush_nat_entries, all dirty nats will be flushed and if their new address isn't NULL_ADDR, their bitmaps will be updated, the free_nid_count of the bitmaps will be increased regardless of whether the nats have already been occupied before. This could lead to wrong free_nid_count. So this patch

[f2fs-dev] [PATCH] f2fs: fix concurrent problem for updating free bitmap

alloc_nid_failed and scan_nat_page can be called at the same time, and we haven't protected add_free_nid and update_free_nid_bitmap with the same nid_list_lock. That could lead to Thread AThread B - __build_free_nids - scan_nat_page

[f2fs-dev] [PATCH] f2fs: fix concurrent problem for updating free bitmap

alloc_nid_failed and scan_nat_page can be called at the same time, and we haven't protected add_free_nid and update_free_nid_bitmap with the same nid_list_lock. That could lead to Thread AThread B - __build_free_nids - scan_nat_page

[f2fs-dev] [PATCH RESEND] f2fs: validate before set/clear free nat bitmap

In flush_nat_entries, all dirty nats will be flushed and if their new address isn't NULL_ADDR, their bitmaps will be updated, the free_nid_count of the bitmaps will be increased regardless of whether the nats have already been occupied before. This could lead to wrong free_nid_count. So this

[f2fs-dev] [PATCH RESEND] f2fs: validate before set/clear free nat bitmap

In flush_nat_entries, all dirty nats will be flushed and if their new address isn't NULL_ADDR, their bitmaps will be updated, the free_nid_count of the bitmaps will be increased regardless of whether the nats have already been occupied before. This could lead to wrong free_nid_count. So this

[f2fs-dev] [PATCH] f2fs: validate before set/clear free nat bitmap

In flush_nat_entries, all dirty nats will be flushed and if their new address isn't NULL_ADDR, their bitmaps will be updated, the free_nid_count of the bitmaps will be increaced regardless of whether the nats have already been occupied before. This could lead to wrong free_nid_count. So this patch

[f2fs-dev] [PATCH] f2fs: validate before set/clear free nat bitmap

In flush_nat_entries, all dirty nats will be flushed and if their new address isn't NULL_ADDR, their bitmaps will be updated, the free_nid_count of the bitmaps will be increaced regardless of whether the nats have already been occupied before. This could lead to wrong free_nid_count. So this patch

Why copy_from/to_user causes KASAN complain?

Hi all, I got "BUG: KASAN: user-memory-access on address ..." message when developing a driver. I reviewed my code twice and didn't find why. I experienced this on various kernel versions. Please tell me why my code cause this warning? Here is a minimal reproduce example: On a Fedora-23 host,

Why copy_from/to_user causes KASAN complain?

Hi all, I got "BUG: KASAN: user-memory-access on address ..." message when developing a driver. I reviewed my code twice and didn't find why. I experienced this on various kernel versions. Please tell me why my code cause this warning? Here is a minimal reproduce example: On a Fedora-23 host,