lists.openwall.net   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  linux-cve-announce  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:	Wed, 27 Aug 2008 14:32:11 +0800
From:	"Peter Teoh" <htmldeveloper@...il.com>
To:	"Peter Zijlstra" <peterz@...radead.org>
Cc:	LKML <linux-kernel@...r.kernel.org>, "Ingo Molnar" <mingo@...e.hu>
Subject: Re: Locking API testsuite: Failures

Thanks for the reply.

On Wed, Aug 27, 2008 at 9:58 AM, Peter Zijlstra <peterz@...radead.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
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