> Luoqi Chen said: > > > > > This seems to be the good old vnode deadlock during vm_fault() that has been > > reported a couple of times, and there's still no satisfactory solution to > > it: > > fgrep does something like this: (don't ask me why) > > > > addr = mmap(0, len, PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, offset); > > read(fd, addr, count); > > > > the read() syscall first locks the vnode, read the data from disk, then copy > > the data to buffer at addr, now if addr is not in core, there'll be a page > > fault and the fault handler vm_fault will try to lock the vnode pager > > backing > > the page at addr, which is already locked, deadlock. This deadlock then > > propagates all the way back to the root vnode and the whole system would > > freeze. > > > I believe that I had a pseudo-fix to that, and it might have been removed. > (In non-multithreaded kernels, when having to do things like the above, > allowing recursive locks under certain circumstances can solve the problem. > The key is to avoid the case where it covers up real bugs.) > > -- > 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. > Do you still have that piece of code? Does it handle the case involves more than one process? For example, process 1 mmaps file B and reads file A into the mmapped region, while process 2 mmaps file A and reads file B, this could also result in a deadlock.
-lq To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
