On Thu, Jul 20, 2006 at 12:13:37PM -0400, Thor Lancelot Simon wrote:
> On Thu, Jul 20, 2006 at 10:44:00AM -0400, Sean Boudreau wrote:
> > On Thu, Jul 20, 2006 at 10:23:34AM -0400, Thor Lancelot Simon wrote:
> > > On Thu, Jul 20, 2006 at 10:14:32AM -0400, Sean Boudreau wrote:
> > > > On Thu, Jul 20, 2006 at 10:00:37AM -0400, Thor Lancelot Simon wrote:
> > > > > On Thu, Jul 20, 2006 at 09:46:51AM -0400, Sean Boudreau wrote:
> > > > > 
> > > > > > Are you sure in[6]_pcbpurgeif0(), in[6]_purgeif()
> > > > > > and in[6]_pcbpurgeif() need splsoftnet()?  This
> > > > > > seems to be outside the pool issue.
> > > > > 
> > > > > Yes, I'm sure: they can call the ICMP purge routine, which
> > > > > does pool_put.
> > > > 
> > > > I don't see it.  What routine exactly does the pool_put?
> > > 
> > > Sorry, IGMP.  igmp_purgeif() calls rti_delete, which does pool_put.
> > 
> > So why not just put the splsoftnet around that particular
> > pool_put?
> 
> It seemed simpler to just move the existing splsoftnet() call up by
> 3 lines -- and it protects us from anyone doing datastructure element
> removals or pool frees from inside any _other_ purge routine in the
> future.
> 

There's a tradeoff between getting the spl multiple
times and holding off interrupts for extended periods.
This seems like it could be a potentially big hammer
for this issue.

Regards,

-seanb