From: Ocean Chen
[ Upstream commit 56f3ce675103e3fb9e631cfb4131fc768bc23e9a ]
blkoff_off might over 512 due to fs corrupt or security
vulnerability. That should be checked before being using.
Use ENTRIES_IN_SUM to protect invalid value in cur_data_blkoff.
Signed-off-by: Ocean Chen
From: Ocean Chen
[ Upstream commit 56f3ce675103e3fb9e631cfb4131fc768bc23e9a ]
blkoff_off might over 512 due to fs corrupt or security
vulnerability. That should be checked before being using.
Use ENTRIES_IN_SUM to protect invalid value in cur_data_blkoff.
Signed-off-by: Ocean Chen
From: Ocean Chen
[ Upstream commit 56f3ce675103e3fb9e631cfb4131fc768bc23e9a ]
blkoff_off might over 512 due to fs corrupt or security
vulnerability. That should be checked before being using.
Use ENTRIES_IN_SUM to protect invalid value in cur_data_blkoff.
Signed-off-by: Ocean Chen
From: Ocean Chen
[ Upstream commit 56f3ce675103e3fb9e631cfb4131fc768bc23e9a ]
blkoff_off might over 512 due to fs corrupt or security
vulnerability. That should be checked before being using.
Use ENTRIES_IN_SUM to protect invalid value in cur_data_blkoff.
Signed-off-by: Ocean Chen
From: Heng Xiao
[ Upstream commit 6e0cd4a9dd4df1a0afcb454f1e654b5c80685913 ]
In umount, we give an constand time to handle pending discard, previously,
in __issue_discard_cmd() we missed to check timeout condition in loop,
result in delaying long time, fix it.
Signed-off-by: Heng Xiao
[Chao
From: Ocean Chen
[ Upstream commit 56f3ce675103e3fb9e631cfb4131fc768bc23e9a ]
blkoff_off might over 512 due to fs corrupt or security
vulnerability. That should be checked before being using.
Use ENTRIES_IN_SUM to protect invalid value in cur_data_blkoff.
Signed-off-by: Ocean Chen
From: Sahitya Tummala
[ Upstream commit 56659ce838456c6f2315ce8a4bd686ac4b23e9d1 ]
The discard thread should issue upto dpolicy->max_requests at once
and wait for all those discard requests at once it reaches
dpolicy->max_requests. It should then sleep for dpolicy->min_interval
timeout before
From: Chao Yu
[ Upstream commit 040d2bb318d1aea4f28cc22504b44e44c86e ]
As Hagbard Celine reported:
[ 615.697824] INFO: task kworker/u16:5:344 blocked for more than 120 seconds.
[ 615.697825] Not tainted 5.0.15-gentoo-f2fslog #4
[ 615.697826] "echo 0 >
From: Daniel Rosenberg
[ Upstream commit ae4ad7ea09d32ff1b6fb908ff12f8c1bd5241b29 ]
The existing threshold for allowable holes at checkpoint=disable time is
too high. The OVP space contains reserved segments, which are always in
the form of free segments. These must be subtracted from the OVP
From: Daniel Rosenberg
[ Upstream commit a4c3ecaaadac5693f555cfef1c9eecf4c39df818 ]
Fixes possible underflows when dealing with unusable blocks.
Signed-off-by: Daniel Rosenberg
Reviewed-by: Chao Yu
Signed-off-by: Jaegeuk Kim
Signed-off-by: Sasha Levin
---
fs/f2fs/f2fs.h | 15
From: Heng Xiao
[ Upstream commit 6e0cd4a9dd4df1a0afcb454f1e654b5c80685913 ]
In umount, we give an constand time to handle pending discard, previously,
in __issue_discard_cmd() we missed to check timeout condition in loop,
result in delaying long time, fix it.
Signed-off-by: Heng Xiao
[Chao
From: Ocean Chen
[ Upstream commit 56f3ce675103e3fb9e631cfb4131fc768bc23e9a ]
blkoff_off might over 512 due to fs corrupt or security
vulnerability. That should be checked before being using.
Use ENTRIES_IN_SUM to protect invalid value in cur_data_blkoff.
Signed-off-by: Ocean Chen
From: Sahitya Tummala
[ Upstream commit 56659ce838456c6f2315ce8a4bd686ac4b23e9d1 ]
The discard thread should issue upto dpolicy->max_requests at once
and wait for all those discard requests at once it reaches
dpolicy->max_requests. It should then sleep for dpolicy->min_interval
timeout before
From: Daniel Rosenberg
[ Upstream commit ae4ad7ea09d32ff1b6fb908ff12f8c1bd5241b29 ]
The existing threshold for allowable holes at checkpoint=disable time is
too high. The OVP space contains reserved segments, which are always in
the form of free segments. These must be subtracted from the OVP
From: Daniel Rosenberg
[ Upstream commit a4c3ecaaadac5693f555cfef1c9eecf4c39df818 ]
Fixes possible underflows when dealing with unusable blocks.
Signed-off-by: Daniel Rosenberg
Reviewed-by: Chao Yu
Signed-off-by: Jaegeuk Kim
Signed-off-by: Sasha Levin
---
fs/f2fs/f2fs.h | 15
From: Chao Yu
[ Upstream commit 5dae2d39074dde941cc3150dcbb7840d88179743 ]
As Ju Hyung reported:
"
I was semi-forced today to use the new kernel and test f2fs.
My Ubuntu initramfs got a bit wonky and I had to boot into live CD and
fix some stuffs. The live CD was using 4.15 kernel, and just
From: Chao Yu
[ Upstream commit 040d2bb318d1aea4f28cc22504b44e44c86e ]
As Hagbard Celine reported:
[ 615.697824] INFO: task kworker/u16:5:344 blocked for more than 120 seconds.
[ 615.697825] Not tainted 5.0.15-gentoo-f2fslog #4
[ 615.697826] "echo 0 >
On a quota disabled image, with fault injection, SBI_QUOTA_NEED_REPAIR
will be set incorrectly in error path of f2fs_evict_inode(), fix it.
Signed-off-by: Chao Yu
---
fs/f2fs/inode.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c
index
On 2019/7/19 8:03, Daniel Rosenberg wrote:
> Modeled after commit b886ee3e778e ("ext4: Support case-insensitive file
> name lookups")
>
> """
> This patch implements the actual support for case-insensitive file name
> lookups in f2fs, based on the feature bit and the encoding stored in the
>
On 2019/7/19 8:03, Daniel Rosenberg wrote:
> Add charset encoding to f2fs to support casefolding. It is modeled after
> the same feature introduced in commit c83ad55eaa91 ("ext4: include charset
> encoding information in the superblock")
>
> Currently this is not compatible with encryption,
On 2019/7/19 5:31, Daniel Rosenberg wrote:
>
> On 7/17/19 3:11 AM, Chao Yu wrote:
>> We need to add one more entry f2fs_fsflags_map[] to map F2FS_CASEFOLD_FL to
>> FS_CASEFOLD_FL correctly and adapt F2FS_GETTABLE_FS_FL/F2FS_SETTABLE_FS_FL
>> as well.
>
> I don't see FS_CASEFOLD_FL. It would
These patches are largely based on the casefolding patches for ext4
v3: Addressed feedback, apart from F2FS_CASEFOLD_FL/FS_CASEFOLD_FL
Added sysfs file "encoding" to see the encoding set on a filesystem
v2: Rebased patches again master, changed f2fs_msg to f2fs_info/f2fs_err
Daniel Rosenberg
Modeled after commit b886ee3e778e ("ext4: Support case-insensitive file
name lookups")
"""
This patch implements the actual support for case-insensitive file name
lookups in f2fs, based on the feature bit and the encoding stored in the
superblock.
A filesystem that has the casefold feature set
Add charset encoding to f2fs to support casefolding. It is modeled after
the same feature introduced in commit c83ad55eaa91 ("ext4: include charset
encoding information in the superblock")
Currently this is not compatible with encryption, similar to the current
ext4 imlpementation. This will
On 7/17/19 3:11 AM, Chao Yu wrote:
We need to add one more entry f2fs_fsflags_map[] to map F2FS_CASEFOLD_FL to
FS_CASEFOLD_FL correctly and adapt F2FS_GETTABLE_FS_FL/F2FS_SETTABLE_FS_FL as
well.
I don't see FS_CASEFOLD_FL. It would make sense for it to exist, but unless
it's in some recent
Pinning a file is heavy, because skipping pinned files make GC
running with heavy load or no effect.
So that this patch propose to separate nocow and pinfile semantics:
- NOCoW flag can only be set on regular file.
- NOCoW file will only trigger IPU at common writeback/flush.
- NOCow file will do
f2fs can support FS_IOC_{GET,SET}FSLABEL now, set max label length
to enable generic/492 testcase for f2fs.
Signed-off-by: Chao Yu
---
common/rc | 3 +++
1 file changed, 3 insertions(+)
diff --git a/common/rc b/common/rc
index 75ca6324..45781619 100644
--- a/common/rc
+++ b/common/rc
@@
https://bugzilla.kernel.org/show_bug.cgi?id=204193
Chao Yu (c...@kernel.org) changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #3 from
As reported in bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=204193
A null pointer dereference bug is triggered in f2fs under kernel-5.1.3.
kasan_report.cold+0x5/0x32
f2fs_write_end_io+0x215/0x650
bio_endio+0x26e/0x320
blk_update_request+0x209/0x5d0
blk_mq_end_request+0x2e/0x230
On 2019/7/18 12:00, Jaegeuk Kim wrote:
> On 07/18, Chao Yu wrote:
>> On 2019/7/18 11:12, Jaegeuk Kim wrote:
>>> f2fs_allocate_data_block() invalidates old block address and enable new
>>> block
>>> address. Then, if we try to read old block by f2fs_submit_page_bio(), it
>>> will
>>> give WARN
30 matches
Mail list logo
