linux-ext4 - Relatively simple ext4 todo item

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

Message-Id: <E1Op6Qu-0005Df-J6@tytso-glaptop>
Date:	Fri, 27 Aug 2010 17:25:56 -0400
From:	"Theodore Ts'o" <tytso@....edu>
To:	linux-ext4@...r.kernel.org
Subject: Relatively simple ext4 todo item

For folks who are interested in getting started with ext4, here's a
relatively simple todo item.

Wu Fenguang has reported a scalability issue with ext4 when running a VM
stress test where there are multiple processes all hammering the file
with random mmap requests.  (Although this would have shown up as well
if we had multiple threads all trying to read from the same file
descriptor at the same time.)  The point of contention is
ext4_inode_info.i_block_reservation_lock(), and the problem is that
we're using this spinlock to protect a simple singleton extent cache,
i_cached_extent.  See the functions ext4_ext_put_gap_in_cache() and
ext4_ext_in_cache().

Your mission should you choose to accept it :-), is to replace
i_cached_extent with an RCU protected data structure.  For bonus points,
try making it support caching more than a single extent.  Also, while
you're at it, fix a race condition with move_inode.c where we should
make should the cached extents have been removed and an RCU grace period
has elapsed before proceeding with the inode defragmentation.

						- 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