From patchwork Thu Jul 17 15:24:18 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Veaceslav Falico X-Patchwork-Id: 371208 Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 59684140174 for ; Fri, 18 Jul 2014 01:27:27 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934533AbaGQP1W (ORCPT ); Thu, 17 Jul 2014 11:27:22 -0400 Received: from mail-wi0-f173.google.com ([209.85.212.173]:41771 "EHLO mail-wi0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933680AbaGQP1R (ORCPT ); Thu, 17 Jul 2014 11:27:17 -0400 Received: by mail-wi0-f173.google.com with SMTP id f8so6937983wiw.0 for ; Thu, 17 Jul 2014 08:27:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=aAiM4pzJHsIOvewBv/a5xRSR2vcK5qpfXHgsSNLn/PY=; b=BhD813YY1MD/Yor1lbUlfJxgZpth0BpUsBzW8hi05rebzIqXny3aWma67NfVih8IJp FkC8T+hxnpKZEvCJLIFy9g/UmMcugX7UGAWj5JGEW7+Gr32y7JrV1kn5IZmnSxziPZNg tN1x8OuDexHWwx0aMlBo2yMMm8jmiId2vTshdopYuTUDz5+Fti6AK6swRiPcRlZpzQLE Hu/WxzDGHyYxPDKmghezKe+yq79izxljBmYLM373b897EANsynjQy6EtF96hU7PCd07H QXyZtZggdHvN6CoAo2XSBZ1r6/+IiooZaTRj2JZeNcRYrVuyM6laIYI/wFKgRvnVBHt0 YutA== X-Received: by 10.194.110.161 with SMTP id ib1mr5017550wjb.129.1405610836002; Thu, 17 Jul 2014 08:27:16 -0700 (PDT) Received: from mikrodark.usersys.redhat.com (nat-pool-brq-t.redhat.com. [209.132.186.34]) by mx.google.com with ESMTPSA id dj2sm69607528wib.11.2014.07.17.08.27.14 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Jul 2014 08:27:15 -0700 (PDT) Date: Thu, 17 Jul 2014 17:24:18 +0200 From: Veaceslav Falico To: David Laight Cc: "netdev@vger.kernel.org" , "David S. Miller" , Jason Baron , Eric Dumazet , Vlad Yasevich , stephen hemminger , Jerry Chu , Ben Hutchings , Tom Gundersen Subject: Re: [PATCH v2 net-next 0/2] net: print net_device name/state more often Message-ID: <20140717152418.GC28357@mikrodark.usersys.redhat.com> References: <1405606186-13703-1-git-send-email-vfalico@gmail.com> <063D6719AE5E284EB5DD2968C1650D6D17276E6E@AcuExch.aculab.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D17276E6E@AcuExch.aculab.com> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, Jul 17, 2014 at 02:48:17PM +0000, David Laight wrote: >From: Veaceslav Falico >> Currently we use net_device->name only if it's the NETREG_REGISTERED >> reg_state, otherwise we return "(unregistered device)". >> >> However, we always populate net_device->name on creation, so it's always >> available to us for use. The only caveat is that we might have a name like >> "eth%d", in which case we cannot use it as it might change in the future. > >While you've got this code out on the operating table what about: I don't think these ideas fit into the current patchset, as it's somehow unrelated to the "lets give the real name/state when possible". However, I like them, see below. >1) Tracing the renames into the kernel message buffer. I think you can enable it already. dev_change_name() (net's function to change net_device name) calls device_rename(), which handles the device renaming, and it has: 1805 dev_dbg(dev, "renaming to %s\n", new_name); It can be easily enabled if you have dynamic debug compiled in. However, indeed, it might be a good info to watch for, and a pretty simple patch, which might be useful. >2) Including the original name in some of the kernel traces. The only possible use-case of that, from what I can see (with the patch from 1) ) - is in the renaming functions themselves, which have already quite a few output sources and, tbh, it's a really rare situation to implenment tracking of renames in-kernel. > >I've been trying to diagnose some issues on a system that renames >its interfaces, and it can get tricky working out which interface >messages refer to. > > David > > > --- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/net/core/dev.c b/net/core/dev.c index 239722a..d14ebf0 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -1113,6 +1113,9 @@ int dev_change_name(struct net_device *dev, const char *newname) return err; } + if (oldname[0] && !strchr(oldname, '%')) + netdev_info(dev, "renamed from %s\n", oldname); + old_assign_type = dev->name_assign_type; dev->name_assign_type = NET_NAME_RENAMED;