Re: [PATCH][RFC] Linux VM hooks for advanced RDMA NICs

From: Brice Goglin
Date: Thu Apr 28 2005 - 02:22:36 EST

@@ -267,6 +270,11 @@
unsigned long hiwater_rss; /* High-water RSS usage */
unsigned long hiwater_vm; /* High-water virtual memory usage */
+ /* hooks for io devices with advanced RDMA capabilities */
+ struct ioproc_ops *ioproc_ops;

+ioproc_register_ops(struct mm_struct *mm, struct ioproc_ops *ip)
+ ip->next = mm->ioproc_ops;
+ mm->ioproc_ops = ip;
+ return 0;
+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;

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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at