On Mon, Feb 01, 2010 at 12:01:13PM +0200, Alexander Motin wrote: > Pawel Jakub Dawidek wrote: > > On Sat, Jan 30, 2010 at 12:44:51PM +0100, Pawel Jakub Dawidek wrote: > >> Maybe I'll add how I understand what's going on: > >> > >> GEOM calls destroy_dev() while holding the topology lock. > >> > >> Destroy_dev() wants to destroy device, but can't because there are > >> threads that still have it open. > >> > >> The threads can't close it, because to close it they need the topology > >> lock. > >> > >> The deadlock is quite obvious, IMHO. > > > > Guys, changing destroy_dev() to destroy_dev_sched() in geom_dev.c fixes > > the problem for me (at least it makes race window so small that I can't > > reproduce it). Is there anyone who isn't happy with such a change? > > Have you done some locking there? Because my system crashes with such > straightforward change, when g_dev_close() called after geom node being > destroyed. Attached patch fixes that for me, but I have doubts that it > is complete. There is still seems to be a race with new I/O requests and > ioctl's, that are not protected by topology lock. At least if devfs code > doesn't handle it somehow. Devfs prevents new threads from entering cdevsw methods after destroy_dev_sched() is called. It is driver responsibility to take care about other code pathes that may access cdev.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:00 UTC