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
| ||
|
Message-ID: <20130311025016.GJ10090@thunk.org> Date: Sun, 10 Mar 2013 22:50:16 -0400 From: Theodore Ts'o <tytso@....edu> To: Lukas Czerner <lczerner@...hat.com> Cc: linux-ext4@...r.kernel.org, gnehzuil.liu@...il.com Subject: Re: [PATCH 2/3] ext4: Update reserved space after the 'correction' On Fri, Mar 08, 2013 at 09:24:18AM +0100, Lukas Czerner wrote: > Currently in ext4_ext_map_blocks() in delayed allocation writeback > we would update the reservation and after that check whether we claimed > cluster outside of the range of the allocation and if so, we'll give the > block back to the reservation pool. > > However this also means that if the number of reserved data block > dropped to zero before the correction, we would release all the metadata > reservation as well, however we might still need it because the we're > not done with the delayed allocation and there might be more blocks to > come. This will result in error messages such as: > > EXT4-fs warning (device sdb): ext4_da_update_reserve_space:361: ino 12, > allocated 1 with only 0 reserved metadata blocks (releasing 1 blocks > with reserved 1 data blocks) > > This will only happen on bigalloc file system and it can be easily > reproduced using fiemap-tester from xfstests like this: > > ./src/fiemap-tester -m DHDHDHDHD -S -p0 /mnt/test/file > > Or using xfstests such as 225. > > Fix this by doing the correction first and updating the reservation > after that so that we do not accidentally decrease > i_reserved_data_blocks to zero. > > Signed-off-by: Lukas Czerner <lczerner@...hat.com> Thanks, applied. - 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
Powered by blists - more mailing lists