Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 24 Feb 1999 01:26:43 -0500 (EST)
From:      Luoqi Chen <luoqi@watermarkgroup.com>
To:        dyson@iquest.net
Cc:        freebsd-current@FreeBSD.org, tegge@fast.no
Subject:   Re: Filesystem deadlock
Message-ID:  <199902240626.BAA10360@lor.watermarkgroup.com>

next in thread | raw e-mail | index | archive | help
> Luoqi Chen said:
> > > 
> > 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.
> > 
> It used to be part of the tree, but I seem to remember that it was removed
> (by those who understand the code :-)) soon after I left.  I will look for
> it, and see if it would help with the problem(s).
> 
> -- 
> 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.
> 
I have some thoughts on how to solve this problem. A deadlock can occur
when you read into a mmapped region or write from a mmapped region, a
solution to this problem must be able to handle both cases.

For the first case (read), (as originally suggested by Tor Egge), we could 
allow vm_fault's shared lock attempt to succeed even if there's already
a process waiting for the exclusive lock. This is unlikely to create any
starvation problem.

For the second case (write), it's trickier if there're two processes
involved. My solution is not to use exclusive lock for write, because
in most cases we don't need to lock the vnode exclusively, except when
disk block allocation is required. We could instead perform a lock
upgrade before and a downgrade after the block allocation, so the process
will only hold a shared lock when copying from the mmapped address,
and thus deadlock can be avoided just as in the first case.

Comments?

-lq


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?199902240626.BAA10360>