Re: [blug-prog] Spin locks in SMP
- Hi Suresh,
> Are u trying to think abt re-assembly stuff?I will pass this one to some other guy with networking knowledge, as
> Take the case of linux box behaving as router with IPSec functionality.
> There is an a sequence number in the ESP and AH headers.
> For anti reply check, this sequence no. is updated in the
> security device frequently. If they come out of order,
> for processing to the vpn module because of some spin locks,
> then there could be a drop of packets as they will not fall in the window,
> resulting of closing of connection. This is one example.
mine isnt enough to answer your question. But it cannot happen,man :-)
Lets take your next question, which is an interesting one and is pretty valid.
> If I am not wrong, lock instruction when executed, will only execute theYou are dead right, my friend.
> next instruction atomically. So only decb is executed atomically.
> decb and jns are not executed atomically. Decrement and testing are notYour suspicion regarding decrement and testing being not atomic are right, but
> atomic, and I am suspecting a race condition.
regarding race-conditions, they are wrong. The atomicity of "decb" is enough.
Lets see how, after tracking your doubts and concerns below.
> Just take this case, I am not sure whether this is valid or not.You just missed out on the specifics of "jns" check after the "lock;decb".
> Suppose cpu0 has executed the instructions lock;decb, atomically.
> u r trying to say that this will invalidate the cache of the other cpus,
> and other cpus cache will be updated with the decremented value. Am I
> If that is the case, suppose after the execution of the lock;decb, a hard
> irq is raised on cpu0. Now cpu1 has executed the lock;decb atomically.
> This will invalidate the cache of cpu0 also, and needs to be refreshed,
> if I am not wrong. When the cpu0 returned from hard-irq handler,
> it will execute the instruction jns to check the if the value is >=0.
> Since the value is decremented twice, it will not acquire the lock and
> all the cpus will be spinning.
Now its a question of explaining what "lock;decb" does thats
interrupt safe from the CPUs perspective that issued the instruction.
"lock;decb" apart from locking the memory bus and decrementing the
value of the spinlock variable in memory, also sets the "Signed FLAG"
or the "SF" flag in the processor FLAGS register.(the EFLAGS that you
can access with pushfl,popfl instructions).
This is done as part of "decb" instruction.
So once the memory bus is released for the other processor, the SF
flag would have been already updated in the CPU flags register.
So the next "jns" instruction checks for the SF flag in the FLAGS
register to determine whether to spin or not. Since registers are
local to the CPUs, its safe even if the other guy comes in and
Now if the CPU is interrupted after the "lock;decb" and before the "jns",
you already have the FLAGS register for the CPU updated. And registers
are saved/restored at exception/trap time.
To cut this short to prevent it into meandering into other
specifics-like kernel interrupt handling, the registers are saved and
restored at interrupt time. Eflags or the flags register is implicity
saved during interrupts, by the CPU along with "eip and cs", by
stacking it in the order as: "eip,cs,eflags".
An "iret" from the kernel would pop them back. Other registers are
saved by the kernel. If you want to know the order of register saves
on the stack- check out pt_regs structure in ptrace.h. And any further
knowledge, squeeze entry.S.
Hope this clears your very _valid_ confusion regarding the race
between "lock;decb" and "jns".
Software is like sex: it's better when it's free.
- Hi karthick,
> An "iret" from the kernel would pop them back. Other registers areThanks for the information given. This is really helpful in understanding
> saved by the kernel. If you want to know the order of register saves
> on the stack- check out pt_regs structure in ptrace.h. And any further
> knowledge, squeeze entry.S.
> Hope this clears your very _valid_ confusion regarding the race
> between "lock;decb" and "jns".
the spin lock implementation. u have shown me some more pointers and any
specific query, will get back to the list. Thanks again, and pl do forward
to me, if u get ne response from ur friend.
IndiaInfo Mail - the free e-mail service with a difference! www.indiainfo.com
Check out our value-added Premium features, such as an extra 20MB for mail storage, POP3, e-mail forwarding, and ads-free mailboxes!
Powered by Outblaze