summaryrefslogtreecommitdiff
path: root/scripts/lib/abi/helpers.py
diff options
context:
space:
mode:
authorKumar Kartikeya Dwivedi <memxor@gmail.com>2025-03-16 07:05:27 +0300
committerAlexei Starovoitov <ast@kernel.org>2025-03-19 18:03:05 +0300
commit3bb159366a13d8f5ead58f1cc1d0efa0183e951e (patch)
tree10d5c7cd764cee526091b5ee930cbc7b0ababea2 /scripts/lib/abi/helpers.py
parent164c246571e97b6f1bdcc7ff5bb68f16da8afedc (diff)
downloadlinux-3bb159366a13d8f5ead58f1cc1d0efa0183e951e.tar.xz
rqspinlock: Protect waiters in trylock fallback from stalls
When we run out of maximum rqnodes, the original queued spin lock slow path falls back to a try lock. In such a case, we are again susceptible to stalls in case the lock owner fails to make progress. We use the timeout as a fallback to break out of this loop and return to the caller. This is a fallback for an extreme edge case, when on the same CPU we run out of all 4 qnodes. When could this happen? We are in slow path in task context, we get interrupted by an IRQ, which while in the slow path gets interrupted by an NMI, whcih in the slow path gets another nested NMI, which enters the slow path. All of the interruptions happen after node->count++. We use RES_DEF_TIMEOUT as our spinning duration, but in the case of this fallback, no fairness is guaranteed, so the duration may be too small for contended cases, as the waiting time is not bounded. Since this is an extreme corner case, let's just prefer timing out instead of attempting to spin for longer. Reviewed-by: Barret Rhoden <brho@google.com> Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Link: https://lore.kernel.org/r/20250316040541.108729-12-memxor@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Diffstat (limited to 'scripts/lib/abi/helpers.py')
0 files changed, 0 insertions, 0 deletions