From owner-freebsd-net@FreeBSD.ORG Tue May 14 21:11:27 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BE1F88C9 for ; Tue, 14 May 2013 21:11:27 +0000 (UTC) (envelope-from pzkordus@gmail.com) Received: from mail-ia0-x242.google.com (mail-ia0-x242.google.com [IPv6:2607:f8b0:4001:c02::242]) by mx1.freebsd.org (Postfix) with ESMTP id 967B7D6E for ; Tue, 14 May 2013 21:11:27 +0000 (UTC) Received: by mail-ia0-f194.google.com with SMTP id r13so200845iar.1 for ; Tue, 14 May 2013 14:11:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=xFHxnn1IpsRjVaMCVkRr2/A4yLkVhh6rZjQmuGs6rw0=; b=wzZBvtpIjOqynNrph3et0+E65yKX/S9VNMFF8DM0DwLyT92VgCOnmh+j+Aszxu3t5k KHFBIwPPfR6/s2fakJgSaZmJ8qyTR26rmdD/jt0N4BoTQR6A273pFjgprtCyitzDJiGc C+x3nerPwZHM73O1xTk/CVqdydEISLXFYQvrW6FpNJovaZNx63Jxo3eZePDiqMv18SFO l00yUGrP/FcHrbG/pKj7qVXLn1oP6au+8Xzhnuc3BonmUX/yVHfBd0ZnZe0lcRmd0CL7 OwjSmxjp71WhicGOR1IvP1SQY7uPdjjwv0rWXzeqqHY8mPtHK3gNin4Ws+tz9oSqw67V SOzg== MIME-Version: 1.0 X-Received: by 10.42.66.140 with SMTP id p12mr18212630ici.15.1368565887259; Tue, 14 May 2013 14:11:27 -0700 (PDT) Received: by 10.50.25.164 with HTTP; Tue, 14 May 2013 14:11:27 -0700 (PDT) Date: Tue, 14 May 2013 17:11:27 -0400 Message-ID: Subject: dangling pointer off rn_mklist From: Ping Kordus To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 21:11:27 -0000 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