destroy_dev_sched(dev);
> > > free_unr(unithdr, unit);
> > >
> > > /* Wait for the cows to come home */
> >
> > From: Konstantin Belousov
> > Sent: Monday, June 11, 2012 3:53 PM
> > To: Steven Haber
> > Cc: freebsd-
rom: Konstantin Belousov
> Sent: Monday, June 11, 2012 3:53 PM
> To: Steven Haber
> Cc: freebsd-geom@freebsd.org
> Subject: Re: Geom / destroy_dev() deadlock
>
> Did you noted the comment above the block you changing ?
> The patch would cause races allowing arbitrary kernel memor
On Mon, Jun 11, 2012 at 03:27:39PM -0700, Steven Haber wrote:
> > I do not understand what you are proposing. Could you, please, show
> > the patch ?
>
> ---
> src/sys/geom/geom_dev.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/sys/geom/geom_dev.c b/src/sys/ge
gt; should be able to protect the cdev with just the devmtx,
provided
> > > > consumers of d_close(), d_open(), etc. ref and rel the dev
> > > > appropriately.
> >
> >
> > > From: Konstantin Belousov
> > > Sent: Monday, June 11, 2012 1:44
troy_dev_tq() holds the devmtx during the destroy and
> devfs
> >> uses this lock to take refs before calling into geom. To me it seems
> we
> >> should be able to protect the cdev with just the devmtx, provided
> >> consumers of d_close(), d_open(), etc. ref an
ble to protect the cdev with just the devmtx, provided
>> consumers of d_close(), d_open(), etc. ref and rel the dev
>> appropriately.
> From: Konstantin Belousov
> Sent: Monday, June 11, 2012 1:44 PM
> To: Steven Haber
> Cc: freebsd-geom@freebsd.org
> Subject: Re: Geom / de
On Mon, Jun 11, 2012 at 10:19:07AM -0700, Steven Haber wrote:
> Hey FreeBSD devs,
>
> I hope this is the right forum for this. I haven't used the FreeBSD
> mailing lists before. I'm a relatively new hire at EMC Isilon. We are
> using FreeBSD 7.0 as the basis for our scale-out NAS product line. We
Hey FreeBSD devs,
I hope this is the right forum for this. I haven't used the FreeBSD
mailing lists before. I'm a relatively new hire at EMC Isilon. We are
using FreeBSD 7.0 as the basis for our scale-out NAS product line. We
are frequently hitting the deadlock described here:
http://lists.freebs
