If we call key_sendup_mbuf from key_acquire that is called on packet
processing, a deadlock can happen like this:
- At key_acquire, a reference to an SP (and an SA) is held
- key_sendup_mbuf will try to take key_so_mtx
- Some other thread may try to localcount_drain to the SP with
holding key_so_mtx in say key_api_spdflush
- In this case localcount_drain never return because key_sendup_mbuf
that has stuck on key_so_mtx never release a reference to the SP
Fix the deadlock by deferring key_sendup_mbuf to the timer
(key_timehandler).
autoloaded modules. These options are disabled everywhere (except ibcs2
on Vax, but Vax does not support kernel modules, so doesn't matter),
therefore there is no issue in removing them from the list. Interested
users will now have to do a 'modload' first, or uncomment the entries in
GENERIC.
From Zhang Fuxin via https://sourceware.org/ml/binutils/2009-11/msg00387.html
- The NOP issue
"The nature of the erratum is deeply related to the microarchitecture of
Loongson-2. It uses roughly a 4-way superscalar dynamically scheduled core,
instructions are excuted as much as possible in parallel with technics like
branch prediction etc. We use a 8-entry internal branch prediction queue to
keep track of each predicted branches, if some branches are proved to be
wrongly predicted, all the instructions following it will be cancelled,together
with the resources used by them, including the registers used for renaming, and
the queue entry will be freeed. There is a bug that might cause a hang when the
queue is full(some resources might been leaked due to conflict branch entries),
the workaround is to reduce the possiblity of branch queue full by using
renaming registers(they are also limited, can prevent too many simutaneos
branches). In theory this is still not enough to fully eliminate possible
hangs, but the possiblity is extremely low now and hard to be hit in real
code."
- The JUMP instructions issue
"The Loongson-2 series processors have quite complex micro-architecture, it will
try to execute instructions from the predicated branch of coming instruction
stream before they are confirmed to be run, if the predication of branch
direction is proved wrong later, the instructions will be cancelled, but if the
instructions is a read from memory, the read action might not be cancelled(but
the changes to register will) to enable some prefetch. This will lead to some
problems when compining with some chipsets. E.g. the AMD CS5536 used in
Yeeloong/Fuloong will hang if it gets an address in the physical address range
of 0x100000-0x200000(might be more other ranges). Speculative reads can perform
read at any address in theory(due to wrong prediction of branch directions and
the use of branch target buffer), thus in very few occasions they might cause a
hard lock of the machine.
To prevent this, we need to prevent some addresses from entering branch
target buffers. A way to do this is that to modify all jump targets, e.g.,
calulations of t9
...
jalr t9 =>
calculations of t9
or t9, t9, 0x80000000; // to make sure t9 is in kseg0
jalr t9
Of course, we have to consider 64/32bit, and modules addresses etc.
This only need to be performed on kernel code, because only there we can have
accesses not translated/limited by TLB. For user code, it is impossible to
generate accesses to unwanted physical address. So it is safe.
Also, to prevent addresses generated by user mode code to be used by the
kernel, we add a few empty jumps to flush the BTB upon entrance to kernel."
If key_sendup_mbuf isn't passed a socket, the assertion fails.
Originally in this case sb->sb_so was softnet_lock and callers
held softnet_lock so the assertion was magically satisfied.
Now sb->sb_so is key_so_mtx and also softnet_lock isn't always
held by callers so the assertion can fail.
Fix it by holding key_so_mtx if key_sendup_mbuf isn't passed a socket.
Reported by knakahara@
Tested by knakahara@ and ozaki-r@
other operating systems.
15 Errata: Issue of Out-of-order in loongson (translated)
In loongson 2F, because of the branch prediction, sometimes the CPU
may fetch the instructions from some unexpected area (for example I/O
space). It is an invalid operation. There are two ways for the CPU to
choose the branch target. The first one is predicting the branch
target according to the branch target history. The second one is
calculating the branch target by the ALU. There are most 8
instructions in the instruction window at the same time in loongson2f
(Remember the loongson 2f is superscalar, right?). Hence, the
branch target of an indirect branch(such as jr) could be got(may be
predicted by the branch target history) earlier and the instrctions of
the branch target could be prefetched even if there are branch
instructions before it. As a result, it is possible to fetch the
instructions from I/O region( say out-of the physical address range of
[0- 0x100000]) in kernel model because of the instruction prefetch of
the branch target.
There are some suggestions to prevent prefetching instructions from
the I/O region in kernel mode.
(1) When switching from user model to kernel model, you should flush
the branch target history such as BTB and RAS.
(2) Doing some tricks to the indirect branch target to make sure that
the indirect branch target can not be in the I/O region.
will now have to type 'modload' to use it, or uncomment the entry in
GENERIC. I should have removed it when I disabled COMPAT_FREEBSD by
default, sorry about that.
localcount(9) is used to protect key_sad.sahlist and sah entries
as well as SPD (and will be used for SAD sav).
Please read the locking notes of SAD for more details.
fixed in 1.31. The old one with UNCONST does work on hpcsh b/c the
kernel is directly mapped. The new one does not work on hpcsh b/c it
calls consinit() very early when malloc() is not yet available.
The real fix for this is to fix the constness of wscons keymap
structures that is self-contradictory.
- Add locking order
- Add locking notes for misc lists such as reglist
- Mention pserialize, key_sp_ref and key_sp_unref on SP operations
Requested by riastradh@
