On 03/07/2017 07:34 PM, Henning Schild wrote: > Am Fri, 26 Jun 2015 16:20:29 +0200 > schrieb Jan Kiszka <[email protected]>: > >> Hi, >> >> just pushed 3 patches to git.xenomai.org/xenomai-jki.git for-forge >> that are supposed to fix race conditions while manipulating >> xnthread::state and info (both need to be nklock-protected). Please >> review if finding and fixes make sense. >> >> cobalt/kernel: Fix locking for xnthread info manipulations >> cobalt/kernel: Fix locking for setting XNFPU >> cobalt/kernel: Rework thread debugging helpers >> >> Maybe some of the issues also exist in Xenomai 2, didn't check yet. > > After looking deeper into the the mysterious -EINTR i asked about a few > days ago we now got a trace that suggests something is going wrong. Jan > remembered the race in thread flag manipulation he found in Xeno3. > > I did not do a thorough code analysis yet but instead just put two > asserts into xnthread_set_info and xnthread_clear_info. > 1. !xnlock_is_owner(&nklock) > 2. xnpod_current_thread() != thread_to_update > > Both cases do happen. The flags are manipulated without holding the > lock and the flags are manipulated from another context. I guess that > suggests that the race found in xenomai3 is also in xenomai2. >
I would not compare both code bases. Much rewrite took place from the legacy nucleus to the cobalt core. I have reviewed every single statement involving set/clear info bits in 3.x and I can't seem to find any unlocked access for those. Any specifics about the exact locations where your debug statements trigger? -- Philippe. _______________________________________________ Xenomai mailing list [email protected] https://xenomai.org/mailman/listinfo/xenomai
