[Bug 1001982] New: scheduler must be unlocked atomically on thread_entry (in SMP systems)

[Bug 1001982] New: scheduler must be unlocked atomically on thread_entry (in SMP systems)

[bugzilla-daemon]

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.

[Bug 1001982] New: scheduler must be unlocked atomically on thread_entry (in SMP systems)

[bugzilla-daemon]

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.