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
| ||
|
Date: Mon, 1 Feb 2016 11:13:17 +0900 From: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com> To: Byungchul Park <byungchul.park@....com> Cc: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>, akpm@...ux-foundation.org, mingo@...nel.org, linux-kernel@...r.kernel.org, akinobu.mita@...il.com, jack@...e.cz, peter@...leysoftware.com, torvalds@...ux-foundation.org Subject: Re: [PATCH v5] lib/spinlock_debug.c: prevent a recursive cycle in the debug code On (02/01/16 10:45), Byungchul Park wrote: > But avoiding an unnecessary recursive cycle is better than panic(). What I handled > in this patch is the warning case which causes unnecessary lockup and don't need to > happen. Hello, correct, that was one of the reasons why I proposed to return back to discussion. it's a bit hard to tell if we have any chance to survive a "lockup suspected" spin_dump() recursion; even if we have one, it's a race spin_unlock on CPUA vs. stack overflow on CPUB. we can be more certain with ->magic mismatch, for example, but "lockup suspected" is tricky. -ss
Powered by blists - more mailing lists