diff options
| author | Kuniyuki Iwashima <[email protected]> | 2025-07-16 22:08:19 +0000 |
|---|---|---|
| committer | Jakub Kicinski <[email protected]> | 2025-07-17 23:25:21 +0000 |
| commit | 13a936bb99fb6385dc8620d24d7111e514448371 (patch) | |
| tree | 35c5d9fe24899669317ff356014991ea7430b9d5 /drivers/usb/cdns3/cdns3-trace.h | |
| parent | neighbour: Drop read_lock_bh(&tbl->lock) in pneigh_lookup(). (diff) | |
| download | kernel-13a936bb99fb6385dc8620d24d7111e514448371.tar.gz kernel-13a936bb99fb6385dc8620d24d7111e514448371.zip | |
neighbour: Protect tbl->phash_buckets[] with a dedicated mutex.
tbl->phash_buckets[] is only modified in the slow path by pneigh_create()
and pneigh_delete() under the table lock.
Both of them are called under RTNL, so no extra lock is needed, but we
will remove RTNL from the paths.
pneigh_create() looks up a pneigh_entry, and this part can be lockless,
but it would complicate the logic like
1. lookup
2. allocate pengih_entry for GFP_KERNEL
3. lookup again but under lock
4. if found, return it after freeing the allocated memory
5. else, return the new one
Instead, let's add a per-table mutex and run lookup and allocation
under it.
Note that updating pneigh_entry part in neigh_add() is still protected
by RTNL and will be moved to pneigh_create() in the next patch.
Signed-off-by: Kuniyuki Iwashima <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Diffstat (limited to 'drivers/usb/cdns3/cdns3-trace.h')
0 files changed, 0 insertions, 0 deletions
