Thanks, I finally got around to looking at this, and I applied the
infiniband/ulp/srp part of this to my tree. However, I noticed some
fishy things in other parts of the patch. First of all, the entire
user_mad.c diff you sent is:
> --- linux.orig/drivers/infiniband/core/user_mad.c
> +++ linux/drivers/infiniband/core/user_mad.c
> @@ -47,7 +47,7 @@
> #include <linux/kref.h>
>
> #include <asm/uaccess.h>
> -#include <asm/semaphore.h>
> +#include <linux/mutex.h>
>
> #include <rdma/ib_mad.h>
> #include <rdma/ib_user_mad.h>
it seems that you're just getting lucky that struct semaphore is
getting defined implicitly, since you didn't remove the actual
semaphore use.
The semaphore usage in user_mad.c seems a little tricky to convert to
a mutex, if I understand things correctly. The idea is that we create
a special file that turns on the "IsSM" bit on the InfiniBand port
when it's open (don't worry about what that means, really). We use a
semaphore to prevent anyone else from opening the file and trying to
be a SM until the first file is closed -- but of course the last
reference to a file might be dropped by a different process than the
one that opened it, so the up() might be called from a different
process than the original down().
Second, in the mthca changes, you have
> --- linux.orig/drivers/infiniband/hw/mthca/mthca_dev.h
> +++ linux/drivers/infiniband/hw/mthca/mthca_dev.h
> @@ -44,7 +44,9 @@
> #include <linux/pci.h>
> #include <linux/dma-mapping.h>
> #include <linux/timer.h>
> -#include <asm/semaphore.h>
> +#include <linux/mutex.h>
but again not all semaphore usages have been removed.
For example, a few lines later in the same file, we have:
> @@ -111,7 +113,7 @@ enum {
> struct mthca_cmd {
> struct pci_pool *pool;
> int use_events;
> - struct semaphore hcr_sem;
> + struct mutex hcr_mutex;
> struct semaphore poll_sem;
> struct semaphore event_sem;
so poll_sem and event_sem remain.
Again, these seem hard to convert to mutexes, especially event_sem.
The device firmware allows some number of commands to be queued up (64
is a typical number) and event_sem is used to keep track of when a
command slot is available. I guess I could rewrite things so that I
use something like wait_event() to block until there is a free command
slot, but I'm not convinced that's an improvement.
Thanks,
Roland
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
