Debian Bug report logs - #469058
Linux doesn't follow x86/x86-64 ABI wrt direction flag

version graph

Package: linux-2.6; Maintainer for linux-2.6 is Debian Kernel Team <debian-kernel@lists.debian.org>;

Reported by: aurel32@debian.org

Date: Sun, 2 Mar 2008 20:06:02 UTC

Severity: critical

Tags: patch

Merged with 469015, 471147, 471598

Found in version 2.6.18.dfsg.1-10

Fixed in versions linux-2.6/2.6.18.dfsg.1-19, linux-2.6/2.6.24-5

Done: dann frazier <dannf@debian.org>

Bug is archived. No further changes may be made.

Forwarded to http://lkml.org/lkml/2008/3/5/207

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#469058; Package libc6. Full text and rfc822 format available.

Acknowledgement sent to Rupert Swarbrick <rswarbrick@googlemail.com>:
New Bug report received and forwarded. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Rupert Swarbrick <rswarbrick@googlemail.com>
To: submit@bugs.debian.org
Subject: libc6: New version of libc6 hangs SBCL
Date: Sun, 02 Mar 2008 20:04:46 +0000
Subject: libc6: New version of libc6 hangs SBCL
Package: libc6
Version: 2.7-9
Severity: critical
Justification: breaks unrelated software

*** Please type your report below this line ***

After upgrading to 2.7-9 of libc6 in unstable, SBCL became extremely
prone to crashing 
randomly (i.e. 5-10 source files compiled of the SBCL CVS code before a
100% CPU hang which 
was only killable with -s 9.

The issue was originally raised on the SBCL devel list here:

http://thread.gmane.org/gmane.lisp.steel-bank.devel/10902/focus=10905

I upgraded the system from libc6 2.7-8, which seems to have caused the
problem. Downgrading 
libc6 to the package in testing (libc 2.7-6) fixes it again: I've since
compiled sbcl from 
CVS twice to make sure.


Rupert Swarbrick


P.S. The System Information below was generated with reportbug and I've
currently got 2.7-6 
installed. libgcc1 doesn't seem to have been up/down-graded, though, so
I think the below is 
mostly true except for the "testing" bits, since all other libraries are
at the current 
versions in unstable.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages libc6 depends on:
ii  libgcc1                 1:4.3-20080227-1 GCC support library

libc6 recommends no packages.

-- debconf information excluded






Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#469058; Package libc6. Full text and rfc822 format available.

Acknowledgement sent to Aurelien Jarno <aurelien@aurel32.net>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. Full text and rfc822 format available.

Message #10 received at 469058@bugs.debian.org (full text, mbox):

From: Aurelien Jarno <aurelien@aurel32.net>
To: Rupert Swarbrick <rswarbrick@googlemail.com>, 469058@bugs.debian.org
Subject: Re: Bug#469058: libc6: New version of libc6 hangs SBCL
Date: Sun, 02 Mar 2008 22:58:23 +0100
Rupert Swarbrick a écrit :
> Subject: libc6: New version of libc6 hangs SBCL
> Package: libc6
> Version: 2.7-9
> Severity: critical
> Justification: breaks unrelated software
> 
> *** Please type your report below this line ***
> 
> After upgrading to 2.7-9 of libc6 in unstable, SBCL became extremely
> prone to crashing 
> randomly (i.e. 5-10 source files compiled of the SBCL CVS code before a
> 100% CPU hang which 
> was only killable with -s 9.

Could you please give a way to reproduce the bug? I know nothing about 
SBCL, so a list of commands to execute or a shell script would be nice.

> The issue was originally raised on the SBCL devel list here:
> 
> http://thread.gmane.org/gmane.lisp.steel-bank.devel/10902/focus=10905
> 
> I upgraded the system from libc6 2.7-8, which seems to have caused the
> problem. Downgrading 
> libc6 to the package in testing (libc 2.7-6) fixes it again: I've since
> compiled sbcl from 
> CVS twice to make sure.

Could you please try to narrow the problem to a single libc6 version? 
Older versions are available on snapshot.debian.net.

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net




Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#469058; Package libc6. Full text and rfc822 format available.

Acknowledgement sent to Rupert Swarbrick <rswarbrick@googlemail.com>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. Full text and rfc822 format available.

Message #15 received at 469058@bugs.debian.org (full text, mbox):

From: Rupert Swarbrick <rswarbrick@googlemail.com>
To: Aurelien Jarno <aurelien@aurel32.net>
Cc: Rupert Swarbrick <rswarbrick@googlemail.com>, 469058@bugs.debian.org
Subject: Re: Bug#469058: libc6: New version of libc6 hangs SBCL
Date: Sun, 02 Mar 2008 22:13:30 +0000
[Message part 1 (text/plain, inline)]
> > After upgrading to 2.7-9 of libc6 in unstable, SBCL became extremely
> > prone to crashing 
> > randomly (i.e. 5-10 source files compiled of the SBCL CVS code before a
> > 100% CPU hang which 
> > was only killable with -s 9.
> 
> Could you please give a way to reproduce the bug? I know nothing about 
> SBCL, so a list of commands to execute or a shell script would be nice.

Of course, sorry. Probably the easiest option is to get sbcl and darcs
(the version control system). It doesn't appear to matter which version
of sbcl - I've had the problem with 1.0.12 up to 1.0.14.

Then get clbuild (which is a little shell script which can among other
things get and build a new copy of sbcl, which is a project large enough
to guarantee the hang on my computer at least) using

darcs get http://common-lisp.net/project/clbuild/clbuild

Chmod +x the clbuild script inside the folder and cd inside and run

./clbuild buildsbcl

Hopefully (!) your system should hang at 100% CPU with the sbcl process
ignoring SIGTERM. Sorry about the involved duplication process - it's
just that you need to compile quite a bit of code before the seemingly
"random" bug strikes.

> Could you please try to narrow the problem to a single libc6 version? 
> Older versions are available on snapshot.debian.net.
> 

Could you let me know a way to convince dpkg to let me do that? Since
you have to up/downgrade a dependent package at the same time, and I'm a
bit scared of using --force-all on libc6 on my only computer! (Or am I
being needlessly cautious?)

Incidentally, as someone pointed out in the sbcl thread I linked to,
it's quite possible that your change in libc6 has thrown up a bug in
sbcl rather than the other way round - we're trying (and failing) to get
strace,gdb to tell us something useful about where sbcl died. However,
I'd be extremely grateful if you could suggest what change you think is
likely to be able to cause this sort of symptom - and I stand by my
categorization: the change definitely breaks an unrelated package :P

Thanks for the really prompt response!

Rupert
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#469058; Package libc6. Full text and rfc822 format available.

Acknowledgement sent to "Liam Healy" <lnp@healy.washington.dc.us>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. Full text and rfc822 format available.

Message #20 received at 469058@bugs.debian.org (full text, mbox):

From: "Liam Healy" <lnp@healy.washington.dc.us>
To: 469058@bugs.debian.org
Subject: libc6 version
Date: Sun, 2 Mar 2008 17:15:06 -0500
The problem started for me when this upgrade happened:
[UPGRADE] libc6 2.7-8 -> 2.7-9
[UPGRADE] libc6-dev 2.7-8 -> 2.7-9
and was not happening before.  Thus it is the changes in going to
2.7-9 from 2.7-8 that reveal this problem.

Liam




Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#469058; Package libc6. Full text and rfc822 format available.

Acknowledgement sent to Aurelien Jarno <aurelien@aurel32.net>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. Full text and rfc822 format available.

Message #25 received at 469058@bugs.debian.org (full text, mbox):

From: Aurelien Jarno <aurelien@aurel32.net>
To: Rupert Swarbrick <rswarbrick@googlemail.com>, 469058@bugs.debian.org
Subject: Re: Bug#469058: libc6: New version of libc6 hangs SBCL
Date: Mon, 03 Mar 2008 00:01:47 +0100
Rupert Swarbrick a écrit :
>>> After upgrading to 2.7-9 of libc6 in unstable, SBCL became extremely
>>> prone to crashing 
>>> randomly (i.e. 5-10 source files compiled of the SBCL CVS code before a
>>> 100% CPU hang which 
>>> was only killable with -s 9.
>> Could you please give a way to reproduce the bug? I know nothing about 
>> SBCL, so a list of commands to execute or a shell script would be nice.
> 
> Of course, sorry. Probably the easiest option is to get sbcl and darcs
> (the version control system). It doesn't appear to matter which version
> of sbcl - I've had the problem with 1.0.12 up to 1.0.14.
> 
> Then get clbuild (which is a little shell script which can among other
> things get and build a new copy of sbcl, which is a project large enough
> to guarantee the hang on my computer at least) using
> 
> darcs get http://common-lisp.net/project/clbuild/clbuild
> 
> Chmod +x the clbuild script inside the folder and cd inside and run
> 
> ./clbuild buildsbcl
> 
> Hopefully (!) your system should hang at 100% CPU with the sbcl process
> ignoring SIGTERM. Sorry about the involved duplication process - it's
> just that you need to compile quite a bit of code before the seemingly
> "random" bug strikes.

I am able to reproduce the bug, except that here the sbcl process hangs 
with 0% CPU.

>> Could you please try to narrow the problem to a single libc6 version? 
>> Older versions are available on snapshot.debian.net.
>>
> 
> Could you let me know a way to convince dpkg to let me do that? Since
> you have to up/downgrade a dependent package at the same time, and I'm a
> bit scared of using --force-all on libc6 on my only computer! (Or am I
> being needlessly cautious?)
> 

Theoretically if you upgrade/downgrade all libc6 related packages 
(libc6-dev, libc6-i686, ...) at the same time it should work.

Anyway now that I am able to reproduce the problem, I can do that myself.

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net




Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#469058; Package libc6. Full text and rfc822 format available.

Acknowledgement sent to Aurelien Jarno <aurelien@aurel32.net>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. Full text and rfc822 format available.

Message #30 received at 469058@bugs.debian.org (full text, mbox):

From: Aurelien Jarno <aurelien@aurel32.net>
To: Liam Healy <lnp@healy.washington.dc.us>, 469058@bugs.debian.org, Rupert Swarbrick <rswarbrick@googlemail.com>
Subject: Re: Bug#469058: libc6 version
Date: Mon, 03 Mar 2008 00:03:23 +0100
Liam Healy a écrit :
> The problem started for me when this upgrade happened:
> [UPGRADE] libc6 2.7-8 -> 2.7-9
> [UPGRADE] libc6-dev 2.7-8 -> 2.7-9
> and was not happening before.  Thus it is the changes in going to
> 2.7-9 from 2.7-8 that reveal this problem.

I get to the same conclusion. The only relevant change I could see 
between 2.7-8 and 2.7-9 is the switch to gcc-4.3 from gcc-4.2 to build 
the glibc. I will try to confirm this is the culprit.

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net




Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#469058; Package libc6. Full text and rfc822 format available.

Acknowledgement sent to Aurelien Jarno <aurelien@aurel32.net>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. Full text and rfc822 format available.

Message #35 received at 469058@bugs.debian.org (full text, mbox):

From: Aurelien Jarno <aurelien@aurel32.net>
To: 469058@bugs.debian.org
Cc: Liam Healy <lnp@healy.washington.dc.us>, Rupert Swarbrick <rswarbrick@googlemail.com>
Subject: Re: Bug#469058: libc6 version
Date: Mon, 03 Mar 2008 07:26:18 +0100
Aurelien Jarno a écrit :
> Liam Healy a écrit :
>> The problem started for me when this upgrade happened:
>> [UPGRADE] libc6 2.7-8 -> 2.7-9
>> [UPGRADE] libc6-dev 2.7-8 -> 2.7-9
>> and was not happening before.  Thus it is the changes in going to
>> 2.7-9 from 2.7-8 that reveal this problem.
> 
> I get to the same conclusion. The only relevant change I could see 
> between 2.7-8 and 2.7-9 is the switch to gcc-4.3 from gcc-4.2 to build 
> the glibc. I will try to confirm this is the culprit.
> 

I confirm that switch to gcc-4.3 from gcc-4.2 causes the problem. The 
next step, understandy why, won't be that easy.

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net




Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#469058; Package libc6. Full text and rfc822 format available.

Acknowledgement sent to "Nikodemus Siivola" <nikodemus@random-state.net>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. Full text and rfc822 format available.

Message #40 received at 469058@bugs.debian.org (full text, mbox):

From: "Nikodemus Siivola" <nikodemus@random-state.net>
To: 469058@bugs.debian.org, sbcl-devel <sbcl-devel@lists.sourceforge.net>
Subject: looking over GCC 4.3 release notes
Date: Tue, 4 Mar 2008 20:28:55 +0200
Looking at http://gcc.gnu.org/gcc-4.3/changes.html, this is the only
thing that really jumps out:

"GCC no longer places the cld instruction before string operations.
Both i386 and x86-64 ABI documents mandate the direction flag to be
clear at the entry of a function. It is now invalid to set the flag in
asm statement without reseting it afterward."

...but (1) SBCL _should_ be resetting the direction flag before any
calls to libc code, and (2) I would expect problems caused by this to
be more deterministic.

Cheers,

 -- Nikodemus




Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#469058; Package libc6. Full text and rfc822 format available.

Acknowledgement sent to Aurelien Jarno <aurelien@aurel32.net>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. Full text and rfc822 format available.

Message #45 received at 469058@bugs.debian.org (full text, mbox):

From: Aurelien Jarno <aurelien@aurel32.net>
To: Nikodemus Siivola <nikodemus@random-state.net>, 469058@bugs.debian.org
Cc: sbcl-devel <sbcl-devel@lists.sourceforge.net>
Subject: Re: Bug#469058: looking over GCC 4.3 release notes
Date: Tue, 04 Mar 2008 20:21:42 +0100
Nikodemus Siivola a écrit :
> Looking at http://gcc.gnu.org/gcc-4.3/changes.html, this is the only
> thing that really jumps out:
> 
> "GCC no longer places the cld instruction before string operations.
> Both i386 and x86-64 ABI documents mandate the direction flag to be
> clear at the entry of a function. It is now invalid to set the flag in
> asm statement without reseting it afterward."
> 
> ...but (1) SBCL _should_ be resetting the direction flag before any
> calls to libc code, and (2) I would expect problems caused by this to
> be more deterministic.
> 

On my side, I have made some progress. I have rebuilt a glibc with 
gcc-4.3 for all files except the signal/ directory, built with gcc-4.2 
instead. SBCL seems to work correctly in this case.


-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net




Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#469058; Package libc6. Full text and rfc822 format available.

Acknowledgement sent to Aurelien Jarno <aurelien@aurel32.net>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. Full text and rfc822 format available.

Message #50 received at 469058@bugs.debian.org (full text, mbox):

From: Aurelien Jarno <aurelien@aurel32.net>
To: Nikodemus Siivola <nikodemus@random-state.net>, 469058@bugs.debian.org
Cc: sbcl-devel <sbcl-devel@lists.sourceforge.net>, control@bugs.debian.org
Subject: Re: Bug#469058: looking over GCC 4.3 release notes
Date: Wed, 05 Mar 2008 03:12:52 +0100
reassign 469058 sbcl
retitle 469058 sbcl don't reset direction flag upon exit
thanks

Nikodemus Siivola a écrit :
> Looking at http://gcc.gnu.org/gcc-4.3/changes.html, this is the only
> thing that really jumps out:
> 
> "GCC no longer places the cld instruction before string operations.
> Both i386 and x86-64 ABI documents mandate the direction flag to be
> clear at the entry of a function. It is now invalid to set the flag in
> asm statement without reseting it afterward."
> 
> ...but (1) SBCL _should_ be resetting the direction flag before any
> calls to libc code, and (2) I would expect problems caused by this to
> be more deterministic.

It actually doesn't reset it. The problem causes the sigemptyset()
function from the glibc to not work correctly.

I have identified the potential part from SBCL causing the problem, I am
currently testing a fix.

Cheers,
Aurelien


-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net




Bug reassigned from package `libc6' to `sbcl'. Request was from Aurelien Jarno <aurelien@aurel32.net> to control@bugs.debian.org. (Wed, 05 Mar 2008 02:15:10 GMT) Full text and rfc822 format available.

Changed Bug title to `sbcl don't reset direction flag upon exit' from `libc6: New version of libc6 hangs SBCL'. Request was from Aurelien Jarno <aurelien@aurel32.net> to control@bugs.debian.org. (Wed, 05 Mar 2008 02:15:12 GMT) Full text and rfc822 format available.

Changed Bug title to `sbcl doesn't reset direction flag upon exit' from `sbcl don't reset direction flag upon exit'. Request was from Aurelien Jarno <aurel32@debian.org> to control@bugs.debian.org. (Wed, 05 Mar 2008 02:21:03 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Common Lisp Team <pkg-common-lisp-devel@lists.alioth.debian.org>:
Bug#469058; Package sbcl. Full text and rfc822 format available.

Acknowledgement sent to Aurelien Jarno <aurelien@aurel32.net>:
Extra info received and forwarded to list. Copy sent to Debian Common Lisp Team <pkg-common-lisp-devel@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #61 received at 469058@bugs.debian.org (full text, mbox):

From: Aurelien Jarno <aurelien@aurel32.net>
To: Nikodemus Siivola <nikodemus@random-state.net>, 469058@bugs.debian.org
Cc: sbcl-devel <sbcl-devel@lists.sourceforge.net>, control@bugs.debian.org
Subject: Re: Bug#469058: looking over GCC 4.3 release notes
Date: Wed, 5 Mar 2008 10:22:18 +0100
tag 469058 + patch
thanks

On Wed, Mar 05, 2008 at 03:12:52AM +0100, Aurelien Jarno wrote:
> reassign 469058 sbcl
> retitle 469058 sbcl don't reset direction flag upon exit
> thanks
> 
> Nikodemus Siivola a écrit :
> > Looking at http://gcc.gnu.org/gcc-4.3/changes.html, this is the only
> > thing that really jumps out:
> > 
> > "GCC no longer places the cld instruction before string operations.
> > Both i386 and x86-64 ABI documents mandate the direction flag to be
> > clear at the entry of a function. It is now invalid to set the flag in
> > asm statement without reseting it afterward."
> > 
> > ...but (1) SBCL _should_ be resetting the direction flag before any
> > calls to libc code, and (2) I would expect problems caused by this to
> > be more deterministic.
> 
> It actually doesn't reset it. The problem causes the sigemptyset()
> function from the glibc to not work correctly.
> 
> I have identified the potential part from SBCL causing the problem, I am
> currently testing a fix.
> 

Please find below the patch to fix the problem. I only tested on amd64,
but it should work the same way on i386.

--- sbcl-1.0.14.0.orig/src/compiler/x86/call.lisp
+++ sbcl-1.0.14.0/src/compiler/x86/call.lisp
@@ -364,7 +364,8 @@
       ;; Restore EDI, and reset the stack.
       (emit-label restore-edi)
       (loadw edi-tn ebx-tn (frame-word-offset 1))
-      (inst mov esp-tn ebx-tn))))
+      (inst mov esp-tn ebx-tn)
+      (inst cld))))
   (values))
 
 ;;;; unknown values receiving
