Date: Wed, 23 Feb 2005 16:45:13 +0000 (UTC) From: Alan Cox <alc@FreeBSD.org> To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/vm vm_object.c Message-ID: <200502231645.j1NGjDWa065554@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
alc 2005-02-23 16:45:13 UTC FreeBSD src repository Modified files: (Branch: RELENG_5) sys/vm vm_object.c Log: MFC revisions 1.333 and 1.334 Eliminate unnecessary calls to vm_page_busy(). MFC revision 1.340 Move the acquisition and release of the page queues lock outside of a loop in vm_object_split() to avoid repeated acquisition and release. MFC revision 1.343 Consider three objects, O, BO, and BBO, where BO is O's backing object and BBO is BO's backing object. Now, suppose that O and BO are being collapsed. Furthermore, suppose that BO has been marked dead (OBJ_DEAD) by vm_object_backing_scan() and that either vm_object_backing_scan() has been forced to sleep due to encountering a busy page or vm_object_collapse() has been forced to sleep due to memory allocation in the swap pager. If vm_object_deallocate() is then called on BBO and BO is BBO's only shadow object, vm_object_deallocate() will collapse BO and BBO. In doing so, it adds a necessary temporary reference to BO. If this collapse also sleeps and the prior collapse resumes first, the temporary reference will cause vm_object_collapse to panic with the message "backing_object %p was somehow re-referenced during collapse!" Resolve this race by changing vm_object_deallocate() such that it doesn't collapse BO and BBO if BO is marked dead. Once O and BO are collapsed, vm_object_collapse() will attempt to collapse O and BBO. So, vm_object_deallocate() on BBO need do nothing. MFC revision 1.345 Update the text of an assertion to reflect changes made in revision 1.148. Eliminate an unnecessary, temporary increment of the backing object's reference count in vm_object_qcollapse(). Revision Changes Path 1.331.2.3 +12 -12 src/sys/vm/vm_object.c
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200502231645.j1NGjDWa065554>