| 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: Sun, 2 Oct 2011 15:14:58 +0800 From: Jeff liu <jeff.liu@...cle.com> To: Andreas Dilger <aedilger@...il.com> Cc: Yongqiang Yang <xiaoqiangnk@...il.com>, Dave Young <hidave.darkstar@...il.com>, "Ted Ts'o" <tytso@....edu>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, linux-ext4@...r.kernel.org Subject: Re: [BUG] copy file result with zero 在 2011-10-2，下午3:59， Andreas Dilger 写道： > On 2011-10-01, at 11:41 PM, Jeff liu wrote: >>> On Sat, Oct 1, 2011 at 10:39 PM, Ted Ts'o <tytso@....edu> wrote: >>>> On Sat, Oct 01, 2011 at 10:01:35PM +0800, Dave Young wrote: >>>>> Hi, >>>>> >>>>> Weird problem, when I build app from source, >>>>> make; make install >>>>> run the command, but got "cannot execute binary file" >>>>> >>>>> hexdump shows the installed binary is full of zero >>>>> >>>>> Is it related to ext4 fiemap problem described below? >>>>> http://lwn.net/Articles/429349/ >>>> >>>> There is general agreement that /bin/cp should not have been relying >>>> on FIEMAP, and I believe the more recent versions of /bin/cp have >>>> removed that code by default pending implementation of >>>> SEEK_HOLE/SEEK_DATA. That being said, ext4 had a workaround to its >>>> FIEMAP implementation that landed in 2.6.39, and you're using >>>> 3.1.0-rc6. >> >> Actually, upstream cp(1) using FIEMAP only if the source file is sparse, or else, it will do normal copy, i.e, block based. > > My understanding is that cp uses the blocks count to determine whether the file is sparse or not. Yes, it based on blocks count to determine that. > In the case of delayed allocation (where blocks are not yet allocated, if they are not reflected in the i_blocks count) it might mistakenly think that the file is sparse. Thanks for pointing this out, I missed this case. So for Dave's issue, even if he updated to the upstream Coreutils, this issue will still exists occasionally for delayed allocation, if not run sync in between times. > > Given the danger of this bug, it is important to ensure ext4 returns DELALLOC extents for pages in the page cache. I think Yongqiang Yang just submitted a patch series to do this for ext4, so it would be important to verify it fixes this problem. Thanks, -Jeff > >>> Do you means It should work in 3.1.0-rc6 even with cp which depends fiemap? >>> >>>> >>>>> I finally managed to find the way to reproduce this: >>>>> just cp a elf binary A to file B, then cp B to file C, then you will get: >>>>> A == B != C >>>>> >>>>> ie. >>>>> cp /bin/ls ls1 >>>>> cp ls1 ls2 >>>>> >>>>> ls2 will be filled with zero >>>> >>>> If you add a "sync" between the two copies, does that work around the >>>> problem? I bet it will... >>> >>> Yes, it works >>> >>>> >>>> My suggestion is to upgrade to a newer version of coreutils that >>>> doesn't try to use FIEMAP. >>> >>> Thanks, will try >>> >>>> >>>> - Ted >>>> >>> >>> >>> >>> -- >>> Regards >>> Dave >>> -- >>> 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 >> >> -- >> 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 > > > Cheers, Andreas > > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists