go-ceph
go-ceph copied to clipboard
ceph
Violations of pointer passing rules
At least at one place we hand over Go pointers to the Ceph API that gonna get stored in a handler registry after the call returns, which violates the pointer passing rules: https://github.com/ceph/go-ceph/blob/312e4cf6b5cfb02e69768232d0fb0888a7ba51ba/rados/read_op.go#L80-L81 So there is no guarantee that the pointers remain valid.
With the iterator right before: https://github.com/ceph/go-ceph/blob/312e4cf6b5cfb02e69768232d0fb0888a7ba51ba/rados/read_op.go#L79 we are safe, since - as far as I can tell - it doesn't get stored anywhere.
Fixing this should largely just be a matter of allocating C-memory and storing C-pointers into our structs right?
Also, do you have any thoughts on why this wasn't caught by the stricter checking we enable with the env var?
Fixing this should largely just be a matter of allocating C-memory and storing C-pointers into our structs right?
Right. Or allocating the whole struct in C memory, if that is easier.
Also, do you have any thoughts on why this wasn't caught by the stricter checking we enable with the env var?
I think the checker can not do anything in this case, because it only can observe, what is passed to C, which is legal in this case. But it can't really check, what the C code is doing with the pointers. So we always have to be aware of that, to make sure, no ceph API is storing some pointers we are passing to it.
Isn't the byte buffer writeStep.cBuffer in write ops susceptible to the same problem as well and might need to be malloc'd?
https://github.com/ceph/go-ceph/blob/87f456311866ddf8c65911c4b0226cd5b5e7e4c2/rados/write_step.go#L25-L28
Isn't the byte buffer
writeStep.cBufferin write ops susceptible to the same problem as well and might need to bemalloc'd?https://github.com/ceph/go-ceph/blob/87f456311866ddf8c65911c4b0226cd5b5e7e4c2/rados/write_step.go#L25-L28
Yes, indeed. Thanks! Here we might use PtrGuard to break the rules. Else we need to copy the data.