From owner-cvs-all Thu Sep 24 19:40:03 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA11010 for cvs-all-outgoing; Thu, 24 Sep 1998 19:40:03 -0700 (PDT) (envelope-from owner-cvs-all) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA10939 for ; Thu, 24 Sep 1998 19:39:54 -0700 (PDT) (envelope-from dillon@backplane.com) Received: (dillon@localhost) by apollo.backplane.com (8.9.1/8.6.5) id TAA22663; Thu, 24 Sep 1998 19:39:49 -0700 (PDT) Date: Thu, 24 Sep 1998 19:39:49 -0700 (PDT) From: Matthew Dillon Message-Id: <199809250239.TAA22663@apollo.backplane.com> To: Luoqi Chen Cc: committers@FreeBSD.ORG Subject: Re: Kernel is hitting my debugging printf's References: <199809250136.VAA00121@lor.watermarkgroup.com> Sender: owner-cvs-all@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk :> :> Ok, I will throw in clearing B_RELBUF if B_DELWRI is set just before :> the VMIO buffer rundown in brelse() and let it run for a day or two :> on our news box before comitting it. :> :> :There's still one thing I don't quite understand. The code path to reach :vfs_vmio_release with B_RELBUF set should be, : vm_fault()->vnode_getpages()->ffs_getpages()->ffs_read()->brelse() :If the page is still in a B_DELWRI buffer, it should be also in the vm object, :the page fault should be a soft fault, the only thing vm_fault() needs to :do is to insert the page into the physical map, no io should be required. :There is still something not quite right, this fix shouldn't be needed at all. :But for now, I think it will plug the hole. : :-lq The filesystem code sets B_RELBUF in ufs/ufs/ufs_readwrite.c. Since we may be doing small write()s, I can see the first write setting B_DELWRI and other writes into the same block setting independantly B_RELBUF, or something to that effect. I think the VM faults are somehow making it more likely that the problem comes to light, perhaps by reordering the page's location in the cache queue making it more likely to be freed or reused. The dnewslink side of the Diablo news system uses madvise() very heavily which could also be an issue along with the mmap. B_RELBUF is only supposed to be advisory, so I think our fix (assuming it works properly... looks good so far!) is the correct thing to do. -Matt Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response)