> On 29 Apr 2021, at 02:48, Alexandr Nedvedicky
> <alexandr.nedvedi...@oracle.com> wrote:
>
> On Thu, Apr 29, 2021 at 02:30:48AM +0300, Vitaliy Makkoveev wrote:
>>
>>
>>> On 29 Apr 2021, at 02:20, Alexandr Nedvedicky
>>> <alexandr.nedvedi...@oracle.com> 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.
> */
Let’s assume only netlock serializes those paths.
