On Thu, Apr 29, 2021 at 02:30:48AM +0300, Vitaliy Makkoveev wrote:
>
>
> > On 29 Apr 2021, at 02:20, Alexandr Nedvedicky
> > <[email protected]> wrote:
> >
> > </snip>
> >>
> >> This time arpcache() is only called by netisr() with both kernel and
> >> exclusive net locks held. RTM_DELETE message processing will also call
> >> ifp->if_rtrequest() with exclusive netlock held.
> >>
> >> So this while() loop within arpcache() can’t be broken by “arp -a -d”.
> >
> > completely agree.
> >
> >>
> >> Also netlock serializes arpcache() and arpresolve().
> >>
> >
> > I agree arepcache() always runs as a writer on netlock + KERNEL_LOCK
> >
> > I suspect arpresolve() might be running also as a reader on netlock.
> > this happens when we forward packet. I think forwarded packets runs
> > arpresolve() as a reader on netlock, when it is dispatched/forwarded
> > to outbound interface.
>
> Sure, but this arpresolve() threads can’t insert packet to la->la_mq
> while we perform arpcache() because of exclusive netlock.
yes, indeed. no other thread can insert packet to queue, because we
own everything:
we run as a writer on netlock
we have a KERNEL_LOCK
OK now I see the bluhm's comment is OK. but still would like to see a notion we
also hold netlock exclusively (as I keep forgetting about it).
how about this:
/*
* Note: we run as a writer on netlock and we also own a kernel lock. No other
* CPU can insert to la_mq while we feed the packets to if_output(). If a
* packet is reinserted from there we have a loop. This should not happen and
* we want to find such cases.
*/
thanks and
regards
sashan
