Project

General

Profile

Actions

Bug #14

closed

spinlock_try_lock() returns error if spinlock is successfully locked when tries=1

Added by danirod over 2 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
High
Assignee:
Category:
-
Start date:
12/31/2021
Due date:
% Done:

100%

Estimated time:

Description

When a spinlock_t is tried to be locked with the spinlock_try_lock() function using the tries=1 parameter, if the spinlock is able to be successfully locked it will return an error instead.

Or either the documentation for the spinlock_t data structure is confusing.

Also, what is exactly the x86_xchg_dword doing? Currently written in source:/arch/i386/kernel/cpu/spinlock.c@3efd6758 as:

static inline int x86_xchg_dword(int* memaddr, int val)
{
    int oldval = *memaddr;
    *memaddr = val;
    return oldval;
}

But this isn't exactly how xchg is supposed to work, right? Looking at the generated binary code through objdump -d spinlock.o all I see is:

00000070 <x86_xchg_dword>:
  70:   55                      push   %ebp
  71:   89 e5                   mov    %esp,%ebp
  73:   50                      push   %eax
  74:   8b 45 0c                mov    0xc(%ebp),%eax
  77:   8b 45 08                mov    0x8(%ebp),%eax
  7a:   8b 45 08                mov    0x8(%ebp),%eax
  7d:   8b 00                   mov    (%eax),%eax
  7f:   89 45 fc                mov    %eax,-0x4(%ebp)
  82:   8b 4d 0c                mov    0xc(%ebp),%ecx
  85:   8b 45 08                mov    0x8(%ebp),%eax
  88:   89 08                   mov    %ecx,(%eax)
  8a:   8b 45 fc                mov    -0x4(%ebp),%eax
  8d:   83 c4 04                add    $0x4,%esp
  90:   5d                      pop    %ebp
  91:   c3                      ret    
  92:   66 2e 0f 1f 84 00 00    nopw   %cs:0x0(%eax,%eax,1)
  99:   00 00 00 
  9c:   0f 1f 40 00             nopl   0x0(%eax)

I suppose that this is a dummy implementation that I did for placeholder purposes. I'm going to need soon to add spinlocks and I need this working fine.

Actions #1

Updated by danirod over 2 years ago

  • Status changed from New to Closed
  • % Done changed from 0 to 100

The bug is now fixed because spinlock v2 has been introduced in dc86e405:

  • It fixes the lock operation not being atomic by replacing the previous swap with the XCHG assembly instruction (at least for i386).
  • It removes the spinlock_try_lock() function, making the bug non-necessary to solve anymore. This function is not expected to be used either way.
Actions

Also available in: Atom PDF