On Fri, 3 Feb 2017 21:29:33 -0800 Jason Harmening <jason.harmen...@gmail.com> wrote:
> Hi,
>
> I'm a bit confused as to how this change breaks MIPS. The new
> function, get_pcpu() is intended to be used only to access the
> per-cpu data pointer locally. It returns pcpup, which is the per-cpu
> pointer wired into the local TLB to translate to the local CPU's
> physical data region, correct?
>
> This is the same value used by the per-CPU accessors such as PCPU_ADD
> and PCPU_GET. The MI portions of this change only use get_pcpu() to
> access the local CPU's data, e.g. under a critical section in the
> rmlock. It is not intended to be used for iterating all CPUs.
>
> If I've missed something and MIPS is truly broken by this, then I'll
> gladly revert, but (maybe because it's late) I'm not seeing where
> this goes wrong on MIPS.
>
> Thanks,
> Jason
The hang is actually due to _rmlock_assert spinning in
rm_trackers_present with interrupts disabled, due to this constructs:
for (queue = pc->pc_rm_queue.rmq_next; queue !=
&pc->pc_rm_queue; queue = queue->rmq_next) {
You changed the code to pass get_pcpu() results instead of direct
pointer to the corresponding pcpu storage and that is NOT the pointer
that was being used in pcpu_init. On architectures that rig TLB to make
local PCPU available at constant address from each CPU, these two are
generally not same, so while empty pc_rm_queue is a cyclic list
consisting of just one element pc_rm_queue, the loop terminating
condition will never be met, as &pc->pc_rm_qeue value will be very
different from the one that pc->pc_rm_queue.rmq_next was set at
initialisation time.
This affects MIPS in SMP configuration only, UP configs do not bother
with TLB hackery.
--
Alexander Kabaev
pgpz8CADzOmvi.pgp
Description: Цифровая подпись OpenPGP
