Date: Mon, 16 Jul 2001 10:43:31 +0900 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei@isl.rdc.toshiba.co.jp> To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Cc: net@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: Use of M_WAITOK in if_addmulti(). Message-ID: <y7vhewdsl6k.wl@condor.jinmei.org> In-Reply-To: <200107152050.f6FKoae21142@khavrinen.lcs.mit.edu> References: <20010715120317.A99869@fump.kawo2.rwth-aachen.de> <20010716.001314.59549708.ume@mahoroba.org> <200107152050.f6FKoae21142@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> On Sun, 15 Jul 2001 16:50:36 -0400 (EDT), >>>>> Garrett Wollman <wollman@khavrinen.lcs.mit.edu> said: >> Current if_addmulti() calls MALLOC() with M_WAITOK. However, >> if_addmulti() can be called from in[6]_addmulti() with splnet(). It >> may lead kernel panic. > This is not a problem (or should not be). It is permissible to sleep > while some interrupts are blocked; it is just not (in 4-stable) > permissible to sleep in interrupt context. The PR that I sent a few > days ago was an example of one such circumstance. Is it really the > case that in6_addmulti() can be invoked in interrupt context, Yes, it is. in6_update_ifa() can be called under an interrupt context, as you pointed out, and it calls in6_joingroup(), which then calls in6_addmulti(). > and if > so, why? When a new unicast address is configured, the configuring node must be join the solicited-node multicast group corresponding to the unicast address. Since the autoconfiguration procedure runs under an interrupt context, the joining routine also runs under the context. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?y7vhewdsl6k.wl>