Hi,
Le 14.10.2013 17:21, Matan Barak a écrit :
On 11/10/2013 8:19 PM, Yann Droneaud wrote:
Flow spec length don't depend on the size of the command
header: they are part of different layers.
Signed-off-by: Yann Droneaud <ydrone...@opteya.com>
Link: http://marc.info/?i=ver.1381510045.git.ydrone...@opteya.com
Link: http://mid.gmane.org/cover.1381510045.git.ydrone...@opteya.com
---
drivers/infiniband/core/uverbs_cmd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/core/uverbs_cmd.c
b/drivers/infiniband/core/uverbs_cmd.c
index 3b732f6..1e5f0dd 100644
--- a/drivers/infiniband/core/uverbs_cmd.c
+++ b/drivers/infiniband/core/uverbs_cmd.c
@@ -2671,8 +2671,8 @@ ssize_t ib_uverbs_create_flow(struct
ib_uverbs_file *file,
if (cmd.flow_attr.num_of_specs > IB_FLOW_SPEC_SUPPORT_LAYERS)
return -EINVAL;
- if (cmd.flow_attr.size > (in_len - sizeof(cmd) - sizeof(struct
- ib_uverbs_cmd_hdr_ex)) || cmd.flow_attr.size >
+ if (cmd.flow_attr.size > (in_len - sizeof(cmd)) ||
+ cmd.flow_attr.size >
(cmd.flow_attr.num_of_specs * sizeof(struct
ib_kern_spec)))
return -EINVAL;
--
1.8.3.1
Hi,
I agree that it was better if the command size we pass to the uverb
didn't include the header size, but since the current implementation
of ib_uverbs_write and its user-space counterpart passes the command
size including the header - I think this fix is incorrect. I think
it'll actually break the current implementation.
You're correct. I'm wrong. I broke this.
I'm so wrong, I've sent a whole patchset that *didn't* take this into
account.
See http://mid.gmane.org/cover.1376847403.git.ydrone...@opteya.com
I had to re-read it again:
return uverbs_cmd_table[hdr.command](file, buf + sizeof hdr,
hdr.in_words * 4,
hdr.out_words * 4);
Seems I'm not mentally trained to accept that the input buffer size
is larger than buffer it's related to. I keep thinking it's written
return uverbs_cmd_table[hdr.command](file, buf + sizeof hdr,
hdr.in_words * 4 - sizeof
hdr, hdr.out_words * 4);
And that's what I've proposed in the extensible infrastructure.
Furthermore, patch 8 overwrites this anyway, so I guess we could
reduce this patchset size by removing it.
I will follow your advice.
Let's try for inclusion in v3.12-rc6
Regards.
--
Yann Droneaud
OPTEYA
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
