Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 14 May 2013 17:11:27 -0400
From:      Ping Kordus <pzkordus@gmail.com>
To:        freebsd-net@freebsd.org
Subject:   dangling pointer off rn_mklist
Message-ID:  <CADPBj_AANDP2wCfCpnNU6sRWAzCoxYTuSZsj7rqRACCMH4tdMA@mail.gmail.com>

next in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADPBj_AANDP2wCfCpnNU6sRWAzCoxYTuSZsj7rqRACCMH4tdMA>