Skip to contentSkip to conversation

bug in ucma_accept()?

PATCH Steve Wise 2 participants 3 messages Jan 7, 2013 2 messages not in the archive InfiniBand

lore
Share & tools
lore

Steve Wise

author
#0 lore raw

Hey Sean,

Is this a bug? I think it is...

drivers/infiniband/core/ucma.c +6 -1
index 2709ff5..fb24f05 100644
@@ -806,8 +806,13 @@ static ssize_t ucma_accept(struct ucma_file *file, const ch
                if (!ret)
                        ctx->uid = cmd.uid;
                mutex_unlock(&file->mut);
-       } else
+       } else {
+               mutex_lock(&file->mut);
                ret = rdma_accept(ctx->cm_id, NULL);
+               if (!ret)
+                       ctx->uid = cmd.uid;
+               mutex_unlock(&file->mut);
+       }
 
        ucma_put_ctx(ctx);
        return ret;

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): 50EB1E49.7020807-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org

#2 lore raw
Quoted 12 lines

Is this a bug? I think it is...

drivers/infiniband/core/ucma.c +0 -0
index 2709ff5..fb24f05 100644
@@ -806,8 +806,13 @@ static ssize_t ucma_accept(struct ucma_file *file,

const ch

                 if (!ret)
                         ctx->uid = cmd.uid;
                 mutex_unlock(&file->mut);

drivers/infiniband/core/ucma.c static ssize_t ucma_accept(struct ucma_file *file, const ch · line 815

Quoted 8 lines
drivers/infiniband/core/ucma.c +6 -1
-       } else
+       } else {
+               mutex_lock(&file->mut);
                 ret = rdma_accept(ctx->cm_id, NULL);
+               if (!ret)
+                       ctx->uid = cmd.uid;
+               mutex_unlock(&file->mut);
+       }

The ctx->uid has already been set in the else case when the user explicitly created the cm_id. We only need to set it when the ctx has been created in the kernel for the user in response to a connection request (the 'if' part to the above else).

- Sean
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): 1828884A29C6694DAF28B7E6B8A8237346AEE645-P5GAC/[email protected]

author
#4 lore raw
Quoted 13 lines · Sean
Quoted 13 lines

Is this a bug? I think it is...

drivers/infiniband/core/ucma.c +0 -0
index 2709ff5..fb24f05 100644
@@ -806,8 +806,13 @@ static ssize_t ucma_accept(struct ucma_file *file,

const ch

                  if (!ret)
                          ctx->uid = cmd.uid;
                  mutex_unlock(&file->mut);

- } else

Quoted 10 lines

drivers/infiniband/core/ucma.c static ssize_t ucma_accept(struct ucma_file *file, const ch · line 815

Quoted 7 lines
drivers/infiniband/core/ucma.c +6 -0
+       } else {
+               mutex_lock(&file->mut);
                  ret = rdma_accept(ctx->cm_id, NULL);
+               if (!ret)
+                       ctx->uid = cmd.uid;
+               mutex_unlock(&file->mut);
+       }

The ctx->uid has already been set in the else case when the user explicitly created the cm_id. We only need to set it when the ctx has been created in the kernel for the user in response to a connection request (the 'if' part to the above else).

Ah. Thanks for clarifying...

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html