src-test2/sys/vm/vm_object.c, branch releng/6.3FreeBSD source treehttps://cgit-dev.freebsd.org/src-test2/atom?h=releng%2F6.32007-04-04T03:15:03ZMFC revision 1.3772007-04-04T03:15:03ZAlan Coxalc@FreeBSD.org2007-04-04T03:15:03Zurn:sha1:34d5daa77d837f4bf0e6dcdb0fc4e54eb24c5032
Prevent a race between vm_object_collapse() and vm_object_split() from
causing a crash.
MFC revision 1.358:2006-09-29T04:37:22ZAlan Coxalc@FreeBSD.org2006-09-29T04:37:22Zurn:sha1:ffcdeef457016be83d12f98362bf06fa2f0491a2
Lock the vm_object while checking its type to see if it is a vnode-backed
object that requires Giant in vm_object_deallocate(). This is somewhat
hairy in that if we can't obtain Giant directly, we have to drop the
object lock, then lock Giant, then relock the object lock and verify that
we still need Giant. If we don't (because the object changed to OBJT_DEAD
for example), then we drop Giant before continuing.
Approved by: re
MFC revision 1.3602006-08-15T17:51:02ZAlan Coxalc@FreeBSD.org2006-08-15T17:51:02Zurn:sha1:6ea7743ba91121bccf29834f4fffa46fa85837f5
Ensure that vm_object_deallocate() doesn't dereference a stale object
pointer: When vm_object_deallocate() sleeps because of a non-zero
paging in progress count on either object or object's shadow,
vm_object_deallocate() must ensure that object is still the shadow's
backing object when it reawakens. In fact, object may have been
deallocated while vm_object_deallocate() slept. If so, reacquiring
the lock on object can lead to a deadlock.
MFC Revs 1.357, 1.3552006-03-13T03:08:21ZJeff Robersonjeff@FreeBSD.org2006-03-13T03:08:21Zurn:sha1:fd7e8a85d7c636de6756f8b4a74031656a22b5c0
VFS SMP fixes, stack api, softupdates fixes.
Sponsored by: Isilon Systems, Inc.
Approved by: re (scottl)
MFC: Eliminate a deadlock when creating snapshots. Blocking2006-03-09T00:18:45ZTor Eggetegge@FreeBSD.org2006-03-09T00:18:45Zurn:sha1:b276e347057e5ecedc792d4d9c89d92a735f83fd
vn_start_write() must be called without any vnode locks held.
Remove calls to vn_start_write() and vn_finished_write() in
vnode_pager_putpages() and add these calls before the vnode lock
is obtained to most of the callers that don't already have them.
Approved by: re (mux)
MFC (by alc) changesets that addresses several race conditions that can2005-10-26T20:21:23ZXin LIdelphij@FreeBSD.org2005-10-26T20:21:23Zurn:sha1:45c30abe27884bd18db5d3af83c4da1f2518b180
cause a kernel compiled with ZERO_COPY_SOCKETS to panic under certain
circumstances:
sys/kern/uipc_cow.c: 1.24 - 1.26
sys/vm/vm_object.c: 1.351
Approved by: re (scottl)
MFC: Don't allow pagedaemon to skip pages while scanning active and2005-08-12T16:43:27ZTor Eggetegge@FreeBSD.org2005-08-12T16:43:27Zurn:sha1:263daf2afa65b4669b638265118eb41fa7f8153c
inactive page queues due to the vm object being locked.
Approved by: re (kensmith)
- We need to inhert the OBJ_NEEDGIANT flag from the original object in2005-05-04T20:54:16ZJeff Robersonjeff@FreeBSD.org2005-05-04T20:54:16Zurn:sha1:b8a0b997fd8afd21ac9b08f4d78a6b1001f1fcb4
vm_object_split().
Spotted by: alc
- Add a new object flag "OBJ_NEEDSGIANT". We set this flag if the2005-05-03T11:11:26ZJeff Robersonjeff@FreeBSD.org2005-05-03T11:11:26Zurn:sha1:ed4fe4f4f5dd2ae7ef62e004a3e1bdd071b8fee6
underlying vnode requires Giant.
- In vm_fault only acquire Giant if the underlying object has NEEDSGIANT
set.
- In vm_object_shadow inherit the NEEDSGIANT flag from the backing object.
Eliminate (now) unnecessary acquisition and release of the global page2005-03-30T05:40:02ZAlan Coxalc@FreeBSD.org2005-03-30T05:40:02Zurn:sha1:c6ec6a7caebd712ffac70508099aeb71f302f033
queues lock in vm_object_backing_scan(). Updates to the page's PG_BUSY
flag and busy field are synchronized by the containing object's lock.
Testing the page's hold_count and wire_count in vm_object_backing_scan()'s
OBSC_COLLAPSE_NOWAIT case is unnecessary. There is no reason why the held
or wired pages cannot be migrated to the shadow object.
Reviewed by: tegge