aboutsummaryrefslogtreecommitdiffstats
path: root/scripts/recordmcount.h
diff options
context:
space:
mode:
authorNathan Lynch <nathanl@linux.ibm.com>2019-06-21 01:05:18 -0500
committerMichael Ellerman <mpe@ellerman.id.au>2019-07-01 16:26:54 +1000
commit9fb603050ffd94f8127df99c699cca2f575eb6a0 (patch)
tree15fd32f87e0c8f58760f5d8625c79ac10ccaf195 /scripts/recordmcount.h
parentpowerpc: Document xive=off option (diff)
downloadlinux-dev-9fb603050ffd94f8127df99c699cca2f575eb6a0.tar.xz
linux-dev-9fb603050ffd94f8127df99c699cca2f575eb6a0.zip
powerpc/rtas: retry when cpu offline races with suspend/migration
The protocol for suspending or migrating an LPAR requires all present processor threads to enter H_JOIN. So if we have threads offline, we have to temporarily bring them up. This can race with administrator actions such as SMT state changes. As of dfd718a2ed1f ("powerpc/rtas: Fix a potential race between CPU-Offline & Migration"), rtas_ibm_suspend_me() accounts for this, but errors out with -EBUSY for what almost certainly is a transient condition in any reasonable scenario. Callers of rtas_ibm_suspend_me() already retry when -EAGAIN is returned, and it is typical during a migration for that to happen repeatedly for several minutes polling the H_VASI_STATE hcall result before proceeding to the next stage. So return -EAGAIN instead of -EBUSY when this race is encountered. Additionally: logging this event is still appropriate but use pr_info instead of pr_err; and remove use of unlikely() while here as this is not a hot path at all. Fixes: dfd718a2ed1f ("powerpc/rtas: Fix a potential race between CPU-Offline & Migration") Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Diffstat (limited to 'scripts/recordmcount.h')
0 files changed, 0 insertions, 0 deletions