On Mon, Dec 8, 2014 at 8:31 PM, Michael van Elst <[email protected]> wrote: > [email protected] (Ryota Ozaki) writes: > >>On Mon, Dec 8, 2014 at 6:36 PM, Michael van Elst <[email protected]> wrote: >>> [email protected] (Ryota Ozaki) writes: >>> >>>>pr_ddain and if_drain memory reclaiming routines >>>>are called from m_reclaim. Most of them are delayed, >>> >>> Where do you see if_drain routines? >>> >>> ./arch/arm/allwinner/awin_eth.c: ifp->if_drain = awin_eth_ifdrain; >>> -> a donothing routine >>> >>> ./net/if.c: ifp->if_drain = if_nulldrain; >>> -> the official donothing routine, set when the interface gets deactivated >>> where setting the pointer to NULL would be ok. >>> >>> ./net/if_ieee1394subr.c: ifp->if_drain = ieee1394_drain; >>> -> the only one that does something. > >>I misspelled. s/pr_ddain/pr_drain/ > >>Anyway I should say clearly that pr_drain routines are delayed >>(such as tcp_drainstub and ip_drainstub) and only ieee1394_drain >>is not delayed. > > Maybe it is better then to add the delay into the reclaim function. > That way it doesn't need to be handled by each driver that wants > to implement if_drain.
Hmm, I mislead you again... I meant putting ieee1394_drain out of m_reclaim and execute it in another context (callout in this case). > > Would if_drain even require a kernel_lock when it is just freeing > memory? I think it's still required for protecting list processing rather than freeing memory, though it is better to use a mutex inside ieee1394_drain for that purpose. And such locking should be out of IFNET_FOREACH for pserialize if possible. ozaki-r
