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-next>] [day] [month] [year] [list]
Date:	Tue, 15 Apr 2008 18:14:30 +0200
From:	Jan Kara <jack@...e.cz>
To:	linux-ext4@...r.kernel.org
Cc:	sandeen@...hat.com
Subject: Delayed allocation and page_lock vs transaction start ordering

  Hi,

  I've ported my patch inversing locking ordering of page_lock and
transaction start to ext4 (on top of ext4 patch queue). Everything except
delayed allocation is converted (the patch is below for interested
readers). The question is how to proceed with delayed allocation. Its
current implementation in VFS is designed to work well with the old
ordering (page lock first, then start a transaction). We could bend it to
work with the new locking ordering but I really see no point since ext4 is
the only user. Also XFS has AFAIK ordering first start transaction, then
lock pages so if we should ever merge delayed alloc implementations the new
ordering would make it easier.
  So what do people think here? Do you agree with reimplementing current
mpage_da_... functions? Eric, I guess you have the best clue how XFS does
this, do you have some advices? Also maybe pointers into XFS code would be
useful if it is reasonably readable :). Thanks.

								Honza
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR

View attachment "ext4-2.6.25-page_lock_vs_transaction.diff" of type "text/x-patch" (18452 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