This is the mail archive of the systemtap@sources.redhat.com mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]