public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* Locking API testsuite: Failures
@ 2008-08-27  0:27 Peter Teoh
  2008-08-27  1:58 ` Peter Zijlstra
  0 siblings, 1 reply; 4+ messages in thread
From: Peter Teoh @ 2008-08-27  0:27 UTC (permalink / raw)
  To: LKML

[    0.000999] | Locking API testsuite:
[    0.000999] ----------------------------------------------------------------------------
[    0.000999]                                  | spin |wlock |rlock
|mutex | wsem | rsem |
[    0.000999]
--------------------------------------------------------------------------
[    0.000999]                      A-A deadlock:failed|failed|  ok
|failed|failed|failed|
[    0.000999]                  A-B-B-A deadlock:failed|failed|  ok
|failed|failed|failed|
[    0.000999]              A-B-B-C-C-A deadlock:failed|failed|  ok
|failed|failed|failed|
[    0.000999]              A-B-C-A-B-C deadlock:failed|failed|  ok
|failed|failed|failed|
[    0.000999]          A-B-B-C-C-D-D-A deadlock:failed|failed|  ok
|failed|failed|failed|
[    0.000999]          A-B-C-D-B-D-D-A deadlock:failed|failed|  ok
|failed|failed|failed|
[    0.000999]          A-B-C-D-B-C-D-A deadlock:failed|failed|  ok
|failed|failed|failed|
[    0.000999]                     double
unlock:failed|failed|failed|failed|failed|failed|
[    0.000999]                   initialize
held:failed|failed|failed|failed|failed|failed|
[    0.000999]                  bad unlock order:  ok  |  ok  |  ok  |
 ok  |  ok  |  ok  |
[    0.000999]
--------------------------------------------------------------------------
[    0.000999]               recursive read-lock:             |  ok  |
            |failed|
[    0.000999]            recursive read-lock #2:             |  ok  |
            |failed|
[    0.000999]             mixed read-write-lock:             |failed|
            |failed|
[    0.000999]             mixed write-read-lock:             |failed|
            |failed|
[    0.000999]
--------------------------------------------------------------------------
[    0.000999]      hard-irqs-on + irq-safe-A/12:failed|failed|  ok  |
[    0.000999]      soft-irqs-on + irq-safe-A/12:failed|failed|  ok  |
[    0.000999]      hard-irqs-on + irq-safe-A/21:failed|failed|  ok  |
[    0.000999]      soft-irqs-on + irq-safe-A/21:failed|failed|  ok  |
[    0.000999]        sirq-safe-A => hirqs-on/12:failed|failed|  ok  |
[    0.000999]        sirq-safe-A => hirqs-on/21:failed|failed|  ok  |
[    0.000999]          hard-safe-A + irqs-on/12:failed|failed|  ok  |
[    0.000999]          soft-safe-A + irqs-on/12:failed|failed|  ok  |
[    0.000999]          hard-safe-A + irqs-on/21:failed|failed|  ok  |
[    0.000999]          soft-safe-A + irqs-on/21:failed|failed|  ok  |
[    0.000999]     hard-safe-A + unsafe-B #1/123:failed|failed|  ok  |
[    0.000999]     soft-safe-A + unsafe-B #1/123:failed|failed|  ok  |

truncated....

I am just curious what does all these failures imply?

thanks.

-- 
Regards,
Peter Teoh

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Locking API testsuite: Failures
  2008-08-27  0:27 Locking API testsuite: Failures Peter Teoh
@ 2008-08-27  1:58 ` Peter Zijlstra
  2008-08-27  6:32   ` Peter Teoh
  0 siblings, 1 reply; 4+ messages in thread
From: Peter Zijlstra @ 2008-08-27  1:58 UTC (permalink / raw)
  To: Peter Teoh; +Cc: LKML, Ingo Molnar

On Wed, 2008-08-27 at 08:27 +0800, Peter Teoh wrote:
> [    0.000999] | Locking API testsuite:
> [    0.000999] ----------------------------------------------------------------------------
> [    0.000999]                                  | spin |wlock |rlock
> |mutex | wsem | rsem |
> [    0.000999]
> --------------------------------------------------------------------------
> [    0.000999]                      A-A deadlock:failed|failed|  ok
> |failed|failed|failed|
> [    0.000999]                  A-B-B-A deadlock:failed|failed|  ok
> |failed|failed|failed|
> [    0.000999]              A-B-B-C-C-A deadlock:failed|failed|  ok
> |failed|failed|failed|
> [    0.000999]              A-B-C-A-B-C deadlock:failed|failed|  ok
> |failed|failed|failed|
> [    0.000999]          A-B-B-C-C-D-D-A deadlock:failed|failed|  ok
> |failed|failed|failed|
> [    0.000999]          A-B-C-D-B-D-D-A deadlock:failed|failed|  ok
> |failed|failed|failed|
> [    0.000999]          A-B-C-D-B-C-D-A deadlock:failed|failed|  ok
> |failed|failed|failed|
> [    0.000999]                     double
> unlock:failed|failed|failed|failed|failed|failed|
> [    0.000999]                   initialize
> held:failed|failed|failed|failed|failed|failed|
> [    0.000999]                  bad unlock order:  ok  |  ok  |  ok  |
>  ok  |  ok  |  ok  |
> [    0.000999]
> --------------------------------------------------------------------------
> [    0.000999]               recursive read-lock:             |  ok  |
>             |failed|
> [    0.000999]            recursive read-lock #2:             |  ok  |
>             |failed|
> [    0.000999]             mixed read-write-lock:             |failed|
>             |failed|
> [    0.000999]             mixed write-read-lock:             |failed|
>             |failed|
> [    0.000999]
> --------------------------------------------------------------------------
> [    0.000999]      hard-irqs-on + irq-safe-A/12:failed|failed|  ok  |
> [    0.000999]      soft-irqs-on + irq-safe-A/12:failed|failed|  ok  |
> [    0.000999]      hard-irqs-on + irq-safe-A/21:failed|failed|  ok  |
> [    0.000999]      soft-irqs-on + irq-safe-A/21:failed|failed|  ok  |
> [    0.000999]        sirq-safe-A => hirqs-on/12:failed|failed|  ok  |
> [    0.000999]        sirq-safe-A => hirqs-on/21:failed|failed|  ok  |
> [    0.000999]          hard-safe-A + irqs-on/12:failed|failed|  ok  |
> [    0.000999]          soft-safe-A + irqs-on/12:failed|failed|  ok  |
> [    0.000999]          hard-safe-A + irqs-on/21:failed|failed|  ok  |
> [    0.000999]          soft-safe-A + irqs-on/21:failed|failed|  ok  |
> [    0.000999]     hard-safe-A + unsafe-B #1/123:failed|failed|  ok  |
> [    0.000999]     soft-safe-A + unsafe-B #1/123:failed|failed|  ok  |
> 
> truncated....
> 
> I am just curious what does all these failures imply?

Probably that you forgot to enable lockdep ;-)

In which case the error cases fail to produce an error, and the test
fails, but its an expected error, otherwise it would have shouted much
more verbose.




^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Locking API testsuite: Failures
  2008-08-27  1:58 ` Peter Zijlstra
