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.

I suppose either way would really be fine.

Now I am looking at the pf code.  It looks as if there is an assumption
in that code that only its timeout routines are ever entered not at
splsoftnet -- but I am not sure that's true.  I really wish we had some
better documentation of which parts of our network stack can and can't
take which interrupts.

-- 
  Thor Lancelot Simon	                                     tls@rek.tjls.com

  "We cannot usually in social life pursue a single value or a single moral
   aim, untroubled by the need to compromise with others."      - H.L.A. Hart