d/freebsd-skq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Move and revise a comment about the relation between the object's paging-

Browse Source 
in-progress count and the vnode.  Prior to r188331, we always acquired
the vnode lock before incrementing the object's paging-in-progress count.
Now, we increment it before attempting to acquire the vnode lock with
LK_NOWAIT, but we never sleep acquiring the vnode lock while we have the
count incremented.

Reviewed by:	kib
MFC after:	3 days
This commit is contained in:
alc 2016-11-01 17:11:10 +00:00
parent b1120d8cc2
commit 00978d6f5e
1 changed files with 8 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
sys/vm/vm_fault.c
View File

@ -420,8 +420,7 @@ RetryFault:;
* they will stay around as well.
*
* Bump the paging-in-progress count to prevent size changes (e.g.
* truncation operations) during I/O. This must be done after
* obtaining the vnode lock in order to avoid possible deadlocks.
* truncation operations) during I/O.
*/
vm_object_reference_locked(fs.first_object);
vm_object_pip_add(fs.first_object, 1);
@ -647,7 +646,13 @@ RetryFault:;
if (locked != LK_EXCLUSIVE)
locked = LK_SHARED;
/* Do not sleep for vnode lock while fs.m is busy */
/*
* We must not sleep acquiring the vnode lock
* while we have the page exclusive busied or
* the object's paging-in-progress count
* incremented. Otherwise, we could deadlock.
*/
error = vget(vp, locked | LK_CANRECURSE |
LK_NOWAIT, curthread);
if (error != 0) {