On Thu, 2018-07-26 at 06:35 -0700, Tejun Heo wrote: +AD4- Making removal asynchronous this way sometimes causes issues because +AD4- whether the user sees the device released or not is racy. +AD4- kernfs/sysfs have mechanisms to deal with these cases - remove+AF8-self +AD4- and kernfs+AF8-break+AF8-active+AF8-protection(). Have you looked at those? Hello Tejun, The call stack in the patch description shows that sdev+AF8-store+AF8-delete() is involved in the deadlock. The implementation of that function is as follows: static ssize+AF8-t sdev+AF8-store+AF8-delete(struct device +ACo-dev, struct device+AF8-attribute +ACo-attr, const char +ACo-buf, size+AF8-t count) +AHs- if (device+AF8-remove+AF8-file+AF8-self(dev, attr)) scsi+AF8-remove+AF8-device(to+AF8-scsi+AF8-device(dev))+ADs- return count+ADs- +AH0AOw- device+AF8-remove+AF8-file+AF8-self() calls sysfs+AF8-remove+AF8-file+AF8-self() and that last function calls kernfs+AF8-remove+AF8-self(). In other words, kernfs+AF8-remove+AF8-self() is already being used. Please let me know if I misunderstood your comment. Thanks, Bart.
