linux-ext4 - Re: [PATCH 1/1 v4] ext4: fix xfstests 75, 112, 127 punch hole failure

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:	Thu, 11 Aug 2011 19:44:45 -0400
From:	Ted Ts'o <tytso@....edu>
To:	Allison Henderson <achender@...ux.vnet.ibm.com>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: [PATCH 1/1 v4] ext4: fix xfstests 75, 112, 127 punch hole
 failure

On Thu, Aug 11, 2011 at 02:31:01PM -0700, Allison Henderson wrote:
> Ah, ok then that makes sense.  So maybe what I need to do is modify
> the ext4_block_zero_page routine to zero everything in the specified
> range and then clear the mapped flag for any buffer header that is
> fully zeroed.  I'm not sure I'm clear about what it means to be
> detached though.  What is the difference between clearing the flag
> and detaching the buffer head?  Thank you for all the explaining!

Technically speaking, there is no guarantee that a page has either no
buffer heads, or all of the buffer heads that cover a page --- or that
the buffer_heads are in any particular order in the linked list.

In practice create_empty_buffers() creates them in a particular order,
and always creates *all* of them --- and I'm not sure if we have any
code paths left that don't use create_empty_buffers() --- but I'm
pretty sure there used to be cases where the buffer_heads could only
be partially present, or in an arbitrary order.

So if you look at the code which iterates over the page buffers,
you'll see they are very defensively coded --- and it's complicated.
One of these days I'd really like to simplify the code so instead of
using linked list, we use an array of structures --- and something
slimmed down from a buffer_head to have only those essential fields
that ext4 uses.

One of these days....

Anyway, clearing the all of the bh_flags as is currently done is good
enough, and actually probably easier (in case there's code which is
dependent on all of the bh's being there, and in order)

					- 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