In one of my previous post entitled Latch acquisition/release call-graph : Dynamic tracing tools in action i have assumed that the function “ksl_get_shared_latch” (in version 126.96.36.199/188.8.131.52) took only 5 arguments :
- ksl_get_shared_latch(laddr, wait, why, where,mode)
As an exercise to my previous post Reverse engineering : What we need to know as a DBA ? i decided to take a deeper look
NOTE : This post contain no disassembly code of the oracle executable just the finding !
After examining some functions that call the function “ksl_get_shared_latch” such as “kcbo_link_q1” and “kcbzfb” it was easy to see that there are effectively 6 args :
- ksl_get_shared_latch(laddr, wait, why, where,mode,?)
The 6th argument is passed in the register R9 but what does it represent ?
Further investigation reveled that this value depend on the mode in which the latch is acquired (Shared or Exclusive) .
- In shared mode this parameter seem to be always equal to 1
- In exclusive mode this parameter is equal to the PID of the process masked with a constant value ( bitmask “PID or 0x2000000000000000” saved in the register R9)
I modified my scripts latch_callgraph.stp to show the new argument in register R9 :
We can see that when the latch is acquired in shared mode it’s value is 1 but in exclusive mode the lower bit represent the PID of the process who acquired the latch (PID 19 in this case “13 in hex”)
Let’s try to call the function using oradebug adding the new argument :
As of Andrey Nikolaev when a shared latch is acquired in exclusive mode the lower bit represent the PID of the holding process.Also 0x20000000 bit in the latch value is a flag for X mode.
Let’s first acquire a cache buffers chain latch with only 5 args :
Let’s now acquire a new cache buffers chain latch with all the 6 args :
The real process that acquired the latch have a PID of 29 but when calling the function i have managed to set another PID 13 (d in hex) in this case that was copied in the latch memory address.
So the arguments to the function ksl_get_shared_latch may look like :
In exclusive mode
- ksl_get_shared_latch(laddr, wait, why, where,mode,pid_with_x_flag)
In shared mode
- ksl_get_shared_latch(laddr, wait, why, where,mode,1)
UPDATE 13/10/2016 : It seems that Andrey Nikolaev and Stefan Koehler have already done a great work to figure out the 6th argument of the function “ksl_get_shared_latch” in the comment section of this blog post.Anyway as i stated it was only an example as an exercise to my previous post to demonstrate the power of disassembly in action.
That’s it 😀