3d69163ace
and R/W emulation aborts under pmap lock. There were two reasons for using of atomic operations: (1) the pmap code is based on i386 one where they are used, (2) there was an idea that access and R/W emulation aborts should be handled as quick as possible, without pmap locking. However, the atomic operations in i386 pmap code are used only because page table entries may be modified by hardware. At the beginning, we were not sure that it's the only reason. So even if arm hardware does not modify them, we did not risk to not use them at that time. Further, it turns out after some testing that using of pmap lock for access and R/W emulation aborts does not bring any extra cost and there was no measurable difference. Thus, we have decided finally to use pmap lock for all operations on page table entries and so, there is no reason for atomic operations on them. This makes the code cleaner and safer. This decision introduce a question if it's safe to use pmap lock for access and R/W emulation aborts. Anyhow, there may happen two cases in general: (A) Aborts while the pmap lock is locked already - this should not happen as pmap lock is not recursive. However, under pmap lock only internal kernel data should be accessed and such data should be mapped with A bit set and NM bit cleared. If double abort happens, then a mapping of data which has caused it must be fixed. (B) Aborts while another lock(s) is/are locked - this already can happen. There is no difference here if it's either access or R/W emulation abort, or if it's some other abort. Reviewed by: kib |
||
---|---|---|
.. | ||
allwinner | ||
altera/socfpga | ||
amlogic/aml8726 | ||
annapurna/alpine | ||
arm | ||
at91 | ||
broadcom/bcm2835 | ||
cavium/cns11xx | ||
conf | ||
freescale | ||
include | ||
lpc | ||
mv | ||
nvidia | ||
qemu | ||
rockchip | ||
samsung/exynos | ||
ti | ||
versatile | ||
xilinx | ||
xscale |