Re: [f2fs-dev] [bug] writes hanging
Hi, I couldn't get any error when replaying your scenario on my arm board. So, could you send the backtrace of any hanged process? # cat /proc/[pid]/stack Thanks, 2013-12-20 (금), 12:29 -0800, John Grub: Hello, I can't seem to write larger files on my f2fs mount. My hardware is an embedded arm platform with an 8GB eMMC nand flash chip: Golbalscale D2Plug I have two of these pieces of hardware and I see this issue on both of them. There is no issue when I use ext4. I am running kernel version 3.13.0-rc4 I've compiled f2fs-tools from here http://git.kernel.org/cgit/linux/kernel/git/jaegeuk/f2fs-tools.git @ 11d187cdfa2dcf504aa25b5a1aab4228f19f22ff I've followed the installation and usage instructions in linux/Documentation/filesystems/f2fs.txt to format my 8GB eMMC nand flash as f2fs. I'm getting freezes when writing larger files to my f2fs partition. Here is an experiment I've done to show this. First create 3 test files of different sizes: # cat /dev/urandom | head -c 50k /tmp/50k # cat /dev/urandom | head -c 100k /tmp/100k # cat /dev/urandom | head -c 150k /tmp/150k Test case #1: Repeatedly copy the same 50k file to j2fs: # cp /tmp/50k /mnt/j2fs/ -- this copy always works fine # cp /tmp/50k /mnt/j2fs/ -- this copy always works fine # cp /tmp/50k /mnt/j2fs/ -- this copy always hangs forever For the failing copy, I've seen 4k, 8k and 12k copied correctly before it stops. Test case #2: Repeatedly copy the same 100k file to f2fs: # cp /tmp/100k /mnt/f2fs/ -- this copy works fine # cp /tmp/100k /mnt/f2fs/ -- this copy hangs forever For the failing copy, I've seen 4k, 8k and 12k copied correctly before it stops. Test case #3: Copy a 150k file to f2fs: # cp /tmp/150k /mnt/f2fs/ This never completes and will hang forever if I don't kill it. It always seems to fail at 120k. Any help would be appreciated. Thanks, John Grub -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel -- Jaegeuk Kim Samsung -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH 1/3] f2fs: check filename length in recover_dentry
2013-12-21 (토), 18:01 +0800, Chao Yu:
In current flow, we will get Null return value of f2fs_find_entry in
recover_dentry when name.len is bigger than F2FS_NAME_LEN, and then we
still add this inode into its dir entry.
To avoid this situation, we must check filename length before we use it.
Another point is that we could remove the code of checking filename length
In f2fs_find_entry, because f2fs_lookup will be called previously to ensure of
validity of filename length.
Signed-off-by: Chao Yu chao2...@samsung.com
---
fs/f2fs/dir.c |3 ---
fs/f2fs/recovery.c |5 +
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
index 0cc26ba..3f3b661 100644
--- a/fs/f2fs/dir.c
+++ b/fs/f2fs/dir.c
@@ -190,9 +190,6 @@ struct f2fs_dir_entry *f2fs_find_entry(struct inode *dir,
unsigned int max_depth;
unsigned int level;
- if (unlikely(namelen F2FS_NAME_LEN))
- return NULL;
-
if (npages == 0)
return NULL;
diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
index a3f4542..fdd175b 100644
--- a/fs/f2fs/recovery.c
+++ b/fs/f2fs/recovery.c
@@ -62,6 +62,11 @@ static int recover_dentry(struct page *ipage, struct inode
*inode)
name.len = le32_to_cpu(raw_inode-i_namelen);
name.name = raw_inode-i_name;
+
+ if (unlikely(name.len F2FS_NAME_LEN)) {
+ err = -ENAMETOOLONG;
+ goto out;
+ }
Have you seen this before?
This is a trivial bug case, so, if you have got this bug, we should fix
the bug first instead of adding any workaround patch.
Let's add WARN_ON() at least.
Thanks,
retry:
de = f2fs_find_entry(dir, name, page);
if (de inode-i_ino == le32_to_cpu(de-ino))
--
Jaegeuk Kim
Samsung
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH 1/3] f2fs: check filename length in recover_dentry
Hi Kim,
-Original Message-
From: Jaegeuk Kim [mailto:jaegeuk@samsung.com]
Sent: Monday, December 23, 2013 9:26 AM
To: Chao Yu
Cc: linux-fsde...@vger.kernel.org; linux-ker...@vger.kernel.org;
linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH 1/3] f2fs: check filename length in
recover_dentry
2013-12-21 (토), 18:01 +0800, Chao Yu:
In current flow, we will get Null return value of f2fs_find_entry in
recover_dentry when name.len is bigger than F2FS_NAME_LEN, and then we
still add this inode into its dir entry.
To avoid this situation, we must check filename length before we use it.
Another point is that we could remove the code of checking filename length
In f2fs_find_entry, because f2fs_lookup will be called previously to ensure
of
validity of filename length.
Signed-off-by: Chao Yu chao2...@samsung.com
---
fs/f2fs/dir.c |3 ---
fs/f2fs/recovery.c |5 +
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
index 0cc26ba..3f3b661 100644
--- a/fs/f2fs/dir.c
+++ b/fs/f2fs/dir.c
@@ -190,9 +190,6 @@ struct f2fs_dir_entry *f2fs_find_entry(struct inode
*dir,
unsigned int max_depth;
unsigned int level;
- if (unlikely(namelen F2FS_NAME_LEN))
- return NULL;
-
if (npages == 0)
return NULL;
diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
index a3f4542..fdd175b 100644
--- a/fs/f2fs/recovery.c
+++ b/fs/f2fs/recovery.c
@@ -62,6 +62,11 @@ static int recover_dentry(struct page *ipage, struct
inode *inode)
name.len = le32_to_cpu(raw_inode-i_namelen);
name.name = raw_inode-i_name;
+
+ if (unlikely(name.len F2FS_NAME_LEN)) {
+ err = -ENAMETOOLONG;
+ goto out;
+ }
Have you seen this before?
Not yet.
This is a trivial bug case, so, if you have got this bug, we should fix
the bug first instead of adding any workaround patch.
What I worry about is that not only f2fs bug lead to this trivial problem,
but also other program with operation in raw disk could do this.
Let's add WARN_ON() at least.
Alright.
Thanks.
Thanks,
retry:
de = f2fs_find_entry(dir, name, page);
if (de inode-i_ino == le32_to_cpu(de-ino))
--
Jaegeuk Kim
Samsung
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
[f2fs-dev] [PATCH 1/3 V2] f2fs: check filename length in recover_dentry
In current flow, we will get Null return value of f2fs_find_entry in
recover_dentry when name.len is bigger than F2FS_NAME_LEN, and then we
still add this inode into its dir entry.
To avoid this situation, we must check filename length before we use it.
Another point is that we could remove the code of checking filename length
In f2fs_find_entry, because f2fs_lookup will be called previously to ensure of
validity of filename length.
V2:
o add WARN_ON() as Jaegeuk Kim suggested.
Signed-off-by: Chao Yu chao2...@samsung.com
---
fs/f2fs/dir.c |3 ---
fs/f2fs/recovery.c |6 ++
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
index 07ad850..f0b4630 100644
--- a/fs/f2fs/dir.c
+++ b/fs/f2fs/dir.c
@@ -190,9 +190,6 @@ struct f2fs_dir_entry *f2fs_find_entry(struct inode *dir,
unsigned int max_depth;
unsigned int level;
- if (unlikely(namelen F2FS_NAME_LEN))
- return NULL;
-
if (npages == 0)
return NULL;
diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
index a3f4542..4d411a2 100644
--- a/fs/f2fs/recovery.c
+++ b/fs/f2fs/recovery.c
@@ -62,6 +62,12 @@ static int recover_dentry(struct page *ipage, struct inode
*inode)
name.len = le32_to_cpu(raw_inode-i_namelen);
name.name = raw_inode-i_name;
+
+ if (unlikely(name.len F2FS_NAME_LEN)) {
+ WARN_ON(1);
+ err = -ENAMETOOLONG;
+ goto out;
+ }
retry:
de = f2fs_find_entry(dir, name, page);
if (de inode-i_ino == le32_to_cpu(de-ino))
--
1.7.9.5
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
