Loading ...
Sorry, an error occurred while loading the content.

Re: [blug-prog] Spin locks in SMP

Expand Messages
  • A.R Karthick
    Hi Suresh, ... 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
    Message 1 of 7 , Apr 1 12:04 AM
    • 0 Attachment
      Hi Suresh,

      > 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
      > right?
      > 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
      changes.
      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".

      Thanks,
      -Karthick

      --
      Software is like sex: it's better when it's free.
      -Linus Torvalds

      A.R.Karthick
      http://mir-os.sourceforge.net
    • suresh kumar
      Hi karthick, ... Thanks for the information given. This is really helpful in understanding the spin lock implementation. u have shown me some more pointers and
      Message 2 of 7 , Apr 1 1:20 AM
      • 0 Attachment
        Hi karthick,
        > 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".
        >


        Thanks for the information given. This is really helpful in understanding
        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.

        regards,
        Suresh

        --
        ______________________________________________
        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
      Your message has been successfully submitted and would be delivered to recipients shortly.