On Wed, 6 Feb 2008, Greg KH wrote:
> On Tue, Jan 22, 2008 at 03:19:33PM -0500, Chuck Ebbert wrote:
> > On 01/22/2008 07:35 AM, Thomas Gleixner wrote:
> > >
> > > That's a long standing bug in both the PI futex and the standard futex
> > > code. Needs to go to stable as well.
> > >
> >
> >
On Wed, 6 Feb 2008, Greg KH wrote:
On Tue, Jan 22, 2008 at 03:19:33PM -0500, Chuck Ebbert wrote:
On 01/22/2008 07:35 AM, Thomas Gleixner wrote:
That's a long standing bug in both the PI futex and the standard futex
code. Needs to go to stable as well.
Here's the 2.6.23
On Thu, Feb 07, 2008 at 12:43:09AM +0100, Ingo Molnar wrote:
>
> * Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> > > I don't see this in Linus's tree, am I just missing it? Do you have
> > > a git commit id?
> >
> > Isn't this 9d55b9923a1b7ea8193b8875c57ec940dc2ff027 (possibly with
> >
On Thu, Feb 07, 2008 at 12:43:09AM +0100, Ingo Molnar wrote:
>
> * Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> > > I don't see this in Linus's tree, am I just missing it? Do you have
> > > a git commit id?
> >
> > Isn't this 9d55b9923a1b7ea8193b8875c57ec940dc2ff027 (possibly with
> >
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > I don't see this in Linus's tree, am I just missing it? Do you have
> > a git commit id?
>
> Isn't this 9d55b9923a1b7ea8193b8875c57ec940dc2ff027 (possibly with
> 2532ec6d178abc55681d049097d3dc577eaa266c on top)?
yeah.
Greg: note that this is
On Wed, 6 Feb 2008, Greg KH wrote:
>
> I don't see this in Linus's tree, am I just missing it? Do you have a
> git commit id?
Isn't this 9d55b9923a1b7ea8193b8875c57ec940dc2ff027 (possibly with
2532ec6d178abc55681d049097d3dc577eaa266c on top)?
Linus
--
To unsubscribe from
On Tue, Jan 22, 2008 at 03:19:33PM -0500, Chuck Ebbert wrote:
> On 01/22/2008 07:35 AM, Thomas Gleixner wrote:
> >
> > That's a long standing bug in both the PI futex and the standard futex
> > code. Needs to go to stable as well.
> >
>
> Here's the 2.6.23 version:
>
>
> Subject: x86: fix
On Tue, Jan 22, 2008 at 03:19:33PM -0500, Chuck Ebbert wrote:
On 01/22/2008 07:35 AM, Thomas Gleixner wrote:
That's a long standing bug in both the PI futex and the standard futex
code. Needs to go to stable as well.
Here's the 2.6.23 version:
Subject: x86: fix missing exception
On Wed, 6 Feb 2008, Greg KH wrote:
I don't see this in Linus's tree, am I just missing it? Do you have a
git commit id?
Isn't this 9d55b9923a1b7ea8193b8875c57ec940dc2ff027 (possibly with
2532ec6d178abc55681d049097d3dc577eaa266c on top)?
Linus
--
To unsubscribe from this
* Linus Torvalds [EMAIL PROTECTED] wrote:
I don't see this in Linus's tree, am I just missing it? Do you have
a git commit id?
Isn't this 9d55b9923a1b7ea8193b8875c57ec940dc2ff027 (possibly with
2532ec6d178abc55681d049097d3dc577eaa266c on top)?
yeah.
Greg: note that this is against
On Thu, Feb 07, 2008 at 12:43:09AM +0100, Ingo Molnar wrote:
* Linus Torvalds [EMAIL PROTECTED] wrote:
I don't see this in Linus's tree, am I just missing it? Do you have
a git commit id?
Isn't this 9d55b9923a1b7ea8193b8875c57ec940dc2ff027 (possibly with
On 01/22/2008 07:35 AM, Thomas Gleixner wrote:
>
> That's a long standing bug in both the PI futex and the standard futex
> code. Needs to go to stable as well.
>
Here's the 2.6.23 version:
Subject: x86: fix missing exception entry for SMP alternatives in futex macros
From: Thomas Gleixner
On Tue, 22 Jan 2008, Andi Kleen wrote:
> Chuck Ebbert <[EMAIL PROTECTED]> writes:
> >
> > There is a fixup, so this should never happen. But the lock instruction
> > was replaced with a nop by the altinstruction code, and that makes the fixup
> > address wrong. AFAICT we don't fix up the
On Tue, 22 Jan 2008, Andi Kleen wrote:
Chuck Ebbert [EMAIL PROTECTED] writes:
There is a fixup, so this should never happen. But the lock instruction
was replaced with a nop by the altinstruction code, and that makes the fixup
address wrong. AFAICT we don't fix up the exception table
On 01/22/2008 07:35 AM, Thomas Gleixner wrote:
That's a long standing bug in both the PI futex and the standard futex
code. Needs to go to stable as well.
Here's the 2.6.23 version:
Subject: x86: fix missing exception entry for SMP alternatives in futex macros
From: Thomas Gleixner [EMAIL
Chuck Ebbert <[EMAIL PROTECTED]> writes:
>
> There is a fixup, so this should never happen. But the lock instruction
> was replaced with a nop by the altinstruction code, and that makes the fixup
> address wrong. AFAICT we don't fix up the exception table when we replace
> a lock with a nop,
On 01/21/2008 03:47 PM, Chuck Ebbert wrote:
> Looking at the oops report from this bug:
>
> [bugzilla] https://bugzilla.redhat.com/show_bug.cgi?id=429412
> [oops] https://bugzilla.redhat.com/attachment.cgi?id=292260
>
> It was an unhandled page fault (protection violation.)
>
> I tracked
Looking at the oops report from this bug:
[bugzilla] https://bugzilla.redhat.com/show_bug.cgi?id=429412
[oops] https://bugzilla.redhat.com/attachment.cgi?id=292260
It was an unhandled page fault (protection violation.)
I tracked it down to the cmpxchg in this code:
Looking at the oops report from this bug:
[bugzilla] https://bugzilla.redhat.com/show_bug.cgi?id=429412
[oops] https://bugzilla.redhat.com/attachment.cgi?id=292260
It was an unhandled page fault (protection violation.)
I tracked it down to the cmpxchg in this code:
On 01/21/2008 03:47 PM, Chuck Ebbert wrote:
Looking at the oops report from this bug:
[bugzilla] https://bugzilla.redhat.com/show_bug.cgi?id=429412
[oops] https://bugzilla.redhat.com/attachment.cgi?id=292260
It was an unhandled page fault (protection violation.)
I tracked it down
Chuck Ebbert [EMAIL PROTECTED] writes:
There is a fixup, so this should never happen. But the lock instruction
was replaced with a nop by the altinstruction code, and that makes the fixup
address wrong. AFAICT we don't fix up the exception table when we replace
a lock with a nop, which makes
21 matches
Mail list logo
