This is the mail archive of the
ecos-bugs@sourceware.org
mailing list for the eCos project.
[Bug 1001982] New: scheduler must be unlocked atomically on thread_entry (in SMP systems)
- From: bugzilla-daemon at bugs dot ecos dot sourceware dot org
- To: unassigned at bugs dot ecos dot sourceware dot org
- Date: Fri, 09 May 2014 11:48:40 +0000
- Subject: [Bug 1001982] New: scheduler must be unlocked atomically on thread_entry (in SMP systems)
- Authentication-results: sourceware.org; auth=none
- Auto-submitted: auto-generated
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.