Philippe Gerum wrote: > Jan Kiszka wrote: >> Jan Kiszka wrote: >>> The state tracking of Linux tasks queue on xnpipe events was fairly >>> broken. An easy way to corrupt some xnpipe_state_t object was to kill a >>> Linux task blocked on opening a /dev/rtpX device (this left the state >>> object queued in xnpipe_sleep, and hell broke loose on next queuing). >>> >>> Another problem that popped up after reworking xnpipe queuing was a >>> stalled XNPIPE_USER_CONN after receiving a signal in xnpipe_open. >>> >>> The following patch addresses both issues, appears to run fine so far >>> (at least the test case no longer triggers), and also cleans up some >>> redundant nklock acquisitions/releases. Nevertheless, I may miss some >>> corner case that might have triggered the original design. So please >>> check carefully. >> While fighting over a single bit elsewhere, let's not forget this open >> issue: > > I did not forget this issue. It is close to the top of stack now. > > Customer asks for a solution of the hard lock-up he faced, and >> /me would like to know if this fix comes with no obvious regressions. >> > > The patch looks sane, but I want to run a few tests that have been developed > over time to chase bugs in that code, before giving the patch a go. ETA: > tomorrow. >
Great, thanks. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux _______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
