Date: Tue, 8 Aug 1995 23:24:41 +1000 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, dyson@freefall.cdrom.com Cc: CVS-commiters@freefall.cdrom.com, cvs-sys@freefall.cdrom.com Subject: Re: cvs commit: src/sys/i386/isa syscons.c Message-ID: <199508081324.XAA09841@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> I think M_WAITOK is no good for general use. Using it safely seems to >> _always_ require fairly tricky locking like we recently added to >> ffs_vget(). If there is any chance that a subroutine of a syscall calls >> ... >> The unified buffer cache probably makes these races more common. >> >It is very tricky to get the allocations correct, but the merged cache >code does lock vnodes and check memory allocations. Additionally, looking >at the vfs_bio it does M_NOWAIT (or equiv vm_page_alloc). (In fact, >I have a deadlock free nfs_bio locking mechanism now, that I am experimenting >with.) My main point was that the problem potentially applies to all uses of M_WAITOK. There are currently 238 plus more in aliases. 5 out of 5 new ones are buggy. I guess more than half of the others are buggy. I didn't mean that the unified buffer cache has bugs. Races should be more common just because memory is more fully committed. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199508081324.XAA09841>