From 00978d6f5e6f4608c828152c0cd24270551f36cd Mon Sep 17 00:00:00 2001 From: alc Date: Tue, 1 Nov 2016 17:11:10 +0000 Subject: [PATCH] Move and revise a comment about the relation between the object's paging- 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 --- sys/vm/vm_fault.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/sys/vm/vm_fault.c b/sys/vm/vm_fault.c index 67f8c754a9a0..47a1bd57ef24 100644 --- a/sys/vm/vm_fault.c +++ b/sys/vm/vm_fault.c @@ -420,8 +420,7 @@ fast_failed: * 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 @@ readrest: 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) {