| 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: Tue, 19 May 2009 18:53:10 +0200 From: Jan Kara <jack@...e.cz> To: linux-ext4@...r.kernel.org Subject: Block estimates for delayed allocation in ext4 wrong? Hi, I was looking into doing delayed allocation for ext3 in page_mkwrite() and I've noticed that the way how ext4 estimates number of blocks it needs to reserve during delayed allocation is probably wrong when inode uses indirect blocks and not extents. The problem is with files with holes - for example we write blocks 1024, 2048, 3072, 4096, we have to allocate indirect block together with each data block we write. Therefore we need at least 8 blocks reserved but ext4_indirect_calc_metadata_amount() will reserve only 6 of them. We can only improve the estimate against the worst case (allocating all indirect blocks) if we know some block before the one for which we estimate needed amount is already allocated / has space reserved. But that's kind of non-trivial to detect. Maybe what we could do is look into pagecache, find the first page before the current one, check that it has mapped or delayed buffer and subtract indirect blocks for buffers in this page from those we need to reserve. But the locking is going to be nasty :( (we need page lock to safely investigate buffers in that page). Maybe counting with the worst case is better after all. What do you think? 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