It is not enough to avoid displaying the contents of the directory,
we need to set FTS_SKIP to avoid descending into any subdirs too.
Otherwise, if a ".foo" directory has a subdirectory "bar", ls will
descend into bar and display its contents. From Todd Miller
Fix crash due to out-of-bounds access with Ctrl-W.
PR is only for nottywerase, but also fix ttywerase case, taken from
OpenBSD via nvi2:
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/vi/vi/v_txt.c#rev1.235d5365d358
Also, comment there is no worry for altwerase specific code, which
seems suspicious at a glance.
Reported by Azuma OKAMOTO.
Thanks for detailed explanation how to reproduce the problem!
- Don't expose how PCI bus configuration resource management is implemented.
Provide a new resource provider API:
==> pciconf_resource_init() -- Initialize a PCI configuration resources
container.
==> pciconf_resource_add() -- Add a PCI configuration resource to the
container (I/O, MEM, or prefetchable MEM). Multiple resources of
each type may be added.
==> pciconf_resource_fini() -- Tear down the PCI configurtation resources
container once the bus has been configured.
This is much easier to use than the previous method of providing an
extent map for each kind of resource, and works better for e.g. ACPI
platforms that provide potentially multiple PCI resources in tables
provided by firmware.
- Re-implement PCI configuration resource management using vmem arenas,
rather than extent maps.
freeze after calling OF_quiesce().
This is why setting color palette crash the system for some Power Mac G5
models, like PowerMac11,2.
Therefore, stop using color-palette and backlight callbacks for genfb(4)
in this case.
Also, postpone OF_quiesce() after rascons_init_rasops(), and initialize
color palette there if OF is going to be quiesced and color depth is 8.
Now, color palette for wscons is initialized correctly for PowerMac11,2.
For some machines like PowerMac11,2, Open Firmware does not correctly
initialize console-related variables, like font-adr and line#, when
``auto-boot?'' is true; -1 is returned instead of correct values.
Fall back to wsfont embedded in kernel in this case. Also, do not use
line# if it is negative.
openssl fails on FPU emulation for powerpc
When machdep.fpu_present sysctl variable can be retrieved, and
its value is zero, avoid using FPU arithmetic.
FPU is absent and emulated by kernel in that case, and calculation
results are not correct in bit-to-bit precision.
This behavior should be useful even if we could fix FPU emulation;
it is much faster to skip FPU arithmetic in general, rather than
relying upon emulation by kernel via illegal instruction handler.
openssl fails on FPU emulation for powerpc
Provide machdep.fpu_present sysctl variable like other ports.
Userland can get informed that FPU is absent and emulated in software
(and calculation results may not be correct in bit-to-bit precision).
This variable should be useful even if we could fix FPU emulation;
it is much faster to skip FPU arithmetic in general, rather than
relying upon emulation by kernel via illegal instruction handler.
pmap for booke assumes that the ``va'' argument for pmap_kenter_pa(9) is
page-aligned. However, by recent changes, tmpfs became to use ``va'' with
page offset via ubc_uiomove(9). So, truncate it to page boundary.
X/Open Curses says in the documentation for newpad():
Automatic refreshes of pads (e.g., from scrolling or echoing of
input) do not occur.
And in the documentation for get*():
If the current or specified window is not a pad, and it has been
moved or modified since the last refresh operation, then it will be
refreshed before another character is read.
From Michael Forney in PR lib/55457
We need to clear the fpu state anyway because it is likely to contain
secrets at this point. Previously we set it to zeros, and then issued
stts to disable the fpu in order to detect the mistake of further use
of the fpu in kernel. But there must be some path I haven't identified
yet that doesn't do fpu_handle_deferred, leading to fpudna panics.
In any case, there's no benefit to restoring the fpu state twice
(once with zeros and once with the real data). The downside is,
although this avoids spurious fpudna traps, using fpu_kern_enter in a
softint has the side effect that -- until the next userland context
switch triggering stts -- we no longer detect misuse of fpu in the
kernel in that lwp. This will serve for now, but we should find
another way to issue clts/stts judiciously to detect such misuse.
May improve the continued symptoms of
https://mail-index.netbsd.org/current-users/2020/07/02/msg039051.html
although may not fix everything.
christos