linux-kernel - Re: [PATCH] wireless: change cfg80211 regulatory domain info as debug messages

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1449844729.2324.15.camel@sipsolutions.net>
Date:	Fri, 11 Dec 2015 15:38:49 +0100
From:	Johannes Berg <johannes@...solutions.net>
To:	Dave Young <dyoung@...hat.com>, linux-wireless@...r.kernel.org
Cc:	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	davem@...emloft.net, Emmanuel Grumbach <egrumbach@...il.com>,
	Stefan Lippers-Hollmann <s.l-h@....de>
Subject: Re: [PATCH] wireless: change cfg80211 regulatory domain info as
 debug messages

On Sun, 2015-11-15 at 15:31 +0800, Dave Young wrote:
> cfg80211 module prints a lot of messages like below. Actually
> printing once is acceptable but sometimes it will print again and
> again, it looks very annoying. It is better to change these detail
> messages to debugging only.
> 

Despite the objections, I've applied this patch now.

I've made one change: keeping the alpha2 (e.g. "US") printed in some of
the pr_err() cases in this file.
I also got rid of CONFIG_CFG80211_REG_DEBUG in a separate patch.

I somewhat agree with the objections, but if the kernel is with
CONFIG_DYNAMIC_DEBUG then it's really simple to get the messages back
by enabling them for this file.

Where the messages were used as an indication of something having gone
awry at a different level (e.g. mac80211 disconnect) I don't really
quite agree - that then perhaps should have a more explicit (and less
noisy) message.

I also agree that the regulatory code is quite opaque, and the way it
arrives at certain conclusions is not always obvious. These messages
don't help all that much though since they don't contain the actual
input to the decisions. I think for that, we'd be much better served
with some kind of tracepoint or so that records all the information.

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/