> On 26 Apr 2023, at 15:30, Hrvoje Popovski <hrv...@srce.hr> wrote: > > 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. >
Thanks for testing. It seems rtfree(rt->rt_parent) was called twice, so I’m confusing a little with this unlocked RTF_REJECT check.
