Re: struct ifnet and ifaddr handling [was: Re: Making global variables of if.c MPSAFE]

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

   Date: Mon, 24 Nov 2014 15:26:21 +0900
   From: Masao Uebayashi <uebayasi%gmail.com@localhost>

   (I'm trying, but I can't follow up all mails soon, because I need more
   than x2 energy & time to write English than you.)

I understand!  I will keep this one brief.

   On Mon, Nov 24, 2014 at 12:12 PM, Taylor R Campbell
   <campbell+netbsd-tech-kern%mumble.net@localhost> wrote:
   > Can you (or ozaki-r@, whose earlier patch I missed until now) explain
   > specifically what this accomplishes?  I have two guesses about the
   > primary goal of this change: either
   >
   > (a) to obviate the need to run if_watchdog/if_slowtimo callbacks
   > inside IFNET_FOREACH, or

   I was thinking of this first.

OK!

   > In case (a), what might an interface do in an if_watchdog/if_slowtimo
   > callback that is safe in a callout but not safe inside a pserialized
   > reader?  Is it simply that it's sort-of-kind-of OK for a callout to
   > block a little, but absolutely not OK for a pserialized reader to
   > block and thus switch?

   I have believed that pserialize(9) reader-side is a critical section.
   pserialize(9) relies on scheduler to notify that readers have passed
   throught those pserialize(9) protected code paths, by calling
   pserialize_switchpoint() from mi_switch().  This obviously implies
   that threads can't sleep from within those pserialize(9) protected
   code paths.  Otherwise that notification has a different meaning.

Yes, that's right.

Ideally, we should avoid blocking much in callouts too.

   I think pserialize_read_{enter,exit}() should explicitly call
   KPREEMPT_{DISABLE,ENABLE}(), as is done in percpu_{getref,putref}().

Not necessary -- splsoftserial is sufficient to prevent switching, and
is necessary to block the pserialize cross-call until the reader is
finished.