error and modify all callers to not brelse() on error.
Welcome to 6.99.16
PR kern/46282 (6.0_BETA crash: msdosfs_bmap -> pcbmap -> bread -> bio_doread)
This stops being true once a process has allocated (and freed) 2^32 lwps.
(I've not timed it!)
There is also some code lurking (eg ld.elf_so) that doesn't expect the
high be be set.
Once the lwp_id wraps, scan the list to find the first free id higher
than the last one allocated.
Maintain the sort order to make the possible.
Note that if some lwp (but not all) are allocated numbers from the pid
space it will go horribly wrong.
Tested by setting the limit to 128 and getting firefox to create threads.
clearly tells us:
kern_rate.c:98: warning: assuming signed overflow does not
occur when assuming that (X + c) > X is always true
Check value against INT_MAX instead. Also, for good measure throw
in a __predict() to flag the assumed common case.
- in close, invalidate f_data and f_type early to prevent accidental re-use
- add a DIAGNOSTIC for when we use unsupported fd's and a KASSERT for f_event
being NULL.
fds. XXX: We should really fix the fd's to be supported in the future.
Unsupported fd's have a NULL f_event, so registering crashes the kernel with
a NULL function dereference of f_event.
this prevents a hang trying to shut down other CPUs on x86,
and in general we could be called in any context from a panic
so it's best to skip unnecessary operations in that case.
for openat() and friends) to ni_atdir to avoid confusion with a
previously existing (and, alas, still documented) ni_startdir field
that meant something else entirely.
This uglifies the interface, because several operations need to be
passed the namei flags and cache_lookup also needs for the time being
to be passed cnp->cn_nameiop. Nonetheless, it's a net benefit.
The glop should be able to go away eventually but requires structural
cleanup elsewhere first.
This change requires a kernel bump.
- Move the namecache's hash computation to inside the namecache code,
instead of being spread out all over the place. Remove cn_hash from
struct componentname and delete all uses of it.
- It is no longer necessary (if it ever was) for cache_lookup and
cache_lookup_raw to clear MAKEENTRY from cnp->cn_flags for the cases
that cache_enter already checks for.
- Rearrange the interface of cache_lookup (and cache_lookup_raw) to
make it somewhat simpler, to exclude certain nonexistent error
conditions, and (most importantly) to make it not require write access
to cnp->cn_flags.
This change requires a kernel bump.
Depending on how the pty had been opened, t_dev could previously have
been set to NODEV. This was probably harmless before, but it caused the
compatibility handler for the COMPAT_60_TIOCPTSNAME ioctl to fail for
ptys that were allocated by screen(1), but only if this was the first
time that the pty had ever been used.
Elide the fs-wide rename lock for single-directory renames. This
required changing the order of lookups, so that we know what the
directories are before we lock the nodes.
Clean up error branches, explain why various nonsense happens and
what it does and doesn't do, and note some of what needs to change.
stale value can be returned and this causes a diagnostic panic in
namei.
In relookup(), clear *vpp before calling VOP_LOOKUP, as is done in
lookup_once(), as an additional precautionary measure.
(in theory both of these fixes are not required together)
Should fix PR 47040.
by calling NDAT(&nd, dirvp) after NDINIT().
Right now the implementation is vile and unspeakable to avoid changing
the kernel ABI; this way we can get openat() and friends into 6.1. I
will rectify the mess and bump the kernel once things are working.
caused by the sequence of passing two fd's with two sendmsg()'s,
then doing a read() and a recvmsg(). The read() calls dom_dispose()
which discards both messages in the mbuf, and sets the fp's in the
array to NULL. Linux dequeues only one message per read() so the
second recvmsg() gets the fd from the second message. This fix
just avoids the NULL pointer de-reference, making the second
recvmsg() to fail. It is dubious to pass fd's with stream sockets
and expect mixing read() and recvmsg() to work. Plus processing
one control message per read() changes the current semantics and
should be examined before applied. In addition there is a race between
dom_externalize() and dom_dispose(): what happens in a multi-threaded
network stack when one thread disposes where the other externalizes
the same array?
NB: Pullup to 6.
