Mailing List Archive

Olivier Galibert wrote:
> On Wed, Mar 05, 2008 at 10:43:33PM +0100, Michael Matz wrote:
>> FWIW I don't think it's a release blocker for 4.3.0. The error is arcane
>> and happens seldomly if at all. And only on unfixed kernels. A program
>> needs to do std explicitely, which most don't do _and_ get hit by a signal
>> while begin in a std region. This happens so seldom that it didn't occur
>> in building the next openSuSE 11.0, and it continually builds packages
>> with 4.3 since months.
>
> How would you know whether it has happened?
>

The same way you do with other bugs: You would observe unexpected behavior.

In this case probably either corrupted memory or a SIGSEGV.

David Daney
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

>>> Richard Guenther wrote:
>>>> We didn't yet run into this issue and build openSUSE with 4.3
>>>> since more
>>>> than
>>>> three month.
>>>
>>> Well, how often do you take a trap inside an overlapping memmove()?
>>
>> How hard is it to change the kernel signal entry path from "pushf" to
>> "pushf;cld"? Problem solved, no?
>
> The problem is with old kernels, which by definition stay unfixed.

My impression was that the problem occurs in GCC compiled code in the
kernel itself, not in user space:

1. User space has direction flag set.
2. signal occurs
3. kernel code is entered
4. kernel code does string operation <boom>

Fixing this instance of the problem by changing GCC requires (at
least) recompiling the kernel.

Changing the ABI for this seems like a pretty crazy solution to a very
minor and easily fixable kernel bug. Distros have control over what
kernels they ship, they have absolute power to ensure this doesn't
affect their users when running default kernels - without changing the
compiler.

-Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Chris Lattner wrote:
>>>> Richard Guenther wrote:
>>>>> We didn't yet run into this issue and build openSUSE with 4.3 since
>>>>> more
>>>>> than
>>>>> three month.
>>>>
>>>> Well, how often do you take a trap inside an overlapping memmove()?
>>>
>>> How hard is it to change the kernel signal entry path from "pushf" to
>>> "pushf;cld"? Problem solved, no?
>>
>> The problem is with old kernels, which by definition stay unfixed.
>
> My impression was that the problem occurs in GCC compiled code in the
> kernel itself, not in user space:

That's wrong.

The issue is that the kernel is entered (due to a trap, interrupt or
whatever) and the state is saved. The kernel decides to revector
userspace to a signal handler. The kernel modifies the userspace state
to do so, but doesn't set DF=0.

Upon return to userspace, the modified state kicks in. Thus the signal
handler is entered with DF from userspace at trap time, not DF=0.

So it's an asynchronous state leak from one piece of userspace to another.

-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Chris Lattner a écrit :
>>>> Richard Guenther wrote:
>>>>> We didn't yet run into this issue and build openSUSE with 4.3 since
>>>>> more
>>>>> than
>>>>> three month.
>>>>
>>>> Well, how often do you take a trap inside an overlapping memmove()?
>>>
>>> How hard is it to change the kernel signal entry path from "pushf" to
>>> "pushf;cld"? Problem solved, no?
>>
>> The problem is with old kernels, which by definition stay unfixed.
>
> My impression was that the problem occurs in GCC compiled code in the
> kernel itself, not in user space:
>
> 1. User space has direction flag set.
> 2. signal occurs
> 3. kernel code is entered
> 4. kernel code does string operation <boom>

Wrong. Except maybe for the Hurd kernel. For other kernels:

4. signal handler is called
5. signal handler does string operation <boom>

The GCC used to compile the kernel doesn't matter. Using gcc 4.3 to
compile the user code triggers the bug.

--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' aurel32@debian.org | aurelien@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Chris Lattner wrote:
>>
>> Upon return to userspace, the modified state kicks in. Thus the
>> signal handler is entered with DF from userspace at trap time, not DF=0.
>>
>> So it's an asynchronous state leak from one piece of userspace to
>> another.
>
> Fine, it can happen either way. In either case, the distro vendor
> should fix the the signal handler in the kernels they distribute. If
> you don't do that, you are still leaking information from one piece of
> user space code to another, you're just papering over it in a horrible
> way :)
>
> GCC defines the direction flag to be clear before inline asm. Enforcing
> the semantics you propose would require issuing a cld before every
> inline asm, not just before every string operation.
>

It's a kernel bug, and it needs to be fixed. The discussion is about
what to do in the meantime.

