[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aPtYvPq12Txu9JCG@stanley.mountain>
Date: Fri, 24 Oct 2025 13:45:16 +0300
From: Dan Carpenter <dan.carpenter@...aro.org>
To: Paolo Abeni <pabeni@...hat.com>
Cc: Lizhi Xu <lizhi.xu@...driver.com>, davem@...emloft.net,
edumazet@...gle.com, horms@...nel.org, kuba@...nel.org,
linux-hams@...r.kernel.org, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org,
syzbot+2860e75836a08b172755@...kaller.appspotmail.com,
syzkaller-bugs@...glegroups.com
Subject: Re: [PATCH V3] netrom: Prevent race conditions between neighbor
operations
On Thu, Oct 23, 2025 at 01:44:18PM +0200, Paolo Abeni wrote:
> Why reordering the statements as:
>
> if (nr_node->routes[2].neighbour->count == 0 &&
> !nr_node->routes[2].neighbour->locked)
> nr_remove_neigh(nr_node->routes[2].neighbour);
> nr_neigh_put(nr_node->routes[2].neighbour);
>
> is not enough?
There are so many unfortunate things like this:
net/netrom/nr_route.c
243 /* It must be better than the worst */
244 if (quality > nr_node->routes[2].quality) {
245 nr_node->routes[2].neighbour->count--;
++/-- are not atomic.
246 nr_neigh_put(nr_node->routes[2].neighbour);
247
248 if (nr_node->routes[2].neighbour->count == 0 && !nr_node->routes[2].neighbour->locked)
249 nr_remove_neigh(nr_node->routes[2].neighbour);
250
251 nr_node->routes[2].quality = quality;
252 nr_node->routes[2].obs_count = obs_count;
253 nr_node->routes[2].neighbour = nr_neigh;
This line should come after the next two lines.
254
255 nr_neigh_hold(nr_neigh);
256 nr_neigh->count++;
257 }
regards,
dan carpenter
Powered by blists - more mailing lists