[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1e6d685a-66c3-3443-3b35-d7b0d0753a20@nvidia.com>
Date: Thu, 16 Jun 2022 11:33:11 -0700
From: Andy Roulin <aroulin@...dia.com>
To: Francesco Ruggeri <fruggeri@...sta.com>
Cc: Stephen Hemminger <stephen@...workplumber.org>,
netdev@...r.kernel.org
Subject: Re: neighbour netlink notifications delivered in wrong order
On 6/10/22 9:18 AM, Francesco Ruggeri wrote:
> On Thu, Jun 9, 2022 at 9:40 AM Francesco Ruggeri <fruggeri@...sta.com> wrote:
>>
>> On Mon, Jun 6, 2022 at 7:07 PM Andy Roulin <aroulin@...dia.com> wrote:
>>>
>>> Below is the patch I have been using and it has worked for me. I didn't
>>> get a chance yet to test all cases or with net-next but I am planning to
>>> send upstream.
>>
>> Thanks Andy, the patch fixes the reordering that I was seeing in my
>> failure scenario.
>
> I think that with this patch there may still be a narrower race
> condition, though probably not as bad.
> The patch guarantees that the notification is for the latest state change,
> but not necessarily the change that initiated the notification.
> In this scenario:
>
> n->nud_state = STALE
> write_unlock_bh(n->lock)
> n->nud_state = REACHABLE
> write_unlock_bh(n->lock)
> neigh_notify
> neigh_notify
>
> wouldn't both notifications be for REACHABLE?
Yes that's right, in this case it will consolidate both notifications to
be the same, i.e., last state.
Powered by blists - more mailing lists