(And yes, you're absolutely right: between global subroutine entry and
the first asm or string operation, you'd have to emit cld.)

-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

"H. Peter Anvin" <hpa@zytor.com> writes:

> Not quite, but fixing it in the kernel is easy.
>
> Still breaks for running on all old kernels.

Many more things break on old kernels. I guess it's not worse than
a (local) root exploit, is it?

*-stable and distributions should take care of it, as they do in
others cases.
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

"H. Peter Anvin" <hpa@zytor.com> writes:

> Richard Guenther wrote:
> > We didn't yet run into this issue and build openSUSE with 4.3 since
> > more than
> > three month.
> >
>
> Well, how often do you take a trap inside an overlapping memmove()?

That was the state with older gcc, but with newer gcc it does not necessarily
reset the flag before the next function call.

so e.g. if you have

memmove(...)
for (... very long loop .... ) {
/* no function calls */
/* signals happen */
}

the signal could see the direction flag

-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Thu, Mar 06, 2008 at 09:44:05AM +0100, Andi Kleen wrote:
> "H. Peter Anvin" <hpa@zytor.com> writes:
>
> > Richard Guenther wrote:
> > > We didn't yet run into this issue and build openSUSE with 4.3 since
> > > more than
> > > three month.
> > >
> >
> > Well, how often do you take a trap inside an overlapping memmove()?
>
> That was the state with older gcc, but with newer gcc it does not necessarily
> reset the flag before the next function call.
>
> so e.g. if you have
>
> memmove(...)
> for (... very long loop .... ) {
> /* no function calls */
> /* signals happen */
> }
>
> the signal could see the direction flag

memmove is supposed to (and does) do a cld insn after it finishes the
backward copying.

Jakub
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Wed, Mar 05, 2008 at 05:12:07PM -0800, H. Peter Anvin wrote:
> It's a kernel bug, and it needs to be fixed. The discussion is about
> what to do in the meantime.

While it is known that 32-bit glibc memmove and also <string.h> inlines
for memmove and memrchr use std; some string op; cld;, 64-bit glibc doesn't
ever use std instruction. gcc itself never generates std instruction.

So, I've disassebled the whole Fedora/x86_64 distro (64-bit binaries/shared
libraries/archives/object files, unpacked over 12000 rpms) to see how common
is std insn in 64-bit code. The only positive hits were the kernel
(/boot/xen-syms-2.6.21.7-2897.fc9 in particular, whatever that is) and
libpolyml.so.1.0.0 (polyml-libs - this one has handwritten assembly in
NASM), though I had to skim through some false positives (0xfd byte
appearing in data within code sections, but it is easy to see if 0xfd
is surrounded by invalid or nonsensical instructions that it is actually
data). The conclusion is that DF=1 in x86_64 64-bit code is extremely rare.

