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, dy...@iquest.net | it makes one look stupid jdy...@nc.com | and it irritates the pig. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message