@@ -1376,7 +1377,8 @@
        (inst sub ecx 1)
        (inst jmp :nz loop)
        ;; NIL out the last cons.
-       (storew nil-value dst 1 list-pointer-lowtag))
+       (storew nil-value dst 1 list-pointer-lowtag)
+       (inst cld))
       (emit-label done))))
 
 ;;; Return the location and size of the &MORE arg glob created by
--- sbcl-1.0.14.0.orig/src/compiler/x86/values.lisp
+++ sbcl-1.0.14.0/src/compiler/x86/values.lisp
@@ -38,6 +38,7 @@
     (inst movs :dword)
     (inst cmp esp-tn esi)
     (inst jmp :be loop)
+    (inst cld)
     DONE
     (inst lea esp-tn (make-ea :dword :base edi :disp n-word-bytes))
     (inst sub edi esi)
--- sbcl-1.0.14.0.orig/src/compiler/x86/nlx.lisp
+++ sbcl-1.0.14.0/src/compiler/x86/nlx.lisp
@@ -237,6 +237,7 @@
     (inst std)
     (inst rep)
     (inst movs :dword)
+    (inst cld)
 
     DONE
     ;; Reset the CSP at last moved arg.
--- sbcl-1.0.14.0.orig/src/compiler/x86-64/call.lisp
+++ sbcl-1.0.14.0/src/compiler/x86-64/call.lisp
@@ -356,7 +356,8 @@
       ;; Restore EDI, and reset the stack.
       (emit-label restore-edi)
       (loadw rdi-tn rbx-tn (- (1+ 1)))
-      (inst mov rsp-tn rbx-tn))))
+      (inst mov rsp-tn rbx-tn)
+      (inst cld))))
   (values))
 
 ;;;; unknown values receiving
@@ -1320,7 +1321,8 @@
        (inst sub rcx 1)
        (inst jmp :nz loop)
        ;; NIL out the last cons.
-       (storew nil-value dst 1 list-pointer-lowtag))
+       (storew nil-value dst 1 list-pointer-lowtag)
+       (inst cld))
       (emit-label done))))
 
 ;;; Return the location and size of the &MORE arg glob created by
--- sbcl-1.0.14.0.orig/src/compiler/x86-64/values.lisp
+++ sbcl-1.0.14.0/src/compiler/x86-64/values.lisp
@@ -38,6 +38,7 @@
     (inst movs :qword)
     (inst cmp rsp-tn rsi)
     (inst jmp :be LOOP)
+    (inst cld)
     DONE
     (inst lea rsp-tn (make-ea :qword :base rdi :disp n-word-bytes))
     (inst sub rdi rsi)
--- sbcl-1.0.14.0.orig/src/compiler/x86-64/nlx.lisp
+++ sbcl-1.0.14.0/src/compiler/x86-64/nlx.lisp
@@ -212,6 +212,7 @@
     (inst std)
     (inst rep)
     (inst movs :qword)
+    (inst cld)
 
     DONE
     ;; Reset the CSP at last moved arg.
--- sbcl-1.0.14.0.orig/src/assembly/x86/assem-rtns.lisp
+++ sbcl-1.0.14.0/src/assembly/x86/assem-rtns.lisp
@@ -54,6 +54,7 @@
   (inst lea edi (make-ea :dword :base ebx :disp (- n-word-bytes)))
   (inst rep)
   (inst movs :dword)
+  (inst cld)                            ; restore direction bit
 
   ;; solaris requires DF being zero.
   #!+sunos (inst cld)
@@ -153,6 +154,7 @@
   (inst sub esi (fixnumize 1))
   (inst rep)
   (inst movs :dword)
+  (inst cld)                            ; restore direction bit
 
   ;; solaris requires DF being zero.
   #!+sunos (inst cld)
--- sbcl-1.0.14.0.orig/src/assembly/x86-64/assem-rtns.lisp
+++ sbcl-1.0.14.0/src/assembly/x86-64/assem-rtns.lisp
@@ -54,6 +54,7 @@
   (inst lea edi (make-ea :qword :base ebx :disp (- n-word-bytes)))
   (inst rep)
   (inst movs :qword)
+  (inst cld)                            ; restore direction bit
 
   ;; Restore the count.
   (inst mov ecx edx)
@@ -150,6 +151,7 @@
   (inst sub esi (fixnumize 1))
   (inst rep)
   (inst movs :qword)
+  (inst cld)                            ; restore direction bit
 
   ;; Load the register arguments carefully.
   (loadw edx rbp-tn -1)

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net




Tags added: patch Request was from Aurelien Jarno <aurelien@aurel32.net> to control@bugs.debian.org. (Wed, 05 Mar 2008 09:26:37 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Common Lisp Team <pkg-common-lisp-devel@lists.alioth.debian.org>:
Bug#469058; Package sbcl. Full text and rfc822 format available.

Acknowledgement sent to "Nikodemus Siivola" <nikodemus@random-state.net>:
Extra info received and forwarded to list. Copy sent to Debian Common Lisp Team <pkg-common-lisp-devel@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #68 received at 469058@bugs.debian.org (full text, mbox):

From: "Nikodemus Siivola" <nikodemus@random-state.net>
To: 469058@bugs.debian.org, sbcl-devel <sbcl-devel@lists.sourceforge.net>
Cc: "Aurelien Jarno" <aurelien@aurel32.net>, "Debian Common Lisp Team" <pkg-common-lisp-devel@lists.alioth.debian.org>
Subject: DF and signal handlers
Date: Wed, 5 Mar 2008 13:39:08 +0200
On 3/5/08, Debian Bug Tracking System <owner@bugs.debian.org> wrote:

> tag 469058 + patch
>  Bug#469058: sbcl doesn't reset direction flag upon exit
>  There were no tags set.
>  Tags added: patch

Thanks for the patch, but... while I agree that it is good to change
SBCL to reset the direction flag every time it is diddled, instead of
just before calling C, I don't think SBCL is actually at fault here.

 1. SBCL does actually reset DF before any call to foreign (GCC generated) code.
    See line 236 in src/compiler/x86/c-call.lisp, and line 125 in
    src/runtime/x86-assem.S.

    (It is possible I'm missing out a call-path here, but even so, read on and
    see if my fears are unfounded or not.)

 2. If the problem was due to a foreign call, it should be deterministic.

 3. If the problem was due to _returning_ to main(), it should be deterministic.

What I suspect is actually going on (especially considering your
statement that compiling signals/ with 4.2 avoided the issue) is that
a signal handler is entered while DF is set.

If this is the case, then clearing it right after each REP loop where
SBCL uses it just makes seeing the bug much more unlikely -- but not
impossible in the presence of async signals.

If so, this may also explain some _very_ hard to reproduce faults we
have seen over the years: using a pre 4.3-GCC compiled libc, a signal
at an in opportune moment in the middle of a REP loop could clear DF!
Yikes!

I'm not sure what is The Right Thing here, though. Should SBCL (and
_any_ program that ever sets DF!) save, clear, and restore DF in its
signal handlers? Should libc/kernel do that? Should signals be blocked
before ever setting DF? Is setting DF Just A Bad Idea?

Cheers,

 -- Nikodemus




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Common Lisp Team <pkg-common-lisp-devel@lists.alioth.debian.org>:
Bug#469058; Package sbcl. Full text and rfc822 format available.

Acknowledgement sent to Aurelien Jarno <aurelien@aurel32.net>:
Extra info received and forwarded to list. Copy sent to Debian Common Lisp Team <pkg-common-lisp-devel@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #73 received at 469058@bugs.debian.org (full text, mbox):

