Messages in this thread | ![/](/images/icornerl.gif) | | Date | Thu, 28 Apr 2005 09:21:13 +0200 | From | Brice Goglin <> | Subject | Re: [PATCH][RFC] Linux VM hooks for advanced RDMA NICs |
| |
> @@ -267,6 +270,11 @@ > > unsigned long hiwater_rss; /* High-water RSS usage */ > unsigned long hiwater_vm; /* High-water virtual memory usage */ > + > +#ifdef CONFIG_IOPROC > + /* hooks for io devices with advanced RDMA capabilities */ > + struct ioproc_ops *ioproc_ops; > +#endif > };
> +int > +ioproc_register_ops(struct mm_struct *mm, struct ioproc_ops *ip) > +{ > + ip->next = mm->ioproc_ops; > + mm->ioproc_ops = ip; > + > + return 0; > +} > + > +EXPORT_SYMBOL_GPL(ioproc_register_ops); > + > +int > +ioproc_unregister_ops(struct mm_struct *mm, struct ioproc_ops *ip) > +{ > + struct ioproc_ops **tmp; > + > + for (tmp = &mm->ioproc_ops; *tmp && *tmp != ip; tmp= &(*tmp)->next) > + ; > + if (*tmp) { > + *tmp = ip->next; > + return 0; > + } > + > + return -EINVAL; > +} > + > +EXPORT_SYMBOL_GPL(ioproc_unregister_ops);
You don't seem to use any synchronization mechanism to protect the ioproc list from concurrent modifications, right ? I understand that it might be useless as long as QsNet is the only user of ioprocs and takes care of locking the address space somewhere in the driver before adding/removing hooks. But, if this patch is to be merged to the mainline, you probably need to do something here. It's not clear how other in-kernel users (IB, Myri, Ammasso, ...) might use ioprocs. And actually, I think all ioproc list traversal need to be protected as well.
A spinlock_t ioproc_lock is probably appropriate here. I don't know whether any of the existing locks in the task_struct might be used instead.
Regards, Brice - 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/
| ![\](/images/icornerr.gif) |