Date: Tue, 8 Aug 1995 21:22:21 +1000 From: Bruce Evans <bde@zeta.org.au> To: CVS-commiters@freefall.cdrom.com, cvs-sys@freefall.cdrom.com, dyson@freefall.cdrom.com Subject: Re: cvs commit: src/sys/i386/isa syscons.c Message-ID: <199508081122.VAA04961@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
> Modified: sys/i386/isa syscons.c > Log: > Fixed a problem that malloc(..,..,M_NOWAIT) was being called without checking > for return values. It just so happens that in the cases where it is likely > to fail, it is okay to change the M_NOWAIT to M_WAITOK -- and all will > be well. This problem was manfest as a panic very regularly on a 4MB > system right after bootup. Actually it isn't really OK to simply substitute M_NOWAIT with M_WAITOK. If one of the malloc()s in scioctl() sleeps, then another process may run and use the half-allocated resources. If one of the malloc()s in in scioctl() or scopen() sleeps, then another process may run and repeat the ioctl and (at best) allocate the resources twice. 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 malloc(..., M_WAIT_OK), then must be done to prevent the syscall being reentered or to support reentrancy, and all resource that might be used or change while malloc() is sleeping have to be locked down and/or checked after waking up. The unified buffer cache probably makes these races more common. scioctl() is also missing necessary spltty() locking. What happens if a character is echoed while the history buffer is being resized? ... Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199508081122.VAA04961>