125182011-02-25 02:26:20 +0000memcpy acts randomly (and differently) with overlapping areas2015-02-25 10:28:38 +0000111Unclassifiedglibclibc2.13AllAllRESOLVEDFIXEDP2normal---1torvaldsdrepper.fspalexander.hunt2005bvassellefelipe.contrerashjl.toolsjakubjvillaloml-bz-dalemwestoliver.henshawshaforostoffsmconveythierry.vignaudtmoodytmraztolzmanntudorbvincent-srcwarey.pronenkoi386oldest_to_newest4719905264torvalds2011-02-25 02:26:20 +0000Created 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).472001torvalds2011-02-25 02:29:37 +0000Btw, 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)472022hjl.tools2011-02-25 03:57:42 +0000Although 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.472033torvalds2011-02-25 04:14:39 +0000So 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.472084drepper.fsp2011-02-25 09:59:18 +0000The 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.472105jakub2011-02-25 12:07:14 +0000If 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.472176hjl.tools2011-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.472277drepper.fsp2011-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.473158felipe.contreras2011-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?473299drepper.fsp2011-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.4733010torvalds2011-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.4733211felipe.contreras2011-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.4733512oliver.henshaw2011-03-05 13:28:28 +0000The 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.4761013bvasselle2011-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.47612145323hjl.tools2011-03-25 04:37:07 +0000Created attachment 5323
A patch
This works for me.4761415jakub2011-03-25 06:45:50 +0000This 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)4763316felipe.contreras2011-03-28 11:53:48 +0000So 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.4765817felipe.contreras2011-03-29 14:43:31 +0000Actually, 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.4766718bvasselle2011-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.4767019felipe.contreras2011-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.47671205341felipe.contreras2011-03-30 07:21:26 +0000Created 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?4769621shaforostoff2011-03-31 08:36:56 +0000i'd like to vote for having memcpy and memmove identical.
(unless there are benchmarks that are showing that perf difference is high)4808022drepper.fsp2011-04-01 23:41:31 +0000HJ's patch which implements what I proposed is in git.4808323hjl.tools2011-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.4818724bvasselle2011-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?48188255660felipe.contreras2011-04-10 15:49:59 +0000Created 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.4851426vincent-srcware2011-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...4851527felipe.contreras2011-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=6984396296528tudorb2013-08-12 17:19:54 +0000FYI, this bug has bitten me in a different way: memcpy() copying backwards defeats the MADV_SEQUENTIAL flag to madvise(). A trivial file copier implementation (mmap source, mmap destination, set MADV_SEQUENTIAL, memcpy from source to destination) would perform much worse on machines that support SSSE3 than on machines that don't because of this bug.
(Before anyone tells me that I should copy files using read() and write(), my actual usage pattern was more complex, but the details are irrelevant.)6304629neleai2013-08-19 23:48:50 +0000On Mon, Aug 12, 2013 at 05:19:54PM +0000, tudorb at gmail dot com wrote:
> --- Comment #28 from Tudor Bosman <tudorb at gmail dot com> ---
> FYI, this bug has bitten me in a different way: memcpy() copying backwards
> defeats the MADV_SEQUENTIAL flag to madvise(). A trivial file copier
> implementation (mmap source, mmap destination, set MADV_SEQUENTIAL, memcpy from
> source to destination) would perform much worse on machines that support SSSE3
> than on machines that don't because of this bug.
>
Wait, do you have overlapping source and destination areas? If so then a
backward copy is necessary.
Or is backward copy called for not overlapping areas?
I have a patch that could call backward copy only if src-n < dest < src+n holds.
> (Before anyone tells me that I should copy files using read() and write(), my
> actual usage pattern was more complex, but the details are irrelevant.)
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.6304730tudorb2013-08-20 01:12:11 +0000(In reply to Ondrej Bilka from comment #29)
> Wait, do you have overlapping source and destination areas? If so then a
> backward copy is necessary.
Backward copy is often used for non-overlapping areas as it is faster on some Intel processors; see https://bugzilla.redhat.com/show_bug.cgi?id=638477#c99 for an explanation. I was pointing out that it also has the (unintended) behavior of pessimizing mmap()ed file accesses.6677531jackie.rosen2014-02-16 19:41:10 +0000*** Bug 260998 has been marked as a duplicate of this bug. ***
Seen from the domain http://volichat.com
Page where seen: http://volichat.com/adult-chat-rooms
Marked for reference. Resolved as fixed @bugzilla.7420532mwest2015-02-25 10:28:38 +0000We have the discribed Problem on a "Intel(R) Atom(TM) CPU D525 @ 1.80GHz" CPU
with a 32 Bit Installation, but the preload module are only in the x64 lib.
Our libc6:i386 is 2.13-38+deb7u752642011-02-25 02:26:20 +00002011-03-25 04:37:07 +0000Example patch to give the basic ideapatch.difftext/plain1271torvaldsIHN5c2RlcHMveDg2XzY0L211bHRpYXJjaC9tZW1jcHktc3NzZTMuUyAgfCAgIDQ4ICsrKysrKysr
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
53232011-03-25 04:37:07 +00002011-03-25 04:37:07 +0000A patchlibc-pr12518-1.patchtext/plain975hjl.toolsMjAxMS0wMy0yNCAgSC5KLiBMdSAgPGhvbmdqaXUubHVAaW50ZWwuY29tPgoKCVBSIGxpYmMvMTI1
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=
53412011-03-30 07:21:26 +00002011-04-10 15:49:59 +0000Patch to check for overlapsglibc-memcpy-ssse3.patchtext/plain420felipe.contrerasLS0tIGdsaWJjLTIuMTMvc3lzZGVwcy94ODZfNjQvbXVsdGlhcmNoL21lbWNweS1zc3NlMy5TCTIw
MTEtMDEtMTggMDY6MzQ6MDcuMDAwMDAwMDAwICswMjAwCisrKyBnbGliYy0yLjEzL3N5c2RlcHMv
eDg2XzY0L211bHRpYXJjaC9tZW1jcHktc3NzZTMuUwkyMDExLTAzLTI5IDIwOjA2OjExLjQ0OTA5
MDEzNiArMDMwMApAQCAtODQsNiArODQsMTcgQEAgTChjb3B5X2ZvcndhcmQpOgogCUFMSUdOICg0
KQogTCg4MGJ5dGVzb3Jtb3JlKToKICNpZm5kZWYgVVNFX0FTX01FTU1PVkUKKwlsZWEJKCVyc2ks
JXJkeCksJXI5CisJbGVhCSglcmRpLCVyZHgpLCVyMTEKKwljbXAJJXJkaSwlcjkJCS8qIGRlc3Qg
c3RhcnQgPj0gc291cmNlIGVuZCAqLworCWphZQlMKG5vbm92ZXJsYXApCQkvKiAgLT4gbm9ub3Zl
cmxhcHBpbmcgKi8KKwljbXAJJXJzaSwlcjExCQkvKiBzb3VyY2Ugc3RhcnQgPj0gZGVzdGluYXRp
b24gZW5kICovCisJamFlCUwobm9ub3ZlcmxhcCkJCS8qICAtPiBub25vdmVybGFwcGluZyAqLwor
CW1vdmIJJDAsIDAKKwlMKG5vbm92ZXJsYXApOgorI2VuZGlmCisKKyNpZm5kZWYgVVNFX0FTX01F
TU1PVkUKIAljbXAJJWRpbCwgJXNpbAogCWpsZQlMKGNvcHlfYmFja3dhcmQpCiAjZW5kaWYKLS0t
IGdsaWJjLTIuMTMvc3lzZGVwcy94ODZfNjQvbXVsdGlhcmNoL21lbWNweS1zc3NlMy1iYWNrLlMJ
MjAxMS0wMS0xOCAwNjozNDowNy4wMDAwMDAwMDAgKzAyMDAKKysrIGdsaWJjLTIuMTMvc3lzZGVw
cy94ODZfNjQvbXVsdGlhcmNoL21lbWNweS1zc3NlMy1iYWNrLlMJMjAxMS0wMy0yOSAyMDowNjoy
MS4yNTIxMTIwMjQgKzAzMDAKQEAgLTkwLDYgKzkwLDE2IEBAIEwoYmtfd3JpdGUpOgogCiAJQUxJ
R04gKDQpCiBMKDE0NGJ5dGVzb3Jtb3JlKToKKyNpZm5kZWYgVVNFX0FTX01FTU1PVkUKKwlsZWEJ
KCVyc2ksJXJkeCksJXI5CisJbGVhCSglcmRpLCVyZHgpLCVyMTEKKwljbXAJJXJkaSwlcjkJCS8q
IGRlc3Qgc3RhcnQgPj0gc291cmNlIGVuZCAqLworCWphZQlMKG5vbm92ZXJsYXApCQkvKiAgLT4g
bm9ub3ZlcmxhcHBpbmcgKi8KKwljbXAJJXJzaSwlcjExCQkvKiBzb3VyY2Ugc3RhcnQgPj0gZGVz
dGluYXRpb24gZW5kICovCisJamFlCUwobm9ub3ZlcmxhcCkJCS8qICAtPiBub25vdmVybGFwcGlu
ZyAqLworCW1vdmIJJDAsIDAKKwlMKG5vbm92ZXJsYXApOgorI2VuZGlmCiAKICNpZm5kZWYgVVNF
X0FTX01FTU1PVkUKIAljbXAJJWRpbCwgJXNpbAo=
56602011-04-10 15:49:59 +00002011-04-10 15:49:59 +0000Patch to check for overlaps0001-memcpy-overlap-test.patchtext/plain577felipe.contrerasRnJvbSAzZDE4OTVlMTcxMzZiNGE1NjVmZmVmZDM3YzAyYTE1OTY2NDAxN2VkIE1vbiBTZXAgMTcg
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==