From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751396Ab3LKUy5 (ORCPT ); Wed, 11 Dec 2013 15:54:57 -0500 Received: from shards.monkeyblade.net ([149.20.54.216]:59442 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751053Ab3LKUyz (ORCPT ); Wed, 11 Dec 2013 15:54:55 -0500 Date: Wed, 11 Dec 2013 15:54:52 -0500 (EST) Message-Id: <20131211.155452.558417595732985707.davem@davemloft.net> To: hannes@stressinduktion.org Cc: dvlasenk@redhat.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, kuznet@ms2.inr.ac.ru, jmorris@namei.org, yoshfuji@linux-ipv6.org, kaber@trash.net, jpirko@redhat.com Subject: Re: [patch net-next v2] ipv6: log autoconfiguration failures From: David Miller In-Reply-To: <20131211192138.GB4675@order.stressinduktion.org> References: <1386762314-5149-1-git-send-email-dvlasenk@redhat.com> <20131211192138.GB4675@order.stressinduktion.org> X-Mailer: Mew version 6.5 on Emacs 24.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.1 (shards.monkeyblade.net [0.0.0.0]); Wed, 11 Dec 2013 12:54:55 -0800 (PST) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Hannes Frederic Sowa Date: Wed, 11 Dec 2013 20:21:38 +0100 > On Wed, Dec 11, 2013 at 12:45:14PM +0100, Denys Vlasenko wrote: >> If ipv6 auto-configuration does not work, currently it's hard >> to track what's going on. This change adds log messages >> (at debug level) on every code path where ipv6 autoconf fails. >> >> v2: fixed indentation in multi-line log output statements. > > Have you seen lots of those problems? Some of those seem like very > serious problems and maybe could also deserve a pr_warn or pr_err. > > I hope these are one-time errors, so I don't think counters would > be helpful. I still think that statitics would better serve this issue. For one thing, the event would always be counted, whereas with pr_debug() someone has to turn on dynamic debugging in order to see the message. You can make them part of the per-inet6_dev MIB, and therefore implicitly letting the admin know what interface the events occurred on. I would even prefer an approach involving signalling netlink events in such circumstances with more detailed information. Thanks.