On 2015-06-26 17:07, Gilles Chanteperdrix wrote: > On Fri, Jun 26, 2015 at 04:20:29PM +0200, Jan Kiszka wrote: >> 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. > > At some point, one of info and state was supposed to be only > modified by the current thread, but I am not sure this still holds.
I vaguely remember something like this as well. From my analysis of today, this is no longer the case. > > Anyway, instead of adding explicit nklock sections around > xnthread_clear_info/xnthread_set_info, would not it be better to > have xnthread_clear_info/xnthread_set_info implicitly take the lock, > and add __xnthread_clear_info/__xnthread_set_info for the sections > where the caller already holds the nklock? That is an option, though we likely only have very few users of self-locking variants. Or we make those fields atomics, but that would affect all users. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux _______________________________________________ Xenomai mailing list [email protected] http://xenomai.org/mailman/listinfo/xenomai
