From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jakub Kicinski Subject: Re: [PATCH net] nfp: don't depend on eth_tbl being available Date: Fri, 27 Apr 2018 10:38:50 -0700 Message-ID: <20180427103850.6f580a14@cakuba.netronome.com> References: <20180425182108.31363-1-jakub.kicinski@netronome.com> <20180427.111556.1931814913979522341.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org, oss-drivers@netronome.com To: David Miller Return-path: Received: from mail-qk0-f193.google.com ([209.85.220.193]:37275 "EHLO mail-qk0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757425AbeD0Riy (ORCPT ); Fri, 27 Apr 2018 13:38:54 -0400 Received: by mail-qk0-f193.google.com with SMTP id d74so2016834qkg.4 for ; Fri, 27 Apr 2018 10:38:54 -0700 (PDT) In-Reply-To: <20180427.111556.1931814913979522341.davem@davemloft.net> Sender: netdev-owner@vger.kernel.org List-ID: On Fri, 27 Apr 2018 11:15:56 -0400 (EDT), David Miller wrote: > From: Jakub Kicinski > Date: Wed, 25 Apr 2018 11:21:08 -0700 > > > For very very old generation of the management FW Ethernet port > > information table may theoretically not be available. This in > > turn will cause the nfp_port structures to not be allocated. > > > > Make sure we don't crash the kernel when there is no eth_tbl: > > > > RIP: 0010:nfp_net_pci_probe+0xf2/0xb40 [nfp] > > ... > > Call Trace: > > nfp_pci_probe+0x6de/0xab0 [nfp] > > local_pci_probe+0x47/0xa0 > > work_for_cpu_fn+0x1a/0x30 > > process_one_work+0x1de/0x3e0 > > > > Found while working with broken/development version of management FW. > > > > Fixes: a5950182c00e ("nfp: map mac_stats and vf_cfg BARs") > > Fixes: 93da7d9660ee ("nfp: provide nfp_port to of nfp_net_get_mac_addr()") > > Signed-off-by: Jakub Kicinski > > Reviewed-by: Dirk van der Merwe > > Applied, thanks Jakub. Thank you! > Do you want this queued up for -stable? It seems borderline, at best, to me. Yes, I think we don't need stable for now. This should never happen (tm) in production and there has been some churn around this code. I don't think it's worth a backport.