Remove locker.Locker from drivers/overlay

[mtrmac]

In all call paths, the layerStore owning the driver is expected to be locked, so, so this seems redundant.

See also #1140 (comment) .

[rhatdan]

LGTM
@vrothberg @nalind @giuseppe @saschagrunert PTAL

[mtrmac]

There are two other users of locker.Locker in drivers/aufs, driver/devmapper. It might make sense to remove them both as well (and then drop the locker package??).

---

Actually… c/storage/drivers.New is, in principle, available to external callers, and they would invoke the driver without the protection of layerStore’s lock. Do we need to worry about that?? At least a quick search can’t find any external code doing that…

[flouthoc]

@mtrmac [I could be wrong] Not a review at all , will try to review this in morning but just a comment if someone reviews this

• Could this open a race where d.Remove( can still be invoked while d.Put( is being invoked or vice-versa.
• Or a d.Get( can be performed while d.Put( / d,Remove( is being invoked.

I guess if layerstore is locked we might not have to worry but just leaving a comment here.

[giuseppe]

LGTM

[mtrmac]

• Could this open a race where d.Remove( can still be invoked while d.Put( is being invoked or vice-versa.
• Or a d.Get( can be performed while d.Put( / d,Remove( is being invoked.

Sure. The question if there is any path how that could happen. I.e.

• is there any call stack from c/storage.Store that doesn’t exclusively lock the layerStore lock) — I couldn’t find a path but I could well have overlooked something
• is it supported/possible to call the driver code without going through c/storage.Store. I wouldn’t know.

[rhatdan]

is it supported/possible to call the driver code without going through c/storage.Store. I wouldn’t know.

I would say no, we don't support this.

[flouthoc]

ah I see I don't think this is an issue then since if layerstore is locked then there might be no issue for any race.

[flouthoc]

LGTM