* Ben Hutchings <ben@xxxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|