Date: Sun, 20 Oct 2002 19:37:08 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: "M. Warner Losh" <imp@bsdimp.com> Cc: jake@locore.ca, ben@stuyts.nl, current@FreeBSD.ORG, jroberson@chesapeake.net, rwatson@FreeBSD.ORG, jeff@FreeBSD.ORG, alfred@FreeBSD.ORG Subject: Re: [Ugly PATCH] Again: panic kmem_malloc() Message-ID: <3DB36854.FFEC4E2F@mindspring.com> References: <20021018213608.A60569@locore.ca> <20021020.125308.35255652.imp@bsdimp.com> <3DB31925.7B70E70@mindspring.com> <20021020.155657.10475080.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"M. Warner Losh" wrote: > : > : + if (sops) > : > : + free(sops, M_SEM); > : > > : > The kernel free() groks free(NULL, M_FOO), so the if isn't needed. > : > : Wow. That's bogus. It should panic. > > It isn't bogus. free(NULL) is defined to be OK in ansi-c. The kernel > just mirrors that. The free(NULL) in ANSI C is to permit invocation of the garbage collector; there are very specific semantics involved. Specifically, if you do not call free(NULL), you are *guaranteed* that a malloc() followed by a free() followed by a subsequent malloc(), if the size of the area allocated by the subsequent malloc() is less than or equal to the size of the area freed, *will not fail*. Of course, FreeBSD is a memory overcommit system, and fails to maintain this guarantee, as required by the standard (e.g. only do garbage collection when it is signalled that it is OK for a subsequent re-malloc() to fail, because the GC'ed memory has been released to the system. This is OK; we all realize that the standard, which permits a NULL argument to free(), allows this value for reasons of compatability with historical source code. But that begs the question: does the kernel interface also allow it for the purposes of compatability with legacy code? This seems unlikely in the extreme. Does the kernel interface use this as a trigger, as the user space interface historically did, to perform garbage collection? This also seems unlikely. Does it do it so that people can write code that doesn't check return values, and get away with it when they shouldn't? This seems highly likely. > : Or we should fix all of libc to take NULL arguments for strings, > : and treat them as if they were actually "". > > That's bogus. I agree that it's bogus, but it's the same argument in user space as in kernel space. Actually, it's not the same: the kernel argument is much poorer, not having legacy code it needs to support. In user space, there is plenty of legacy code that acts this way; in fact, one could trap a zero dereference (one does; one just faults on it, currently), map a page full of zeros at page zero, and then a dereference would in fact b giving a pointer to a NULL string. SVR4 does this, as a kernel option for compatability with legacy software. It is tunable to be able to turn it off, and you can not only run legacy software which will not run in FreeBSD ABI compatability (hardly compatable, that...), but you can know from the memory map of the process, as examined through /proc, that a NULL dereference has occurred. So it should arguably be controllable via sysctl, minimally for IBCS2 and similar ABI modules, for user space. But it's still unjustified in kernel space. And panic'ing on attempts to free NULL pointers would be a nice way of avoiding cascade failures later on, and keep the problem from being hidden a long ways away from its effect. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DB36854.FFEC4E2F>