public inbox for ecos-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug 1001982] New: scheduler must be unlocked atomically on thread_entry (in SMP systems)
@ 2014-05-09 11:48 bugzilla-daemon
0 siblings, 0 replies; 2+ messages in thread
From: bugzilla-daemon @ 2014-05-09 11:48 UTC (permalink / raw)
To: ecos-bugs
Please do not reply to this email, use the link below.
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001982
Bug ID: 1001982
Summary: scheduler must be unlocked atomically on thread_entry
(in SMP systems)
Product: eCos
Version: 3.0
Target: All
Architecture/Host All
OS:
Status: UNCONFIRMED
Severity: critical
Priority: low
Component: Kernel
Assignee: unassigned@bugs.ecos.sourceware.org
Reporter: christoph.borchert@tu-dortmund.de
CC: ecos-bugs@ecos.sourceware.org
Created attachment 2507
--> http://bugs.ecos.sourceware.org/attachment.cgi?id=2507&action=edit
patch
Dear eCos developers,
on thread startup, the scheduler lock gets unlocked in a loop, testing the lock
status in each loop iteration:
while( get_sched_lock() != 0 )
unlock();
On an SMP system (or any other multi-core system), this piece of code is not
valid. Once the lock reaches zero, it could be taken immediately by another
CPU. In such a case, one CPU decrements the scheduler lock held by another CPU
- eventually corrupting kernel data or crashing the system.
Attached is a patch that solves this issue (and which is still valid for
single-core systems).
Best regards,
Christoph
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 2+ messages in thread
* [Bug 1001982] New: scheduler must be unlocked atomically on thread_entry (in SMP systems)
@ 2014-05-09 11:48 bugzilla-daemon
0 siblings, 0 replies; 2+ messages in thread
From: bugzilla-daemon @ 2014-05-09 11:48 UTC (permalink / raw)
To: unassigned
Please do not reply to this email, use the link below.
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001982
Bug ID: 1001982
Summary: scheduler must be unlocked atomically on thread_entry
(in SMP systems)
Product: eCos
Version: 3.0
Target: All
Architecture/Host All
OS:
Status: UNCONFIRMED
Severity: critical
Priority: low
Component: Kernel
Assignee: unassigned@bugs.ecos.sourceware.org
Reporter: christoph.borchert@tu-dortmund.de
CC: ecos-bugs@ecos.sourceware.org
Created attachment 2507
--> http://bugs.ecos.sourceware.org/attachment.cgi?id=2507&action=edit
patch
Dear eCos developers,
on thread startup, the scheduler lock gets unlocked in a loop, testing the lock
status in each loop iteration:
while( get_sched_lock() != 0 )
unlock();
On an SMP system (or any other multi-core system), this piece of code is not
valid. Once the lock reaches zero, it could be taken immediately by another
CPU. In such a case, one CPU decrements the scheduler lock held by another CPU
- eventually corrupting kernel data or crashing the system.
Attached is a patch that solves this issue (and which is still valid for
single-core systems).
Best regards,
Christoph
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2014-05-09 11:48 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-05-09 11:48 [Bug 1001982] New: scheduler must be unlocked atomically on thread_entry (in SMP systems) bugzilla-daemon
2014-05-09 11:48 bugzilla-daemon
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).