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:	Wed, 11 Nov 2015 16:25:42 +0100
From:	Jan Kara <jack@...e.cz>
To:	Dave Chinner <david@...morbit.com>
Cc:	Jan Kara <jack@...e.cz>,
	"Boylston, Brian" <brian.boylston@....com>,
	Jan Kara <jack@...e.com>, Ted Tso <tytso@....edu>,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
	Ross Zwisler <ross.zwisler@...ux.intel.com>,
	"dan.j.williams@...el.com" <dan.j.williams@...el.com>,
	dchinner@...hat.com
Subject: Re: [PATCH 0/9 v3] ext4: Punch hole and DAX fixes

On Wed 11-11-15 09:31:39, Dave Chinner wrote:
> On Tue, Nov 10, 2015 at 11:02:53AM +0100, Jan Kara wrote:
> > On Tue 10-11-15 11:00:27, Dave Chinner wrote:
> > > On Mon, Nov 09, 2015 at 05:51:49PM +0100, Jan Kara wrote:
> > > > The zeroing code in __dax_fault() needs to go away anyway so whether we
> > > > return buffer_new buffer is not really substantial but I'd like to get some
> > > > agreement and consistency among filesystems in with which flags zeroed
> > > > blocks are returned. Thoughts?
> > > 
> > > There is no consistency to begin with, especially w.r.t. unwritten
> > > extent behaviour as the upper layers don't all understand that
> > > buffer_unwritten is a valid flag for getblock to return. Hence we
> > > have hacks in XFS setting buffer_new() in strange cases to get the
> > > upper level code to zero stuff that really needs zeroing...
> > 
> > In ext4 we set buffer as new in two cases:
> > 
> > 1) When it was freshly allocated (regardless whether into unwritten or
> >    normal extent).
> 
> Which only works for freshly allocated unwritten extents, not for
> writes into preallocated extents.
> 
> > 2) When it was converted from unwritten to written state.
> 
> Which, for direct IO, is no good when we do the conversion after IO
> completion because we need to know at IO submission if we need to do
> sub-block zeroing (i.e. dio_zero_block() will skip the zeroing if
> buffer_new() is not set on unwritten blocks).

OK, sorry I parsed the code flow wrong, ext4 sets buffer_new for any
unwritten extent it returns (when create == 1 only but that doesn't really
make a difference). And then for any freshly allocated block. This seems
pretty consistent to me. There are two places in ext4 that set returned
buffer as new (those two cases mentioned above) and that seems to be
enough. Maybe XFS needs something different but at least from looking at
ext4 setting of buffer_new is not complex...

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR
--
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