Hi Andy
Here add one 'void *data' parameter just piont to the entry hdr in
ring buffer:
struct tcmu_cmd {
...
+ void *data; ===> pionting to entry hdr
...
}
When some cmds were expired, target_core_user will set the opcode in
the entry hdr to TCMU_OP_EXP(or reuse TCMU_OP_PAD here?), and then
the tcmu-runner will just skip all the TCMU_OP_EXP cmds, so is the
target_core_user.
I think this may cause race conditions. Once we "give" part of the cmd
ring to userspace, it's racy to change it because we don't know if
userspace has already accessed it, or not.
Thanks for you analysis, that's right.
We could put the new OP_EXP opcode on the cmd ring as a new entry.
This would ensure the old cmd's processing was terminated and not
finish out-of-order with a new cmd the initiator sent to retry the
aborted one, avoiding corruption. Implementing this could get a little
complicated because we'd need to handle if the cmd ring was full, and
prioritize queued OP_EXP opcodes over OP_CMD when ring space became
available.
Mike made me aware of this as an issue recently -- do you have any
further thoughts for how best to solve this?
How about implementing one API for the userspace to check whether the
tcmu_cmd is expired just before the runner is going to process the
corresponding entry. But this will make the ring buffer a bit more
inefficient.
Thanks,
BRs
Xiubo Li
Regards -- Andy
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
