Re: [tip:core/locking] lockdep, rtmutex, bug: Show taint flags on error

[Ingo Molnar <mingo@elte.hu>]

* Ben Hutchings <ben@decadent.org.uk> wrote:

> So what I would like to do is either:
> 
> 1. No longer disable lock debugging due to any taint
> or
> 2. Disable lock debugging only when TAINT_PROPRIETARY_MODULE is set

I'd like a whitelist - i.e. disable on taint by default, but 
allow case by case exceptions such as OOT_MODULE.

Nor am i singling out bin-only modules, look at the current set 
of taint flags:

#define TAINT_PROPRIETARY_MODULE        0
#define TAINT_FORCED_MODULE             1
#define TAINT_UNSAFE_SMP                2
#define TAINT_FORCED_RMMOD              3
#define TAINT_MACHINE_CHECK             4
#define TAINT_BAD_PAGE                  5
#define TAINT_USER                      6
#define TAINT_DIE                       7
#define TAINT_OVERRIDDEN_ACPI_TABLE     8
#define TAINT_WARN                      9
#define TAINT_CRAP                      10
#define TAINT_FIRMWARE_WORKAROUND       11
#define TAINT_OOT_MODULE                12

*all* except TAINT_FIRMWARE_WORKAROUND, TAINT_CRAP and OOT 
should result in lockdep disabling. (perhaps 
OVERRIDDEN_ACPI_TABLE, as a variant of FIRMWARE_WORKAROUND, 
could be added as an exception too)

Module forcing causes various lifetime issues and lockdep tracks 
lifetime so can get confused on that. Unsafe SMP - enough said. 
Lockdep also wants to disable on the first WARN_ON() - which is 
typically the sign of some initial badness, which should be 
investigated before any lockdep splat is looked into.

Since most of the taint flags show deep kernel or hardware 
troubles i'd like most new taint flags to be lockdep off by 
default. As new taint flags are introduced they can be added to 
the whitelist when justified.

Thanks,

	Ingo