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
| ||
|
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