[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 8/8] rpctrace: use condition variable to keep messages in seq

From: Kalle Olavi Niemitalo
Subject: Re: [PATCH 8/8] rpctrace: use condition variable to keep messages in sequence
Date: Mon, 31 Oct 2016 08:11:22 +0200
User-agent: Gnus/5.110007 (No Gnus v0.7) Emacs/23.0.51 (gnu/linux)

"Brent W. Baccala" <cosine@freesoft.org> writes:

> My solution is to signal the condition variable right before the call to
> mach_msg, but this creates a race condition where messages can get
> reordered.
> As you know, I never liked this blocking behavior of mach_msg, but I just
> can't see any way around it now.  If you can suggest something, let me
> know...

If rpctrace could detect whether the memory_object_data_request
RPC was caused by one of its threads, it could set the condition
variable on behalf of that thread then.  However, this won't work
if rpctrace doesn't see the memory_object_data_request message.
The original thread might have sent a memory_object_data_request
message to a pager not traced by rpctrace, and that pager might
then have sent a message to the traced task via a port wrapped by

If rpctrace could ask Mach whether the thread that was supposed
to call mach_msg is blocked because of a pager, that might solve
this.  IIRC, GNU Mach doesn't provide a way to ask that, but it
shouldn't be too hard to add.  rpctrace might have to
inefficiently poll the flag though.

Or examine the contents of the messages and use that to decide
whether they can be safely reordered.  In your example, vm_copy
should be safe to reorder against both mach_port_deallocate and
vm_allocate, if the address ranges and ports do not overlap.

Or implement system call tracing in GNU Mach.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]