12518 2011-02-25 02:26:00 +0000 memcpy acts randomly (and differently) with overlapping areas 2011-06-07 03:06:24 +0000 1 1 1 Unclassified glibc libc 2.13 All All RESOLVED FIXED P2 normal --- 1 torvalds drepper.fsp alexander.hunt2005 bvasselle felipe.contreras hjl.tools jakub jvillalo kenyon ml-bz-dale oliver.henshaw shaforostoff smconvey thierry.vignaud tmoody tmraz tolzmann vincent-srcware y.pronenko oldest_to_newest 47199 0 5264 torvalds 2011-02-25 02:26:20 +0000 Created attachment 5264 Example patch to give the basic idea I realize that it's technically "undefined", but the behavior has changed, and in the process broken existing binaries. It's a common bug to use memcpy() instead of memmove(), and the traditional behavior of "copy upwards" means that that bug can go unnoticed for a *long* time if the memory move moves things downwards. The change was introduced in commit 6fb8cbcb58a29fff73eb2101b34caa19a7f88eba ("Improve 64bit memcpy/memmove for Atom, Core 2 and Core i7"), which was part of the 2.13 release. As a result, upgrading from Fedora-13 to Fedora-14 caused applications like flash to fail. But it's a bug that has been reported for other applications too (and it's a bug that I've personally introduced in 'git' too - happily, people had run things like valgrind, so I don't know of any _current_ cases of it). And there is absolutely _zero_ reason to not handle overlapping areas correctly. The "undefined behavior" is due to historical implementation issues, not because it's better than just doing the right thing. And now applications will randomly do different things depending on the phase of the moon (technically, depending on which CPU they have and what particular version of memcpy() glibc happens to choose). So from a pure Quality-of-Implementation standpoint, just make glibc implement memcpy() as memmove(), if you don't want to re-instate the traditional behavior that binaries have at least been tested with. Don't break random existing binaries just because the glibc version changed, and they had never been tested with the new random behavior! I'm attaching an EXAMPLE patch against the current glibc git tree: it just tries to get rid of the unnecessary differences between memcpy and memmove for the normal ssse3 case. The approach is simple: - small copies (less than 80 bytes) have hand-coded optimized code that gets called through a jump table. Those cases already handle overlapping areas correctly (simply because they do all loads up-front, and stores at the end), and they are used for memmove() as-is. So change the memcpy() function to test for the small case first, since that's the one that can be latency critical. - once we're talking about bigger memcpy() cases, the extra couple of cycles to check "which direction should I copy" are totally immaterial, and having two different versions of basically the same code is just silly and is quite likely to cost more than (in I$ and page fault overhead) than just doing it in the same code. So just remove all the USE_AS_MEMMOVE games. I haven't actually tested the patch, since building glibc is black magic and the simple "just alias __memmove_ssse3 to __memcpy_sse3" thing didn't work for me and resulted in linker errors. There's probably some simple (but subtle) magic reason for that, that I simply don't know about. So take the patch as a "hey, doing it this way should be simpler and avoid the problem" rather than "apply this patch as-is". The ssse3-back case (which prefers backwards copies) needs similar treatment, I'll happily do that and test it if people just let me know that it's worth my time (and tell me what the black magic incantation is). 47200 1 torvalds 2011-02-25 02:29:37 +0000 Btw, this has hit quite a lot of people. It's Fedora https://bugzilla.redhat.com/show_bug.cgi?id=638477 and there are examples of having other things than just flash break (like old gstreamer plugins etc) 47202 2 hjl.tools 2011-02-25 03:57:42 +0000 Although the current memcpy in glibc follows the spec, some applications call memcpy with overlapping destination and source. I think we should help those applications without punishing the correctly written applications. We can check an environment variable for IFUNC, like LD_BIND_IFUNC_MEMCPY_TO_MEMMOVE. If it is set, IFUNC memcpy will return memmove instead of memcpy. I can prepare a patch to implement it if we should do it. 47203 3 torvalds 2011-02-25 04:14:39 +0000 So is there any real reason to believe that memmove() can't just be as fast as memcpy? Seriously. That's what it all boils down to. Why have a separate memcpy() at all, when it clearly is correct - and nice to people - to always just implement it as a memmove(). And I really don't see the downside. It's not like it's going to be slower. People who want to check whether their application is portable can use valgrind, the same way you have to check for portability issues in other areas (eg the extra glibc specific printf formats etc - they just "work", but they certainly aren't portable). So why not just be nice. If anything, from a "be nice" standpoint, it would perhaps be good to have a "debug mode", that would actually _warn_ - or even assert - about overlapping memcpy(). That obviously shouldn't be the default (since that only helps developers), but it would be along the same lines of the nice malloc debugging help that glibc can give. IOW, I think this is an area where glibc can be _better_ than what is required of it. 47208 4 drepper.fsp 2011-02-25 09:59:18 +0000 The existence of code written by people who should never have been allowed to touch a keyboard cannot be allowed to prevent a correct implementation. If there is a large bod of code out there we can work around the issue for that. We can have the existing memcpy@GLIBC_2.2.5 implementation work around the issue by avoiding the backward copying code. A new memcpy@GLIBC_2.14 could use the code currently in use. Whether the current, new memcpy is only slightly faster than one mimicking memmove is really not that important. There are going to be more and different implementations in the future and they shouldn't be prevented from being used because of buggy programs. We should be happy to have this code here and now. With this proposed implementation old code remains in working order until those lousy programmers use a newer platform and then they will experience the problems themselves and will fix them before releasing their code. I'm happy to entertain a patch to this effect. 47210 5 jakub 2011-02-25 12:07:14 +0000 If we go that route (symbol versioning memcpy), then wouldn't it be better to just alias the old memcpy@GLIBC_2.2.5 to memmove and have the new memcpy@@GLIBC_2.14 be the only memcpy implementation? Having two sets of memcpy implementations (especially when we have many memcpy implementations on x86_64 and i?86 selectable via STT_GNU_IFUNC), even if the workaroundish one is placed in compat .text subsections, would waste too much code section in libc.so.6. 47217 6 hjl.tools 2011-02-25 15:19:47 +0000 (In reply to comment #5) > If we go that route (symbol versioning memcpy), then wouldn't it be better to > just alias the old memcpy@GLIBC_2.2.5 to memmove and have the new > memcpy@@GLIBC_2.14 be the only memcpy implementation? Having two sets of memcpy I like this idea. 47227 7 drepper.fsp 2011-02-26 01:56:18 +0000 (In reply to comment #5) > If we go that route (symbol versioning memcpy), then wouldn't it be better to > just alias the old memcpy@GLIBC_2.2.5 to memmove and have the new > memcpy@@GLIBC_2.14 be the only memcpy implementation? That's what I have in mind. 47315 8 felipe.contreras 2011-03-03 23:27:33 +0000 "Buggy" code can be linked to the new memcpy@@GLIBC_2.14 by just recompiling, no? That doesn't really solve anything. Sure, code should use memcpy correctly, and if glibc has a compelling reason to break these programs, it should. As Ulrich mentions in comment #4 "There are going to be more and different implementations in the future and they shouldn't be prevented from being used because of buggy programs." But _today_ that's not the case. Today, the regression can be fixed easily with a patch like what Linus is proposing, and there will be no *downside* whatsoever. How about glibc breaks the behavior _only_ when there's an *upside* to breaking it? 47329 9 drepper.fsp 2011-03-04 23:41:41 +0000 (In reply to comment #8) > "Buggy" code can be linked to the new memcpy@@GLIBC_2.14 by just recompiling, > no? That doesn't really solve anything. It solves everything. If you just relink without retesting you're an idiot and acting irresponsible. 47330 10 torvalds 2011-03-04 23:53:36 +0000 (In reply to comment #9) > > It solves everything. If you just relink without retesting you're an idiot and > acting irresponsible. It does solve a lot, and at least fixes the "you broke stuff that used to work" issue. However, I still don't understand why you guys can't just admit that you might as well just do memmove() and be done with it. It's not slower. And the excuse that "you'll have more implementations in the future" is just an even stronger reason to do that. To make this very clear: your new "and improved" memcpy() ACTS DIFFERENTLY ON DIFFERENT MACHINES. That means that all that testing that was done by the developer at link-time is ALMOST TOTALLY WORTHLESS, because what was tested wasn't necessarily at all what the user sees. I really don't understand why you can't admit that random behavior like that by a very fundamental core library routine is actually a real problem. And there really isn't any upside. The optimized routines up to 80 bytes are the same (in fact, my patch should speed them up by a few cycles), and anything bigger than that will not notice the extra couple of cycles to check for overlap. So while I agree that it's a fix to the immediate problem to just say "don't screw up for existing binaries", I do NOT understand why the glibc people then apparently think it's fine to be stupid for new binaries. 47332 11 felipe.contreras 2011-03-05 00:28:38 +0000 (In reply to comment #9) > (In reply to comment #8) > > "Buggy" code can be linked to the new memcpy@@GLIBC_2.14 by just recompiling, > > no? That doesn't really solve anything. > > It solves everything. If you just relink without retesting you're an idiot and > acting irresponsible. You cannot test every possible code-path. 47335 12 oliver.henshaw 2011-03-05 13:28:28 +0000 The thread starting at http://lwn.net/Articles/414496/ may be instructive on how this can cause problems despite the good(-ish) intentions of the developer. In short, squashfs used memcpy with data that was known not to overlap but later changes invalidated this assumption. 47610 13 bvasselle 2011-03-24 21:03:57 +0000 (In reply to comment #9) > (In reply to comment #8) > > "Buggy" code can be linked to the new memcpy@@GLIBC_2.14 by just recompiling, > > no? That doesn't really solve anything. > > It solves everything. If you just relink without retesting you're an idiot and > acting irresponsible. Nobody is interested in an optimization in lib C that would at best gain less than the simple fact of calling the function. Everybody is interested in using the code that idiots may produce. 47612 14 5323 hjl.tools 2011-03-25 04:37:07 +0000 Created attachment 5323 A patch This works for me. 47614 15 jakub 2011-03-25 06:45:50 +0000 This is not correct: 1) glibc 2.13 has been released already, so new symbol versions must be GLIBC_2.14 2) you do it only on x86_64, therefore you should add it into sysdeps/x86_64/Versions (though, you will need to add GLIBC_2.14 to toplevel Versions.def too) 47633 16 felipe.contreras 2011-03-28 11:53:48 +0000 So we have two solutions: 1) The solution proposed by Linus Torvalds, attachment #5264 Advantages: everything works the same as before Disadvantages: a few extra cycles in certain memcpy's 2) The solution proposed by Ulrich Drepper, attachment #5323 Advantages: old binaries keep working Disadvantages: newly compiled code remains affected Clearly 1) is the most sensible solution as the only advantage of 2) is a few cycles, and has drastic disadvantages. 47658 17 felipe.contreras 2011-03-29 14:43:31 +0000 Actually, why not have both? I think this plan would fit everyone: 1) Apply Linus' patch Both to 2.13 and 2.14, this would not introduce any issues and would restore back the previous behavior, so applications would still work. As I mentioned before, the disadvantages are minimal. 2) Apply H.J. Lu's patch This would go to 2.14, but not only to x86 but all architectures, and add an overlap check, and when triggered issue a crash. This would allow old binaries to keep working on 2.14, but newly compiled ones would crash if they are doing something wrong. This would allow all the users of glibc to fix their code for the impending changes. 3) Remove overlap checks On 2.15, after a transition period, the overlap checks can be removed, and thus save the few extra cycles. This has all the advantages of all the proposals, and makes it easy to fix the applications that are using memcpy wrong. 47667 18 bvasselle 2011-03-29 22:27:52 +0000 (In reply to comment #17) > Actually, why not have both? I think this plan would fit everyone: No, it does not. It certainly does not. It is not only the problem of recompiling the existing code, it's also the problem of fixing it and re-qualifying it. This plan has a huge cost... and it's vain. The contract C programmers have with C and the C library is clear: we accept a fair amount of inefficency, but we don't have to program in assembly nor care about the system's internals. How many people still use the C library when it comes to be important to gain an addition plus a comparison? The problem we're facing just made this fact plain: there is no reason why memcpy should not be memmove. 47670 19 felipe.contreras 2011-03-30 05:14:25 +0000 (In reply to comment #18) > (In reply to comment #17) > > Actually, why not have both? I think this plan would fit everyone: > > No, it does not. It certainly does not. > > It is not only the problem of recompiling the existing code, it's also the > problem of fixing it and re-qualifying it. This plan has a huge cost... and > it's vain. I understand that, but it's better than the current alternative that Ulrich is more likely to merge, which is basically to do nothing. 47671 20 5341 felipe.contreras 2011-03-30 07:21:26 +0000 Created attachment 5341 Patch to check for overlaps I'm trying this patch to find out how many things in the system use overlapping memcpy, however, it doesn't seem to cause any crashes... Can anyone spot something wrong? 47696 21 shaforostoff 2011-03-31 08:36:56 +0000 i'd like to vote for having memcpy and memmove identical. (unless there are benchmarks that are showing that perf difference is high) 48080 22 drepper.fsp 2011-04-01 23:41:31 +0000 HJ's patch which implements what I proposed is in git. 48083 23 hjl.tools 2011-04-02 02:57:19 +0000 (In reply to comment #3) > > If anything, from a "be nice" standpoint, it would perhaps be good to have a > "debug mode", that would actually _warn_ - or even assert - about overlapping > memcpy(). That obviously shouldn't be the default (since that only helps You can use LD_AUDIT to do it today. 48187 24 bvasselle 2011-04-10 15:39:30 +0000 (In reply to comment #4) > The existence of code written by people who should never have been allowed to > touch a keyboard cannot be allowed to prevent a correct implementation. If > there is a large bod of code out there we can work around the issue for that. > Don't you see it is just NOT a correct implementation? 48188 25 5660 felipe.contreras 2011-04-10 15:49:59 +0000 Created attachment 5660 Patch to check for overlaps Actually the code from Linus had a bug in the 'cmp' checks, here's the updated version. I just started to run my Fedora system with this, and I already see crashes in pulseaudio and readahead-collector. I will continue running this for a bit, but I think it's pretty clear that we should not assume that all applications in a typical system have been using memcpy properly. So, again, I think we need at least a transition period so that people can detect and fix the issues. 48514 26 vincent-srcware 2011-05-04 13:29:06 +0000 (In reply to comment #18) > The problem we're facing just made this fact plain: there is no reason why > memcpy should not be memmove. If these two functions should behave in the same way, then why not all programmers use memmove (which has fewer requirements)? If memcpy is called while the objects overlap, the bug is not necessarily that memmove should have been used instead. The cause may be an incorrect size. So, with this point of view, it should be safer to abort than letting the program behave in an uncontrolled way. (In reply to comment #25) > So, again, I think we need at least a transition period so that people can > detect and fix the issues. But it may be difficult to detect the issues. For instance, zsh was affected by a similar problem (now fixed in CVS only) with the optimized strcpy, but to detect the problem, it involves keyboard input: http://www.zsh.org/mla/workers/2011/msg00533.html http://www.zsh.org/mla/workers/2011/msg00544.html For strcpy, this is even worse, as there is no strmove function, so that either programmers have to write non-portable code or they have to reimplement a naive version of strcpy or find some other workaround, such as memmove + strlen: http://www.zsh.org/mla/workers/2011/msg00542.html I suppose that if this has been done for memcpy, then strcpy should also be patched in some way... 48515 27 felipe.contreras 2011-05-04 15:01:05 +0000 (In reply to comment #26) > (In reply to comment #25) > > So, again, I think we need at least a transition period so that people can > > detect and fix the issues. > > But it may be difficult to detect the issues. For instance, zsh was affected by > a similar problem (now fixed in CVS only) with the optimized strcpy, but to > detect the problem, it involves keyboard input: Yes, it is difficult, that's why I think it should be enabled globally. BTW. Here's another issue on zsh I found while enabling the memcpy checks: https://bugzilla.redhat.com/show_bug.cgi?id=698439 5264 2011-02-25 02:26:00 +0000 2011-03-25 04:37:07 +0000 Example patch to give the basic idea patch.diff text/plain 3870 torvalds IHN5c2RlcHMveDg2XzY0L211bHRpYXJjaC9tZW1jcHktc3NzZTMuUyAgfCAgIDQ4ICsrKysrKysr KysrKysrKy0tLS0tLS0tLS0tLS0tLQogc3lzZGVwcy94ODZfNjQvbXVsdGlhcmNoL21lbW1vdmUt c3NzZTMuUyB8ICAgIDggKystLQogMiBmaWxlcyBjaGFuZ2VkLCAyOCBpbnNlcnRpb25zKCspLCAy OCBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9zeXNkZXBzL3g4Nl82NC9tdWx0aWFyY2gvbWVt Y3B5LXNzc2UzLlMgYi9zeXNkZXBzL3g4Nl82NC9tdWx0aWFyY2gvbWVtY3B5LXNzc2UzLlMKaW5k ZXggOWE4NzhkMy4uNzQ3ZDJlZiAxMDA2NDQKLS0tIGEvc3lzZGVwcy94ODZfNjQvbXVsdGlhcmNo L21lbWNweS1zc3NlMy5TCisrKyBiL3N5c2RlcHMveDg2XzY0L211bHRpYXJjaC9tZW1jcHktc3Nz ZTMuUwpAQCAtNjEsMTggKzYxLDE1IEBAIEVOVFJZIChNRU1DUFkpCiAjaWZkZWYgVVNFX0FTX01F TVBDUFkKIAlhZGQJJXJkeCwgJXJheAogI2VuZGlmCi0KLSNpZmRlZiBVU0VfQVNfTUVNTU9WRQot CWNtcAklcnNpLCAlcmRpCi0JamIJTChjb3B5X2ZvcndhcmQpCi0JamUJTCh3cml0ZV8wYnl0ZXMp Ci0JY21wCSQ3OSwgJXJkeAotCWpiZQlMKGNvcHlfZm9yd2FyZCkKLQlqbXAJTChjb3B5X2JhY2t3 YXJkKQotTChjb3B5X2ZvcndhcmQpOgotI2VuZGlmCi0JY21wCSQ3OSwgJXJkeAotCWxlYSAgICAg TCh0YWJsZV9sZXNzXzgwYnl0ZXMpKCVyaXApLCAlcjExCisJLyoKKwkgKiBUaGUgc21hbGwgY2Fz ZXMgd2UgY2FuIGRvIHdpdGhvdXQgY2hlY2tpbmcgZm9yIGFueQorCSAqIG92ZXJsYXAgYXQgYWxs LCBzaW5jZSB3ZSBkbyB0aGVtIGFzIGFsbCBsb2FkcyBmb2xsb3dlZAorCSAqIGJ5IGFsbCBzdG9y ZXMuCisJICoKKwkgKiBTbyBqdXN0IGp1bXAgdGhyb3VnaCB0aGUgbGVzcy10aGFuLTgwYnl0ZXMg dGFibGUuCisJICovCisJY21wCSQ3OSwlcmR4CisJbGVhCUwodGFibGVfbGVzc184MGJ5dGVzKSgl cmlwKSwgJXIxMQogCWphCUwoODBieXRlc29ybW9yZSkKIAltb3ZzbHEJKCVyMTEsICVyZHgsIDQp LCAlcjkKIAlhZGQJJXJkeCwgJXJzaQpAQCAtODEsMTMgKzc4LDI0IEBAIEwoY29weV9mb3J3YXJk KToKIAlqbXAJKiVyOQogCXVkMgogCi0JQUxJR04gKDQpCisJLyoKKwkgKiBGb3IgdGhlIDgwKyBi eXRlIGNhc2VzIHdlIG5lZWQgdG8gY2hlY2sgb3ZlcmxhcAorCSAqLwogTCg4MGJ5dGVzb3Jtb3Jl KToKLSNpZm5kZWYgVVNFX0FTX01FTU1PVkUKKwlsZWEJKCVyc2ksJXJkeCksJXI5CisJbGVhCSgl cmRpLCVyZHgpLCVyMTEKKwljbXAJJXJkaSwlcjkJCS8qIGRlc3Qgc3RhcnQgPj0gc291cmNlIGVu ZCAqLworCWphZQlMKG5vbm92ZXJsYXApCQkvKiAgLT4gbm9ub3ZlcmxhcHBpbmcgKi8KKwljbXAJ JXJzaSwlcjExCQkvKiBzb3VyY2Ugc3RhcnQgPj0gZGVzdGluYXRpb24gZW5kICovCisJamFlCUwo bm9ub3ZlcmxhcCkJCS8qICAtPiBub25vdmVybGFwcGluZyAqLworCWNtcAklcnNpLCAlcmRpCQkv KiBvdmVybGFwOiAqLworCWpiCUwoY29weV9mb3J3YXJkKQkJLyogc291cmNlIDwgZGVzdDogZm9y d2FyZCBjb3B5ICovCisJamUJTCh3cml0ZV8wYnl0ZXMpCQkvKiBzb3VyY2UgPT0gZGVzdDogbm8g Y29weSAqLworCWptcAlMKGNvcHlfYmFja3dhcmQpCS8qIHNvdXJjZSA+IGRlc3Q6IGJhY2t3YXJk IGNvcHkgKi8KK0wobm9ub3ZlcmxhcCk6CiAJY21wCSVkaWwsICVzaWwKIAlqbGUJTChjb3B5X2Jh Y2t3YXJkKQotI2VuZGlmCi0KK0woY29weV9mb3J3YXJkKToKIAltb3ZkcXUJKCVyc2kpLCAleG1t MAogCW1vdgklcmRpLCAlcmN4CiAJYW5kCSQtMTYsICVyZGkKQEAgLTI4MDUsNyArMjgxMyw2IEBA IEwobGFyZ2VfcGFnZV9md2QpOgogCW1vdm50ZHEJJXhtbTEsICglcmRpKQogCWxlYQkxNiglcmRp KSwgJXJkaQogCWxlYQktMHg5MCglcmR4KSwgJXJkeAotI2lmZGVmIFVTRV9BU19NRU1NT1ZFCiAJ bW92CSVyc2ksICVyOQogCXN1YgklcmRpLCAlcjkKIAljbXAJJXJkeCwgJXI5CkBAIC0yODE0LDcg KzI4MjEsNiBAQCBMKGxhcmdlX3BhZ2VfZndkKToKIAljbXAJJXJjeCwgJXJkeAogCWpiCUwobGxf Y2FjaGVfY29weV9md2Rfc3RhcnQpCiBMKG1lbW1vdmVfaXNfbWVtY3B5X2Z3ZCk6Ci0jZW5kaWYK IEwobGFyZ2VfcGFnZV9sb29wKToKIAltb3ZkcXUJKCVyc2kpLCAleG1tMAogCW1vdmRxdQkweDEw KCVyc2kpLCAleG1tMQpAQCAtMjg1OSw3ICsyODY1LDYgQEAgTChsYXJnZV9wYWdlX2xlc3NfNjRi eXRlcyk6CiAJc2ZlbmNlCiAJQlJBTkNIX1RPX0pNUFRCTF9FTlRSWSAoTCh0YWJsZV9sZXNzXzgw Ynl0ZXMpLCAlcmR4LCA0KQogCi0jaWZkZWYgVVNFX0FTX01FTU1PVkUKIAlBTElHTiAoNCkKIEwo bGxfY2FjaGVfY29weV9md2Rfc3RhcnQpOgogCXByZWZldGNodDAgMHgxYzAoJXJzaSkKQEAgLTI5 MDYsNyArMjkxMSw2IEBAIEwobGFyZ2VfcGFnZV9sbF9sZXNzX2Z3ZF82NGJ5dGVzKToKIAlhZGQJ JXJkeCwgJXJkaQogCUJSQU5DSF9UT19KTVBUQkxfRU5UUlkgKEwodGFibGVfbGVzc184MGJ5dGVz KSwgJXJkeCwgNCkKIAotI2VuZGlmCiAJQUxJR04gKDQpCiBMKGxhcmdlX3BhZ2VfYndkKToKIAlt b3ZkcXUJLTB4MTAoJXJzaSksICV4bW0xCkBAIC0yOTE1LDcgKzI5MTksNiBAQCBMKGxhcmdlX3Bh Z2VfYndkKToKIAltb3ZkcWEJJXhtbTEsIC0weDEwKCVyZGkpCiAJbGVhCS0xNiglcmRpKSwgJXJk aQogCWxlYQktMHg5MCglcmR4KSwgJXJkeAotI2lmZGVmIFVTRV9BU19NRU1NT1ZFCiAJbW92CSVy ZGksICVyOQogCXN1YgklcnNpLCAlcjkKIAljbXAJJXJkeCwgJXI5CkBAIC0yOTIzLDcgKzI5MjYs NiBAQCBMKGxhcmdlX3BhZ2VfYndkKToKIAljbXAJJXJjeCwgJXI5CiAJamIJTChsbF9jYWNoZV9j b3B5X2J3ZF9zdGFydCkKIEwobWVtbW92ZV9pc19tZW1jcHlfYndkKToKLSNlbmRpZgogTChsYXJn ZV9wYWdlX2J3ZF9sb29wKToKIAltb3ZkcXUJLTB4MTAoJXJzaSksICV4bW0wCiAJbW92ZHF1CS0w eDIwKCVyc2kpLCAleG1tMQpAQCAtMjk2Niw3ICsyOTY4LDYgQEAgTChsYXJnZV9wYWdlX2xlc3Nf YndkXzY0Ynl0ZXMpOgogCXNmZW5jZQogCUJSQU5DSF9UT19KTVBUQkxfRU5UUlkgKEwodGFibGVf bGVzc184MGJ5dGVzKSwgJXJkeCwgNCkKIAotI2lmZGVmIFVTRV9BU19NRU1NT1ZFCiAJQUxJR04g KDQpCiBMKGxsX2NhY2hlX2NvcHlfYndkX3N0YXJ0KToKIAlwcmVmZXRjaHQwIC0weDFjMCglcnNp KQpAQCAtMzAxMCw3ICszMDExLDYgQEAgTChsbF9jYWNoZV9jb3B5X2J3ZF9zdGFydCk6CiAJc3Vi CSQweDQwLCAlcmR4CiBMKGxhcmdlX3BhZ2VfbGxfbGVzc19id2RfNjRieXRlcyk6CiAJQlJBTkNI X1RPX0pNUFRCTF9FTlRSWSAoTCh0YWJsZV9sZXNzXzgwYnl0ZXMpLCAlcmR4LCA0KQotI2VuZGlm CiAKIEVORCAoTUVNQ1BZKQogCmRpZmYgLS1naXQgYS9zeXNkZXBzL3g4Nl82NC9tdWx0aWFyY2gv bWVtbW92ZS1zc3NlMy5TIGIvc3lzZGVwcy94ODZfNjQvbXVsdGlhcmNoL21lbW1vdmUtc3NzZTMu UwppbmRleCAyOTU0MzBiLi5hMzhkNDQ1IDEwMDY0NAotLS0gYS9zeXNkZXBzL3g4Nl82NC9tdWx0 aWFyY2gvbWVtbW92ZS1zc3NlMy5TCisrKyBiL3N5c2RlcHMveDg2XzY0L211bHRpYXJjaC9tZW1t b3ZlLXNzc2UzLlMKQEAgLTEsNCArMSw0IEBACi0jZGVmaW5lIFVTRV9BU19NRU1NT1ZFCi0jZGVm aW5lIE1FTUNQWQkJX19tZW1tb3ZlX3Nzc2UzCi0jZGVmaW5lIE1FTUNQWV9DSEsJX19tZW1tb3Zl X2Noa19zc3NlMwotI2luY2x1ZGUgIm1lbWNweS1zc3NlMy5TIgorI2luY2x1ZGUgPHN5c2RlcC5o PgorCitzdHJvbmdfYWxpYXMoX19tZW1tb3ZlX3Nzc2UzLCBfX21lbWNweV9zc3NlMyk7CitzdHJv bmdfYWxpYXMoX19tZW1tb3ZlX2Noa19zc3NlMywgX19tZW1jcHlfY2hrX3Nzc2UzKTsK 5323 2011-03-25 04:37:00 +0000 2011-03-25 04:37:07 +0000 A patch libc-pr12518-1.patch text/plain 2282 hjl.tools MjAxMS0wMy0yNCAgSC5KLiBMdSAgPGhvbmdqaXUubHVAaW50ZWwuY29tPgoKCVBSIGxpYmMvMTI1 MTgKCSogc3RyaW5nL1ZlcnNpb25zOiBBZGQgbWVtY3B5IHRvIEdMSUJDXzIuMTMuCgoJKiBzeXNk ZXBzL3g4Nl82NC9tdWx0aWFyY2gvbWVtY3B5LlM6IEluY2x1ZGUgPHNobGliLWNvbXBhdC5oPi4K CShtZW1jcHkpOiBSZW5hbWVkIHRvIC4uLgoJKF9fbmV3X21lbWNweSk6IFRoaXMuCgkobWVtY3B5 KTogUHJvdmlkZSBHTElCQ18yXzEzIG1lbWNweS4KCgkqIHN5c2RlcHMveDg2XzY0L211bHRpYXJj aC9tZW1tb3ZlLmM6IEluY2x1ZGUgPHNobGliLWNvbXBhdC5oPi4KCShtZW1jcHkpOiBQcm92aWRl IEdMSUJDXzJfMl81IG1lbWNweS4KCmRpZmYgLS1naXQgYS9zdHJpbmcvVmVyc2lvbnMgYi9zdHJp bmcvVmVyc2lvbnMKaW5kZXggZjE0NWZkMy4uYjdiZjIzNSAxMDA2NDQKLS0tIGEvc3RyaW5nL1Zl cnNpb25zCisrKyBiL3N0cmluZy9WZXJzaW9ucwpAQCAtODAsNCArODAsNyBAQCBsaWJjIHsKICAg R0xJQkNfMi42IHsKICAgICBzdHJlcnJvcl9sOwogICB9CisgIEdMSUJDXzIuMTMgeworICAgIG1l bWNweTsKKyAgfQogfQpkaWZmIC0tZ2l0IGEvc3lzZGVwcy94ODZfNjQvbXVsdGlhcmNoL21lbWNw eS5TIGIvc3lzZGVwcy94ODZfNjQvbXVsdGlhcmNoL21lbWNweS5TCmluZGV4IDhlOWZiMTkuLmQ4 MzA1OWEgMTAwNjQ0Ci0tLSBhL3N5c2RlcHMveDg2XzY0L211bHRpYXJjaC9tZW1jcHkuUworKysg Yi9zeXNkZXBzL3g4Nl82NC9tdWx0aWFyY2gvbWVtY3B5LlMKQEAgLTE5LDYgKzE5LDcgQEAKICAg IDAyMTExLTEzMDcgVVNBLiAgKi8KIAogI2luY2x1ZGUgPHN5c2RlcC5oPgorI2luY2x1ZGUgPHNo bGliLWNvbXBhdC5oPgogI2luY2x1ZGUgPGluaXQtYXJjaC5oPgogCiAvKiBEZWZpbmUgbXVsdGlw bGUgdmVyc2lvbnMgb25seSBmb3IgdGhlIGRlZmluaXRpb24gaW4gbGliIGFuZCBmb3IKQEAgLTI2 LDggKzI3LDggQEAKICAgIGhhcHBlbmVkLiAgKi8KICNpZiBkZWZpbmVkIFNIQVJFRCAmJiAhZGVm aW5lZCBOT1RfSU5fbGliYwogCS50ZXh0Ci1FTlRSWShtZW1jcHkpCi0JLnR5cGUJbWVtY3B5LCBA Z251X2luZGlyZWN0X2Z1bmN0aW9uCitFTlRSWShfX25ld19tZW1jcHkpCisJLnR5cGUJX19uZXdf bWVtY3B5LCBAZ251X2luZGlyZWN0X2Z1bmN0aW9uCiAJY21wbAkkMCwgS0lORF9PRkZTRVQrX19j cHVfZmVhdHVyZXMoJXJpcCkKIAlqbmUJMWYKIAljYWxsCV9faW5pdF9jcHVfZmVhdHVyZXMKQEAg LTM5LDcgKzQwLDcgQEAgRU5UUlkobWVtY3B5KQogCWp6CTJmCiAJbGVhcQlfX21lbWNweV9zc3Nl M19iYWNrKCVyaXApLCAlcmF4CiAyOglyZXQKLUVORChtZW1jcHkpCitFTkQoX19uZXdfbWVtY3B5 KQogCiAjIHVuZGVmIEVOVFJZCiAjIGRlZmluZSBFTlRSWShuYW1lKSBcCkBAIC02OCw2ICs2OSw4 IEBAIEVORChtZW1jcHkpCiAgICBieSB0aGUgaW5kaXJlY3QgY2FsbCBpbiB0aGUgUExULiAgKi8K ICMgZGVmaW5lIGxpYmNfaGlkZGVuX2J1aWx0aW5fZGVmKG5hbWUpIFwKIAkuZ2xvYmwgX19HSV9t ZW1jcHk7IF9fR0lfbWVtY3B5ID0gX19tZW1jcHlfc3NlMgorCit2ZXJzaW9uZWRfc3ltYm9sIChs aWJjLCBfX25ld19tZW1jcHksIG1lbWNweSwgR0xJQkNfMl8xMyk7CiAjZW5kaWYKIAogI2luY2x1 ZGUgIi4uL21lbWNweS5TIgpkaWZmIC0tZ2l0IGEvc3lzZGVwcy94ODZfNjQvbXVsdGlhcmNoL21l bW1vdmUuYyBiL3N5c2RlcHMveDg2XzY0L211bHRpYXJjaC9tZW1tb3ZlLmMKaW5kZXggMzc5ODYy Ny4uMDQ2OTJhYiAxMDA2NDQKLS0tIGEvc3lzZGVwcy94ODZfNjQvbXVsdGlhcmNoL21lbW1vdmUu YworKysgYi9zeXNkZXBzL3g4Nl82NC9tdWx0aWFyY2gvbWVtbW92ZS5jCkBAIC0yMCw2ICsyMCw3 IEBACiAjaW5jbHVkZSA8c3RyaW5nLmg+CiAKICNpZm5kZWYgTk9UX0lOX2xpYmMKKyNpbmNsdWRl IDxzaGxpYi1jb21wYXQuaD4KICNpbmNsdWRlICJpbml0LWFyY2guaCIKIAogI2RlZmluZSBNRU1N T1ZFIF9fbWVtbW92ZV9zc2UyCkBAIC00Miw0ICs0Myw4IEBAIGxpYmNfaWZ1bmMgKG1lbW1vdmUs CiAJICAgID8gKEhBU19GQVNUX0NPUFlfQkFDS1dBUkQKIAkgICAgICAgPyBfX21lbW1vdmVfc3Nz ZTNfYmFjayA6IF9fbWVtbW92ZV9zc3NlMykKIAkgICAgOiBfX21lbW1vdmVfc3NlMik7CisKKyNp ZiBTSExJQl9DT01QQVQgKGxpYmMsIEdMSUJDXzJfMl81LCBHTElCQ18yXzEzKQorY29tcGF0X3N5 bWJvbCAobGliYywgbWVtbW92ZSwgbWVtY3B5LCBHTElCQ18yXzJfNSk7CisjZW5kaWYKICNlbmRp Zgo= 5341 2011-03-30 07:21:00 +0000 2011-04-10 15:49:59 +0000 Patch to check for overlaps glibc-memcpy-ssse3.patch text/plain 1226 felipe.contreras LS0tIGdsaWJjLTIuMTMvc3lzZGVwcy94ODZfNjQvbXVsdGlhcmNoL21lbWNweS1zc3NlMy5TCTIw MTEtMDEtMTggMDY6MzQ6MDcuMDAwMDAwMDAwICswMjAwCisrKyBnbGliYy0yLjEzL3N5c2RlcHMv eDg2XzY0L211bHRpYXJjaC9tZW1jcHktc3NzZTMuUwkyMDExLTAzLTI5IDIwOjA2OjExLjQ0OTA5 MDEzNiArMDMwMApAQCAtODQsNiArODQsMTcgQEAgTChjb3B5X2ZvcndhcmQpOgogCUFMSUdOICg0 KQogTCg4MGJ5dGVzb3Jtb3JlKToKICNpZm5kZWYgVVNFX0FTX01FTU1PVkUKKwlsZWEJKCVyc2ks JXJkeCksJXI5CisJbGVhCSglcmRpLCVyZHgpLCVyMTEKKwljbXAJJXJkaSwlcjkJCS8qIGRlc3Qg c3RhcnQgPj0gc291cmNlIGVuZCAqLworCWphZQlMKG5vbm92ZXJsYXApCQkvKiAgLT4gbm9ub3Zl cmxhcHBpbmcgKi8KKwljbXAJJXJzaSwlcjExCQkvKiBzb3VyY2Ugc3RhcnQgPj0gZGVzdGluYXRp b24gZW5kICovCisJamFlCUwobm9ub3ZlcmxhcCkJCS8qICAtPiBub25vdmVybGFwcGluZyAqLwor CW1vdmIJJDAsIDAKKwlMKG5vbm92ZXJsYXApOgorI2VuZGlmCisKKyNpZm5kZWYgVVNFX0FTX01F TU1PVkUKIAljbXAJJWRpbCwgJXNpbAogCWpsZQlMKGNvcHlfYmFja3dhcmQpCiAjZW5kaWYKLS0t IGdsaWJjLTIuMTMvc3lzZGVwcy94ODZfNjQvbXVsdGlhcmNoL21lbWNweS1zc3NlMy1iYWNrLlMJ MjAxMS0wMS0xOCAwNjozNDowNy4wMDAwMDAwMDAgKzAyMDAKKysrIGdsaWJjLTIuMTMvc3lzZGVw cy94ODZfNjQvbXVsdGlhcmNoL21lbWNweS1zc3NlMy1iYWNrLlMJMjAxMS0wMy0yOSAyMDowNjoy MS4yNTIxMTIwMjQgKzAzMDAKQEAgLTkwLDYgKzkwLDE2IEBAIEwoYmtfd3JpdGUpOgogCiAJQUxJ R04gKDQpCiBMKDE0NGJ5dGVzb3Jtb3JlKToKKyNpZm5kZWYgVVNFX0FTX01FTU1PVkUKKwlsZWEJ KCVyc2ksJXJkeCksJXI5CisJbGVhCSglcmRpLCVyZHgpLCVyMTEKKwljbXAJJXJkaSwlcjkJCS8q IGRlc3Qgc3RhcnQgPj0gc291cmNlIGVuZCAqLworCWphZQlMKG5vbm92ZXJsYXApCQkvKiAgLT4g bm9ub3ZlcmxhcHBpbmcgKi8KKwljbXAJJXJzaSwlcjExCQkvKiBzb3VyY2Ugc3RhcnQgPj0gZGVz dGluYXRpb24gZW5kICovCisJamFlCUwobm9ub3ZlcmxhcCkJCS8qICAtPiBub25vdmVybGFwcGlu ZyAqLworCW1vdmIJJDAsIDAKKwlMKG5vbm92ZXJsYXApOgorI2VuZGlmCiAKICNpZm5kZWYgVVNF X0FTX01FTU1PVkUKIAljbXAJJWRpbCwgJXNpbAo= 5660 2011-04-10 15:49:00 +0000 2011-04-10 15:49:59 +0000 Patch to check for overlaps 0001-memcpy-overlap-test.patch text/plain 1771 felipe.contreras RnJvbSAzZDE4OTVlMTcxMzZiNGE1NjVmZmVmZDM3YzAyYTE1OTY2NDAxN2VkIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBGZWxpcGUgQ29udHJlcmFzIDxmZWxpcGUuY29udHJlcmFzQGdt YWlsLmNvbT4KRGF0ZTogU3VuLCAxMCBBcHIgMjAxMSAxNzoyOTo0NCArMDMwMApTdWJqZWN0OiBb UEFUQ0hdIG1lbWNweSBvdmVybGFwIHRlc3QKClNpZ25lZC1vZmYtYnk6IEZlbGlwZSBDb250cmVy YXMgPGZlbGlwZS5jb250cmVyYXNAZ21haWwuY29tPgotLS0KIHN5c2RlcHMveDg2XzY0L211bHRp YXJjaC9tZW1jcHktc3NzZTMtYmFjay5TIHwgICAxMSArKysrKysrKysrKwogc3lzZGVwcy94ODZf NjQvbXVsdGlhcmNoL21lbWNweS1zc3NlMy5TICAgICAgfCAgIDExICsrKysrKysrKysrCiAyIGZp bGVzIGNoYW5nZWQsIDIyIGluc2VydGlvbnMoKyksIDAgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0 IGEvc3lzZGVwcy94ODZfNjQvbXVsdGlhcmNoL21lbWNweS1zc3NlMy1iYWNrLlMgYi9zeXNkZXBz L3g4Nl82NC9tdWx0aWFyY2gvbWVtY3B5LXNzc2UzLWJhY2suUwppbmRleCA0OGM5NzRlLi40ZTNl ZTc4IDEwMDY0NAotLS0gYS9zeXNkZXBzL3g4Nl82NC9tdWx0aWFyY2gvbWVtY3B5LXNzc2UzLWJh Y2suUworKysgYi9zeXNkZXBzL3g4Nl82NC9tdWx0aWFyY2gvbWVtY3B5LXNzc2UzLWJhY2suUwpA QCAtNTcsNiArNTcsMTcgQEAgRU5EIChNRU1DUFlfQ0hLKQogI2VuZGlmCiAKIEVOVFJZIChNRU1D UFkpCisjaWZuZGVmIFVTRV9BU19NRU1NT1ZFCisJbGVhCSglcnNpLCAlcmR4KSwgJXI5CisJbGVh CSglcmRpLCAlcmR4KSwgJXIxMQorCWNtcAklcjksICVyZGkJCS8qIGRlc3Qgc3RhcnQgPj0gc291 cmNlIGVuZCAqLworCWphZQlMKG5vbm92ZXJsYXApCQkvKiAgLT4gbm9ub3ZlcmxhcHBpbmcgKi8K KwljbXAJJXIxMSwgJXJzaQkJLyogc291cmNlIHN0YXJ0ID49IGRlc3RpbmF0aW9uIGVuZCAqLwor CWphZQlMKG5vbm92ZXJsYXApCQkvKiAgLT4gbm9ub3ZlcmxhcHBpbmcgKi8KKwltb3ZiCSQwLCAw CisJTChub25vdmVybGFwKToKKyNlbmRpZgorCiAJbW92CSVyZGksICVyYXgKICNpZmRlZiBVU0Vf QVNfTUVNUENQWQogCWFkZAklcmR4LCAlcmF4CmRpZmYgLS1naXQgYS9zeXNkZXBzL3g4Nl82NC9t dWx0aWFyY2gvbWVtY3B5LXNzc2UzLlMgYi9zeXNkZXBzL3g4Nl82NC9tdWx0aWFyY2gvbWVtY3B5 LXNzc2UzLlMKaW5kZXggOWE4NzhkMy4uY2MzMTZlOCAxMDA2NDQKLS0tIGEvc3lzZGVwcy94ODZf NjQvbXVsdGlhcmNoL21lbWNweS1zc3NlMy5TCisrKyBiL3N5c2RlcHMveDg2XzY0L211bHRpYXJj aC9tZW1jcHktc3NzZTMuUwpAQCAtNTcsNiArNTcsMTcgQEAgRU5EIChNRU1DUFlfQ0hLKQogI2Vu ZGlmCiAKIEVOVFJZIChNRU1DUFkpCisjaWZuZGVmIFVTRV9BU19NRU1NT1ZFCisJbGVhCSglcnNp LCAlcmR4KSwgJXI5CisJbGVhCSglcmRpLCAlcmR4KSwgJXIxMQorCWNtcAklcjksICVyZGkJCS8q IGRlc3Qgc3RhcnQgPj0gc291cmNlIGVuZCAqLworCWphZQlMKG5vbm92ZXJsYXApCQkvKiAgLT4g bm9ub3ZlcmxhcHBpbmcgKi8KKwljbXAJJXIxMSwgJXJzaQkJLyogc291cmNlIHN0YXJ0ID49IGRl c3RpbmF0aW9uIGVuZCAqLworCWphZQlMKG5vbm92ZXJsYXApCQkvKiAgLT4gbm9ub3ZlcmxhcHBp bmcgKi8KKwltb3ZiCSQwLCAwCisJTChub25vdmVybGFwKToKKyNlbmRpZgorCiAJbW92CSVyZGks ICVyYXgKICNpZmRlZiBVU0VfQVNfTUVNUENQWQogCWFkZAklcmR4LCAlcmF4Ci0tIAoxLjcuNS5y YzEKCg==