linux-ext4 - Re: [PATCH 2/2]Fix return value of splitting extents for dio write over fallocate

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <1255043289.4931.17.camel@mingming-laptop>
Date:	Thu, 08 Oct 2009 16:08:09 -0700
From:	Mingming <cmm@...ibm.com>
To:	tytso@....edu
Cc:	ext4 development <linux-ext4@...r.kernel.org>,
	Curt Wohlgemuth <curtw@...gle.com>
Subject: Re: [PATCH 2/2]Fix return value of splitting extents for dio write
 over fallocate

On Wed, 2009-10-07 at 11:50 -0700, Mingming wrote:
> On Wed, 2009-10-07 at 10:23 -0700, Mingming wrote:
> > ext4: Fix return value of splitting extents for dio write over fallocate 
> 
> Please pick up this patch instead, after fixing compile warning.
> 
> ext4: Fix return value of splitting extents for dio write over fallocate
> 
> To prepare direct IO write, we need to split the unwritten extents before
> submit the IO. In case of no split needs at all, ext4_split_unwritten_extents()
> was incorrectly returns 0 instead of the size of uninitalized extents. This bug
> caused wrong return value sent back to VFS code when it gets called from async
> IO path, leads to falling back to buffered IO.
> 
> Signed-off-by: Mingming Cao <cmm@...ibm.com>

Jiayang zhang pointed that there is another issue with avoid splitting
the unintialized extent when it's going to be fullfilled. The start
offset to write needs to be at the beginning of the uninitialized
extent. The following is the updated patch.

Please review and pick up this patch. Thanks.
Mingming



ext4: Fix direct IO return values over fallocate space

To prepare direct IO write, we need to split the unwritten extents before
submit the IO. In case of the full uninitialized extent is going to be written,
there is no need to split the extenT at all. ext4_split_unwritten_extents() has
bug to check whether it's full fill of the unintialized extent, and
incorrectly returns 0 instead of the size of uninitalized extents. The later bug
caused wrong return value sent back to VFS code when it gets called from async
IO path, leads to falling back to buffered IO.

Thanks to Jiaying Zhang who reported the bugs and tested the patch.

Signed-off-by: Mingming Cao <cmm@...ibm.com>
---
 fs/ext4/extents.c |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

Index: linux-2.6.31-rc4/fs/ext4/extents.c
===================================================================
--- linux-2.6.31-rc4.orig/fs/ext4/extents.c
+++ linux-2.6.31-rc4/fs/ext4/extents.c
@@ -2788,6 +2788,8 @@ fix_extent_len:
  * into three uninitialized extent(at most). After IO complete, the part
  * being filled will be convert to initialized by the end_io callback function
  * via ext4_convert_unwritten_extents().
+ *
+ * Returns the size of unitialized extent to be writen, on success.
  */
 static int ext4_split_unwritten_extents(handle_t *handle,
 					struct inode *inode,
@@ -2805,7 +2807,6 @@ static int ext4_split_unwritten_extents(
 	unsigned int allocated, ee_len, depth;
 	ext4_fsblk_t newblock;
 	int err = 0;
-	int ret = 0;
 	unsigned int newdepth;
 
 	ext_debug("ext4_split_unwritten_extents: inode %lu,"
@@ -2828,8 +2829,8 @@ static int ext4_split_unwritten_extents(
  	 * the size of extent to write, there is no need to split
  	 * uninitialized extent
  	 */
- 	if (allocated <= max_blocks)
-		return ret;
+ 	if (iblock == ee_block && allocated <= max_blocks)
+		return allocated;
 
 	err = ext4_ext_get_access(handle, inode, path + depth);
 	if (err)


--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html