linux-kernel - Re: [BUG?] possible recursive locking detected

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: <20060727144542.GA27451@elte.hu>
Date:	Thu, 27 Jul 2006 16:45:43 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Anton Altaparmakov <aia21@....ac.uk>
Cc:	Andrew Morton <akpm@...l.org>, nickpiggin@...oo.com.au,
	eike-kernel@...tec.de, linux-kernel@...r.kernel.org,
	aia21@...tab.net, Arjan van de Ven <arjan@...radead.org>
Subject: Re: [BUG?] possible recursive locking detected


* Anton Altaparmakov <aia21@....ac.uk> wrote:

> Note that even the above patch is not a 100% solution.  What 
> guarantees are there that the page faulted in will still be around 
> when it is read a few lines down the line in the code?  Given 
> sufficient parallel memory pressure/io pressure it can still cause the 
> page to be evicted again immediately after it is faulted in...
>
> All the above patch does is to _dramatically_ reduce the race window 
> for this happening but it does not eliminate it in theory (AFAICS).
> 
> So if your stance is that deadlocks are completely unacceptable it 
> still is not fixed.  If your stance is that _really_ unlikely 
> deadlocks are acceptable then it is fixed.

my 'stance' is pretty common-sense: exploitable deadlocks (it's possible 
to force eviction of a page), or even hard-to-trigger but possible 
deadlocks (which are not associated with hopeless resource exhaustation) 
must be fixed.

couldnt we exclude the case of 'write writing to the same page it is 
reading from' abuse, to avoid the deadlock problem?

	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/