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: <20130810060212.GA6945@blackbox.djwong.org>
Date:	Fri, 9 Aug 2013 23:02:12 -0700
From:	"Darrick J. Wong" <darrick.wong@...cle.com>
To:	Jeff Moyer <jmoyer@...hat.com>
Cc:	Zheng Liu <gnehzuil.liu@...il.com>,
	"Theodore Ts'o" <tytso@....edu>, linux-ext4@...r.kernel.org
Subject: Re: [PATCH v1 0/5] ext4: Shut down block groups when damage is
 detected

On Mon, Jul 29, 2013 at 11:28:38AM -0400, Jeff Moyer wrote:
> Zheng Liu <gnehzuil.liu@...il.com> writes:
> 
> > My idea is to let file system can ignore the currurted block.  Namely,
> > when we meet a currupted block, we will track it as bad block in bad
> > block inode and find another block to save data.  This currupted block
> > will never be used.  The first step in my mind is to detect a currpted
> > block and mark it as bad block.  After reading the thread and Darrick's
> > original patch, I think Darrick's patch is a good start.
> 
> I think it's important to call out the exact failure scenario you're
> trying to address.  For hard disks, if you get a read error, it can
> typically be recovered by re-writing the block.  I imagine this is what
> fsck would be doing for metadata repair.  So, I'm not at all sure why
> you'd want to track bad blocks in the file system itself.  Could you
> elaborate, please?

Sorry, was on vacation.

Actually, I had a few different scenarios in mind when I was writing this
patchset.  I've observed that feeding bad block bitmaps to ext4 (misplaced
write, for example) results in it using the garbage bitmap for allocations and
smashing the fs.  Metadata checksumming (and the other sanity checks) at least
help us to detect these situations, but even with that, the allocators will
repeatedly beat on broken block groups.  The repetition causes log spew and in
a few cases the block allocator will go into an infinite loop looking for
space.  This patch set fixes the log spew and the infinite loops.

--D
> 
> Cheers,
> Jeff
> --
> 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
--
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

Powered by blists - more mailing lists