Messages in this thread | | | Date | Fri, 08 Aug 2008 22:07:12 -0700 | From | Jeremy Fitzhardinge <> | Subject | Re: [ANNOUNCE] mdb-2.6.27-rc2-ia32-08-07-08.patch |
| |
Stefan Richter wrote: > jmerkey@wolfmountaingroup.com wrote: > >> The mdb-rc2 patch was posted this morning with the changes for a modular >> kernel debugger using kprobes. >> >> ftp://ftp.wolfmountaingroup.org/pub/mdb/mdb-2.6.27-rc2-ia32-08-07-08.patch >> >> Jeffrey Vernon Merkey >> > > > Quoting from this patch: > > >> +typedef struct _RLOCK >> +{ >> +#if defined(CONFIG_SMP) >> + spinlock_t lock; >> +#endif >> + unsigned long flags; >> + unsigned long processor; >> + unsigned long count; >> +} rlock_t; >> > > Is this something along the lines of a counting semaphore? As far as I > understand its accessor functions, an rlock > - can be taken by one CPU multiple times, > - will block the other CPUs as long as the first CPU hasn't unlocked > the rlock as many times as it locked it. > > The accessors rspin_lock() and rspin_try_lock() peek into spinlock_t and > may therefore not be fully portable. Also, they and rspin_unlock() > don't look SMP safe: > > >> +// >> +// returns 0 - atomic lock occurred, processor assigned >> +// 1 - recusive count increased >> +// >> + >> +unsigned long rspin_lock(volatile rlock_t *rlock) >> +{ >> +#if defined(CONFIG_SMP) >> + register unsigned long proc = get_processor_id(); >> + register unsigned long retCode; >> + >> + if (rlock->lock.raw_lock.slock && rlock->processor == proc) >>
Ticket locks will almost always have a non-zero slock. It doesn't indicate anything about the locked/unlocked state. But this looks like it's effectively doing a trylock:
if (!spin_trylock(rlock) && rlock->processor == proc) { rlock->count++; ... } else { rlock->processor = proc; ... }
J
| |