From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752570AbdIAVQn (ORCPT ); Fri, 1 Sep 2017 17:16:43 -0400 Received: from mail-pf0-f176.google.com ([209.85.192.176]:35957 "EHLO mail-pf0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752397AbdIAVQl (ORCPT ); Fri, 1 Sep 2017 17:16:41 -0400 X-Google-Smtp-Source: ADKCNb7Pd/IW7mfVyEVMpGbz+SqNFRt0MHMQcA8DmgkarJrn6zc+fgVV5tDEmjN6jGS19TCPdqBvGA== Date: Fri, 1 Sep 2017 14:16:39 -0700 From: Stephen Hemminger To: Michal Kubecek Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH iproute2 0/2] fix "ip link show dev ..." for NICs with many VFs Message-ID: <20170901141639.2f77d60f@xeon-e3> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 1 Sep 2017 18:39:06 +0200 (CEST) Michal Kubecek wrote: > Two of our customers recently encountered problems with processing of large > messages produced by kernel in response to "ip link show" for NICs with > many (120-128) virtual functions. While some of them have been already > addressed in recent versions of iproute2, some still persist. > > Patch 1 adds check to handle the case when a message fits into the > buffer in rtnl_talk() but not into the buffer in iplink_get(). > > Patch 2 increases the buffer size in iplink_get() to suffice even for > NICs with 128 VFs. > > Note: after applying patch 2, patch 1 seems useless as both buffers have > the same size so that the check cannot actually trigger. However, as we > cannot guarantee they will always stay the same, I believe the check > should still be added. > > Michal Kubecek (2): > iplink: check for message truncation in iplink_get() > iplink: double the buffer size also in iplink_get() > > ip/iplink.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > Looks like the best set of solutions to the kernel side API issue. Applied, thanks Michal.