Re: kern/41918: pppoe BROKEN: panic:kernel diagnostic assertion "!cpu_softintr_p()" ... subr_kmem.c

[Frank Kardel <kardel%netbsd.org@localhost>]

The following reply was made to PR kern/41918; it has been noted by GNATS.

From: Frank Kardel <kardel%netbsd.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: dyoung%netbsd.org@localhost
Subject: Re: kern/41918: pppoe BROKEN: panic:kernel diagnostic assertion 
"!cpu_softintr_p()"
 ... subr_kmem.c
Date: Sun, 23 Aug 2009 08:43:16 +0200

 Besides that there is always room for improvement, the problem occurred 
 just recently - a feeled 1-2weeks ago (I noticed it with my -current 
 update of last week).
 So it is likely the deferral of the setting of link-local and loopback 
 addresses to a thread. The workqueue setup code uses kmem_zalloc that 
 imports the non softintr
 requirement into in6_ifattach() (in6_ifattach.c:1.83 2009-08-13). Using 
 malloc() instead might be an option (in6_createmkludge()) does that.
 
 Frank
  
 Martin Husemann wrote:
 > The following reply was made to PR kern/41918; it has been noted by GNATS.
 >
 > From: Martin Husemann <martin%duskware.de@localhost>
 > To: gnats-bugs%NetBSD.org@localhost
 > Cc: 
 > Subject: Re: kern/41918: pppoe BROKEN: panic:kernel diagnostic assertion 
 > "!cpu_softintr_p()" ... subr_kmem.c
 > Date: Sun, 23 Aug 2009 00:32:58 +0200
 >
 >  On Sat, Aug 22, 2009 at 11:40:00AM +0000, kardel%pip.acrys.com@localhost 
 > wrote:
 >  > The violation of calling kmem_zalloc() (likely in
 >  > in6_ifaddrs_schedule()) from a softint seems clear.
 >  > Possibly pppoe shouldn't call in6_ifattach from softint.
 >  
 >  Pppoe does not call in6_ifattach, but if_up().
 >  I don't see why this should not be allowed from a softint (so IMHO the upper
 >  layers should be fixed instead), but if we decide it isn't allowed to do so,
 >  we could move it to a full thread context, though I don't like that either.
 >  
 >  The way IFF_UP is used in this code certainly is ... uhm ... "creative", 
 >  so completely reworking it is worth considering, but not as simple
 >  a task at it looks at first glance.
 >  
 >  Martin
 >  
 >