tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: m_reclaim & ieee1394_drain

On Mon, Dec 8, 2014 at 8:31 PM, Michael van Elst <> wrote:
> (Ryota Ozaki) writes:
>>On Mon, Dec 8, 2014 at 6:36 PM, Michael van Elst <> wrote:
>>> (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

> 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.


Home | Main Index | Thread Index | Old Index