linux-ext4 - Re: [PATCH 2/2] Ext3: remove a useless check for the function ext3_free_blocks

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]

Date:	Tue, 29 Jan 2013 12:08:09 -0500
From:	Theodore Ts'o <tytso@....edu>
To:	Jan Kara <jack@...e.cz>
Cc:	Wang Shilong <wangshilong1991@...il.com>,
	linux-ext4@...r.kernel.org
Subject: Re: [PATCH 2/2] Ext3: remove a useless check for the function
 ext3_free_blocks_sb

On Tue, Jan 29, 2013 at 03:40:14PM +0100, Jan Kara wrote:
> > As we know the block to be freed can not be superblock and GDT..
> > I don't see any check about it in ext2/ext3/ext4....
>   Yes, you are right we apparently don't check for superblock or GDT
> blocks. But checking for those will be a bit more complex and they are
> really scarce so I don't think it's worth the overhead.

We actually do have code to test for that in ext4.  Take a look at
fs/ext4/block_validity.c.  We normally only check to make sure the
data block is within the file system bounds, but if you mount the file
system with the block_validity, it will actually check to make sure
the block being allocated or freed is not part of the superblock, GDT,
allocation bitmaps, or inode table.

I use this mount option when running my xfstests, just to add an
additional level of checking.  It's not enabled by default, since it
does increase CPU usage.  I suspect it would only be visible for
benchmarks such as TPC-C, but it's not something we've actually
measured to see if we could afford to enable by default.

The other major short coming is that we don't update the system zone
after an online resize, which means we don't protect the newly
metadata blocks until the next time the file system is mounted.  If we
added updating after a online resize, we'd also have to add some kind
of locking to protect the rbtree while it is being changed, and this
would increase its overhead if people wanted to use it in production.
We might be able to use RCU to avoid doing a real hard lock, but it's
not something that I've considered high priority.

If someone wanted to look at this, it would actually be a pretty good
starter project for someone who wanted to get started with doing ext4
hacking.

Cheers,

						- Ted
--
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