@ 2008-08-27  6:32   ` Peter Teoh
  2008-08-27  6:45     ` Ingo Molnar
  0 siblings, 1 reply; 4+ messages in thread
From: Peter Teoh @ 2008-08-27  6:32 UTC (permalink / raw)
  To: Peter Zijlstra; +Cc: LKML, Ingo Molnar

Thanks for the reply.

On Wed, Aug 27, 2008 at 9:58 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Wed, 2008-08-27 at 08:27 +0800, Peter Teoh wrote:
>> [    0.000999] | Locking API testsuite:
>> [    0.000999] ----------------------------------------------------------------------------
>> [    0.000999]                                  | spin |wlock |rlock
>> |mutex | wsem | rsem |
>> [    0.000999]
>> --------------------------------------------------------------------------
>> [    0.000999]                      A-A deadlock:failed|failed|  ok
>> |failed|failed|failed|
>> [    0.000999]                  A-B-B-A deadlock:failed|failed|  ok
>> |failed|failed|failed|
>> [    0.000999]              A-B-B-C-C-A deadlock:failed|failed|  ok
>> |failed|failed|failed|
>> [    0.000999]              A-B-C-A-B-C deadlock:failed|failed|  ok
>> |failed|failed|failed|
>> [    0.000999]          A-B-B-C-C-D-D-A deadlock:failed|failed|  ok
>> |failed|failed|failed|
>> [    0.000999]          A-B-C-D-B-D-D-A deadlock:failed|failed|  ok
>> |failed|failed|failed|
>> [    0.000999]          A-B-C-D-B-C-D-A deadlock:failed|failed|  ok
>> |failed|failed|failed|
>> [    0.000999]                     double
>> unlock:failed|failed|failed|failed|failed|failed|
>> [    0.000999]                   initialize
>> held:failed|failed|failed|failed|failed|failed|
>> [    0.000999]                  bad unlock order:  ok  |  ok  |  ok  |
>>  ok  |  ok  |  ok  |
>> [    0.000999]
>> --------------------------------------------------------------------------
>> [    0.000999]               recursive read-lock:             |  ok  |
>>             |failed|
>> [    0.000999]            recursive read-lock #2:             |  ok  |
>>             |failed|
>> [    0.000999]             mixed read-write-lock:             |failed|
>>             |failed|
>> [    0.000999]             mixed write-read-lock:             |failed|
>>             |failed|
>> [    0.000999]
>> --------------------------------------------------------------------------
>> [    0.000999]      hard-irqs-on + irq-safe-A/12:failed|failed|  ok  |
>> [    0.000999]      soft-irqs-on + irq-safe-A/12:failed|failed|  ok  |
>> [    0.000999]      hard-irqs-on + irq-safe-A/21:failed|failed|  ok  |
>> [    0.000999]      soft-irqs-on + irq-safe-A/21:failed|failed|  ok  |
>> [    0.000999]        sirq-safe-A => hirqs-on/12:failed|failed|  ok  |
>> [    0.000999]        sirq-safe-A => hirqs-on/21:failed|failed|  ok  |
>> [    0.000999]          hard-safe-A + irqs-on/12:failed|failed|  ok  |
>> [    0.000999]          soft-safe-A + irqs-on/12:failed|failed|  ok  |
>> [    0.000999]          hard-safe-A + irqs-on/21:failed|failed|  ok  |
>> [    0.000999]          soft-safe-A + irqs-on/21:failed|failed|  ok  |
>> [    0.000999]     hard-safe-A + unsafe-B #1/123:failed|failed|  ok  |
>> [    0.000999]     soft-safe-A + unsafe-B #1/123:failed|failed|  ok  |
>>
>> truncated....
>>
>> I am just curious what does all these failures imply?
>
> Probably that you forgot to enable lockdep ;-)
>

