On Fri, 27 Jul 2001, Matthew Dharm wrote:
>
> Hrm... just to be clear, then... this only is a problem with semaphores
> that are declared on the local stack?
Yes.
In theory you can have the same problem on any allocation that is free'd
after the semaphore has been used, but most (hopefully all) other forms of
allocations should be using proper reference counting etc, so that it is
impossible for a semaphore user to have the semaphore disappear from under
it.
> IIRC, usb-storage only uses semaphores that are allocated via kfree, so I
> think we're okay. Tho, I think the new semantics are probably better, and
> will probably switch to them. Later.
If you're using kmalloc/kfree, just make sure that the kfree never happens
early (ie the "down()" does not protect the kfree, but some other
reference count or lock does).
If you have
CPU #1 CPU #2
down(mem->semaphore); up(mem->semaphore);
kfree(mem);
you can still have the same bug.
But if you have
CPU #1 CPU #2
down(mem->semaphore) up(mem->semaphore);
put(mem); put(mem);
where "put(mem)" does something like
if (atomic_dec_and_test(&mem->refcount))
kfree(mem);
then you're obvoiusly ok, because now the free'ing of the data structure
cannot happen until all users have handed off on it.
Linus
-
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/
This archive was generated by hypermail 2b29 : Tue Jul 31 2001 - 21:00:36 EST