which potentially have multiple output files, which confuses make(1).
This wrapper copies all involved files into /tmp, execute the command, and
copy the wanted file back to ${.OBJDIR}. If this is expensive, consider to
rewrite the generation command to output files individually.
XXX bsd.own.mk is too bloated.
"marked clean" after however much inactivity; it is *actually* clean
as soon as the component disks all do their thing (on the order of ms,
usually), just the same as before.
The bikeshed is now less of a taupe and more of an ecru.
check the signal number to be in the allowed range. An invalid
signal number could crash the kernel by overflowing the sigset_t
array.
More checks would be good, and SIGEV_THREAD shouldn't be dropped
silently, but this fixes at least the local DOS vulnerability.
Split a segment if its size is larger than dm_maxsegsz.
iommu_dvmamap_load_raw:
Don't coalesce segments if total size is larger than dm_maxsegsz.
This should fix port-sparc64/35299.
-an invalid signal number passed to mq_notify(2) could crash the kernel
on delivery -- add a boundary check
-mq_receive(2) from an empty queue crashed the kernel by NULL dereference
in timeout calculation -- handle the NULL case
-likewise for mq_send(2) to a full queue
-a user could set mq_maxmsg (the maximal number of messages in a queue)
to a huge value on mq_open(O_CREAT) and later use up all kernel
memory by mq_send(2) -- add a sysctl'able limit which defaults
to 16*mq_def_maxmsg
(mq_notify(2) should get some more checks, and SIGEV_* values other
than SIGEV_SIGNAL should be handled somehow, but this doesn't look
security critical)
do drain' in many places, whereas fo_drain() was called in order to force
blocking read()/write() etc calls to return to userspace so that a close()
call from a different thread can complete.
In the sockets code comment out the broken code in the inner function,
it was being called from compat code.
BaiYang per PR lib/42434
the sad truth is that this doesn't help much because SIGEV_THREAD just
doesn't work (at least on -current, likely on -5, perhaps it worked
woth scheduler activations)
list of sources. This, in a rather curious twist of linker magic,
broke anything using rump file systems when librumpvfs was compiled
with LIBDPLIBS pointing to librump.
Thanks to the several people who reported the problem, and especially
Arnaud Ysmal for noticing the paramount symptom that components
compiled in src/lib did not work while ones compiled in sys/rump/librump
did work.
They were incorrect since 1997 on amiga and atari, and since 2002
on other ports, but fortunately they don't look so fatal.
Anyway, these values will be moved into <m68k/pmap_motorola.h> soon
since they are quite pmap implementation dependent.
patch OSIOC{G,S}IFFLAGS is supposed to work, but unfortunately getifaddrs
seems to be the next problem getting the 4.99.x i386 ifconfig working on an
amd64 current machine.
