deadlock avoidance?

[Johannes Erdfelt]

On Mon, Jan 31, 2000, Johannes Erdfelt <jerdfelt en sventech.com> wrote:
> On Wed, Dec 08, 1999, Davide Libenzi <dlibenzi en maticad.it> wrote:
> > Wednesday, December 08, 1999 1:53 AM
> > Johannes Erdfelt <jerdfelt en sventech.com> wrote :
> > > > All  pid and count modify fall inside 1) a nested lock ( ie. the task
> > > > already own the lock  : ++lock->count )
> > > > 2) a lock acquired  :  lock->pid = getpid()   and   ++lock->count
> > > 
> > > The setting is, but not all of the reading.
> > 
> > There is not test & set operations other than spin_... in my code.
> > Look at it better and try to find a sequence of operations that stall it.
> > 
> > struct s_nested_lock {
> >     spinlock_t lock;
> >     short int pid;
> >     short int count;
> > };
> > 
> > #define nested_lock(lock, flags) \
> >     if (lock->pid == getpid()) { \
> >         ++lock->count; \
> >     } else { \
> >         spin_lock_irqsave(&lock->lock, flags); \
> >         ++lock->count; \
> >         lock->pid = getpid(); \
> >     }
> > 
> > #define nested_unlock(lock, flags) \
> >     if (--lock->count == 0) { \
> >         lock->pid = 0; \
> >         spin_unlock_irqrestore(&lock->lock, flags); \
> >     }
> 
> Hate to bother you again, but I'm running into some issues.
> 
> getpid() is no longer implemented in 2.3 and using current->pid
> sometimes results in 0 which is causing the logic to fail (since we set
> the pid to 0 if the lock is not acquired)
> 
> Is there anyway to get a unique pid like number under 2.3 kernels?

I've switched it to using current instead of pid as this atleast allows
the code to work with a SMP kernel on a UP machine. However I'm far from
sure this is a safe solution.

JE


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo en vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/