Violations of pointer passing rules

[ansiwen]

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:

go-ceph/rados/read_op.go

Lines 80 to 81 in 312e4cf

	&gos.more,
	&gos.rval,

So there is no guarantee that the pointers remain valid.

With the iterator right before:

go-ceph/rados/read_op.go

Line 79 in 312e4cf

&gos.iter,

we are safe, since - as far as I can tell - it doesn't get stored anywhere.

[phlogistonjohn]

Fixing this should largely just be a matter of allocating C-memory and storing C-pointers into our structs right?

[phlogistonjohn]

Also, do you have any thoughts on why this wasn't caught by the stricter checking we enable with the env var?

[ansiwen]

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.

[gman0]

Isn't the byte buffer writeStep.cBuffer in write ops susceptible to the same problem as well and might need to be malloc'd?

go-ceph/rados/write_step.go

Lines 25 to 28 in 87f4563

	func newWriteStep(b []byte, writeLen, offset uint64) *writeStep {
	return &writeStep{
	b: b,
	cBuffer: (*C.char)(unsafe.Pointer(&b[0])),

[ansiwen]

Isn't the byte buffer writeStep.cBuffer in write ops susceptible to the same problem as well and might need to be malloc'd?

go-ceph/rados/write_step.go

Lines 25 to 28 in 87f4563

	func newWriteStep(b []byte, writeLen, offset uint64) *writeStep {
	return &writeStep{
	b: b,
	cBuffer: (*C.char)(unsafe.Pointer(&b[0])),

Yes, indeed. Thanks! Here we might use PtrGuard to break the rules. Else we need to copy the data.

[gman0]

Do you have any ETA on this please, so that I can continue with PRs?