> 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:
>>>
>>>
>>>>
&
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
> >> exclusiv
> 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 ne
>
> 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”.
=
>> RCS file: /cvs/src/sys/netinet/if_ether.c,v
>> retrieving revision 1.248
>> diff -u -p -r1.248 if_ether.c
>> --- netinet/if_ether.c 28 Apr 2021 21:21:44 - 1.248
>> +++ netinet/if_ether.c 28 Apr 2021 21:44:22 -
>>
her.c28 Apr 2021 21:21:44 - 1.248
> +++ netinet/if_ether.c28 Apr 2021 21:44:22 -0000
> @@ -689,12 +689,15 @@ arpcache(struct ifnet *ifp, struct ether
> len = ml_len(&ml);
> while ((m = ml_dequeue(&ml)) != NULL)
> ifp->if_outp
error case
> that should not exist.
Such a diff is below. I will test extensively towmorrow. If anyone
wants to try now, be my guest.
Is the comment correct?
> There are a few more issues in the arp code once the concurrency goes up.
> The way the link-local address is updated looks no
if_ether.c
--- netinet/if_ether.c 27 Apr 2016 14:47:27 - 1.205
+++ netinet/if_ether.c 17 May 2016 12:42:10 -
@@ -83,6 +83,7 @@ void arptimer(void *);
struct rtentry *arplookup(u_int32_t, int, int, u_int);
void in_arpinput(struct mbuf *);
void in_revarpinput(struct mbuf *);
+int arpcache
