Error Message

A typical thread stack trace will show a VxFS thread hung in the Solaris kernel page_lock_es routine:

The code in vx_page_alloc is there as a result of the interaction of two
different things: ILASTPAGEZEROED and VMODSORT.

When the end of a file doesn't land on a page boundary, the portion past the
end of file needs to be zeroed when the page is mapped. The simplest way to
do this is to always zero past end of file when the file is loaded. However,
if the page is never mapped, the page can never be accessed past end of file,
so the zeroing is not needed.

ILASTPAGEZEROED is an optimization VxFS has to delay zeroing past end of file
as much as possible. There are a few places where we'll do the zeroing, but
the relevant part is that VxFS will zero the page on the first page fault of
the last page through a user mapping (e.g. segvn).

VMODSORT is an optimization Sun added to Solaris where a vnode's page list is
sorted so that all of the dirty pages are on one end of the list. Because of the
way this is implemented, if we're going to be writing into a page during a page
fault, we need to lock the page exclusively.

In simple terms, the code in vx_page_alloc says that if VxFS found the page in
the page cache already, it's the last page of the file, end of file is in the
middle of the page, the inode is mapped, and we're faulting through a user
mapping, then VxFS needs to lock the page exclusively because it will be zeroed
later in getpage.

The bug occurs during writing to a file that is also mmapped. If mmap'ing the
last page of the file (and end of file is in the middle of a page) and use
that mapping to write to the end of the same file, then the source and
destination page are the same. The applicatin code would look something like:

addr = mmap(..., fd, )
lseek(fd, 0, SEEK_END)
write(fd, addr, 1)

During the write, VxFS will first fault in the destination page. Although it's
the last page of the file, we're not faulting through the user mapping at this
point, so getpage will not zero the page and VxFS will only lock it shared.
Later, uiomove will fault the source page. This time, VxFS is faulting through
the user mapping, so VxFS will need to lock the page exclusively. Since the
source and destination pages are the same, and VxFS has already locked the
destination page in shared mode, VxFS can't get the exclusive lock on the
page, thus the deadlock.

The fix removes the requirement that the page has to be faulted through the user
mapping to zero it. With that change, the page will end up getting zeroed when
the write faults in the destination page. After it zeroes the end of the page,
it downgrades the lock to shared. When uiomove faults it the source page, it's
already been zeroed, so it doesn't need to lock the page exclusively, avoiding
the deadlock.
 

A fix has been developed in VxFS  5.1RP1HF6.  The first generally available release to include this fix is 5.1SP1.The SYMC Etrack for this issue is 2120692

Applies To

Solaris environments with VxFS and VMODSORT support.