callout is started before kern_setitimer() acquires process mutex, but
looses a race and kern_setitimer() gets the process mutex before the
callout. Then, assuming that new specified struct itimerval has
it_interval zero, but it_value non-zero, the callout, after it starts
executing again, clears p->p_realtimer.it_value, but kern_setitimer()
already rescheduled the callout.
As the result of the race, both p_realtimer is zero, and the callout
is rescheduled. Then, in the exit1(), the exit code sees that it_value
is zero and does not even try to stop the callout. This allows the
struct proc to be reused and eventually the armed callout is
re-initialized. The consequence is the corrupted callwheel tailq.
Use process mutex to interlock the callout start, which fixes the race.
Reported and tested by: pho
Reviewed by: jhb
MFC after: 2 weeks
- Check V_deembed_scopeid before checking if sa_family == AF_INET6.
- Fix scope id handing in route(8)[2] and ifconfig(8).
Reported by: rpaulo[1], Mateusz Guzik[1], peter[2]
instead of /libexec/ld-elf.so.1. Below in the Makefile we execute
'chflags noschg ${DESTDIR}/usr/libexec/ld-elf.so.1', which follows
symlink and removes 'schg' flag from system's /libexec/ld-elf.so.1
instead of the one in DESTDIR. It is also more friendly to use
replative paths in symlink in case of jail/chroot environments.
Obtained from: WHEEL Systems
MFC after: 2 weeks
- Do not limit recent processors to "prescott" class for i386 target. There
is no reason for this hack because clang is default now. On top of that, it
will only grow indefinitely over time.
- Add more CPUTYPEs, i.e., "athlon-fx", "core-avx2", "atom", "penryn", and
"yonah". Note "penryn" and "yonah" are intentionally undocumented because
they are not supported by gcc and marked deprecated by clang.
- Add more CPUTYPE aliases, i.e., "barcelona" (-> amdfam10), "westmere" and
"nehalem" (-> corei7). Note these are intentionally undocumented because
they are not supported by (base) gcc and/or clang. However, LLVM (backend)
seems to "know" the differences. Most likely, they were deprecated with
other vendor code names and clang did not bother implementing them at all.
- Add i686 to MACHINE_CPU for "c3-2" (VIA Nehemiah). Both gcc & clang treat
it like an i686-class processor.
- Add IDT "winchip2" and "winchip-c6" for completeness (undocumented).
- Order processors per make.conf example, i.e., CPU vendors and models.
- Tidy up make.conf example, i.e., remove "by gcc" (because we have aliases)
and remove "prescott" from AMD64 architecture (because it is not correct).
over the active list. The mount interlock is not enough to guarantee
the validity of the tailq link pointers. The __mnt_vnode_next_active()
and __mnt_vnode_first_active() active lists iterators helper functions
did not provided the neccessary stability for the list, allowing the
iterators to pick garbage.
This was uncovered after the r243599 made the active list iterators
non-nop.
Since a vnode interlock is before the vnode_free_list_mtx, obtain the
vnode ilock in the non-blocking manner when under vnode_free_list_mtx,
and restart iteration after the yield if the lock attempt failed.
Assert that a vnode found on the list is active, and assert that the
helpers return the vnode with interlock owned.
Reported and tested by: pho
MFC after: 1 week
Note that a preprocessor cannot output an empty file, since that
is interpreted as meaning there is no replacement, and the origi-
nal file is used. To avoid this, if LESSOPEN starts with two ver-
tical bars, the exit status of the script becomes meaningful. If
the exit status is zero, the output is considered to be replace-
ment text, even if it empty. If the exit status is nonzero, any
output is ignored and the original file is used. For compatibil-
ity with previous versions of less, if LESSOPEN starts with only
one vertical bar, the exit status of the preprocessor is ignored.
Use two pipe symbols for zless, so that zless'ing a compressed empty
file will give output rather than being interpreted as its compressed
form, which is typically a binary.
Thanks Mark Nudelman for pointing out this difference and the
suggested solution.
Reported by: Matthias Meyser <meyser xenet.de>
PR: bin/168839
MFC after: 2 weeks
thought I've decided its overkill,a simple tuneable for
each RX and TX limit, and then init sets the ring values
based on that, should be sufficient.
More importantly, fix a bug causing a panic, when changing
the define style to IXGBE_LEGACY_TX a taskqueue init was
inadvertently set #ifdef when it should be #ifndef.
UPDATING by URL.
As there has been some confusion over the need to run "mergemaster -p",
part of our standard upgrade procedure, following the recent addition of
an "auditdistd" user, add a note about it to UPDATING explicitly.
