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]
Message-ID: <20090514131429.GH11352@mit.edu>
Date:	Thu, 14 May 2009 09:14:29 -0400
From:	Theodore Tso <tytso@....edu>
To:	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
Cc:	Eric Sandeen <sandeen@...hat.com>, cmm@...ibm.com,
	linux-ext4@...r.kernel.org
Subject: Re: [PATCH 2/3] ext4: Clear the unwritten buffer_head flag properly

On Thu, May 14, 2009 at 11:10:02AM +0530, Aneesh Kumar K.V wrote:
> 
> It should only be set in the !create case. With create == 1, we would
> have already converted the uninitialized extent to initialized one and
> the buffer_head should not be unwritten at all.  My understanding is
> unwritten flag is used to indicate the buffer_head state between a
> write_begin and write_page phase with delayed allocation. ie, when we
> write to fallocate space, since we have delalloc enabled, we  just
> do a block lookup (get_block with create = 0). The buffer_head returned
> in the above case should have unwritten set so that during writepage
> we do the actual block allocation (get_block writh create = 1)
> looking at the flag.

At the moment, ext4_da_get_block_prep(), which is used as a callback
function by ext4_da_write_begin(), checks for buffer_unwritten(), and
if true, set BH_New and BH_Mapped.

So between the time that that write_begin() and the time when the page
is actually written out, BH_Unwritten and BH_Mapped will both be set.
If we end up bailing due to some error of some kind, such that we
don't complete the write(2) operation we *can* have some pages that
are simultaneously have BH_Unwritten and BH_Mapped flags set.  So this
had better be a harmless case, since I think it can happen.

What's confusing then is some of the comments which have been made
about why BH_Unwritten and BH_Mapped simultaneously are a bad.  It may
be bad at some points in time, but at other points in time it's
completely normal operations.  Or am I missing something?

	   	  	       	       - 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