From: Ingo Molnar <mingo@elte.hu>
To: Anton Altaparmakov <aia21@cam.ac.uk>
Cc: Andrew Morton <akpm@osdl.org>,
nickpiggin@yahoo.com.au, eike-kernel@sf-tec.de,
linux-kernel@vger.kernel.org, aia21@cantab.net,
Arjan van de Ven <arjan@infradead.org>
Subject: Re: [BUG?] possible recursive locking detected
Date: Thu, 27 Jul 2006 16:45:43 +0200 [thread overview]
Message-ID: <20060727144542.GA27451@elte.hu> (raw)
In-Reply-To: <1154010677.21849.66.camel@imp.csi.cam.ac.uk>
* Anton Altaparmakov <aia21@cam.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
next prev parent reply other threads:[~2006-07-27 14:52 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-26 16:05 Rolf Eike Beer
2006-07-27 5:53 ` Andrew Morton
2006-07-27 6:51 ` Nick Piggin
2006-07-27 7:15 ` Anton Altaparmakov
2006-07-27 7:38 ` Andrew Morton
2006-07-27 8:19 ` Anton Altaparmakov
2006-07-27 8:53 ` Andrew Morton
2006-07-27 9:28 ` Anton Altaparmakov
2006-07-27 9:46 ` Ingo Molnar
2006-07-27 14:31 ` Anton Altaparmakov
2006-07-27 14:45 ` Ingo Molnar [this message]
2006-07-27 18:04 ` Andrew Morton
2006-07-27 9:18 ` Nick Piggin
2006-07-27 9:35 ` Anton Altaparmakov
2006-07-27 10:02 ` Nick Piggin
2006-07-27 12:30 ` Anton Altaparmakov
2006-07-27 7:24 ` Andrew Morton
2006-07-27 7:29 ` Arjan van de Ven
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060727144542.GA27451@elte.hu \
--to=mingo@elte.hu \
--cc=aia21@cam.ac.uk \
--cc=aia21@cantab.net \
--cc=akpm@osdl.org \
--cc=arjan@infradead.org \
--cc=eike-kernel@sf-tec.de \
--cc=linux-kernel@vger.kernel.org \
--cc=nickpiggin@yahoo.com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®