Messages in this thread |  | | | Date | Wed, 31 Jul 2002 10:37:37 -0700 | | From | Russell Lewis <> | | Subject | Re: [Linux-ia64] Linux kernel deadlock caused by spinlock bug |
| |
Sean Griffin wrote:
> >Mr. Lewis' solution fails to address the scenario of recursively >taken read locks. Since in that case, the thread taking the lock >already holds the lock, running some nops doesn't really give >another thread the possibility of acquiring the write lock. So >it works out to be the same situation only with a bunch of nops >executed in the critical path. > > >-Sean Griffin > Right. It's not a very good solution, just one of many hacks that might work :(
What if we kept a value (in per-CPU or per-thread memory) that was a pointer to the last r/w lock we'd gained? When we release ANY r/w lock, we could blindly initialize the "lastLock" pointer back to NULL. Then we have a very quick (i.e. not very good) heuristic for detecting recursive locks; if the "lastLock" pointer equals the pointer to the thing you're about to try to lock, then you know that you already hold it and are about to grab it recursively...otherwise, you fall back to other routines.
If you really wanted, you could keep multiple pointers per CPU (exact number tunable by a kernel #define), and on release only clear the one you are actually releasing. Most builds, I imagine, wouldn't need more than just a single pointer, though.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |