Unsure what makes this protocol safe... Some better comments might help, or else there seems to be an issue with the code.

It would have been sufficient to wait until the providers leave the doorstep (upon nend reaching nstart), but there is no notification for that.

Because that is not a normal operation logic, but a dirty hacky workaround for broken classes, that do not wait for I/O completion before closing provider (there were some, most IIRC are fixed now). This code just should not be there, and that is why it has no notification.

I have no specific objections about this patch, but I am not sure it really needs to use providergone method, that was not in original GEOM design and was added as workaround. softc could be freed on the last close. In case of gmirror, for example, providergone has to be used, since it uses custom locks and require topology lock to be dropped during g_mirror_access() call, that created a race window. This class seems less complicated, there is no any lock magic, so it could work in original GEOM logic, tracking opens instead.

@mav thank you for the suggestion! Just to clarify, do you mean adding tracking of the open provider count into g_slice_access ?

In D12809#266148, @avg wrote:

Just to clarify, do you mean adding tracking of the open provider count into g_slice_access ?

Yes. You may see, for example, how gmultipath uses sc->sc_opened.

In D12809#266149, @mav wrote:

In D12809#266148, @avg wrote:

Just to clarify, do you mean adding tracking of the open provider count into g_slice_access ?

Yes. You may see, for example, how gmultipath uses sc->sc_opened.

Thank you! How does the new version look?

The idea looks fine, but logic of gsp->nopen and d_nopen in g_slice_access() looks over-engineered. I suppose gsp->nopen will never be above 1 here. I think you could even use just (cp->acr == 0 && cp->acw == 0 && cp->ace == 0) expression instead of additional open counter.

In D12809#266162, @mav wrote:

The idea looks fine, but logic of gsp->nopen and d_nopen in g_slice_access() looks over-engineered. I suppose gsp->nopen will never be above 1 here.

I think that gsp->nopen can be as high as slices parameter passed to g_slice_new that is greater than one for several geom classes.
There is some confusing naming, but gsp does not correspond to a single slice, it represents a "slicer" with potentially many slices.

I think you could even use just (cp->acr == 0 && cp->acw == 0 && cp->ace == 0) expression instead of additional open counter.

Do you mean cp as the consumer used by g_slice to access the underlying provider?
Looks like that can work, let me think about it.

Thanks!

In D12809#266212, @avg wrote:

In D12809#266162, @mav wrote:

The idea looks fine, but logic of gsp->nopen and d_nopen in g_slice_access() looks over-engineered. I suppose gsp->nopen will never be above 1 here.

I think that gsp->nopen can be as high as slices parameter passed to g_slice_new that is greater than one for several geom classes.
There is some confusing naming, but gsp does not correspond to a single slice, it represents a "slicer" with potentially many slices.

But (cp->acr == 0 && cp->acw == 0 && cp->ace == 0) in g_slice_access() will be true only once until all slices will be closed, since cp here is a lower level consumer and it is opened by every slice.

I think you could even use just (cp->acr == 0 && cp->acw == 0 && cp->ace == 0) expression instead of additional open counter.

Do you mean cp as the consumer used by g_slice to access the underlying provider?

Yes, I am talking about line 127 as an example.

Nice improvements, I learned some interesting details while following these improvements :-)