From: Aurelien Jarno <aurelien@aurel32.net>
To: Nikodemus Siivola <nikodemus@random-state.net>
Cc: 469058@bugs.debian.org, sbcl-devel <sbcl-devel@lists.sourceforge.net>, Debian Common Lisp Team <pkg-common-lisp-devel@lists.alioth.debian.org>
Subject: Re: DF and signal handlers
Date: Wed, 05 Mar 2008 14:33:08 +0100
Nikodemus Siivola a écrit :
> On 3/5/08, Debian Bug Tracking System <owner@bugs.debian.org> wrote:
> 
>> tag 469058 + patch
>>  Bug#469058: sbcl doesn't reset direction flag upon exit
>>  There were no tags set.
>>  Tags added: patch
> 
> Thanks for the patch, but... while I agree that it is good to change
> SBCL to reset the direction flag every time it is diddled, instead of
> just before calling C, I don't think SBCL is actually at fault here.
> 
>  1. SBCL does actually reset DF before any call to foreign (GCC generated) code.
>     See line 236 in src/compiler/x86/c-call.lisp, and line 125 in
>     src/runtime/x86-assem.S.
> 
>     (It is possible I'm missing out a call-path here, but even so, read on and
>     see if my fears are unfounded or not.)
> 
>  2. If the problem was due to a foreign call, it should be deterministic.
> 
>  3. If the problem was due to _returning_ to main(), it should be deterministic.

Looks correct.

> What I suspect is actually going on (especially considering your
> statement that compiling signals/ with 4.2 avoided the issue) is that
> a signal handler is entered while DF is set.

What I am sure is that sigemptyset() from the glibc is called with the
direction flag set, and that should not happen.

> If this is the case, then clearing it right after each REP loop where
> SBCL uses it just makes seeing the bug much more unlikely -- but not
> impossible in the presence of async signals.

Seems correct, though I have made half a dozen of build here, without
any problem.

> If so, this may also explain some _very_ hard to reproduce faults we
> have seen over the years: using a pre 4.3-GCC compiled libc, a signal
> at an in opportune moment in the middle of a REP loop could clear DF!
> Yikes!
> 
> I'm not sure what is The Right Thing here, though. Should SBCL (and
> _any_ program that ever sets DF!) save, clear, and restore DF in its
> signal handlers? Should libc/kernel do that? Should signals be blocked

I currently have no idea about that.

> before ever setting DF? Is setting DF Just A Bad Idea?

I don't think so. Not setting DF means less optimized code has to be used.

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Common Lisp Team <pkg-common-lisp-devel@lists.alioth.debian.org>:
Bug#469058; Package sbcl. Full text and rfc822 format available.

Acknowledgement sent to "Nikodemus Siivola" <nikodemus@random-state.net>:
Extra info received and forwarded to list. Copy sent to Debian Common Lisp Team <pkg-common-lisp-devel@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #78 received at 469058@bugs.debian.org (full text, mbox):

From: "Nikodemus Siivola" <nikodemus@random-state.net>
To: "Aurelien Jarno" <aurelien@aurel32.net>
Cc: 469058@bugs.debian.org, sbcl-devel <sbcl-devel@lists.sourceforge.net>, "Debian Common Lisp Team" <pkg-common-lisp-devel@lists.alioth.debian.org>
Subject: Re: DF and signal handlers
Date: Wed, 5 Mar 2008 15:48:05 +0200
On 3/5/08, Aurelien Jarno <aurelien@aurel32.net> wrote:
> Nikodemus Siivola a écrit :
>
> > On 3/5/08, Debian Bug Tracking System <owner@bugs.debian.org> wrote:
>  >
>  >> tag 469058 + patch
>  >>  Bug#469058: sbcl doesn't reset direction flag upon exit
>  >>  There were no tags set.
>  >>  Tags added: patch
>  >
>  > Thanks for the patch, but... while I agree that it is good to change
>  > SBCL to reset the direction flag every time it is diddled, instead of
>  > just before calling C, I don't think SBCL is actually at fault here.
>  >
>  >  1. SBCL does actually reset DF before any call to foreign (GCC generated) code.
>  >     See line 236 in src/compiler/x86/c-call.lisp, and line 125 in
>  >     src/runtime/x86-assem.S.
>  >
>  >     (It is possible I'm missing out a call-path here, but even so, read on and
>  >     see if my fears are unfounded or not.)
>  >
>  >  2. If the problem was due to a foreign call, it should be deterministic.
>  >
>  >  3. If the problem was due to _returning_ to main(), it should be deterministic.
>
>
> Looks correct.
>
>
>  > What I suspect is actually going on (especially considering your
>  > statement that compiling signals/ with 4.2 avoided the issue) is that
>  > a signal handler is entered while DF is set.
>
>
> What I am sure is that sigemptyset() from the glibc is called with the
> direction flag set, and that should not happen.

Right.

I'm about to merge a patch to SBCL based on yours, which moves all DF
resets to immediate vicinity of STDs for easier auditing, and removed
the then-unnecessary CLD instructions from foreign call sequences.
This will fix them symptoms, and be good for SBCL, but I think the
underlying problem is still there in signal handling. :/

>  > If this is the case, then clearing it right after each REP loop where
>  > SBCL uses it just makes seeing the bug much more unlikely -- but not
>  > impossible in the presence of async signals.
>
>
> Seems correct, though I have made half a dozen of build here, without
> any problem.

That is not too suprising: the are normally no asynch signals
delivered during the build, but SIGSEGV is a regular occurance (it is
used by the GC), so SIGSEGV handlers may have been seeing the DF set.

What _is_ strange is that this appears to have been random. (At least
all the reporters seemed to characterize it as semirandom behaviour.)
Multiple builds from the same source with the same host compiler
should have essentially identical GC characteristics.

>  > If so, this may also explain some _very_ hard to reproduce faults we
>  > have seen over the years: using a pre 4.3-GCC compiled libc, a signal
>  > at an in opportune moment in the middle of a REP loop could clear DF!
>  > Yikes!
>  >
>  > I'm not sure what is The Right Thing here, though. Should SBCL (and
>  > _any_ program that ever sets DF!) save, clear, and restore DF in its
>  > signal handlers? Should libc/kernel do that? Should signals be blocked
>
>
> I currently have no idea about that.

I'll see if I can cook up a small test-case using async signals. (One
that doesn't need SBCL so that it can be passed to upstream libc /
kernel people if necessary without too much friction.)

Cheers,

 -- Nikodemus

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Common Lisp Team <pkg-common-lisp-devel@lists.alioth.debian.org>:
Bug#469058; Package sbcl. Full text and rfc822 format available.

Acknowledgement sent to Aurelien Jarno <aurelien@aurel32.net>:
Extra info received and forwarded to list. Copy sent to Debian Common Lisp Team <pkg-common-lisp-devel@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #83 received at 469058@bugs.debian.org (full text, mbox):

From: Aurelien Jarno <aurelien@aurel32.net>
To: Nikodemus Siivola <nikodemus@random-state.net>
Cc: 469058@bugs.debian.org, sbcl-devel <sbcl-devel@lists.sourceforge.net>, Debian Common Lisp Team <pkg-common-lisp-devel@lists.alioth.debian.org>
Subject: Re: DF and signal handlers
Date: Wed, 05 Mar 2008 14:55:38 +0100
Nikodemus Siivola a écrit :
> On 3/5/08, Aurelien Jarno <aurelien@aurel32.net> wrote:
>> Nikodemus Siivola a écrit :
>>
>>> On 3/5/08, Debian Bug Tracking System <owner@bugs.debian.org> wrote:
>>  >
>>  >> tag 469058 + patch
>>  >>  Bug#469058: sbcl doesn't reset direction flag upon exit
>>  >>  There were no tags set.
>>  >>  Tags added: patch
>>  >
>>  > Thanks for the patch, but... while I agree that it is good to change
>>  > SBCL to reset the direction flag every time it is diddled, instead of
>>  > just before calling C, I don't think SBCL is actually at fault here.
>>  >
>>  >  1. SBCL does actually reset DF before any call to foreign (GCC generated) code.
>>  >     See line 236 in src/compiler/x86/c-call.lisp, and line 125 in
>>  >     src/runtime/x86-assem.S.
>>  >
>>  >     (It is possible I'm missing out a call-path here, but even so, read on and
>>  >     see if my fears are unfounded or not.)
>>  >
>>  >  2. If the problem was due to a foreign call, it should be deterministic.
>>  >
>>  >  3. If the problem was due to _returning_ to main(), it should be deterministic.
>>
>>
>> Looks correct.
>>
>>
>>  > What I suspect is actually going on (especially considering your
>>  > statement that compiling signals/ with 4.2 avoided the issue) is that
>>  > a signal handler is entered while DF is set.
>>
>>
>> What I am sure is that sigemptyset() from the glibc is called with the
>> direction flag set, and that should not happen.
> 
> Right.
> 
> I'm about to merge a patch to SBCL based on yours, which moves all DF
> resets to immediate vicinity of STDs for easier auditing, and removed
> the then-unnecessary CLD instructions from foreign call sequences.
> This will fix them symptoms, and be good for SBCL, but I think the
> underlying problem is still there in signal handling. :/
> 
>>  > If this is the case, then clearing it right after each REP loop where
>>  > SBCL uses it just makes seeing the bug much more unlikely -- but not
>>  > impossible in the presence of async signals.
>>
>>
>> Seems correct, though I have made half a dozen of build here, without
>> any problem.
> 
> That is not too suprising: the are normally no asynch signals
> delivered during the build, but SIGSEGV is a regular occurance (it is
> used by the GC), so SIGSEGV handlers may have been seeing the DF set.
> 
> What _is_ strange is that this appears to have been random. (At least
> all the reporters seemed to characterize it as semirandom behaviour.)
> Multiple builds from the same source with the same host compiler
> should have essentially identical GC characteristics.

Well it may depends on the kernel. On one machine, it was hanging
randomly. On another machine, I get an error from GC at the very
beginning of the build.

>>  > If so, this may also explain some _very_ hard to reproduce faults we
>>  > have seen over the years: using a pre 4.3-GCC compiled libc, a signal
>>  > at an in opportune moment in the middle of a REP loop could clear DF!
>>  > Yikes!
>>  >
>>  > I'm not sure what is The Right Thing here, though. Should SBCL (and
>>  > _any_ program that ever sets DF!) save, clear, and restore DF in its
>>  > signal handlers? Should libc/kernel do that? Should signals be blocked
>>
>>
>> I currently have no idea about that.
> 
> I'll see if I can cook up a small test-case using async signals. (One
> that doesn't need SBCL so that it can be passed to upstream libc /
> kernel people if necessary without too much friction.)
> 

GCC developer says it's the job of the kernel. I doubt the glibc can do
something here, that's the kernel which calls the signal handler.

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Common Lisp Team <pkg-common-lisp-devel@lists.alioth.debian.org>:
Bug#469058; Package sbcl. Full text and rfc822 format available.

Acknowledgement sent to Aurelien Jarno <aurelien@aurel32.net>:
Extra info received and forwarded to list. Copy sent to Debian Common Lisp Team <pkg-common-lisp-devel@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #88 received at 469058@bugs.debian.org (full text, mbox):

From: Aurelien Jarno <aurelien@aurel32.net>
To: Nikodemus Siivola <nikodemus@random-state.net>
Cc: 469058@bugs.debian.org, sbcl-devel <sbcl-devel@lists.sourceforge.net>, Debian Common Lisp Team <pkg-common-lisp-devel@lists.alioth.debian.org>
Subject: Re: DF and signal handlers
Date: Wed, 05 Mar 2008 15:07:02 +0100
Nikodemus Siivola a écrit :
> On 3/5/08, Debian Bug Tracking System <owner@bugs.debian.org> wrote:
> 
>> tag 469058 + patch
>>  Bug#469058: sbcl doesn't reset direction flag upon exit
>>  There were no tags set.
>>  Tags added: patch
> 
> Thanks for the patch, but... while I agree that it is good to change
> SBCL to reset the direction flag every time it is diddled, instead of
> just before calling C, I don't think SBCL is actually at fault here.
> 
>  1. SBCL does actually reset DF before any call to foreign (GCC generated) code.
>     See line 236 in src/compiler/x86/c-call.lisp, and line 125 in
>     src/runtime/x86-assem.S.
> 
>     (It is possible I'm missing out a call-path here, but even so, read on and
>     see if my fears are unfounded or not.)
> 
>  2. If the problem was due to a foreign call, it should be deterministic.
> 
>  3. If the problem was due to _returning_ to main(), it should be deterministic.
> 
> What I suspect is actually going on (especially considering your
> statement that compiling signals/ with 4.2 avoided the issue) is that
> a signal handler is entered while DF is set.
> 
> If this is the case, then clearing it right after each REP loop where
> SBCL uses it just makes seeing the bug much more unlikely -- but not
> impossible in the presence of async signals.
> 
> If so, this may also explain some _very_ hard to reproduce faults we
> have seen over the years: using a pre 4.3-GCC compiled libc, a signal
> at an in opportune moment in the middle of a REP loop could clear DF!
> Yikes!

I doubt this is related, as the flags register is saved by gcc upon
enter to the signal handler and restored upon exit.

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Common Lisp Team <pkg-common-lisp-devel@lists.alioth.debian.org>:
Bug#469058; Package sbcl. Full text and rfc822 format available.

Acknowledgement sent to Aurelien Jarno <aurelien@aurel32.net>:
Extra info received and forwarded to list. Copy sent to Debian Common Lisp Team <pkg-common-lisp-devel@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #93 received at 469058@bugs.debian.org (full text, mbox):

