Date: Mon, 25 Oct 2004 10:14:45 -0700 From: John-Mark Gurney <gurney_j@resnet.uoregon.edu> To: Sam <sah@softcardsystems.com> Cc: freebsd-arch@freebsd.org Subject: Re: 6.0 Witness squawk Message-ID: <20041025171445.GE22681@funkthat.com> In-Reply-To: <Pine.LNX.4.60.0410251215290.29901@athena> References: <Pine.LNX.4.60.0410251037540.29901@athena> <Pine.LNX.4.60.0410251126010.29901@athena> <xzpk6tedbrc.fsf@dwp.des.no> <Pine.LNX.4.60.0410251215290.29901@athena>
next in thread | previous in thread | raw e-mail | index | archive | help
Sam wrote this message on Mon, Oct 25, 2004 at 12:22 -0500:
> >Sam <sah@softcardsystems.com> writes:
> >>There are three entry points into the driver. 1) The disk
> >>layer 2) the netisr routine 3) the rexmit timer.
> >
> >AFAIK, if the code that calls malloc() can be reached from 2) or 3),
> >you're not allowed to use M_WAITOK.
>
> Hm. If that's true then I've either got to petition you
> fellas to change disk_alloc(), disk_create(), and disk_destroy()
> to use M_NOWAIT or schedule a callback where these calls
> can be handled properly.
>
> Thoughts about either approach?
I'd go and do a callback.. You can do that using the generic taskqueue
setup for this task... It's not an event that happens often, so the
delay to schedule and execute won't be significant...
Changing disk_alloc and friends to use M_NOWAIT would have significant
implications to other code...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041025171445.GE22681>