![]() | |||||||||||||
Messages in this thread |
Dipankar Sarma wrote: > > On Mon, Oct 28, 2002 at 02:20:04AM +0100, Rusty Russell wrote: > > Yes, nonsensical. Firstly, it's in violation of the standard to fail > > IPC_RMID under random circumstances. Secondly, failing to clean up is > > an unhandlable error, since you're quite possible in the failure path > > of the code already. This is a well known issue. > > I am not sure how Ming/Hugh's current IPC changes affect IPC_RMID. > It affects only when you are trying to add a new ipc. In fact, > since it is a *add* operation (grow_ary()), it seems ok to fail it if rcu_head > allocation fails. Feel free to correct me if I missed something here. > AFAICS, the rcu stuff doesn't affect any freeing other than the IPC > id array. > We extended the usage of RCU to IPC_RMID, to prevent ipc_lock() returning an invalid IPC ID which has been removed by ioc_rmid. > > It's a hacky, fragile and incorrect solution. It's completely > > tasteless. > > Yes, the mempool code is broken, but only because rcu_backup_pool > is created three times, one by each IPC mechanism init :-) > That's my bad, thanks for pointing this out. It's easy to fix if we decide to go with mempool way. > > Patch below is against Mingming's mm4 release. Compiles, untested. > > Rusty. > > Yes, this is the typical RCU model, except that in this case (IPC), > I am not quite sure if it is in effect that different from what Ming/Hugh > have done. Rusty's patch looks good to me. I would like to replace the mempool in IPC with this typical RCU model. Rusty, if you like, I will make a patch against mm6. There need some cleanups. One thing is that ipc_alloc() are called by other places(besides grow_ary()), and they don't need to the RCU header structure. Mingming - 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/ | ||||||||||||
| Last update: 2005-03-22 12:30 [from the cache] ©2003-2008 | |||||||||||||