From owner-freebsd-net@freebsd.org Tue Oct 17 15:05:38 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7960CE3C85B for ; Tue, 17 Oct 2017 15:05:38 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2A55170124 for ; Tue, 17 Oct 2017 15:05:38 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by mail-qt0-x22c.google.com with SMTP id f8so4188016qta.5 for ; Tue, 17 Oct 2017 08:05:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=bNzd5/GivIOXGGfuCCgVHwm1NjdZ9gaWAyJ9sjKjNuQ=; b=d2EFvy7ft20f/Zs/CDydFqicLZLTlyzyopFJmc3f4W5eb9xMiprd3IzwccrjG+QO4Q HiLylF4TakdqDepgW3Nx8GHCB7YC7Pop3KYlrhwdkOLrimO9890DeErBVPHGkcWUhPwO x33qNY8/2IblmkaoS/YqJclXlHwkho2u0ccE926AxchNt3Hiy0qLVcH/nKWKr/7ixPCt rfbY8+FZOnM4DRa6IZr4fE8B0aIKD/OBdNMGpU6E4d4zMtsio2a/fn9D8UU4qitlcUQi 1mkAPP8VXL5paz98pd5C24rFfAbFsT+HsGaL2OK4LRtzp2PezI4Dpkrr7511F/daPO1S 7hUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=bNzd5/GivIOXGGfuCCgVHwm1NjdZ9gaWAyJ9sjKjNuQ=; b=UNbssrImeQSSrBbqrHioN+CS97dIwGrjSYXBDg1tL1NM5AC3IxygXrhqAz0Od+Sj00 PgQzVfDK+3ITn4WLx5yzGDe7iBbQ57XvWPSsb3o6SmO0Y9pkmj727Fi4tz92WEh5I3K2 uiFCXZ8i3SgqoHs3yL/Q+EFgqllhdxgFHTJjcS7t0HX2+xX2s5ZXH1ymnLJ/34AsCFsy UM6fICfV2GX9JPG+bH4GKaYcWrriFp7X2Cjtd6weq5ryxIv337OmB5Gvsm77r6E1yEt4 1nTM6qfUUvdz4jjzegestBQF4tvu5jzof/Vo6KZLaqpmH9YEEuiMJOpFMYdzpqW+49AK desg== X-Gm-Message-State: AMCzsaVKeSQGJvuOPqYiJ6w2A72rpBXLn+0Bk+b8SiXbvEGpbBk2U9n6 F/MDpAYhPvDjGPP5kctA62TxMVkVzoqe0vvDCps= X-Google-Smtp-Source: ABhQp+TLj+SRxGC4PD7Ejkff12fIvKtx9l9P+JOKUhWwYGMKDVIKemi8M4Lq1cthu/aRD9Q5Vq5HOIyUnPXdlGk0IJs= X-Received: by 10.200.47.169 with SMTP id l38mr4714623qta.272.1508252736834; Tue, 17 Oct 2017 08:05:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.53.186 with HTTP; Tue, 17 Oct 2017 08:05:36 -0700 (PDT) From: Ryan Stone Date: Tue, 17 Oct 2017 11:05:36 -0400 Message-ID: Subject: Should RO_RTFREE() also free the cached lle entry? To: freebsd-net Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 17 Oct 2017 15:05:38 -0000 About a year back we brought back lle (the ARP/NDP entry) caching back into the network stack. As near as I can tell, the ethernet layer will take a reference on the lle and place a pointer to it in the ro_lle field in the struct route passed down from the upper layer. The upper layer is expected to do something sensible with the lle. This appears to have introduced bugs in code that doesn't perform route caching. For example, ip_forward() passes a struct route down to ip_output(), but never checks if it needs to free an lle. Similarly, if ip_output() is passed NULL for the route, it substitutes a locally allocated one, and again does nothing with the lle. I believe that this means that these code paths now leak a reference on the lle. Both paths do call RO_RTFREE() on the struct route when they are done with it. I am wondering if the easiest path forward is to have that macro also release the reference on the cached lle. Otherwise fixing this is going to require a very invasive change that fixes any caller that ultimately might call into ether_output().