> On 29 Apr 2021, at 02:48, Alexandr Nedvedicky
> wrote:
>
> On Thu, Apr 29, 2021 at 02:30:48AM +0300, Vitaliy Makkoveev wrote:
>>
>>
>>> On 29 Apr 2021, at 02:20, Alexandr Nedvedicky
>>> wrote:
>>>
>>>
This time arpcache() is only called by netisr() with both kernel and
On Thu, Apr 29, 2021 at 02:30:48AM +0300, Vitaliy Makkoveev wrote:
>
>
> > On 29 Apr 2021, at 02:20, Alexandr Nedvedicky
> > wrote:
> >
> >
> >>
> >> This time arpcache() is only called by netisr() with both kernel and
> >> exclusive net locks held. RTM_DELETE message processing will also ca
> On 29 Apr 2021, at 02:20, Alexandr Nedvedicky
> wrote:
>
>
>>
>> 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 w
>
> 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.
> On 29 Apr 2021, at 01:38, Alexandr Nedvedicky
> wrote:
>
> Hello,
>
>
>> Such a diff is below. I will test extensively towmorrow. If anyone
>> wants to try now, be my guest.
>>
>> Is the comment correct?
>
>I think comment is not quite right.
>
>
>
> the packet gets inserted in
Hello,
> Such a diff is below. I will test extensively towmorrow. If anyone
> wants to try now, be my guest.
>
> Is the comment correct?
I think comment is not quite right.
the packet gets inserted into la->la_mq via arpresolve(), which
is not protected by KERNEL_LOCK().
arpresolve()
On Wed, Apr 28, 2021 at 03:31:41PM +0200, Claudio Jeker wrote:
> On Wed, Apr 28, 2021 at 02:56:27PM +0200, Alexandr Nedvedicky wrote:
> > I would say the la->la_mq queue should be empty once we dispatch all
> > packets to wire. If it is not empty, then something went wrong and
> > packets
