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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 04 Oct 2007 14:31:26 -0700
From:	Roland Dreier <>
To:	"John W. Linville" <>
Cc:	Michael Wu <>,
	Michael Buesch <>, Daniel Drake <>,,,
Subject: Re: [PATCH] mac80211: Fix TX after monitor interface is converted to managed

 > Programming with assertions (and BUG_ON is a form of that) is
 > generally a good practice.  Almost any book or other source on
 > good programming practices will agree.  Yes, it can be overdone.
 > But I don't really think that is the case here, since the check is
 > relatively inexpensive and the consequence should it ever *somehow*
 > happen could be a something wierd (crash, corruption, etc) w/o any
 > other indication of what occured.

The problem with BUG_ON is that it kills the whole system.  So every
time you add a BUG_ON into code, you have to weigh whether the problem
you detected is so severe that the right response is to panic.  For
example, I can see panicking on something fundamental like corrupted
page tables.  However I would submit that the wireless stack should
*never* use BUG_ON -- printing a warning and trying to limp on seems
preferable to me.

 - R.
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists