linux-ext4 - Re: [PATCH -V3 09/11] ext4: Fix ext4 nomballoc allocator for ENOSPC

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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 29 Aug 2008 09:44:12 +0530
From:	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
To:	Mingming Cao <cmm@...ibm.com>
Cc:	tytso@....edu, sandeen@...hat.com, linux-ext4@...r.kernel.org
Subject: Re: [PATCH -V3 09/11] ext4: Fix ext4 nomballoc allocator for ENOSPC

On Fri, Aug 29, 2008 at 09:14:51AM +0530, Aneesh Kumar K.V wrote:
> On Thu, Aug 28, 2008 at 02:57:49PM -0700, Mingming Cao wrote:
> > 
> > From: Mingming Cao <cmm@...ibm.com>
> > 
> > ext4: Fix ext4 nomballoc allocator for ENOSPC
> >     
> > We run into ENOSPC error on nonmballoc ext4, even when there is free blocks
> > on the filesystem.
> > 
> > The problem is triggered in the case the goal block group has 0 free blocks
> > , and the rest block groups are skipped due to the check of "free_blocks 
> > < windowsz/2".
> 
> The goal block group had free blocks < windowsz .
> 
> 

Ok how about this. The Final change is same to what you have done.
But it make the code easier to understand. I also added a comment
explaining the details

commit 0216ee1ac13270c1ab7b7517d41775727f7da02d
Author: Aneesh Kumar K.V <aneesh.kumar@...ux.vnet.ibm.com>
Date:   Fri Aug 29 09:35:15 2008 +0530

    ext4: Fix ext4 nomballoc allocator for ENOSPC
    
    We run into ENOSPC error on nonmballoc ext4, even when there is free blocks
    on the filesystem.
    
    The patch include two changes
    
    a) Set reservation to NULL if we trying to allocate near group_target_block
    from the goal group if the free block in the group is less than windowsz.
    This should give us a better chance to allocate near group_target_block.
    This also ensures that if we are not allocating near group_target_block
    then we don't trun off reservation. This should enable us to allocate
    with reservation from other groups that have large free blocks count.
    
    b) we don't need to check the window size if the block reservation is off.
    
    Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@...ux.vnet.ibm.com>
    Signed-off-by: Mingming Cao <cmm@...ibm.com>

diff --git a/fs/ext4/balloc.c b/fs/ext4/balloc.c
index cfe01b4..399bec5 100644
--- a/fs/ext4/balloc.c
+++ b/fs/ext4/balloc.c
@@ -1802,15 +1802,17 @@ ext4_fsblk_t ext4_old_new_blocks(handle_t *handle, struct inode *inode,
 		goto io_error;
 
 	free_blocks = le16_to_cpu(gdp->bg_free_blocks_count);
-	/*
-	 * if there is not enough free blocks to make a new resevation
-	 * turn off reservation for this allocation
-	 */
-	if (my_rsv && (free_blocks < windowsz)
-		&& (rsv_is_empty(&my_rsv->rsv_window)))
-		my_rsv = NULL;
 
 	if (free_blocks > 0) {
+		/*
+		 * try to allocate with group target block
+		 * in the goal group. If we have low free_blocks
+		 * count turn off reservation
+		 */
+		if (my_rsv && (free_blocks < windowsz)
+			&& (rsv_is_empty(&my_rsv->rsv_window)))
+			my_rsv = NULL;
+
 		bitmap_bh = ext4_read_block_bitmap(sb, group_no);
 		if (!bitmap_bh)
 			goto io_error;
@@ -1843,7 +1845,7 @@ ext4_fsblk_t ext4_old_new_blocks(handle_t *handle, struct inode *inode,
 		 * free blocks is less than half of the reservation
 		 * window size.
 		 */
-		if (free_blocks <= (windowsz/2))
+		if (my_rsv && (free_blocks <= (windowsz/2)))
 			continue;
 
 		brelse(bitmap_bh);
--
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