fixes pmap_steal_memory() as it can now unplug from the start of the
segment. This might be the right thing to do too as the pages before
kernend are accessed via directly mapped P1, but i need to ask someone
with a clue. This is also what evbsh3 always did.
Anyway, this at least unbreaks landisk after uvm hotplug fallout.
by UVM, so there is no physical loss.
On amd64 we always remap the kernel text with 2MB pages, and because of the
1MB start address we were forced to map [0MB; 2MB[ inside the first large
page. The problem is, the lower half is used by UVM to allocate physical
pages, and it is possible that some of these could be used by userland. We
could end up with userland-controllable data mapped into the kernel text on
a privileged page, which is far from being a good idea from a security pov.
I am not fixing i386 yet, because the large page size depends on PAE, and
we probably don't want to have a text located at 4MB on low-memory systems.
(note: I didn't introduce this issue, it was already there when I came in)
see http://mail-index.netbsd.org/tech-kern/2016/12/06/msg021281.html
tested device:
* ath at pci: AR5212, AR5424
* athn at pci: AR9287
* ipw at pci: 2100BG
* iwi at pci: 2915ABG
* iwm at pci: 3165, 7260, 8260
* iwn at pci: 4945, 6235
* ral at pci: RT2560
* rtwn at pci: RTL8192CE
pr_input is currently called in softint. Some pr_input such as ICMP, ICMPv6
and CARP can add/delete/update IP addresses and routing table entries. For
example, icmp6_redirect_input updates an a routing table entry and
nd6_ra_input may delete an IP address.
Basically such operations shouldn't be done in softint. That aside, we have
a reason to avoid the situation; psz/psref waits cannot be used in softint,
however they are required to work in such pr_input in the MP-safe world.
The change implements the workqueue pr_input framework called wqinput which
provides a means to defer pr_input of a protocol to workqueue easily.
Currently icmp_input, icmp6_input, carp_proto_input and carp6_proto_input
are deferred to workqueue by the framework.
Proposed and discussed on tech-kern and tech-net
These functions are described in the body of the man page but not
mentioned in the NAME section. Without an entry in the NAME section
apropos(1) doesn't get this man page in the results when queried for
one of those functions.
ok from christos.
