Re: Re: Closing enbd devices

> Well, that's OK too, but it's fairly harmless (I am trying to get you to
> do the testing and development here, since you have the interest and
> the use for this particular functionality, and I don't - apologies).

Don't apologise, that's just how it should be. What I meant was that I
wanted to inform you about the quality (testedness) of the patch, so
that you (as maintainer of the source) could make a decision about
including the patch in the next enbd release or not. I don't know what
quality standards you operate by. I did not want you to test it for me
(but I really appriciate the help I've got here on the mailing list).

> I don't use "reset" so whatever you do there is OK with me :-). Be
> aware, however, that I somewhat doubt that reset can work as expected in
> many useful situations, because of all the race conditions associated
> with stopping a device.

Isn't this contrary to reset's comment:
 * This has no dangerous race condition, as we disable the device
 * rather than destroy it!
?

"all the race conditions" is kind of greek to me. Well, I do know what a
race condition is, but I'm not at all familiar with all the stuff going
on that could lead to it in this scenario.

Here's what I do when I need reset: Unmount the device lazily, kill
enbd-client, call reset on the device, then some waiting (possibly
minutes or hours), then reconnect and mount something else. No access on
the device but the mounting is done.

- Reset checks that refcount is 0, so no references will be left from
userspace (enbd-client).
- And if it is just marked disabled rather than destroyed, the kernel
will still get any requests satisfied in the same way that it did before
the reset? (since no enbd-clients are connected, that means I/O-error?)
- Upon reconnection with a different signature...well, one better make
sure no references to the device is around first. Is this where you
think the problem is?

Is it enough to make sure it is not actively used (ie mounted or
otherwise made accessible for a user), or would the kernel have
references to it lying around for a long time afterwards? If I take care
to stop using the device before resetting it then I'm fine? Obviously a
reset function shouldn't be used if the device could in any way still be
needed somewhere, but if the kernel could still give it requests after
all access from userspace and all mounts are stopped then it is worse.

> Perhaps I should introduce the state "stopped"? Maybe I could add
> the signature of the device to outgoing requests. Then if requests come
> back in bearing a signature that does not match, I could error them.
> 
> That would kill quite a lot of races, no?

Hmm. But I have no chance of doing this without learning a lot more
about enbd, and you probably wouldn't have any interest in it unless it
would also kill a lot of other races that you are struggling with...

// Dag Sverre