From: Aurelien Jarno <aurelien@aurel32.net>
To: Nikodemus Siivola <nikodemus@random-state.net>
Cc: 469058@bugs.debian.org, sbcl-devel <sbcl-devel@lists.sourceforge.net>, Debian Common Lisp Team <pkg-common-lisp-devel@lists.alioth.debian.org>
Subject: Re: DF and signal handlers
Date: Wed, 5 Mar 2008 16:10:53 +0100
On Wed, Mar 05, 2008 at 03:48:05PM +0200, Nikodemus Siivola wrote:
> On 3/5/08, Aurelien Jarno <aurelien@aurel32.net> wrote:
> > Nikodemus Siivola a écrit :
> >
> > > On 3/5/08, Debian Bug Tracking System <owner@bugs.debian.org> wrote:
> >  >
> >  >> tag 469058 + patch
> >  >>  Bug#469058: sbcl doesn't reset direction flag upon exit
> >  >>  There were no tags set.
> >  >>  Tags added: patch
> >  >
> >  > Thanks for the patch, but... while I agree that it is good to change
> >  > SBCL to reset the direction flag every time it is diddled, instead of
> >  > just before calling C, I don't think SBCL is actually at fault here.
> >  >
> >  >  1. SBCL does actually reset DF before any call to foreign (GCC generated) code.
> >  >     See line 236 in src/compiler/x86/c-call.lisp, and line 125 in
> >  >     src/runtime/x86-assem.S.
> >  >
> >  >     (It is possible I'm missing out a call-path here, but even so, read on and
> >  >     see if my fears are unfounded or not.)
> >  >
> >  >  2. If the problem was due to a foreign call, it should be deterministic.
> >  >
> >  >  3. If the problem was due to _returning_ to main(), it should be deterministic.
> >
> >
> > Looks correct.
> >
> >
> >  > What I suspect is actually going on (especially considering your
> >  > statement that compiling signals/ with 4.2 avoided the issue) is that
> >  > a signal handler is entered while DF is set.
> >
> >
> > What I am sure is that sigemptyset() from the glibc is called with the
> > direction flag set, and that should not happen.
> 
> Right.
> 
> I'm about to merge a patch to SBCL based on yours, which moves all DF
> resets to immediate vicinity of STDs for easier auditing, and removed
> the then-unnecessary CLD instructions from foreign call sequences.
> This will fix them symptoms, and be good for SBCL, but I think the
> underlying problem is still there in signal handling. :/
> 
> >  > If this is the case, then clearing it right after each REP loop where
> >  > SBCL uses it just makes seeing the bug much more unlikely -- but not
> >  > impossible in the presence of async signals.
> >
> >
> > Seems correct, though I have made half a dozen of build here, without
> > any problem.
> 
> That is not too suprising: the are normally no asynch signals
> delivered during the build, but SIGSEGV is a regular occurance (it is
> used by the GC), so SIGSEGV handlers may have been seeing the DF set.
> 
> What _is_ strange is that this appears to have been random. (At least
> all the reporters seemed to characterize it as semirandom behaviour.)
> Multiple builds from the same source with the same host compiler
> should have essentially identical GC characteristics.
> 
> >  > If so, this may also explain some _very_ hard to reproduce faults we
> >  > have seen over the years: using a pre 4.3-GCC compiled libc, a signal
> >  > at an in opportune moment in the middle of a REP loop could clear DF!
> >  > Yikes!
> >  >
> >  > I'm not sure what is The Right Thing here, though. Should SBCL (and
> >  > _any_ program that ever sets DF!) save, clear, and restore DF in its
> >  > signal handlers? Should libc/kernel do that? Should signals be blocked
> >
> >
> > I currently have no idea about that.
> 
> I'll see if I can cook up a small test-case using async signals. (One
> that doesn't need SBCL so that it can be passed to upstream libc /
> kernel people if necessary without too much friction.)
> 

The small code below exhibits the problem. It was there already with
gcc-4.2, but in that case, gcc generates a cld or std instruction 
before any instruction that uses the direction flag.


#include <stdint.h>
#include <stdlib.h>
#include <stdio.h>
#include <signal.h>

void handler(int signal) {
	uint64_t rflags;
	
	asm volatile("pushfq ; popq %0" : "=g" (rflags));

	if (rflags & (1 << 10))
		printf("DF = 1\n");
	else
		printf("DF = 0\n");
}

int main() {
	signal(SIGUSR1, handler);

	while(1)
	{
		asm volatile("std\r\n");
	}
}


-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Common Lisp Team <pkg-common-lisp-devel@lists.alioth.debian.org>:
Bug#469058; Package sbcl. Full text and rfc822 format available.

Acknowledgement sent to Aurelien Jarno <aurelien@aurel32.net>:
Extra info received and forwarded to list. Copy sent to Debian Common Lisp Team <pkg-common-lisp-devel@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #98 received at 469058@bugs.debian.org (full text, mbox):

From: Aurelien Jarno <aurelien@aurel32.net>
To: Nikodemus Siivola <nikodemus@random-state.net>
Cc: 469058@bugs.debian.org, sbcl-devel <sbcl-devel@lists.sourceforge.net>, Debian Common Lisp Team <pkg-common-lisp-devel@lists.alioth.debian.org>, debian-kernel@lists.debian.org, debian-gcc@lists.debian.org
Subject: Re: DF and signal handlers
Date: Wed, 5 Mar 2008 16:49:21 +0100
reassign 469058 linux-2.6,gcc-4.3
thanks

On Wed, Mar 05, 2008 at 04:10:53PM +0100, Aurelien Jarno wrote:
> On Wed, Mar 05, 2008 at 03:48:05PM +0200, Nikodemus Siivola wrote:
> > On 3/5/08, Aurelien Jarno <aurelien@aurel32.net> wrote:
> > > Nikodemus Siivola a écrit :
> > >
> > > > On 3/5/08, Debian Bug Tracking System <owner@bugs.debian.org> wrote:
> > >  >
> > >  >> tag 469058 + patch
> > >  >>  Bug#469058: sbcl doesn't reset direction flag upon exit
> > >  >>  There were no tags set.
> > >  >>  Tags added: patch
> > >  >
> > >  > Thanks for the patch, but... while I agree that it is good to change
> > >  > SBCL to reset the direction flag every time it is diddled, instead of
> > >  > just before calling C, I don't think SBCL is actually at fault here.
> > >  >
> > >  >  1. SBCL does actually reset DF before any call to foreign (GCC generated) code.
> > >  >     See line 236 in src/compiler/x86/c-call.lisp, and line 125 in
> > >  >     src/runtime/x86-assem.S.
> > >  >
> > >  >     (It is possible I'm missing out a call-path here, but even so, read on and
> > >  >     see if my fears are unfounded or not.)
> > >  >
> > >  >  2. If the problem was due to a foreign call, it should be deterministic.
> > >  >
> > >  >  3. If the problem was due to _returning_ to main(), it should be deterministic.
> > >
> > >
> > > Looks correct.
> > >
> > >
> > >  > What I suspect is actually going on (especially considering your
> > >  > statement that compiling signals/ with 4.2 avoided the issue) is that
> > >  > a signal handler is entered while DF is set.
> > >
> > >
> > > What I am sure is that sigemptyset() from the glibc is called with the
> > > direction flag set, and that should not happen.
> > 
> > Right.
> > 
> > I'm about to merge a patch to SBCL based on yours, which moves all DF
> > resets to immediate vicinity of STDs for easier auditing, and removed
> > the then-unnecessary CLD instructions from foreign call sequences.
> > This will fix them symptoms, and be good for SBCL, but I think the
> > underlying problem is still there in signal handling. :/
> > 
> > >  > If this is the case, then clearing it right after each REP loop where
> > >  > SBCL uses it just makes seeing the bug much more unlikely -- but not
> > >  > impossible in the presence of async signals.
> > >
> > >
> > > Seems correct, though I have made half a dozen of build here, without
> > > any problem.
> > 
> > That is not too suprising: the are normally no asynch signals
> > delivered during the build, but SIGSEGV is a regular occurance (it is
> > used by the GC), so SIGSEGV handlers may have been seeing the DF set.
> > 
> > What _is_ strange is that this appears to have been random. (At least
> > all the reporters seemed to characterize it as semirandom behaviour.)
> > Multiple builds from the same source with the same host compiler
> > should have essentially identical GC characteristics.
> > 
> > >  > If so, this may also explain some _very_ hard to reproduce faults we
> > >  > have seen over the years: using a pre 4.3-GCC compiled libc, a signal
> > >  > at an in opportune moment in the middle of a REP loop could clear DF!
> > >  > Yikes!
> > >  >
> > >  > I'm not sure what is The Right Thing here, though. Should SBCL (and
> > >  > _any_ program that ever sets DF!) save, clear, and restore DF in its
> > >  > signal handlers? Should libc/kernel do that? Should signals be blocked
> > >
> > >
> > > I currently have no idea about that.
> > 
> > I'll see if I can cook up a small test-case using async signals. (One
> > that doesn't need SBCL so that it can be passed to upstream libc /
> > kernel people if necessary without too much friction.)
> > 

That's definitively a kernel/gcc-4.3 problem, I have reported it
upstream: http://lkml.org/lkml/2008/3/5/207

I am therefore reassigning the bug to those packages.

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net




Bug reassigned from package `sbcl' to `linux-2.6,gcc-4.3'. Request was from Aurelien Jarno <aurelien@aurel32.net> to control@bugs.debian.org. (Wed, 05 Mar 2008 15:51:13 GMT) Full text and rfc822 format available.

Tags removed: patch Request was from Aurelien Jarno <aurelien@aurel32.net> to control@bugs.debian.org. (Wed, 05 Mar 2008 16:24:03 GMT) Full text and rfc822 format available.

Tags removed: patch Request was from Aurelien Jarno <aurel32@debian.org> to control@bugs.debian.org. (Wed, 05 Mar 2008 16:24:05 GMT) Full text and rfc822 format available.

Noted your statement that Bug has been forwarded to http://lkml.org/lkml/2008/3/5/207. Request was from Aurelien Jarno <aurel32@debian.org> to control@bugs.debian.org. (Wed, 05 Mar 2008 16:33:05 GMT) Full text and rfc822 format available.

