Date: Thu, 8 Jul 1999 07:58:49 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: The Hermit Hacker <scrappy@hub.org> Cc: freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: Known MMAP() race conditions ... ? Message-ID: <199907081458.HAA40125@apollo.backplane.com> References: <Pine.BSF.4.05.9907080812570.4088-100000@thelab.hub.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:At that time, Matt pop'd up and stated that he knew of *at least* 6 MMAP()
:related race conditions that he was hoping to be able to get fixed "within
:a week"...that would have been two weeks ago.
I think I was talking about mmap w/ NFS.
Under FreeBSD-current I know of two problems ( though I could be
forgetting some ) - there is a problem when a lot of pages get dirtied
that can cause a low-memory deadlock to occur, and I believe there is a
problem when mlock() or madvise() is used though I haven't reproduced
it yet.
Under FreeBSD-stable there are a number of additional, but minor problems
related to visibility of non-zero garbage after file EOF in an mmap(),
but these would have no effect on INN.
What we need to know is why the machines are locking up. The usual
way to figure this out is to compile the kernel up with DDB and then
when it locks up ctl-alt-esc on the console to get the DDB prompt,
and do a 'ps' to see what the procsses are blocked in.
If the problem is the dirty-page problem, there are ways around it
(basically by syncing more often).
-Matt
Matthew Dillon
<dillon@backplane.com>
:Thanks...
:
:Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
:Systems Administrator @ hub.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907081458.HAA40125>