Several questions:

1.   I noticed there is a Kconfig.debug with this entry:

config DEBUG_LOCKING_API_SELFTESTS
        bool "Locking API boot-time self-tests"
        depends on DEBUG_KERNEL
        help
          Say Y here if you want the kernel to run a short self-test during
          bootup. The self-test checks whether common types of locking bugs
          are detected by debugging mechanisms or not. (if you disable
          lock debugging then those bugs wont be detected of course.)
          The following locking APIs are covered: spinlocks, rwlocks,
          mutexes and rwsems.

How do I use this Kconfig.debug, just overwriting the standard
lib/Kconfig?   I overwrote it and got the following errors:

scripts/kconfig/conf -o arch/x86/Kconfig
file kernel/trace/Kconfig already scanned?
make[1]: *** [oldconfig] Error 1
make: *** [oldconfig] Error 2

2.   So does it make sense to  compile with
CONFIG_DEBUG_LOCKING_API_SELFTESTS without CONFIG_LOCKDEP?
Should the lib/Kconfig indicate such a dependency?

3.   My current .config (which gave rise to the failure errors) has
CONFIG_LOCKDEP_SUPPORT=y, and CONFIG_DEBUG_LOCKING_API_SELFTESTS=y.
Question is what is the different between LOCKDEP_SUPPORT and LOCKDEP
alone?

Thanks.

> In which case the error cases fail to produce an error, and the test
> fails, but its an expected error, otherwise it would have shouted much
> more verbose.
>
>
>
>



-- 
Regards,
Peter Teoh

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Locking API testsuite: Failures
  2008-08-27  6:32   ` Peter Teoh
@ 2008-08-27  6:45     ` Ingo Molnar
  0 siblings, 0 replies; 4+ messages in thread
From: Ingo Molnar @ 2008-08-27  6:45 UTC (permalink / raw)
  To: Peter Teoh; +Cc: Peter Zijlstra, LKML


* Peter Teoh <htmldeveloper@gmail.com> wrote:

> Several questions:

[...]
> 3.  My current .config (which gave rise to the failure errors) [...]

You should have read this bit of the self-test printout:

[    0.004000] 133 out of 218 testcases failed, as expected. |

there was no unexpected failure. A real test-case failure is displayed 
as: 'FAILED', and you'll get a verbose printout about the unexpected 
testcase failures.

> 1.   I noticed there is a Kconfig.debug with this entry:
> 
> config DEBUG_LOCKING_API_SELFTESTS
>         bool "Locking API boot-time self-tests"
>         depends on DEBUG_KERNEL
>         help
>           Say Y here if you want the kernel to run a short self-test during
>           bootup. The self-test checks whether common types of locking bugs
>           are detected by debugging mechanisms or not. (if you disable
>           lock debugging then those bugs wont be detected of course.)
>           The following locking APIs are covered: spinlocks, rwlocks,
>           mutexes and rwsems.
> 
> How do I use this Kconfig.debug, just overwriting the standard
> lib/Kconfig? [...]

no, that messes up the kernel. Kconfig.debug is a separate, unique 
kconfig file with debugging related options.

> 2.   So does it make sense to  compile with
> CONFIG_DEBUG_LOCKING_API_SELFTESTS without CONFIG_LOCKDEP?

yes. It shows the kinds of bugs we dont find when PROVE_LOCKING is 
disabled. It also shows that the test-cases are working as expected.

	Ingo

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2008-08-27  6:46 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-08-27  0:27 Locking API testsuite: Failures Peter Teoh
2008-08-27  1:58 ` Peter Zijlstra
2008-08-27  6:32   ` Peter Teoh
2008-08-27  6:45     ` Ingo Molnar

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox