On 26.4.2023. 12:15, Alexander Bluhm wrote: > On Wed, Apr 26, 2023 at 11:17:32AM +0200, Alexander Bluhm wrote: >> On Tue, Apr 25, 2023 at 11:57:09PM +0300, Vitaliy Makkoveev wrote: >>> On Tue, Apr 25, 2023 at 11:44:34AM +0200, Alexander Bluhm wrote: >>>> Hi, >>>> >>>> Mutex arp_mtx protects the llinfo_arp la_... fields. So kernel >>>> lock is only needed for changing the route rt_flags. >>>> >>>> Of course there is a race between checking and setting rt_flags. >>>> But the other checks of the RTF_REJECT flags were without kernel >>>> lock before. This does not cause trouble, the worst thing that may >>>> happen is to wait another exprire time for ARP retry. My diff does >>>> not make it worse, reading rt_flags and rt_expire is done without >>>> lock anyway. >>>> >>>> The kernel lock is needed to change rt_flags. Testing without >>>> KERNEL_LOCK() caused crashes. >>>> >>> Hi, >>> >>> I'm interesting is the system stable with the diff below? If so, we >>> could avoid kernel lock in the arpresolve(). >> I could not crash it. > I was too fast. Just after writing this mail I restarted the test.
Hi, my boxes are still ok with mvs@ diff even if I'm running arp -ad in loop.
