> Are u trying to think abt re-assembly stuff?
> 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.
I will pass this one to some other guy with networking knowledge, as
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 the
> next instruction atomically. So only decb is executed atomically.
You are dead right, my friend.
> decb and jns are not executed atomically. Decrement and testing are not
> atomic, and I am suspecting a race condition.
Your suspicion regarding decrement and testing being not atomic are right, but
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.
> 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.
You just missed out on the specifics of "jns" check after the "lock;decb".
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.