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: <20060727094617.GA5955@elte.hu>
Date:	Thu, 27 Jul 2006 11:46:17 +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:

> An example is the potential deadlock in generic buffered file write 
> where we fault in a page via fault_in_pages_readable() but there is 
> nothing to guarantee that page will not go away between us doing this 
> and us using the page.

isnt this solved by:

 commit 6527c2bdf1f833cc18e8f42bd97973d583e4aa83
 Author: Vladimir V. Saveliev <vs@...esys.com>
 Date:   Tue Jun 27 02:53:57 2006 -0700

     [PATCH] generic_file_buffered_write(): deadlock on vectored write

?

if not, do you have any description of the problem or a link to previous 
discussion[s] outlining the problem? To me it appears this is a kernel 
bug where we simply dropped the ball to fix it. I personally dont find 
it acceptable to have deadlocks in the kernel, where all that is needed 
to trigger it is "high i/o loads", no matter how hard it is to fix the 
deadlock.

	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/