linux-ext4 - Re: [PATCH 2/3] ext4: Try to initialize all groups we can in case of failure on ppc64

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.00.1506020953100.4950@localhost.localdomain>
Date:	Tue, 2 Jun 2015 09:53:27 +0200 (CEST)
From:	Lukáš Czerner <lczerner@...hat.com>
To:	Andreas Dilger <adilger@...ger.ca>
cc:	linux-ext4@...r.kernel.org
Subject: Re: [PATCH 2/3] ext4: Try to initialize all groups we can in case
 of failure on ppc64

On Mon, 1 Jun 2015, Andreas Dilger wrote:

> Date: Mon, 1 Jun 2015 13:15:35 -0600
> From: Andreas Dilger <adilger@...ger.ca>
> To: Lukas Czerner <lczerner@...hat.com>
> Cc: linux-ext4@...r.kernel.org
> Subject: Re: [PATCH 2/3] ext4: Try to initialize all groups we can in case of
>     failure on ppc64
> 
> 
> > On Jun 1, 2015, at 1:55 AM, Lukas Czerner <lczerner@...hat.com> wrote:
> > 
> > Currently on the machines with page size > block size when initializing
> > block group buddy cache we initialize it for all the block group bitmaps
> > in the page. However in the case of read error, checksum error, or if
> > a single bitmap is in any way corrupted we would fail to initialize all
> > of the bitmaps. This is problematic because we will not have access to
> > the other allocation groups even though those might be perfectly fine
> > and usable.
> > 
> > Fix this by reading all the bitmaps instead of error out on the first
> > problem and simply skip the bitmaps which were either not read properly,
> > or are not valid.
> > 
> > Signed-off-by: Lukas Czerner <lczerner@...hat.com>
> > ---
> > fs/ext4/mballoc.c | 10 +++++++---
> > 1 file changed, 7 insertions(+), 3 deletions(-)
> > 
> > diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
> > index 8d1e602..5677a03 100644
> > --- a/fs/ext4/mballoc.c
> > +++ b/fs/ext4/mballoc.c
> > @@ -882,10 +882,8 @@ static int ext4_mb_init_cache(struct page *page, char *incore)
> > 
> > 	/* wait for I/O completion */
> > 	for (i = 0, group = first_group; i < groups_per_page; i++, group++) {
> > -		if (bh[i] && ext4_wait_block_bitmap(sb, group, bh[i])) {
> > +		if (bh[i] && ext4_wait_block_bitmap(sb, group, bh[i]))
> > 			err = -EIO;
> > -			goto out;
> > -		}
> > 	}
> > 
> > 	first_block = page->index * blocks_per_page;
> > @@ -898,6 +896,12 @@ static int ext4_mb_init_cache(struct page *page, char *incore)
> > 			/* skip initialized uptodate buddy */
> > 			continue;
> > 
> > +		if (!buffer_verified(bh[group - first_group]))
> > +			/* Skip faulty bitmaps */
> > +			continue;
> > +		else
> > +			err = 0;
> 
> Not really a need for "else" here after the "continue" line, but that
> is mostly harmless.
> 
> Cheers, Andreas

Good point, I can fix that.

Thanks!
-Lukas
--
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