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] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 28 May 2009 11:44:34 +0200
From:	Jan Kara <jack@...e.cz>
To:	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
Cc:	Jan Kara <jack@...e.cz>, LKML <linux-kernel@...r.kernel.org>,
	npiggin@...e.de, linux-ext4@...r.kernel.org
Subject: Re: [PATCH 08/11] vfs: Unmap underlying metadata of new data
	buffers only when buffer is mapped

On Wed 27-05-09 21:05:59, Aneesh Kumar K.V wrote:
> On Wed, May 27, 2009 at 03:01:05PM +0200, Jan Kara wrote:
> > When we do delayed allocation of some buffer, we want to signal to VFS that
> > the buffer is new (set buffer_new) so that it properly zeros out everything.
> > But we don't have the buffer mapped yet so we cannot really unmap underlying
> > metadata in this state. Make VFS avoid doing unmapping of metadata when the
> > buffer is not yet mapped.
> > 
...
> > @@ -2683,7 +2685,7 @@ int nobh_write_begin(struct file *file, struct address_space *mapping,
> >  			goto failed;
> >  		if (!buffer_mapped(bh))
> >  			is_mapped_to_disk = 0;
> > -		if (buffer_new(bh))
> > +		if (buffer_new(bh) && buffer_mapped(bh))
> >  			unmap_underlying_metadata(bh->b_bdev, bh->b_blocknr);
> >  		if (PageUptodate(page)) {
> >  			set_buffer_uptodate(bh);
> 
> Both xfs and ext4 return mapped delay buffer_head when we do a get_block
> with delayed allocation in write_begin phase.
  Yeah, I knew about ext4 doing this. Thanks for pointing this out. I
wanted to trigger a separate discussion about this and similar problems -
the current state of buffer bits is quite messy (I think Ted complained
about this as well recently) and we should somehow clean it up.
  In this particular case: What's the point in returning the buffer mapped?
It does not make any sence logically (block *does not* have any physical
location assigned) and technically you have to map it to some fake block
and later remap it correctly when you do block allocation. So maybe I'm
missing some good reason but from what I can see, it just does not make
sence...

									Honza
-- 
Jan Kara <jack@...e.cz>
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