On Fri, Jul 31, 2020 at 08:45:05AM +0200, Greg Kroah-Hartman wrote:
> On Thu, Jul 30, 2020 at 11:56:10AM +0200, Lukas Wunner wrote:
> > On Thu, Jul 30, 2020 at 08:53:26AM +0200, Greg Kroah-Hartman wrote:
> > > On Wed, Jul 08, 2020 at 03:27:02PM +0200, Lukas Wunner wrote:
> > > > kill_device() is cu
On Thu, Jul 30, 2020 at 11:56:10AM +0200, Lukas Wunner wrote:
> On Thu, Jul 30, 2020 at 08:53:26AM +0200, Greg Kroah-Hartman wrote:
> > On Wed, Jul 08, 2020 at 03:27:02PM +0200, Lukas Wunner wrote:
> > > kill_device() is currently serialized with driver probing by way of the
> > > device_lock(). W
On Thu, Jul 30, 2020 at 08:53:26AM +0200, Greg Kroah-Hartman wrote:
> On Wed, Jul 08, 2020 at 03:27:02PM +0200, Lukas Wunner wrote:
> > kill_device() is currently serialized with driver probing by way of the
> > device_lock(). We're about to serialize it with device_add() as well
> > to prevent ad
On Wed, Jul 08, 2020 at 03:27:02PM +0200, Lukas Wunner wrote:
> kill_device() is currently serialized with driver probing by way of the
> device_lock(). We're about to serialize it with device_add() as well
> to prevent addition of children below a device which is going away.
Why? Who does this?
kill_device() is currently serialized with driver probing by way of the
device_lock(). We're about to serialize it with device_add() as well
to prevent addition of children below a device which is going away.
However the parent's device_lock() cannot be taken by device_add()
lest deadlocks occur:
5 matches
Mail list logo