On Thu, 2019-03-21 at 19:11 -0400, Douglas Gilbert wrote: +AD4 That doesn't sound right. If it was correct then sg+AF8-open() and sg+AF8-release() +AD4 have mutex overkill (and I don't think that is caused by the complexity of +AD4 adding O+AF8-EXCL which is damn hard to implement correctly). +AD4 +AD4 Example with existing ch driver code, two threads T1 and T2: +AD4 +AD4 T1 T2 +AD4 +AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0 +AD4 f1 +AD0 open(+ACI-/dev/ch1+ACI) +AD4 .... +AD4 close(f1) f2 +AD0 open(+ACI-dev/sg1+ACI) +AD4 +AD4 +AD4 So if f2+AD0-open() gets ch (a pointer) but +AF8-before+AF8 it does kref+AF8-get(), +AD4 close(f1) gets in and does kref+AF8-put(+ACY-ch-+AD4-ref, ch+AF8-destroy), ref goes +AD4 to 0 and ch+AF8-destroy() gets called and now ch is dangling .... Hi Doug, I don't think that what you described can happen. The kref+AF8-put() call in ch+AF8-release() can only drop the final reference after ch+AF8-remove() has been called. Before ch+AF8-remove() calls kref+AF8-put() it removes the index from the idr so ch+AF8-open() won't find that index in the idr anymore. In other words, ch+AF8-open() can never encounter a zero refcount for an index that it found in the idr. Bart.
