[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20111207074901.GD16942@elte.hu>
Date: Wed, 7 Dec 2011 08:49:01 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Ben Hutchings <ben@...adent.org.uk>
Cc: Alan Cox <alan@...rguk.ukuu.org.uk>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>, mingo@...hat.com,
hpa@...or.com, linux-kernel@...r.kernel.org, tglx@...utronix.de,
linux-tip-commits@...r.kernel.org
Subject: Re: [tip:core/locking] lockdep, rtmutex, bug: Show taint flags on
error
* Ben Hutchings <ben@...adent.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
--
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/
Powered by blists - more mailing lists