they cannot mount a filesystem that they cannot see in getvfsbyname().
Part 1 of this is a hack, make vfsisloadable() always return true - the
ultimate decider of whether it's loadable or not is kldload() or mount().
Part 2 of this is to have vfsload() call kldload(2) and return success if
it works. This means that we will use a viable kld module in preference
to an LKM!
Ultimately, the thing to do is remove the hacks to do a vfsload in all the
mount_* commands and let the kernel do it by itself in mount(2).
vfork() can't be used. We could use alloca() in execl() so that
it can be called between vfork() and execve(), but a "portable"
popen() shouldn't depend on this. Calling execle() instead of
execl() should be fairly safe, since execle() is supposed to be
callable from signal handlers and signal handlers can't call
malloc(). However, execle() is broken.
ever saw one), and move the description of NULL behaviour out to a
'NOTES' section, with an extra note that programs should not rely up
on it.
Kinda-approve-by: bde (by not replying to the mail with the diff)
PR: 7923
Submitted by: Archie Cobbs <archie@whistle.com>
The scandir() function returns -1 if it fails.
In many cases when this happens, it does not free
the memory that it allocated, resulting in a memory
leak, or close the directory opened with opendir().
BAD DOG, BAD!
realloc functions check for recursion within the malloc code itself. In
a thread-safe library, the single spinlock ensures that no two threads
go inside the protected code at the same time. The thread implementation
is responsible for ensuring that the spinlock does in fact protect malloc.
There was a window of opportunity in which this was not the case. I'll fix
that with a commit RSN.
string. From the submitted patch:
Credit for patch: Chris Torek <torek@bsdi.com>
Tod Miller <millert@openbsd.org>
This makes us in line with SunOS 4.1.3_U1, Solaris 2.6, OpenBSD 2.3,
HP-UX 10.20, Irix 5.3. The previous behavior was in line with Ultrix 4.4.
PR: bin/7970
Submitted by: Niall Smart nialls@euristix.ie
Our spinlock implementation allows a particular thread to obtain a lock
multiple times, but release the lock with a single unlock call. Since
we're detecting recursion, we know the lock is already owned by the
current thread in a previous call and must not be released in the
current call. This is really far too dependent on this particular
spinlock implementation, so I've added commented out calls to
THREAD_UNLOCK in the appropriate places. We can activate this code when
spinlock is taught to count each lock operation.
