Race condition on TCMU_CMD_ADDED_DEVICE
bno1 opened this issue · comments
Hello,
I was playing with tcmu-runner and the example handlers and I noticed that if I run tcmu-synthesizer and try to add a user:syn device in targetcli it sometimes fails with UserBackedStorageObject creation failed. Could this be caused by tcmu-runner because it replies to TCMU_CMD_ADDED_DEVICE before tcmu-synthesizer [1]?
[1] https://github.com/open-iscsi/tcmu-runner/blob/master/libtcmu.c#L217-L242
Do you have the tcmu-runner daemon and tcmu-synthesizer running at the same time?
If so, then I'm not sure what could happen. It's not supported to have multiple daemons. You will fail like you saw. I think this patch:
fixes that issue, but I think there was some more bugs, so I never got around to merging that patch.
Is this something you need to support? If so, test out that patch and feel free to send patches.
I think that pull request breaks stuff if no daemon has a handler for the added device. I think it would break what this PR tried to solve: #177.
Anyway, if multiple daemons are not supported, how does tcmu-synthesizer work with targetcli? It tries to register the handler with tcmu-runner over dbus, so I assumed that this is a valid use case. Also, if multiple daemons are not supported, then tcmulib_register shouldn't even exist.
If this is the case, then can you please add a disclaimer in the readme and tcmu-synthesizer explaining this so people don't waste their time trying this like I did.
Writing your own tcmu daemon is appealing because some applications are too big or complex to be contained in a tcmu-runner plugin, and libtcmu doesn't copy memory between the kernel and the handler, so I'm not the first or the last person to think of writing their own daemon.