Therefore, if we decide to apply a workaround for the kernel bug in gcc
(I'm not convinced we should), it should be IMNSHO limited to 32-bit code.

Jakub
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Wed, Mar 05, 2008 at 05:12:07PM -0800, H. Peter Anvin wrote:
> It's a kernel bug, and it needs to be fixed.

I'm not convinced. It's been that way for 15 years, it's that way in
the BSD kernels, at that point it's a feature. The bug is in the
documentation, nowhere else. And in gcc for blindly trusting the
documentation.

OG.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Olivier Galibert wrote:
> On Wed, Mar 05, 2008 at 05:12:07PM -0800, H. Peter Anvin wrote:
>> It's a kernel bug, and it needs to be fixed.
>
> I'm not convinced. It's been that way for 15 years, it's that way in
> the BSD kernels, at that point it's a feature. The bug is in the
> documentation, nowhere else. And in gcc for blindly trusting the
> documentation.

No, the bug *in the kernel* was already present (if you had a signal
raised during a call to memmove). It's just more visible with GCC 4.3.

Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Olivier Galibert wrote:
> On Wed, Mar 05, 2008 at 05:12:07PM -0800, H. Peter Anvin wrote:
>> It's a kernel bug, and it needs to be fixed.
>
> I'm not convinced. It's been that way for 15 years, it's that way in
> the BSD kernels, at that point it's a feature. The bug is in the
> documentation, nowhere else. And in gcc for blindly trusting the
> documentation.

No, the bug *in the kernel* was already present (if you had a signal
raised during a call to memmove). It's just more visible with GCC 4.3.

Paolo

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Wed, Mar 05, 2008 at 03:21:43PM -0800, David Daney wrote:
> Olivier Galibert wrote:
> >On Wed, Mar 05, 2008 at 10:43:33PM +0100, Michael Matz wrote:
> >>FWIW I don't think it's a release blocker for 4.3.0. The error is arcane
> >>and happens seldomly if at all. And only on unfixed kernels. A program
> >>needs to do std explicitely, which most don't do _and_ get hit by a
> >>signal while begin in a std region. This happens so seldom that it
> >>didn't occur in building the next openSuSE 11.0, and it continually
> >>builds packages with 4.3 since months.
> >
> >How would you know whether it has happened?
> >
>
> The same way you do with other bugs: You would observe unexpected behavior.
>
> In this case probably either corrupted memory or a SIGSEGV.

So that probably means the programs you use for compiling packages
probably aren't hit. Doesn't mean the packages you've compiled with
it aren't hit. Compiling packages doesn't test what's in them at all.

It's extremely rare, no doubt about it. It's just that it *yells*
security issue in the making. It's not a source bug, i.e. not easily
reviewable. It's related to signal handlers which are the mark of a
server and/or more failure-conscious program than usual. It's obscure
(breaking a stringop, probably memset, or a not-paranoid-enough inline
asm in a signal handler through a running memmove in the main program,
oh my) but reasonably predictable for someone looking for an
exploitable flaw.

It's gcc's job to adapt to the realities of its running environment,
not the other way around.

OG.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Thu, Mar 06, 2008 at 03:03:15PM +0100, Paolo Bonzini wrote:
> Olivier Galibert wrote:
> >On Wed, Mar 05, 2008 at 05:12:07PM -0800, H. Peter Anvin wrote:
> >>It's a kernel bug, and it needs to be fixed.
> >
> >I'm not convinced. It's been that way for 15 years, it's that way in
> >the BSD kernels, at that point it's a feature. The bug is in the
> >documentation, nowhere else. And in gcc for blindly trusting the
> >documentation.
>
> No, the bug *in the kernel* was already present (if you had a signal
> raised during a call to memmove). It's just more visible with GCC 4.3.

I'm curious, since when paper documentation became the Truth and
reality became a bug?

OG.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Olivier Galibert wrote:
> On Thu, Mar 06, 2008 at 03:03:15PM +0100, Paolo Bonzini wrote:
>> Olivier Galibert wrote:
>>> On Wed, Mar 05, 2008 at 05:12:07PM -0800, H. Peter Anvin wrote:
>>>> It's a kernel bug, and it needs to be fixed.
>>> I'm not convinced. It's been that way for 15 years, it's that way in
>>> the BSD kernels, at that point it's a feature. The bug is in the
>>> documentation, nowhere else. And in gcc for blindly trusting the
>>> documentation.
>> No, the bug *in the kernel* was already present (if you had a signal
>> raised during a call to memmove). It's just more visible with GCC 4.3.
>
> I'm curious, since when paper documentation became the Truth and
> reality became a bug?

Isn't that the definition of a bug? That a program does not meet
its specification?

Andrew.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Olivier Galibert wrote:
> On Wed, Mar 05, 2008 at 05:12:07PM -0800, H. Peter Anvin wrote:
>> It's a kernel bug, and it needs to be fixed.
>
> I'm not convinced. It's been that way for 15 years, it's that way in
> the BSD kernels, at that point it's a feature. The bug is in the
> documentation, nowhere else. And in gcc for blindly trusting the
> documentation.

I agree, it reminds me of Burroughs on the 5500 believing the
Fortran standard which carefully allowed for a stack based
implementation of Fortran, Algol-style, unfortunately no real
Fortran programs worked with this semantics, and it was one of
the factors contributing the demise of the 5500.
>
> OG.
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Jakub Jelinek wrote:
> On Thu, Mar 06, 2008 at 09:44:05AM +0100, Andi Kleen wrote:
>> "H. Peter Anvin" <hpa@zytor.com> writes:
>>
>>> Richard Guenther wrote:
>>>> We didn't yet run into this issue and build openSUSE with 4.3 since
>>>> more than
>>>> three month.
>>>>
>>> Well, how often do you take a trap inside an overlapping memmove()?
>> That was the state with older gcc, but with newer gcc it does not necessarily
>> reset the flag before the next function call.

If so, that's a much worse bug.

>> so e.g. if you have
>>
>> memmove(...)
>> for (... very long loop .... ) {
>> /* no function calls */
>> /* signals happen */
>> }
>>
>> the signal could see the direction flag
>
> memmove is supposed to (and does) do a cld insn after it finishes the
> backward copying.

You can still take a signal inside memmove() itself, of course.

-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On 3/6/08, Olivier Galibert <galibert@pobox.com> wrote:
> On Wed, Mar 05, 2008 at 05:12:07PM -0800, H. Peter Anvin wrote:
> > It's a kernel bug, and it needs to be fixed.
>
> I'm not convinced. It's been that way for 15 years, it's that way in
> the BSD kernels, at that point it's a feature. The bug is in the
> documentation, nowhere else. And in gcc for blindly trusting the
> documentation.

The issue should not be evaluated as: "It's always been that way,
therefore, it's right." Instead, it should be: "What's the right way
to do it?"

You don't just change documentation because no existing code meets the
requirement -- UNLESS -- the non-conforming code is actually the right
way to do things.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

I agree with it. There is no right or wrong here Let's start from
scratch and figure out
what is the best way to handle this, assuming we are defining a new psABI.

H.J.
On Thu, Mar 6, 2008 at 7:37 AM, NightStrike <nightstrike@gmail.com> wrote:
>
> On 3/6/08, Olivier Galibert <galibert@pobox.com> wrote:
> > On Wed, Mar 05, 2008 at 05:12:07PM -0800, H. Peter Anvin wrote:
> > > It's a kernel bug, and it needs to be fixed.
> >
> > I'm not convinced. It's been that way for 15 years, it's that way in
> > the BSD kernels, at that point it's a feature. The bug is in the
> > documentation, nowhere else. And in gcc for blindly trusting the
> > documentation.
>
> The issue should not be evaluated as: "It's always been that way,
> therefore, it's right." Instead, it should be: "What's the right way
> to do it?"
>
> You don't just change documentation because no existing code meets the
> requirement -- UNLESS -- the non-conforming code is actually the right
> way to do things.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

H.J. Lu wrote:
> I agree with it. There is no right or wrong here Let's start from
> scratch and figure out
> what is the best way to handle this, assuming we are defining a new psABI.

No, I believe the right way to approach this is by applying the good
old-fashioned principle from Ask Mr. Protocol:

Be liberal in what you receive, conservative in what you send

In other words:

a. Fix the kernel. Already in progress.
b. Do *not* make gcc assume DF is clean for now. Adding a
switch would be a useful thing, since if nothing else it
would benefit embedded environments. We might assume
DF is clean on 64 bits, since it appears it is rarely used
anyway, and 64 bits is more important in the long run.
c. Once fixed kernels have been out long enough, we can
flip the default of the switch, one platform at a time if
need be (e.g. there may never be another SCO OpenServer.)

-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

NightStrike wrote:
> On 3/6/08, Olivier Galibert <galibert@pobox.com> wrote:
>> On Wed, Mar 05, 2008 at 05:12:07PM -0800, H. Peter Anvin wrote:
>>> It's a kernel bug, and it needs to be fixed.
>> I'm not convinced. It's been that way for 15 years, it's that way in
>> the BSD kernels, at that point it's a feature. The bug is in the
>> documentation, nowhere else. And in gcc for blindly trusting the
>> documentation.
>
> The issue should not be evaluated as: "It's always been that way,
> therefore, it's right." Instead, it should be: "What's the right way
> to do it?"
>
> You don't just change documentation because no existing code meets the
> requirement -- UNLESS -- the non-conforming code is actually the right
> way to do things.

Sounds good, but has almost nothing to do with the real world. I
remember back in Realia COBOL days, we had to carefully copy IBM
bugs in the IBM mainframe COBOL compiler. Doing things right and
fixing the bug would have been the right thing to do, but no one
would have used Realia COBOL :-)

