Messages in this thread | | | From | Rusty Russell <> | Subject | Re: [PATCH]updated ipc lock patch | Date | Fri, 25 Oct 2002 17:27:37 +1000 |
| |
In message <3DB8DC72.6A08C74F@us.ibm.com> you write: > > This is unacceptable crap, sorry. You *must* allocate the resources > > required to free the object *at the time you allocate the object*, > > since freeing must not fail. > > > > > Even better: is it possible to embed the rcu_ipc_free inside the > > > object-to-be-freed? Perhaps not? > > > > Yes, this must be done. > > > I thought about embed rcu_ipc_free inside the ipc_ids structure before. > But there could be a problem if grow_ary() is called again before the > old array associated with the previous grow_ary() has not scheduled to > be freed yet. I see a need to do that now, as you made very good point. > I will make the changes tomorrow.
You don't need to allocate it in the object, but you *do* need to fail grow_ary() if you can't allocate it.
I had the same dilemma when I tried to write a generic "kfree_rcu(void *)" last year: you simply can't do it 8(
Cheers, Rusty. -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. - 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/
| |