From: Chuck Ebbert
David Laight david.lai...@aculab.com wrote:
From: Aaron Tomlin
Currently in the event of a stack overrun a call to schedule()
does not check for this type of corruption. This corruption is
often silent and can go unnoticed. However once the corrupted
region is
What's with the threading all versions together? Please don't do that --
also don't post a new version just for this though.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Thu, Sep 11, 2014 at 05:53:03PM +0200, Peter Zijlstra wrote:
What's with the threading all versions together? Please don't do that --
also don't post a new version just for this though.
Sorry about that. Noted.
--
Aaron Tomlin
___
Linuxppc-dev
From: Aaron Tomlin
Currently in the event of a stack overrun a call to schedule()
does not check for this type of corruption. This corruption is
often silent and can go unnoticed. However once the corrupted
region is examined at a later stage, the outcome is undefined
and often results in a
On Thu, 11 Sep 2014 16:02:45 +
David Laight david.lai...@aculab.com wrote:
From: Aaron Tomlin
Currently in the event of a stack overrun a call to schedule()
does not check for this type of corruption. This corruption is
often silent and can go unnoticed. However once the corrupted
On Thu, Sep 11, 2014 at 04:02:45PM +, David Laight wrote:
From: Aaron Tomlin
Currently in the event of a stack overrun a call to schedule()
does not check for this type of corruption. This corruption is
often silent and can go unnoticed. However once the corrupted
region is examined