Another story, the sad story of the intel chip (I think it was
the 80188) where Intel made use of Int 5, which was documented
as reserved. Unfortunately, Microsoft/IBM had used this for
print screen or some such. Intel was absolutely right that
their documentation was clear and it was wrong to have used
these interrupts .. but the result was a warehouse of unused
chips.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Olivier Galibert wrote:
> On Wed, Mar 05, 2008 at 05:12:07PM -0800, H. Peter Anvin wrote:
>> It's a kernel bug, and it needs to be fixed.
>
> I'm not convinced. It's been that way for 15 years, it's that way in
> the BSD kernels, at that point it's a feature. The bug is in the
> documentation, nowhere else. And in gcc for blindly trusting the
> documentation.

well, you could see this either way -- either the kernel is buggy and
needs to be fixed or the current behavior is correct and the abi needs
an errata. If there were no performance implications i'd go for the
latter, mostly because of the security aspect.
But this thread made me dig up an old benchmark and apparently omitting
the cld before the string ops makes a significant difference; on P2 it
was ~8%, on P4 it's ~6% for 1480 byte copies; for 32 byte ones the gain
is more like 90% on a P4 [1].

So the impact on small structure memcpy/memset etc is significant, hence
fixing the kernel looks like a better long term plan.

artur

[1]
P4 # ./bcsp m
IACCK 0.9.29 Artur Skawina <...>
[ exec time; lower is better ] [speed ] [ time ] [ok?]
TIME-N+S TIME32 TIME33 TIME1480 MBYTES/S TIMEXXXX CSUM FUNCTION ( rdtsc_overhead=0 null=0 )
0 0 0 0 inf 0 ffff csum_partial_copy_null
1885 375 389 156 7589.74 39350 0 generic_memcpy
10894 532 666 1696 698.11 108557 0 kernel_memcpylib
1804 325 346 151 7841.06 19614 0 kernel_memcpy686
1804 325 346 151 7841.06 19693 0 kernel_memcpy686ncld
1744 323 381 148 8000.00 19687 0 kernel_memcpy686as1
1332 157 232 139 8517.99 19235 0 kernel_memcpy686as1ncld
1782 318 339 148 8000.00 19607 0 kernel_memcpy686as2
1371 168 189 139 8517.99 19221 0 kernel_memcpy686as2ncld

