linux-kernel - Re: 2.6.23-rc2-mm1: hang, prop_norm

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]

Message-ID: <20070809145132.26111a08@gondolin.boeblingen.de.ibm.com>
Date:	Thu, 9 Aug 2007 14:51:32 +0200
From:	Cornelia Huck <cornelia.huck@...ibm.com>
To:	Alexey Dobriyan <adobriyan@...ru>
Cc:	akpm@...l.org, linux-kernel@...r.kernel.org, a.p.zijlstra@...llo.nl
Subject: Re: 2.6.23-rc2-mm1: hang, prop_norm_single involved

On Thu, 9 Aug 2007 15:10:44 +0400,
Alexey Dobriyan <adobriyan@...ru> wrote:

> LTP run reproducably hangs during rwtest01 test
> rwtest -N rwtest01 -c -q -i 60s -f sync 10%25000:rs-sync=$$
> Calltrace is always the same:
> 
> INFO: trying to register non-static key
> 	__lock_acquire+0x210/0xc9e
> 	lock_acquire+0x87/0xa3
> 	_spin_lock_irqsave+0x2f/0x5f
> 	prop_norm_single+0x32/0x74
> 	set_page_dirty+0xd6/0x151
> 	set_page_dirty_balance+0xc/0x71
> 	do_wp_page+0x4ae/0x52b
> 	handle_mm_fault+0x616/0x6c4
> 	do_page_fault+0x1b0/0x51c
> 

On s390, I get a bad spinlock magic which also has prop_norm_single in
the call chain. Don't know if that is related:

BUG: spinlock bad magic on CPU#1, 05-pam_console./2560
 lock: 000000000602de00, .magic: 00000000, .owner: 05-pam_console./2560, .owner_cpu: 1
000000000038d9f0 0000000000000002 0000000000000000 000000000604ba40 
       000000000604b9b8 0000000000434800 0000000000434800 00000000000153d4
       0000000000000000 0000000000000000 0000000000000000 0000000000517020
       0000000000000000 000000000604ba00 000000000604b9a0 000000000000000e
       000000000038d9e0 000000000001541e 000000000604b9a0 000000000604b9f0
Call Trace:
([<000000000001535c>] show_trace+0xc8/0xe4)
 [<000000000001544e>] show_stack+0xd6/0x100
 [<00000000000154a6>] dump_stack+0x2e/0x3c
 [<00000000001a6fee>] spin_bug+0x106/0x120
 [<00000000001a7268>] _raw_spin_unlock+0xb0/0xd4
 [<00000000003724f2>] _spin_unlock_irqrestore+0x2a/0x70
 [<000000000019e962>] prop_norm_single+0xce/0xdc
 [<000000000007fcc2>] set_page_dirty+0x9e/0x144
 [<0000000000096862>] page_remove_rmap+0xd2/0x1e8
 [<000000000008c74c>] unmap_vmas+0x4ac/0xc1c
 [<0000000000092248>] exit_mmap+0xac/0x288
 [<000000000003810e>] mmput+0x7a/0x110
 [<000000000003d79e>] exit_mm+0xaa/0x114
 [<000000000003e89a>] do_exit+0x152/0x908
 [<000000000003f0a0>] do_group_exit+0x50/0xa8
 [<000000000003f12e>] sys_exit_group+0x36/0x44
 [<0000000000022c30>] sysc_noemu+0x10/0x16
 [<00000200000d8e1c>] 0x200000d8e1c

The system seems to be completely usable afterwards. I can reliably
produce this callchain (or a similar one, but always involving mmput)
with the attached .config; however, turning on more lock debugging
makes it go away :(

View attachment "config-t29lp20-mm-nodbg" of type "text/plain" (16972 bytes)