From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8163BC433E3 for ; Wed, 29 Jul 2020 11:43:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 622B4207E8 for ; Wed, 29 Jul 2020 11:43:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="jcTXLUVb" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726865AbgG2LnW (ORCPT ); Wed, 29 Jul 2020 07:43:22 -0400 Received: from wout1-smtp.messagingengine.com ([64.147.123.24]:41047 "EHLO wout1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726365AbgG2LnW (ORCPT ); Wed, 29 Jul 2020 07:43:22 -0400 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 134894B8; Wed, 29 Jul 2020 07:43:21 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 29 Jul 2020 07:43:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=l38fM3 lfQzmFl33A4ZEsdirrgbJNyipF5taLaKCC1rM=; b=jcTXLUVb1txLf2jpLP3OY8 Db4Z6hT6lcTSI+mTr+TT9OExa5zTZApMula3YS4z/RebeAxkauljY5hSSFrjSIi6 vOtqJPG807XjrSyJlRtyiPexV1f+nbgW3YlMaat4fumoXA6+82mJVoaEgWVe7RFl lrUUe6Vx3IT7NyTqaIyB1WHB5KIl3nRfJmYTjjt7u//8TODwjeAABzCN0HZqCdaT d9AJOuEVwqVtRY7HccI1xnIcKmoq4Bd7WSyOY0EYwh6/3YbmFGxkPZP7cmNsilWT eBid4EyV9xwOEPGLJ0+vjSWXvY5LgSwHrs42ii27XE3OXgjxGEqp6DnOiBX2rDCg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrieeggdegfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepkfguohcuufgt hhhimhhmvghluceoihguohhstghhsehiughoshgthhdrohhrgheqnecuggftrfgrthhtvg hrnheptdffkeekfeduffevgeeujeffjefhtefgueeugfevtdeiheduueeukefhudehleet necukfhppedutdelrdeihedrudefjedrvdehtdenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpehiughoshgthhesihguohhstghhrdhorhhg X-ME-Proxy: Received: from localhost (bzq-109-65-137-250.red.bezeqint.net [109.65.137.250]) by mail.messagingengine.com (Postfix) with ESMTPA id 1474E30600B1; Wed, 29 Jul 2020 07:43:19 -0400 (EDT) Date: Wed, 29 Jul 2020 14:43:17 +0300 From: Ido Schimmel To: Ashutosh Grewal , dsahern@gmail.com Cc: davem@davemloft.net, netdev@vger.kernel.org Subject: Re: Bug: ip utility fails to show routes with large # of multipath next-hops Message-ID: <20200729114317.GA2120829@shredder> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Tue, Jul 28, 2020 at 05:52:44PM -0700, Ashutosh Grewal wrote: > Hello David and all, > > I hope this is the correct way to report a bug. Sure > > I observed this problem with 256 v4 next-hops or 128 v6 next-hops (or > 128 or so # of v4 next-hops with labels). > > Here is an example - > > root@a6be8c892bb7:/# ip route show 2.2.2.2 > Error: Buffer too small for object. > Dump terminated > > Kernel details (though I recall running into the same problem on 4.4* > kernel as well) - > root@ubuntu-vm:/# uname -a > Linux ch1 5.4.0-33-generic #37-Ubuntu SMP Thu May 21 12:53:59 UTC 2020 > x86_64 x86_64 x86_64 GNU/Linux > > I think the problem may be to do with the size of the skbuf being > allocated as part of servicing the netlink request. > > static int netlink_dump(struct sock *sk) > { > > > skb = alloc_skb(...) Yes, I believe you are correct. You will get an skb of size 4K and it can't fit the entire RTA_MULTIPATH attribute with all the nested nexthops. Since it's a single attribute it cannot be split across multiple messages. Looking at the code, I think a similar problem was already encountered with IFLA_VFINFO_LIST. See commit c7ac8679bec9 ("rtnetlink: Compute and store minimum ifinfo dump size"). Maybe we can track the maximum number of IPv4/IPv6 nexthops during insertion and then consult it to adjust 'min_dump_alloc' for RTM_GETROUTE. It's a bit complicated for IPv6 because you can append nexthops, but I believe anyone using so many nexthops is already using RTA_MULTIPATH to insert them, so we can simplify. David, what do you think? You have a better / simpler idea? Maybe one day everyone will be using the new nexthop API and this won't be needed :) > > Thanks, > Ashutosh