dangling pointer off rn_mklist

Ping Kordus pzkordus at gmail.com
Tue May 14 21:11:27 UTC 2013


Hi,
We are seeing a dangling pointer off rn_mklist, this happened in the
following condition.

1. a RNF_NORMAL flagged element on an internal node's rn_mklist is pointing
to a child leaf route say route A via rm_rmu.rmu_leaf.
2. a dup route B of route A is added and becomes the head of rn_dupedkey
3. Route A is deleted. As route A is no longer at the head of the
rn_dupedkey, MPATH code simply unlinks it without traversing parent to
clean up the pointer off the parent's rn_mklist.

Below is the GDB trace indicating route state after step 2.

Route A:0xffffff000beb8410
Route B:0xffffff000c7c55b0
internal node:0xffffff000beb8850, its rn_mklist is traversed via GDB macro
as below

-----GDB macro snippet to traverse rn_mklist
set $m = $arg0->rn_mklist
while ($m !=0)
      if ($m->rm_flags & $RNF_NORMAL)
         set $mp=$m->rm_rmu.rmu_leaf
         printf "mlist: %p\n", $mp
      end
      set $m = $m->rm_mklist
end
---------------------------------------------------------------



kgdb-amd64-7.4-65)
parent node 0xffffff000beb8850:mlist: 0xffffff000beb8410
right child rtentry node 0xffffff000beb8340:
172.31.21.52                    link#1                  U-H-------S-------
  0        0  8232      lo0 0
left child rtentry node 0xffffff000c7c55b0
172.31.0.0                      link#1                  U-----------------
  0       19  1500      e0a 0 =>
dup:0xffffff000beb8410
route entry = 0xffffff000beb8410
172.31.0.0                      link#2                  U-----------------
  1       42  1500      e0b 0



So after step 3 where route A is deleted the routing table looks like below
with a dangling pointer on parent's rn_mklist

parent node 0xffffff000beb8850:mlist: 0xffffff000beb8410
right child rtentry node 0xffffff000beb8340:
172.31.21.52                    link#1                  U-H-------S-------
  0        0  8232      lo0 0
left child rtentry node 0xffffff000c7c55b0
172.31.0.0                      link#1                  U-----------------
  0       19  1500      e0a 0




Did anybody else see the issue? It seems to us the correct patch would do
1. Everytime add to the head of the dupedkey list, update the parent mklist
to point to the new head.
2.Everytime the head is  deleted update the parent mklist to point to the
new head.


Thanks a lot for your help,
Ping


More information about the freebsd-net mailing list