Date: Mon, 7 Jun 1999 06:04:26 -0500 (EST) From: "John S. Dyson" <dyson@iquest.net> To: green@unixhelp.org (Brian Feldman) Cc: hackers@FreeBSD.org Subject: Re: problem for the VM gurus Message-ID: <199906071104.GAA64050@dyson.iquest.net.> In-Reply-To: <Pine.BSF.4.10.9906061720010.71926-100000@janus.syracuse.net> from Brian Feldman at "Jun 6, 1999 05:24:41 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Brian Feldman said:
> In the long-standing tradition of deadlocks, I present to you all a new one.
> This one locks in getblk, and causes other processes to lock in inode. It's
> easy to induce, but I have no idea how I'd go about fixing it myself
> (being very new to that part of the kernel.)
> Here's the program which induces the deadlock:
>
>
> tmp = mmap(NULL, psize, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
> if (tmp == MAP_FAILED) {
> perror("mmap");
> exit(1);
> }
> printf("write retval == %lld", write(fd, tmp, psize));
>
I responded earlier to a reply to this message :-). This did
work about the time that I left, and it appears that it is likely
that code has been removed that mitigated this as a problem.
It is important to either modify the way that read or write
operations occur (perhaps prefault before letting the uiomove
operation occur (yuck, and it also still doesn't close all
windows), or reinstate the handling of recursive operations
on a vnode by the same process.) Handling the vnode locking
in a more sophistcated way would be better, but reinstating
(or fixing) the already existant code that used to handle
this would be a good fix that will mitigate the problem
for now.
--
John | Never try to teach a pig to sing,
dyson@iquest.net | it makes one look stupid
jdyson@nc.com | and it irritates the pig.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199906071104.GAA64050>