Changed Bug title to `Linux doesn't follow x86/x86-64 ABI wrt direction flag' from `sbcl doesn't reset direction flag upon exit'. Request was from Aurelien Jarno <aurel32@debian.org> to control@bugs.debian.org. (Wed, 05 Mar 2008 16:36:02 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>, Debian GCC Maintainers <debian-gcc@lists.debian.org>:
Bug#469058; Package linux-2.6,gcc-4.3. Full text and rfc822 format available.

Acknowledgement sent to Aurelien Jarno <aurelien@aurel32.net>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>, Debian GCC Maintainers <debian-gcc@lists.debian.org>. Full text and rfc822 format available.

Message #113 received at 469058@bugs.debian.org (full text, mbox):

From: Aurelien Jarno <aurelien@aurel32.net>
To: debian-kernel@lists.debian.org
Cc: 469058@bugs.debian.org, sbcl-devel <sbcl-devel@lists.sourceforge.net>, Debian Common Lisp Team <pkg-common-lisp-devel@lists.alioth.debian.org>, Nikodemus Siivola <nikodemus@random-state.net>, debian-gcc@lists.debian.org, debian-bsd@lists.debian.org, debian-hurd@lists.debian.org, debian-glibc@lists.debian.org
Subject: Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag
Date: Wed, 5 Mar 2008 22:53:28 +0100
reassign 469058 linux-2.6
submitter 469058 aurel32@debian.org
clone 469058 -1 -2 -3 -4 -5
reassign -1 kfreebsd-6
retitle -1 FreeBSD kernel doesn't follow x86/x86-64 ABI wrt direction flag
reassign -2 kfreebsd-7
retitle -2 FreeBSD kernel doesn't follow x86/x86-64 ABI wrt direction flag
reassign -3 hurd
retitle -3 Hurd crashes when a signal handler is called with DF = 1
reassign -4 gcc-4.3
retitle -4 gcc-4.3: old behavior wrt cld/std should be restored
reassign -5 glibc
retitle -5 libc6 should build-depends on a fixde gcc 4.3 wrt cld/std
submitter -5 nikodemus@random-state.net
thanks


On Wed, Mar 05, 2008 at 04:49:21PM +0100, Aurelien Jarno wrote:
> reassign 469058 linux-2.6,gcc-4.3
> thanks
> 
> On Wed, Mar 05, 2008 at 04:10:53PM +0100, Aurelien Jarno wrote:
> That's definitively a kernel/gcc-4.3 problem, I have reported it
> upstream: http://lkml.org/lkml/2008/3/5/207
> 
> I am therefore reassigning the bug to those packages.
> 

Now that the situation is more clear, let's clone/reassign the bugs to
the right packages. While the kernels have to be fixed, gcc 4.3
behavior wrt to cld/std has to be reverted to the old behavior to 
ensure an upgrade path from Etch.

So let's summarize:
- linux 2.6 has to be fixed. A patch is available on the lkml [1] for
  2.6.25-rc. It could be easily backported to 2.6.24
- kfreebsd 6 and 7 exhibit the same behavior. They have to be fixed
- hurd crashes in this case. It has to be fixed
- gcc 4.3 should not strictly follow the ABI when it comes to cld/std
  and use the old behavior, which is now a de facto ABI for some time.
- glibc 2.7-9 is broken with the current kernels. It has to be rebuilt
  with a fixed gcc.

[1] http://lkml.org/lkml/2008/3/5/306
[2] http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00354.html

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net




Bug reassigned from package `linux-2.6,gcc-4.3' to `linux-2.6'. Request was from Aurelien Jarno <aurelien@aurel32.net> to control@bugs.debian.org. (Wed, 05 Mar 2008 22:03:06 GMT) Full text and rfc822 format available.

Changed Bug submitter from Rupert Swarbrick <rswarbrick@googlemail.com> to aurel32@debian.org. Request was from Aurelien Jarno <aurelien@aurel32.net> to control@bugs.debian.org. (Wed, 05 Mar 2008 22:03:07 GMT) Full text and rfc822 format available.

Bug 469058 cloned as bugs 469564, 469565, 469566, 469567, 469568. Request was from Aurelien Jarno <aurelien@aurel32.net> to control@bugs.debian.org. (Wed, 05 Mar 2008 22:03:07 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#469058; Package linux-2.6. Full text and rfc822 format available.

Acknowledgement sent to Aurelien Jarno <aurelien@aurel32.net>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #124 received at 469058@bugs.debian.org (full text, mbox):

From: Aurelien Jarno <aurelien@aurel32.net>
To: 469058@bugs.debian.org
Cc: control@bugs.debian.org
Subject: Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag
Date: Thu, 6 Mar 2008 19:12:21 +0100
tag 469058 + patch
thanks

On Wed, Mar 05, 2008 at 10:53:28PM +0100, Aurelien Jarno wrote:
> 
> So let's summarize:
> - linux 2.6 has to be fixed. A patch is available on the lkml [1] for
>   2.6.25-rc. It could be easily backported to 2.6.24

The patch for 2.6.25-rc went upstream. Please find a backported patch
for 2.6.24 below.



x86: Clear DF before calling signal handler

The Linux kernel currently does not clear the direction flag before
calling a signal handler, whereas the x86/x86-64 ABI requires that.
This become a real problem with gcc version 4.3, which assumes that
the direction flag is correctly cleared at the entry of a function.

This patches changes the setup_frame() functions to clear the
direction before entering the signal handler.

Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
---
 arch/x86/ia32/ia32_signal.c |    4 ++--
 arch/x86/kernel/signal_32.c |    4 ++--
 arch/x86/kernel/signal_64.c |    2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/x86/ia32/ia32_signal.c b/arch/x86/ia32/ia32_signal.c
index 6ea19c2..4eaaf78 100644
--- a/arch/x86/ia32/ia32_signal.c
+++ b/arch/x86/ia32/ia32_signal.c
@@ -494,7 +494,7 @@ int ia32_setup_frame(int sig, struct k_sigaction *ka,
 	regs->ss = __USER32_DS; 
 
 	set_fs(USER_DS);
-	regs->eflags &= ~TF_MASK;
+	regs->eflags &= ~(TF_MASK | X86_EFLAGS_DF);
 	if (test_thread_flag(TIF_SINGLESTEP))
 		ptrace_notify(SIGTRAP);
 
@@ -600,7 +600,7 @@ int ia32_setup_rt_frame(int sig, struct k_sigaction *ka, siginfo_t *info,
 	regs->ss = __USER32_DS; 
 
 	set_fs(USER_DS);
-	regs->eflags &= ~TF_MASK;
+	regs->eflags &= ~(TF_MASK | X86_EFLAGS_DF);
 	if (test_thread_flag(TIF_SINGLESTEP))
 		ptrace_notify(SIGTRAP);
 
diff --git a/arch/x86/kernel/signal_32.c b/arch/x86/kernel/signal_32.c
index 9bdd830..20056db 100644
--- a/arch/x86/kernel/signal_32.c
+++ b/arch/x86/kernel/signal_32.c
@@ -396,7 +396,7 @@ static int setup_frame(int sig, struct k_sigaction *ka,
 	 * The tracer may want to single-step inside the
 	 * handler too.
 	 */
-	regs->eflags &= ~TF_MASK;
+	regs->eflags &= ~(TF_MASK | X86_EFLAGS_DF);
 	if (test_thread_flag(TIF_SINGLESTEP))
 		ptrace_notify(SIGTRAP);
 
@@ -489,7 +489,7 @@ static int setup_rt_frame(int sig, struct k_sigaction *ka, siginfo_t *info,
 	 * The tracer may want to single-step inside the
 	 * handler too.
 	 */
-	regs->eflags &= ~TF_MASK;
+	regs->eflags &= ~(TF_MASK | X86_EFLAGS_DF);
 	if (test_thread_flag(TIF_SINGLESTEP))
 		ptrace_notify(SIGTRAP);
 
diff --git a/arch/x86/kernel/signal_64.c b/arch/x86/kernel/signal_64.c
index ab086b0..62964c5 100644
--- a/arch/x86/kernel/signal_64.c
+++ b/arch/x86/kernel/signal_64.c
@@ -295,7 +295,7 @@ static int setup_rt_frame(int sig, struct k_sigaction *ka, siginfo_t *info,
 	   see include/asm-x86_64/uaccess.h for details. */
 	set_fs(USER_DS);
 
-	regs->eflags &= ~TF_MASK;
+	regs->eflags &= ~(TF_MASK | X86_EFLAGS_DF);
 	if (test_thread_flag(TIF_SINGLESTEP))
 		ptrace_notify(SIGTRAP);
 #ifdef DEBUG_SIG

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net




Tags added: patch Request was from Aurelien Jarno <aurelien@aurel32.net> to control@bugs.debian.org. (Thu, 06 Mar 2008 18:15:04 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#469058; Package linux-2.6. Full text and rfc822 format available.

Acknowledgement sent to Johannes Weiner <hannes@saeurebad.de>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #131 received at 469058@bugs.debian.org (full text, mbox):

From: Johannes Weiner <hannes@saeurebad.de>
To: "Nikodemus Siivola" <nikodemus@random-state.net>
Cc: 469058@bugs.debian.org, sbcl-devel <sbcl-devel@lists.sourceforge.net>, Debian Common Lisp Team <pkg-common-lisp-devel@lists.alioth.debian.org>, Aurelien Jarno <aurelien@aurel32.net>
Subject: Re: [Sbcl-devel] DF and signal handlers
Date: Sun, 09 Mar 2008 13:30:20 +0100
Hi Nikodemus,

"Nikodemus Siivola" <nikodemus@random-state.net> writes:

> I'm not sure what is The Right Thing here, though. Should SBCL (and
> _any_ program that ever sets DF!) save, clear, and restore DF in its
> signal handlers? Should libc/kernel do that? Should signals be blocked
> before ever setting DF? Is setting DF Just A Bad Idea?

Perhaps this [1] helps.  The rest of the thread is a big discussion
about whose fault this is ;)

	Hannes

[1] http://lkml.org/lkml/2008/3/5/306




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#469058; Package linux-2.6. Full text and rfc822 format available.

Acknowledgement sent to dann frazier <dannf@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #136 received at 469058@bugs.debian.org (full text, mbox):

From: dann frazier <dannf@debian.org>
To: 469058@bugs.debian.org
Subject: pending upstream
Date: Sun, 23 Mar 2008 10:37:32 -0600
fyi, this change is pending in the stable queue for 2.6.24.4, so will
likley be included in 2.6.24-5
-- 
dann frazier





Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#469058; Package linux-2.6. Full text and rfc822 format available.

Acknowledgement sent to Aurelien Jarno <aurelien@aurel32.net>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #141 received at 469058@bugs.debian.org (full text, mbox):

From: Aurelien Jarno <aurelien@aurel32.net>
To: Debian Kernel Team <debian-kernel@lists.debian.org>, 469058@bugs.debian.org
Cc: control@bugs.debian.org
Subject: Fix for Etch
Date: Mon, 24 Mar 2008 10:33:52 +0100
found 469058 2.6.18.dfsg.1-10
thanks

Please find below a patch for 2.6.18, which should also apply to all
pre- x86/x86-64 merge 2.6 kernels.

Aurelien


commit d726666de04eb1a0269fd37d1edefe03d44446d0
Author: Aurelien Jarno <aurelien@aurel32.net>
Date:   Wed Mar 5 18:59:11 2008 +0100

    x86: Clear DF before calling signal handler
    
    The Linux kernel currently does not clear the direction flag before
    calling a signal handler, whereas the x86/x86-64 ABI requires that.
    This become a real problem with gcc version 4.3, which assumes that
    the direction flag is correctly cleared at the entry of a function.
    
    This patches changes the setup_frame() functions to clear the
    direction before entering the signal handler.
    
    Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>

diff --git a/arch/x86/ia32/ia32_signal.c b/arch/x86/ia32/ia32_signal.c
index 1c0503b..5e7771a 100644
--- a/arch/x86/ia32/ia32_signal.c
+++ b/arch/x86/ia32/ia32_signal.c
@@ -500,7 +500,7 @@ int ia32_setup_frame(int sig, struct k_sigaction *ka,
 	regs->ss = __USER32_DS;
 
 	set_fs(USER_DS);
-	regs->flags &= ~X86_EFLAGS_TF;
+	regs->flags &= ~(X86_EFLAGS_TF | X86_EFLAGS_DF);
 	if (test_thread_flag(TIF_SINGLESTEP))
 		ptrace_notify(SIGTRAP);
 
@@ -600,7 +600,7 @@ int ia32_setup_rt_frame(int sig, struct k_sigaction *ka, siginfo_t *info,
 	regs->ss = __USER32_DS;
 
 	set_fs(USER_DS);
-	regs->flags &= ~X86_EFLAGS_TF;
+	regs->flags &= ~(X86_EFLAGS_TF | X86_EFLAGS_DF);
 	if (test_thread_flag(TIF_SINGLESTEP))
 		ptrace_notify(SIGTRAP);
 
diff --git a/arch/x86/kernel/signal_32.c b/arch/x86/kernel/signal_32.c
index caee1f0..0157a6f 100644
--- a/arch/x86/kernel/signal_32.c
+++ b/arch/x86/kernel/signal_32.c
@@ -407,7 +407,7 @@ static int setup_frame(int sig, struct k_sigaction *ka,
 	 * The tracer may want to single-step inside the
 	 * handler too.
 	 */
-	regs->flags &= ~TF_MASK;
+	regs->flags &= ~(TF_MASK | X86_EFLAGS_DF);
 	if (test_thread_flag(TIF_SINGLESTEP))
 		ptrace_notify(SIGTRAP);
 
@@ -500,7 +500,7 @@ static int setup_rt_frame(int sig, struct k_sigaction *ka, siginfo_t *info,
 	 * The tracer may want to single-step inside the
 	 * handler too.
 	 */
-	regs->flags &= ~TF_MASK;
+	regs->flags &= ~(TF_MASK | X86_EFLAGS_DF);
 	if (test_thread_flag(TIF_SINGLESTEP))
 		ptrace_notify(SIGTRAP);
 
diff --git a/arch/x86/kernel/signal_64.c b/arch/x86/kernel/signal_64.c
index 7347bb1..56b72fb 100644
--- a/arch/x86/kernel/signal_64.c
+++ b/arch/x86/kernel/signal_64.c
@@ -295,7 +295,7 @@ static int setup_rt_frame(int sig, struct k_sigaction *ka, siginfo_t *info,
 	   see include/asm-x86_64/uaccess.h for details. */
 	set_fs(USER_DS);
 
-	regs->flags &= ~X86_EFLAGS_TF;
+	regs->flags &= ~(X86_EFLAGS_TF | X86_EFLAGS_DF);
 	if (test_thread_flag(TIF_SINGLESTEP))
 		ptrace_notify(SIGTRAP);
 #ifdef DEBUG_SIG

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net




Bug marked as found in version 2.6.18.dfsg.1-10. Request was from Aurelien Jarno <aurelien@aurel32.net> to control@bugs.debian.org. (Mon, 24 Mar 2008 09:41:48 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#469058; Package linux-2.6. Full text and rfc822 format available.

Acknowledgement sent to Bastian Blank <waldi@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #148 received at 469058@bugs.debian.org (full text, mbox):

From: Bastian Blank <waldi@debian.org>
To: Aurelien Jarno <aurelien@aurel32.net>
Cc: 469058@bugs.debian.org
Subject: Re: Fix for Etch
Date: Mon, 24 Mar 2008 11:43:08 +0100
On Mon, Mar 24, 2008 at 10:33:52AM +0100, Aurelien Jarno wrote:
> Please find below a patch for 2.6.18, which should also apply to all
> pre- x86/x86-64 merge 2.6 kernels.

No, it does not.

Bastian

-- 
The idea of male and female are universal constants.
		-- Kirk, "Metamorphosis", stardate 3219.8




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#469058; Package linux-2.6. Full text and rfc822 format available.

Acknowledgement sent to Bastian Blank <waldi@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #153 received at 469058@bugs.debian.org (full text, mbox):

From: Bastian Blank <waldi@debian.org>
To: Aurelien Jarno <aurelien@aurel32.net>
Cc: 469058@bugs.debian.org
Subject: Re: Bug#469058: Fix for Etch
Date: Mon, 24 Mar 2008 12:59:29 +0100
On Mon, Mar 24, 2008 at 11:43:08AM +0100, Bastian Blank wrote:
> On Mon, Mar 24, 2008 at 10:33:52AM +0100, Aurelien Jarno wrote:
> > Please find below a patch for 2.6.18, which should also apply to all
> > pre- x86/x86-64 merge 2.6 kernels.
> No, it does not.

But I have a variant which seems to work.

Bastian

-- 
We fight only when there is no other choice.  We prefer the ways of
peaceful contact.
		-- Kirk, "Spectre of the Gun", stardate 4385.3




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#469058; Package linux-2.6. Full text and rfc822 format available.

Acknowledgement sent to Aurelien Jarno <aurelien@aurel32.net>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #158 received at 469058@bugs.debian.org (full text, mbox):

From: Aurelien Jarno <aurelien@aurel32.net>
To: Bastian Blank <waldi@debian.org>
Cc: 469058@bugs.debian.org
Subject: Re: Fix for Etch
Date: Mon, 24 Mar 2008 19:08:22 +0100
On Mon, Mar 24, 2008 at 11:43:08AM +0100, Bastian Blank wrote:
> On Mon, Mar 24, 2008 at 10:33:52AM +0100, Aurelien Jarno wrote:
> > Please find below a patch for 2.6.18, which should also apply to all
> > pre- x86/x86-64 merge 2.6 kernels.
> 
> No, it does not.
> 

Oops I've sent the wrong patch. Please find the correct patch below:

commit 9b25e7f72161a95d7e255b0277c951f7f9aee59f
Author: Aurelien Jarno <aurelien@aurel32.net>
Date:   Mon Mar 24 09:43:27 2008 +0100

    x86: Clear DF before calling signal handler
    
    The Linux kernel currently does not clear the direction flag before
    calling a signal handler, whereas the x86/x86-64 ABI requires that.
    This become a real problem with gcc version 4.3, which assumes that
    the direction flag is correctly cleared at the entry of a function.
    
    This patches changes the setup_frame() functions to clear the
    direction before entering the signal handler.

diff --git a/arch/i386/kernel/signal.c b/arch/i386/kernel/signal.c
index 43002cf..2dea594 100644
--- a/arch/i386/kernel/signal.c
+++ b/arch/i386/kernel/signal.c
@@ -391,7 +391,7 @@ static int setup_frame(int sig, struct k_sigaction *ka,
 	 * The tracer may want to single-step inside the
 	 * handler too.
 	 */
-	regs->eflags &= ~TF_MASK;
+	regs->eflags &= ~(TF_MASK | X86_EFLAGS_DF);
 	if (test_thread_flag(TIF_SINGLESTEP))
 		ptrace_notify(SIGTRAP);
 
@@ -485,7 +485,7 @@ static int setup_rt_frame(int sig, struct k_sigaction *ka, siginfo_t *info,
 	 * The tracer may want to single-step inside the
 	 * handler too.
 	 */
-	regs->eflags &= ~TF_MASK;
+	regs->eflags &= ~(TF_MASK | X86_EFLAGS_DF);
 	if (test_thread_flag(TIF_SINGLESTEP))
 		ptrace_notify(SIGTRAP);
 
diff --git a/arch/x86_64/ia32/ia32_signal.c b/arch/x86_64/ia32/ia32_signal.c
index 25e5ca2..97febdf 100644
--- a/arch/x86_64/ia32/ia32_signal.c
+++ b/arch/x86_64/ia32/ia32_signal.c
@@ -499,7 +499,7 @@ int ia32_setup_frame(int sig, struct k_sigaction *ka,
 	regs->ss = __USER32_DS; 
 
 	set_fs(USER_DS);
-    regs->eflags &= ~TF_MASK;
+    regs->eflags &= ~(TF_MASK | X86_EFLAGS_DF);
     if (test_thread_flag(TIF_SINGLESTEP))
         ptrace_notify(SIGTRAP);
 
@@ -595,7 +595,7 @@ int ia32_setup_rt_frame(int sig, struct k_sigaction *ka, siginfo_t *info,
 	regs->ss = __USER32_DS; 
 
 	set_fs(USER_DS);
-    regs->eflags &= ~TF_MASK;
+    regs->eflags &= ~(TF_MASK | X86_EFLAGS_DF);
     if (test_thread_flag(TIF_SINGLESTEP))
         ptrace_notify(SIGTRAP);
 
diff --git a/arch/x86_64/kernel/signal.c b/arch/x86_64/kernel/signal.c
index 2816117..a4baa0f 100644
--- a/arch/x86_64/kernel/signal.c
+++ b/arch/x86_64/kernel/signal.c
@@ -333,7 +333,7 @@ static int setup_rt_frame(int sig, struct k_sigaction *ka, siginfo_t *info,
 	   see include/asm-x86_64/uaccess.h for details. */
 	set_fs(USER_DS);
 
-	regs->eflags &= ~TF_MASK;
+	regs->eflags &= ~(TF_MASK | X86_EFLAGS_DF);
 	if (test_thread_flag(TIF_SINGLESTEP))
 		ptrace_notify(SIGTRAP);
 #ifdef DEBUG_SIG


-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net




Tags added: pending Request was from Bastian Blank <waldi@alioth.debian.org> to control@bugs.debian.org. (Mon, 24 Mar 2008 21:27:24 GMT) Full text and rfc822 format available.

Reply sent to Bastian Blank <waldi@debian.org>:
You have taken responsibility. Full text and rfc822 format available.

Notification sent to aurel32@debian.org:
Bug acknowledged by developer. Full text and rfc822 format available.

Message #165 received at 469058-close@bugs.debian.org (full text, mbox):

From: Bastian Blank <waldi@debian.org>
To: 469058-close@bugs.debian.org
Subject: Bug#469058: fixed in linux-2.6 2.6.24-5
Date: Thu, 27 Mar 2008 16:02:27 +0000
Source: linux-2.6
Source-Version: 2.6.24-5

We believe that the bug you reported is fixed in the latest version of
linux-2.6, which is due to be installed in the Debian FTP archive:

linux-2.6_2.6.24-5.diff.gz
  to pool/main/l/linux-2.6/linux-2.6_2.6.24-5.diff.gz
linux-2.6_2.6.24-5.dsc
  to pool/main/l/linux-2.6/linux-2.6_2.6.24-5.dsc
linux-doc-2.6.24_2.6.24-5_all.deb
  to pool/main/l/linux-2.6/linux-doc-2.6.24_2.6.24-5_all.deb
linux-headers-2.6.24-1-all-powerpc_2.6.24-5_powerpc.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.24-1-all-powerpc_2.6.24-5_powerpc.deb
linux-headers-2.6.24-1-all_2.6.24-5_powerpc.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.24-1-all_2.6.24-5_powerpc.deb
linux-headers-2.6.24-1-common_2.6.24-5_powerpc.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.24-1-common_2.6.24-5_powerpc.deb
linux-headers-2.6.24-1-powerpc-miboot_2.6.24-5_powerpc.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.24-1-powerpc-miboot_2.6.24-5_powerpc.deb
linux-headers-2.6.24-1-powerpc-smp_2.6.24-5_powerpc.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.24-1-powerpc-smp_2.6.24-5_powerpc.deb
linux-headers-2.6.24-1-powerpc64_2.6.24-5_powerpc.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.24-1-powerpc64_2.6.24-5_powerpc.deb
linux-headers-2.6.24-1-powerpc_2.6.24-5_powerpc.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.24-1-powerpc_2.6.24-5_powerpc.deb
linux-image-2.6.24-1-powerpc-miboot_2.6.24-5_powerpc.deb
  to pool/main/l/linux-2.6/linux-image-2.6.24-1-powerpc-miboot_2.6.24-5_powerpc.deb
linux-image-2.6.24-1-powerpc-smp_2.6.24-5_powerpc.deb
  to pool/main/l/linux-2.6/linux-image-2.6.24-1-powerpc-smp_2.6.24-5_powerpc.deb
linux-image-2.6.24-1-powerpc64_2.6.24-5_powerpc.deb
  to pool/main/l/linux-2.6/linux-image-2.6.24-1-powerpc64_2.6.24-5_powerpc.deb
linux-image-2.6.24-1-powerpc_2.6.24-5_powerpc.deb
  to pool/main/l/linux-2.6/linux-image-2.6.24-1-powerpc_2.6.24-5_powerpc.deb
linux-libc-dev_2.6.24-5_powerpc.deb
  to pool/main/l/linux-2.6/linux-libc-dev_2.6.24-5_powerpc.deb
linux-manual-2.6.24_2.6.24-5_all.deb
  to pool/main/l/linux-2.6/linux-manual-2.6.24_2.6.24-5_all.deb
linux-patch-debian-2.6.24_2.6.24-5_all.deb
  to pool/main/l/linux-2.6/linux-patch-debian-2.6.24_2.6.24-5_all.deb
linux-source-2.6.24_2.6.24-5_all.deb
  to pool/main/l/linux-2.6/linux-source-2.6.24_2.6.24-5_all.deb
linux-support-2.6.24-1_2.6.24-5_all.deb
  to pool/main/l/linux-2.6/linux-support-2.6.24-1_2.6.24-5_all.deb
linux-tree-2.6.24_2.6.24-5_all.deb
  to pool/main/l/linux-2.6/linux-tree-2.6.24_2.6.24-5_all.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 469058@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Bastian Blank <waldi@debian.org> (supplier of updated linux-2.6 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Thu, 27 Mar 2008 12:40:16 +0100
Source: linux-2.6
Binary: linux-source-2.6.24 linux-doc-2.6.24 linux-manual-2.6.24 linux-patch-debian-2.6.24 linux-tree-2.6.24 linux-support-2.6.24-1 linux-libc-dev linux-headers-2.6.24-1-all linux-headers-2.6.24-1-all-alpha linux-headers-2.6.24-1-common linux-image-2.6.24-1-alpha-generic linux-headers-2.6.24-1-alpha-generic linux-image-2.6.24-1-alpha-smp linux-headers-2.6.24-1-alpha-smp linux-image-2.6.24-1-alpha-legacy linux-headers-2.6.24-1-alpha-legacy linux-headers-2.6.24-1-all-amd64 linux-image-2.6.24-1-amd64 linux-headers-2.6.24-1-amd64 linux-headers-2.6.24-1-all-arm linux-image-2.6.24-1-footbridge linux-headers-2.6.24-1-footbridge linux-image-2.6.24-1-iop32x linux-headers-2.6.24-1-iop32x linux-image-2.6.24-1-ixp4xx linux-headers-2.6.24-1-ixp4xx linux-headers-2.6.24-1-all-armel linux-image-2.6.24-1-versatile linux-headers-2.6.24-1-versatile linux-headers-2.6.24-1-all-hppa linux-image-2.6.24-1-parisc linux-headers-2.6.24-1-parisc linux-image-2.6.24-1-parisc-smp linux-headers-2.6.24-1-parisc-smp linux-image-2.6.24-1-parisc64 linux-headers-2.6.24-1-parisc64 linux-image-2.6.24-1-parisc64-smp linux-headers-2.6.24-1-parisc64-smp linux-headers-2.6.24-1-all-i386 linux-image-2.6.24-1-486 linux-headers-2.6.24-1-486 linux-image-2.6.24-1-686 linux-headers-2.6.24-1-686 linux-image-2.6.24-1-686-bigmem linux-headers-2.6.24-1-686-bigmem linux-headers-2.6.24-1-common-xen linux-image-2.6.24-1-xen-686 linux-modules-2.6.24-1-xen-686 linux-headers-2.6.24-1-xen-686 linux-headers-2.6.24-1-all-ia64 linux-image-2.6.24-1-itanium linux-headers-2.6.24-1-itanium linux-image-2.6.24-1-mckinley linux-headers-2.6.24-1-mckinley linux-headers-2.6.24-1-all-m68k linux-image-2.6.24-1-amiga linux-headers-2.6.24-1-amiga linux-image-2.6.24-1-atari linux-headers-2.6.24-1-atari linux-image-2.6.24-1-bvme6000 linux-headers-2.6.24-1-bvme6000 linux-image-2.6.24-1-mac linux-headers-2.6.24-1-mac linux-image-2.6.24-1-mvme147 linux-headers-2.6.24-1-mvme147 linux-image-2.6.24-1-mvme16x linux-headers-2.6.24-1-mvme16x linux-headers-2.6.24-1-all-mips linux-image-2.6.24-1-r4k-ip22 linux-headers-2.6.24-1-r4k-ip22 linux-image-2.6.24-1-r5k-ip32 linux-headers-2.6.24-1-r5k-ip32 linux-image-2.6.24-1-sb1-bcm91250a linux-headers-2.6.24-1-sb1-bcm91250a linux-image-2.6.24-1-sb1a-bcm91480b linux-headers-2.6.24-1-sb1a-bcm91480b linux-image-2.6.24-1-4kc-malta linux-headers-2.6.24-1-4kc-malta linux-image-2.6.24-1-5kc-malta linux-headers-2.6.24-1-5kc-malta linux-headers-2.6.24-1-all-mipsel linux-image-2.6.24-1-r5k-cobalt linux-headers-2.6.24-1-r5k-cobalt linux-headers-2.6.24-1-all-powerpc linux-image-2.6.24-1-powerpc linux-headers-2.6.24-1-powerpc linux-image-2.6.24-1-powerpc-smp linux-headers-2.6.24-1-powerpc-smp linux-image-2.6.24-1-powerpc-miboot linux-headers-2.6.24-1-powerpc-miboot linux-image-2.6.24-1-powerpc64 linux-headers-2.6.24-1-powerpc64 linux-headers-2.6.24-1-all-s390 linux-image-2.6.24-1-s390 linux-headers-2.6.24-1-s390 linux-image-2.6.24-1-s390-tape linux-image-2.6.24-1-s390x linux-headers-2.6.24-1-s390x linux-headers-2.6.24-1-all-sparc linux-image-2.6.24-1-sparc64 linux-headers-2.6.24-1-sparc64 linux-image-2.6.24-1-sparc64-smp linux-headers-2.6.24-1-sparc64-smp
Architecture: source all powerpc
Version: 2.6.24-5
Distribution: unstable
Urgency: low
Maintainer: Debian Kernel Team <debian-kernel@lists.debian.org>
Changed-By: Bastian Blank <waldi@debian.org>
Description: 
 linux-doc-2.6.24 - Linux kernel specific documentation for version 2.6.24
 linux-headers-2.6.24-1-all - All header files for Linux 2.6.24
 linux-headers-2.6.24-1-all-powerpc - All header files for Linux 2.6.24
 linux-headers-2.6.24-1-common - Common header files for Linux 2.6.24
 linux-headers-2.6.24-1-powerpc - Header files for Linux 2.6.24 on uniprocessor 32-bit PowerPC
 linux-headers-2.6.24-1-powerpc-miboot - Header files for Linux 2.6.24 on 32-bit PowerPC for miboot floppy
 linux-headers-2.6.24-1-powerpc-smp - Header files for Linux 2.6.24 on multiprocessor 32-bit PowerPC
 linux-headers-2.6.24-1-powerpc64 - Header files for Linux 2.6.24 on 64-bit PowerPC
 linux-image-2.6.24-1-powerpc - Linux 2.6.24 image on uniprocessor 32-bit PowerPC
 linux-image-2.6.24-1-powerpc-miboot - Linux 2.6.24 image on 32-bit PowerPC for miboot floppy
 linux-image-2.6.24-1-powerpc-smp - Linux 2.6.24 image on multiprocessor 32-bit PowerPC
 linux-image-2.6.24-1-powerpc64 - Linux 2.6.24 image on 64-bit PowerPC
 linux-libc-dev - Linux Kernel Headers for development
 linux-manual-2.6.24 - Linux kernel API manual pages for version 2.6.24
 linux-patch-debian-2.6.24 - Debian patches to version 2.6.24 of the Linux kernel
 linux-source-2.6.24 - Linux kernel source for version 2.6.24 with Debian patches
 linux-support-2.6.24-1 - Support files for Linux 2.6.24
 linux-tree-2.6.24 - Linux kernel source tree for building Debian kernel images
Closes: 463669 466719 469058 471062
Changes: 
 linux-2.6 (2.6.24-5) unstable; urgency=low
 .
   [ Gordon Farquharson ]
   * [arm] Enable asix driver (USB_NET_AX8817X).
   * [arm] Enable CONFIG_USB_CATC, CONFIG_USB_KAWETH, CONFIG_USB_PEGASUS,
           and CONFIG_USB_RTL8150.
   * [arm/ixp4xx] Update Ethernet driver (closes: #471062).
   * [arm/ixp4xx] Add HSS driver.
 .
   [ Bastian Blank ]
   * [s390/s390-tape]: Override localversion correctly.
   * Add stable release 2.6.24.3:
     - x86_64: CPA, fix cache attribute inconsistency bug
     - bonding: fix NULL pointer deref in startup processing
     - POWERPC: Revert chrp_pci_fixup_vt8231_ata devinit to fix libata on pegasos
     - PCMCIA: Fix station address detection in smc
     - SCSI: gdth: scan for scsi devices
     - USB: fix pm counter leak in usblp
     - S390: Fix futex_atomic_cmpxchg_std inline assembly.
     - genirq: do not leave interupts enabled on free_irq
     - hrtimer: catch expired CLOCK_REALTIME timers early
     - hrtimer: check relative timeouts for overflow
     - SLUB: Deal with annoying gcc warning on kfree()
     - hrtimer: fix *rmtp/restarts handling in compat_sys_nanosleep()
     - hrtimer: fix *rmtp handling in hrtimer_nanosleep()
     - Disable G5 NAP mode during SMU commands on U3
     - Be more robust about bad arguments in get_user_pages()
     - AUDIT: Increase skb->truesize in audit_expand
     - BLUETOOTH: Add conn add/del workqueues to avoid connection fail.
     - INET: Prevent out-of-sync truesize on ip_fragment slow path
     - INET_DIAG: Fix inet_diag_lock_handler error path.
     - IPCOMP: Fetch nexthdr before ipch is destroyed
     - IPCOMP: Fix reception of incompressible packets
     - IPV4: fib: fix route replacement, fib_info is shared
     - IPV4: fib_trie: apply fixes from fib_hash
     - PKT_SCHED: ematch: oops from uninitialized variable (resend)
     - SELinux: Fix double free in selinux_netlbl_sock_setsid()
     - TC: oops in em_meta
     - TCP: Fix a bug in strategy_allowed_congestion_control
     - SCSI: sd: handle bad lba in sense information
     - Fix dl2k constants
     - XFS: Fix oops in xfs_file_readdir()
     - hugetlb: add locking for overcommit sysctl
     - inotify: fix check for one-shot watches before destroying them
     - NFS: Fix a potential file corruption issue when writing
     - NETFILTER: nf_conntrack_tcp: conntrack reopening fix
     - SPARC/SPARC64: Fix usage of .section .sched.text in assembler code.
   * Add stable release 2.6.24.4:
     - S390 futex: let futex_atomic_cmpxchg_pt survive early functional tests.
     - slab: NUMA slab allocator migration bugfix
     - relay: fix subbuf_splice_actor() adding too many pages
     - BLUETOOTH: Fix bugs in previous conn add/del workqueue changes.
     - SCSI advansys: Fix bug in AdvLoadMicrocode
     - async_tx: avoid the async xor_zero_sum path when src_cnt > device->max_xor
     - aio: bad AIO race in aio_complete() leads to process hang
     - jbd: correctly unescape journal data blocks
     - jbd2: correctly unescape journal data blocks
     - zisofs: fix readpage() outside i_size
     - NETFILTER: nfnetlink_log: fix computation of netlink skb size
     - NETFILTER: nfnetlink_queue: fix computation of allocated size for netlink skb
     - NETFILTER: xt_time: fix failure to match on Sundays
     - sched_nr_migrate wrong mode bits
     - nfsd: fix oops on access from high-numbered ports
     - sched: fix race in schedule()
     - SCSI: mpt fusion: don't oops if NumPhys==0
     - SCSI: gdth: fix to internal commands execution
     - SCSI: gdth: bugfix for the at-exit problems
     - Fix default compose table initialization
     - x86: don't use P6_NOPs if compiling with CONFIG_X86_GENERIC
     - SCSI: fix BUG when sum(scatterlist) > bufflen
     - USB: ehci: handle large bulk URBs correctly (again)
     - USB: ftdi_sio - really enable EM1010PC
     - USB: ftdi_sio: Workaround for broken Matrix Orbital serial port
     - VT notifier fix for VT switch
     - eCryptfs: make ecryptfs_prepare_write decrypt the page
     - ioat: fix 'ack' handling, driver must ensure that 'ack' is zero
     - macb: Fix speed setting
     - x86: move out tick_nohz_stop_sched_tick() call from the loop
     - atmel_spi: fix clock polarity
     - b43: Backport bcm4311 fix
     - arcmsr: fix IRQs disabled warning spew
     - e1000e: Fix CRC stripping in hardware context bug
     - PCI x86: always use conf1 to access config space below 256 bytes
     - moduleparam: fix alpha, ia64 and ppc64 compile failures
     - pata_hpt*, pata_serverworks: fix UDMA masking
     - SCSI advansys: fix overrun_buf aligned bug
     - NETFILTER: fix ebtable targets return
     - NETFILTER: Fix incorrect use of skb_make_writable
     - NETFILTER: nfnetlink_queue: fix SKB_LINEAR_ASSERT when mangling packet data
     - spi: pxa2xx_spi clock polarity fix
     - ufs: fix parenthesisation in ufs_set_fs_state()
     - hugetlb: ensure we do not reference a surplus page after handing it to buddy
     - file capabilities: simplify signal check
     - futex: runtime enable pi and robust functionality
     - futex: fix init order
     - ARM pxa: fix clock lookup to find specific device clocks
     - x86: replace LOCK_PREFIX in futex.h
     - SCSI aic94xx: fix REQ_TASK_ABORT and REQ_DEVICE_RESET
     - SCSI gdth: don't call pci_free_consistent under spinlock
     - SCSI ips: fix data buffer accessors conversion bug
     - usb-storage: don't access beyond the end of the sg buffer
     - fuse: fix permission checking
     - CRYPTO xts: Use proper alignment
     - CRYPTO xcbc: Fix crash with IPsec
     - SCSI ips: handle scsi_add_host() failure, and other err cleanups
     - x86: adjust enable_NMI_through_LVT0()
     - drivers: fix dma_get_required_mask
     - iov_iter_advance() fix
     - x86: Clear DF before calling signal handler (closes: #469058)
     - ub: fix up the conversion to sg_init_table()
     - MIPS: Mark all but i8259 interrupts as no-probe.
     - IRQ_NOPROBE helper functions
     - IPCOMP: Disable BH on output when using shared tfm
     - IPCONFIG: The kernel gets no IP from some DHCP servers
     - IPV4: Remove IP_TOS setting privilege checks.
     - IPV6: dst_entry leak in ip4ip6_err.
     - IPV6: Fix IPsec datagram fragmentation
     - NET: Fix race in dev_close(). (Bug 9750)
     - NET: Messed multicast lists after dev_mc_sync/unsync (closes: #466719)
     - NIU: Bump driver version and release date.
     - NIU: Fix BMAC alternate MAC address indexing.
     - NIU: More BMAC alt MAC address fixes.
     - TCP: Improve ipv4 established hash function.
     - SPARC: Fix link errors with gcc-4.3
     - SPARC64: Loosen checks in exception table handling.
 .
   [ Martin Michlmayr ]
   * [mips/r4k-ip22] Enable BLK_DEV_LOOP and BLK_DEV_CRYPTOLOOP.
   * [mips/r5k-ip32] Enable BLK_DEV_LOOP and BLK_DEV_CRYPTOLOOP.
   * [mips/r4k-ip22] Enable PPP, PPPOE and SLIP.
   * [mips/r5k-ip32] Enable PPP, PPPOE and SLIP.
   * Don't check the section size when we're cross compiling.
 .
   [ dann frazier ]
   * Remove cap_task_kill (closes: #463669)
Files: 
 efbfbb001ad6ce99beb7ab29cdb9c291 4297 devel optional linux-2.6_2.6.24-5.dsc
 a2c6f43db486207458ecf37fa042dac3 4409773 devel optional linux-2.6_2.6.24-5.diff.gz
 8be733ca517fca9b6dffe8d88c71517e 4283866 doc optional linux-doc-2.6.24_2.6.24-5_all.deb
 c877cc0ddaca81148172e4e85eeb6bb6 1536990 doc optional linux-manual-2.6.24_2.6.24-5_all.deb
 1a75c2e925661e72048ab0435bf0143a 649206 devel optional linux-patch-debian-2.6.24_2.6.24-5_all.deb
 4e40ee955b23900145b07a77b9efcf2b 45959174 devel optional linux-source-2.6.24_2.6.24-5_all.deb
 584b4eede3d554c7e38bdd2a702a1ca0 92564 devel optional linux-support-2.6.24-1_2.6.24-5_all.deb
 1ec553a3b6a7938de2856cd7b76ceb19 77680 devel optional linux-tree-2.6.24_2.6.24-5_all.deb
 278def9e428c3ce63f424595eee3d40b 19096156 admin optional linux-image-2.6.24-1-powerpc_2.6.24-5_powerpc.deb
 4061d953f0f4e52495abd3639e428ddd 311748 devel optional linux-headers-2.6.24-1-powerpc_2.6.24-5_powerpc.deb
 c13890c3c09129e05731e57e0f46168c 17353162 admin optional linux-image-2.6.24-1-powerpc-miboot_2.6.24-5_powerpc.deb
 30c6ba9410524ce974faf2f4e941d812 284028 devel optional linux-headers-2.6.24-1-powerpc-miboot_2.6.24-5_powerpc.deb
 1e7f73643de436cd7bcfe2d141d34dda 19380412 admin optional linux-image-2.6.24-1-powerpc-smp_2.6.24-5_powerpc.deb
 e4dc9593895d7533b37c845f09fbb0c7 311064 devel optional linux-headers-2.6.24-1-powerpc-smp_2.6.24-5_powerpc.deb
 61654e4d0699c5a88ca8bc01bd8b4813 21021086 admin optional linux-image-2.6.24-1-powerpc64_2.6.24-5_powerpc.deb
 c116f9d594b0c05effcd106231a25173 312470 devel optional linux-headers-2.6.24-1-powerpc64_2.6.24-5_powerpc.deb
 2b126ab4a2a4aa9b4874b3d5636739e7 3597654 devel optional linux-headers-2.6.24-1-common_2.6.24-5_powerpc.deb
 3e4635d0939a1cbbb55a16f2fb9c4936 77314 devel optional linux-headers-2.6.24-1-all_2.6.24-5_powerpc.deb
 c59bb93161c13b709e0980c172986db1 77342 devel optional linux-headers-2.6.24-1-all-powerpc_2.6.24-5_powerpc.deb
 d1fd585f0a41f7d5da8d37647eb75e2a 717124 devel optional linux-libc-dev_2.6.24-5_powerpc.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iEYEARECAAYFAkfrvX4ACgkQxWtQqFixGB4pJACgh5bd/vjgQkZsZ5wPjj627aht
wIwAmwQQOeF1D42Vowl+lnfnwYvvm1Jw
=7dNW
-----END PGP SIGNATURE-----





Reply sent to dann frazier <dannf@debian.org>:
You have taken responsibility. Full text and rfc822 format available.

Notification sent to aurel32@debian.org:
Bug acknowledged by developer. Full text and rfc822 format available.

Message #170 received at 469058-close@bugs.debian.org (full text, mbox):

From: dann frazier <dannf@debian.org>
To: 469058-close@bugs.debian.org
Subject: Bug#469058: fixed in linux-2.6 2.6.18.dfsg.1-19
Date: Sat, 05 Apr 2008 07:52:17 +0000
Source: linux-2.6
Source-Version: 2.6.18.dfsg.1-19

We believe that the bug you reported is fixed in the latest version of
linux-2.6, which is due to be installed in the Debian FTP archive:

linux-2.6_2.6.18.dfsg.1-19.diff.gz
  to pool/main/l/linux-2.6/linux-2.6_2.6.18.dfsg.1-19.diff.gz
linux-2.6_2.6.18.dfsg.1-19.dsc
  to pool/main/l/linux-2.6/linux-2.6_2.6.18.dfsg.1-19.dsc
linux-doc-2.6.18_2.6.18.dfsg.1-19_all.deb
  to pool/main/l/linux-2.6/linux-doc-2.6.18_2.6.18.dfsg.1-19_all.deb
linux-headers-2.6.18-6-all-ia64_2.6.18.dfsg.1-19_ia64.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.18-6-all-ia64_2.6.18.dfsg.1-19_ia64.deb
linux-headers-2.6.18-6-all_2.6.18.dfsg.1-19_ia64.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.18-6-all_2.6.18.dfsg.1-19_ia64.deb
linux-headers-2.6.18-6-itanium_2.6.18.dfsg.1-19_ia64.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.18-6-itanium_2.6.18.dfsg.1-19_ia64.deb
linux-headers-2.6.18-6-mckinley_2.6.18.dfsg.1-19_ia64.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.18-6-mckinley_2.6.18.dfsg.1-19_ia64.deb
linux-headers-2.6.18-6_2.6.18.dfsg.1-19_ia64.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.18-6_2.6.18.dfsg.1-19_ia64.deb
linux-image-2.6.18-6-itanium_2.6.18.dfsg.1-19_ia64.deb
  to pool/main/l/linux-2.6/linux-image-2.6.18-6-itanium_2.6.18.dfsg.1-19_ia64.deb
linux-image-2.6.18-6-mckinley_2.6.18.dfsg.1-19_ia64.deb
  to pool/main/l/linux-2.6/linux-image-2.6.18-6-mckinley_2.6.18.dfsg.1-19_ia64.deb
linux-manual-2.6.18_2.6.18.dfsg.1-19_all.deb
  to pool/main/l/linux-2.6/linux-manual-2.6.18_2.6.18.dfsg.1-19_all.deb
linux-patch-debian-2.6.18_2.6.18.dfsg.1-19_all.deb
  to pool/main/l/linux-2.6/linux-patch-debian-2.6.18_2.6.18.dfsg.1-19_all.deb
linux-source-2.6.18_2.6.18.dfsg.1-19_all.deb
  to pool/main/l/linux-2.6/linux-source-2.6.18_2.6.18.dfsg.1-19_all.deb
linux-support-2.6.18-6_2.6.18.dfsg.1-19_all.deb
  to pool/main/l/linux-2.6/linux-support-2.6.18-6_2.6.18.dfsg.1-19_all.deb
linux-tree-2.6.18_2.6.18.dfsg.1-19_all.deb
  to pool/main/l/linux-2.6/linux-tree-2.6.18_2.6.18.dfsg.1-19_all.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 469058@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
dann frazier <dannf@debian.org> (supplier of updated linux-2.6 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Thu, 03 Apr 2008 16:22:55 -0600
Source: linux-2.6
Binary: linux-image-2.6.18-6-vserver-powerpc linux-image-2.6.18-6-sparc32 linux-headers-2.6.18-6-r4k-kn04 linux-image-2.6.18-6-s390x linux-headers-2.6.18-6-r4k-ip22 linux-headers-2.6.18-6-xen-vserver-686 linux-headers-2.6.18-6-alpha-legacy linux-modules-2.6.18-6-xen-686 linux-headers-2.6.18-6-alpha-generic linux-headers-2.6.18-6-powerpc-miboot linux-headers-2.6.18-6-all-mips linux-image-2.6.18-6-r4k-ip22 linux-headers-2.6.18-6-powerpc-smp linux-headers-2.6.18-6-vserver-k7 xen-linux-system-2.6.18-6-xen-amd64 linux-manual-2.6.18 linux-image-2.6.18-6-footbridge linux-image-2.6.18-6-parisc-smp linux-image-2.6.18-6-s390 linux-image-2.6.18-6-xen-686 linux-image-2.6.18-6-amd64 linux-image-2.6.18-6-powerpc-miboot linux-headers-2.6.18-6-qemu linux-headers-2.6.18-6-mac linux-image-2.6.18-6-powerpc-smp linux-headers-2.6.18-6-rpc linux-image-2.6.18-6-xen-amd64 linux-headers-2.6.18-6-r5k-cobalt linux-headers-2.6.18-6-itanium linux-image-2.6.18-6-itanium linux-headers-2.6.18-6-vserver-sparc64 linux-image-2.6.18-6-powerpc linux-image-2.6.18-6-parisc linux-modules-2.6.18-6-xen-vserver-amd64 linux-image-2.6.18-6-parisc64-smp linux-headers-2.6.18-6-iop32x linux-image-2.6.18-6-sparc64-smp linux-image-2.6.18-6-686-bigmem linux-headers-2.6.18-6-all-mipsel linux-headers-2.6.18-6-all-ia64 linux-headers-2.6.18-6-ixp4xx linux-image-2.6.18-6-amiga linux-headers-2.6.18-6-all-m68k linux-image-2.6.18-6-r3k-kn02 linux-headers-2.6.18-6-mckinley linux-modules-2.6.18-6-xen-vserver-686 linux-image-2.6.18-6-alpha-legacy linux-image-2.6.18-6-alpha-smp linux-headers-2.6.18-6-xen-vserver-amd64 linux-headers-2.6.18-6-atari linux-image-2.6.18-6-vserver-powerpc64 linux-image-2.6.18-6-alpha-generic linux-headers-2.6.18-6-vserver-686 xen-linux-system-2.6.18-6-xen-vserver-686 linux-image-2.6.18-6-k7 linux-image-2.6.18-6-sb1a-bcm91480b linux-headers-2.6.18-6-all-hppa linux-headers-2.6.18-6-xen-amd64 linux-image-2.6.18-6-rpc linux-support-2.6.18-6 linux-doc-2.6.18 linux-headers-2.6.18-6-sparc64 linux-headers-2.6.18-6-all-amd64 linux-headers-2.6.18-6-sparc32 linux-headers-2.6.18-6-all-alpha linux-headers-2.6.18-6-alpha-smp linux-headers-2.6.18-6 linux-image-2.6.18-6-iop32x linux-image-2.6.18-6-vserver-k7 linux-image-2.6.18-6-parisc64 linux-headers-2.6.18-6-k7 linux-image-2.6.18-6-r5k-ip32 linux-image-2.6.18-6-r4k-kn04 linux-headers-2.6.18-6-all linux-image-2.6.18-6-atari linux-headers-2.6.18-6-vserver-powerpc linux-source-2.6.18 linux-headers-2.6.18-6-amd64 linux-headers-2.6.18-6-xen-686 linux-headers-2.6.18-6-r5k-ip32 linux-headers-2.6.18-6-sb1-bcm91250a linux-image-2.6.18-6-qemu linux-headers-2.6.18-6-xen linux-headers-2.6.18-6-prep linux-headers-2.6.18-6-all-sparc linux-image-2.6.18-6-mckinley linux-headers-2.6.18-6-vserver-s390x xen-linux-system-2.6.18-6-xen-vserver-amd64 linux-headers-2.6.18-6-footbridge linux-image-2.6.18-6-sb1-bcm91250a linux-image-2.6.18-6-xen-vserver-amd64 linux-image-2.6.18-6-mac xen-linux-system-2.6.18-6-xen-686 linux-image-2.6.18-6-r5k-cobalt linux-headers-2.6.18-6-s390x linux-image-2.6.18-6-xen-vserver-686 linux-headers-2.6.18-6-parisc64 linux-headers-2.6.18-6-parisc-smp linux-headers-2.6.18-6-r3k-kn02 linux-headers-2.6.18-6-s3c2410 linux-headers-2.6.18-6-xen-vserver linux-image-2.6.18-6-vserver-sparc64 linux-headers-2.6.18-6-686 linux-image-2.6.18-6-vserver-amd64 linux-headers-2.6.18-6-powerpc linux-headers-2.6.18-6-686-bigmem linux-image-2.6.18-6-686 linux-headers-2.6.18-6-amiga linux-image-2.6.18-6-vserver-686 linux-image-2.6.18-6-powerpc64 linux-headers-2.6.18-6-vserver-powerpc64 linux-headers-2.6.18-6-all-arm linux-image-2.6.18-6-sparc64 linux-headers-2.6.18-6-all-powerpc linux-image-2.6.18-6-486 linux-image-2.6.18-6-s3c2410 linux-headers-2.6.18-6-vserver-alpha linux-headers-2.6.18-6-parisc64-smp linux-image-2.6.18-6-prep linux-patch-debian-2.6.18 linux-headers-2.6.18-6-sparc64-smp linux-modules-2.6.18-6-xen-amd64 linux-tree-2.6.18 linux-image-2.6.18-6-s390-tape linux-headers-2.6.18-6-vserver-amd64 linux-image-2.6.18-6-vserver-s390x linux-image-2.6.18-6-vserver-alpha linux-headers-2.6.18-6-sb1a-bcm91480b linux-headers-2.6.18-6-powerpc64 linux-headers-2.6.18-6-all-i386 linux-headers-2.6.18-6-parisc linux-headers-2.6.18-6-s390 linux-headers-2.6.18-6-vserver linux-image-2.6.18-6-ixp4xx linux-headers-2.6.18-6-486 linux-headers-2.6.18-6-all-s390
Architecture: source ia64 all
Version: 2.6.18.dfsg.1-19
Distribution: stable
Urgency: high
Maintainer: Debian Kernel Team <debian-kernel@lists.debian.org>
Changed-By: dann frazier <dannf@debian.org>
Description: 
 linux-doc-2.6.18 - Linux kernel specific documentation for version 2.6.18
 linux-headers-2.6.18-6 - Common header files for Linux 2.6.18
 linux-headers-2.6.18-6-all - All header files for Linux 2.6.18
 linux-headers-2.6.18-6-all-ia64 - All header files for Linux 2.6.18
 linux-headers-2.6.18-6-itanium - Header files for Linux 2.6.18 on Itanium
 linux-headers-2.6.18-6-mckinley - Header files for Linux 2.6.18 on Itanium II
 linux-image-2.6.18-6-itanium - Linux 2.6.18 image on Itanium
 linux-image-2.6.18-6-mckinley - Linux 2.6.18 image on Itanium II
 linux-manual-2.6.18 - Linux kernel API manual pages for version 2.6.18
 linux-patch-debian-2.6.18 - Debian patches to version 2.6.18 of the Linux kernel
 linux-source-2.6.18 - Linux kernel source for version 2.6.18 with Debian patches
 linux-support-2.6.18-6 - Support files for Linux 2.6.18
 linux-tree-2.6.18 - Linux kernel source tree for building Debian kernel images
Closes: 466401 469058 470719 471427 473824
Changes: 
 linux-2.6 (2.6.18.dfsg.1-19) stable; urgency=high
 .
   [ Martin Michlmayr ]
   * [mips] Enable UART on RaQ1 (closes: #473824).
 .
   [ dann frazier ]
   * e1000: Add PCI-IDs for 82571EB 4-port cards (closes: #466401).
   * Fix potential nfs write corruption (closes: #470719)
   * [ia64] Fix multi-thread/nfs text corruption (closes: #471427).
 .
   [ Bastian Blank ]
   * [i386/amd64] Clear DF before calling signal handler. (closes: #469058)
Files: 
 0f7ea4103e090d7f9a156090f0294a7f 5662 devel optional linux-2.6_2.6.18.dfsg.1-19.dsc
 d1ed973e192795b55ab4d2867917fcee 5384246 devel optional linux-2.6_2.6.18.dfsg.1-19.diff.gz
 e74a3731ac89fce2845cce8fbd8cdbea 3589694 doc optional linux-doc-2.6.18_2.6.18.dfsg.1-19_all.deb
 879d589774fe1c33b6b848289a6e6d83 1085018 doc optional linux-manual-2.6.18_2.6.18.dfsg.1-19_all.deb
 265071ab13306d769ff70b7e37537b97 1585778 devel optional linux-patch-debian-2.6.18_2.6.18.dfsg.1-19_all.deb
 9871f68780353bd51c547cafd849bf0a 41463294 devel optional linux-source-2.6.18_2.6.18.dfsg.1-19_all.deb
 1d95b3d601c24344be1895a9564601f1 3735816 devel optional linux-support-2.6.18-6_2.6.18.dfsg.1-19_all.deb
 8428701762805d8ebb9e03af6a52a48f 54000 devel optional linux-tree-2.6.18_2.6.18.dfsg.1-19_all.deb
 043dd78c61c392dc021817b9f09d99f4 53480 devel optional linux-headers-2.6.18-6-all_2.6.18.dfsg.1-19_ia64.deb
 6de572157a52da1d9b135445c753de71 53498 devel optional linux-headers-2.6.18-6-all-ia64_2.6.18.dfsg.1-19_ia64.deb
 3f86b7207fe411a06c66fc12d10df8d3 3081340 devel optional linux-headers-2.6.18-6_2.6.18.dfsg.1-19_ia64.deb
 7719e421131814d56db8b1928127f2e3 28014540 admin optional linux-image-2.6.18-6-itanium_2.6.18.dfsg.1-19_ia64.deb
 2f3c4b013a565e8041ca6d1e3da232be 254860 devel optional linux-headers-2.6.18-6-itanium_2.6.18.dfsg.1-19_ia64.deb
 305276651992845a116e9fa51955be3e 28181824 admin optional linux-image-2.6.18-6-mckinley_2.6.18.dfsg.1-19_ia64.deb
 e00866b66276db62c91478740b582702 255722 devel optional linux-headers-2.6.18-6-mckinley_2.6.18.dfsg.1-19_ia64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFH9ZzFhuANDBmkLRkRAkFLAJ0b6tCkStQjUkV2MPitzVjemrpxBwCggIcu
uh14bqjVJ89+rmzO6mDydn4=
=Fif/
-----END PGP SIGNATURE-----





Forcibly Merged 469015 469058 471147 471598. Request was from Luca Capello <luca@pca.it> to control@bugs.debian.org. (Wed, 30 Apr 2008 14:39:06 GMT) Full text and rfc822 format available.

Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Sun, 27 Jul 2008 07:26:52 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Sun Apr 20 08:27:27 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.