- Avoid calling bread() with different sizes on the same blkno.
Although the buffer cache is designed to handle differing size
buffers, it erroneously tries to write the incorrectly-sized buffer
buffer back to disk before reading the correctly-sized one, even
when it's not dirty. This behaviour caused a panic for read-only
NTFS mounts when INVARIANTS was enabled ("bundirty: buffer x still
on queue y"), reported by NAKAJI Hiroyuki.
- Fix a bug in the code handling holes: a variable was incremented
instead of decremented, which could cause an infinite loop.
for vnodes reached through double indirection (i.e. **vpp). This
is worked-around by special-casing the identifier "vpp" (adding one
level of indirection).
The alternative fix mentioned in the PR had required substantial
changes to this script.
In case there are locking violations that had been hidden without
this patch, they may suddenly show up, now ...
This change does not affect code compiled without DEBUG_VFS_LOCKS.
PR: kern/46652
before calling it for bound thread. To avoid this problem, change
thread_schedule_upcall to not put new thread on run queue, let caller
do it, so we can tweak the new thread before setting it to run.
Reported by: pho
threads in the process have already masked the signal, so job control
is delayed. But later a thread unmasking the STOP signal should enable
job control, so in issignal(), scanning all threads in process to see
if we can direct suspend some of them, not just suspend current thread.
we can deadlock because of lock order reversals. This was not
caught because Witness ignores pool mutexes right now.
Diagnosis and help: truckman
Noticed by: pho
special files it was treated like -l. This commit adds the -x option
in for special files as well.
PR: bin/46249
Submitted by: Colin Percival <cperciva@sfu.ca>
least the 4.4-lite days. This is pointless, since fortune(6) performs
its own randomization. It was also problematic for binary update
systems such as ports/security/freebsd-update. This commit simply
removes the -r option to strfile so that the datfiles are constant.
Submitted by: Colin Percival <cperciva@sfu.ca>
"maxproc limit exceeded by uid %i, please see tuning(7) and login.conf(5)."
Which will be triggered whenever a user hits his/her maxproc limit or
the systemwide maxproc limit is reached.
MFC after: 1 week
