This is the mail archive of the
systemtap@sources.redhat.com
mailing list for the systemtap project.
RE: [RFC][PATCH]Atomically insert/remove probes
- From: "Lynch, Rusty" <rusty dot lynch at intel dot com>
- To: <prasanna at in dot ibm dot com>, "Keshavamurthy, Anil S" <anil dot s dot keshavamurthy at intel dot com>
- Cc: <systemtap at sources dot redhat dot com>
- Date: Wed, 25 May 2005 10:10:15 -0700
- Subject: RE: [RFC][PATCH]Atomically insert/remove probes
>> On many architecture it is not architecturally possible to atomically
>>insert or remove a probe as the size of the instruction to be patched
>>might exceed the atomic width of that architecture. Hence there is
>>alway a race condition where in, cpuN while inserting/removing a probe
at
>some
>>address, cpuM might be reading/executing at the same address. In this
>>case, cpuM if it see's old instruction then there is no issuess, but
if
>>it reads/executes the incompletely updated instruction, then this
might
>trigger
>>all sorts of uncertainty as the instruction which cpuM is executing
could
>>vary from random instruction to illegal instruction.
>
>Probably this case might be true in IA-64, but I cannot think of such a
>situation on intel i386 and x86_64 architecture. If you have a test
case,
>could you please post it.
>
>Thanks
>Prasanna
I think the best way of reproducing this for any architecture will be a
matter of stressing the system to increase the odds of hitting the race
condition. Another complicating factor in the likelihood of reproducing
this is the instruction cache.
So far I haven't see this race condition happen, but so far I haven't
had the time to do proper stress testing. I would think a test that:
* repeatedly calling a very small function so that a given instruction
is executed a significant portion of the given processor's time
* one another cpu, enter a tight loop of registering/unregistering a
kprobe on one of the instructions in that function
The hard part is to setup the test such that when the bug is trigger,
that it is very obvious.
--rusty