Dmitry Adamushko wrote:
yep, it's a problem since data may be client-dependent. In such a case, for a new client old messages are just irrelevant. And xnpipe_release() cleans up the queus but, well, does it too earlier.


1) should xnpipe_open_handler() and xnpipe_close_handler() be called without holding a lock?

Yes, it on purpose. I know this make things a bit trickier since this breaks the overall atomicity of the caller, but open/close hooks are expected to initiate/finalize communication sessions, and that may take an unbounded amount of time, so we definitely don't want to do this with the superlock being held.

they are not used currently so I can't see.

I intend to make xnpipe_open() completely atomic.

2) the cleaning of the queues (inq, outq) must take place atomically at the time when XNPIPE_USER_CONN is dropped.

it's about something like



// clean up all the queues


it looks like we can't make the whole xnpipe_release() atomic because of PREEMPT_RT + wake_up_interruptible_all() things, right? Or no.

You must _never_ _ever_ reschedule with the nucleus lock held; this is a major cause of jittery I recently stumbled upon that was induced by xnpipe_read_wait() at that time. So indeed, xnpipe_release() cannot be made atomic this way under a fully preemptible kernel.





Reply via email to