P2 # ./bcsp m
IACKK 0.9.28 Artur Skawina <...>
TIME-N+S TIME32 TIME33 TIME1480 MBYTES/S TIMEXXXX CKSUM FUNCTION ( rdtsc_overhead=1 null=0 )
0 0 0 0 inf 0 : ffff csum_partial_copy_null
7121 746 1215 730 1621.92 127418 : 0 generic_memcpy
43604 2032 1709 6574 180.10 416409 : 0 kernel_memcpylib
7480 771 726 684 1730.99 96084 : 0 kernel_memcpy686
7036 735 543 685 1728.47 95508 : 0 kernel_memcpy686ncld
7498 1015 711 716 1653.63 92200 : 0 kernel_memcpy686as1
5826 438 489 662 1788.52 91598 : 0 kernel_memcpy686as1ncld
6667 657 488 708 1672.32 89366 : 0 kernel_memcpy686as2
6614 456 270 658 1799.39 91203 : 0 kernel_memcpy686as2ncld

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Thu, Mar 06, 2008 at 07:50:12AM -0800, H. Peter Anvin wrote:
> H.J. Lu wrote:
> >I agree with it. There is no right or wrong here Let's start from
> >scratch and figure out
> >what is the best way to handle this, assuming we are defining a new psABI.

BTW, just tested icc and icc doesn't generate cld either (so it matches the
new gcc behavior).
char buf1[32], buf2[32];
void bar (void);
void foo (void)
{
__builtin_memset (buf1, 0, 32);
bar ();
__builtin_memset (buf2, 0, 32);
}

Jakub
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Hi,

On Thu, Mar 6, 2008 at 6:23 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Thu, Mar 06, 2008 at 07:50:12AM -0800, H. Peter Anvin wrote:
> > H.J. Lu wrote:
> > >I agree with it. There is no right or wrong here Let's start from
> > >scratch and figure out
> > >what is the best way to handle this, assuming we are defining a new psABI.
>
> BTW, just tested icc and icc doesn't generate cld either (so it matches the
> new gcc behavior).
> char buf1[32], buf2[32];
> void bar (void);
> void foo (void)
> {
> __builtin_memset (buf1, 0, 32);
> bar ();
> __builtin_memset (buf2, 0, 32);
> }

Also LKML discussion pointed out that Solaris gets this right too.

Regards,
ismail

--
Never learn by your mistakes, if you do you may never dare to try again.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

> Another story, the sad story of the intel chip (I think it was
> the 80188) where Intel made use of Int 5, which was documented
> as reserved. Unfortunately, Microsoft/IBM had used this for
> print screen or some such. Intel was absolutely right that
> their documentation was clear and it was wrong to have used
> these interrupts .. but the result was a warehouse of unused
> chips.

Not really. Just, no one used the BOUND instruction. All computers
running DOS (Intel, AMD, even the old NEC V20/V30 chips) still connect
INT 5 to Print Screen.

Paolo

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/