diff options
author | Johannes Berg <johannes.berg@intel.com> | 2025-04-04 17:05:19 +0200 |
---|---|---|
committer | Johannes Berg <johannes.berg@intel.com> | 2025-05-05 10:06:51 +0200 |
commit | 68025adfc13e6cd15eebe2293f77659f47daf13b (patch) | |
tree | ed250635fcbce5f1c21a12af1785d7e3891ec860 /drivers/gpu/drm/lib/drm_random.c | |
parent | 92a09c47464d040866cf2b4cd052bc60555185fb (diff) | |
download | linux-68025adfc13e6cd15eebe2293f77659f47daf13b.tar.gz linux-68025adfc13e6cd15eebe2293f77659f47daf13b.tar.bz2 linux-68025adfc13e6cd15eebe2293f77659f47daf13b.zip |
um: fix _nofault accesses
Nathan reported [1] that when built with clang, the um kernel
crashes pretty much immediately. This turned out to be an issue
with the inline assembly I had added, when clang used %rax/%eax
for both operands. Reorder it so current->thread.segv_continue
is written first, and then the lifetime of _faulted won't have
overlap with the lifetime of segv_continue.
In the email thread Benjamin also pointed out that current->mm
is only NULL for true kernel tasks, but we could do this for a
userspace task, so the current->thread.segv_continue logic must
be lifted out of the mm==NULL check.
Finally, while looking at this, put a barrier() so the NULL
assignment to thread.segv_continue cannot be reorder before
the possibly faulting operation.
Reported-by: Nathan Chancellor <nathan@kernel.org>
Closes: https://lore.kernel.org/r/20250402221254.GA384@ax162 [1]
Fixes: d1d7f01f7cd3 ("um: mark rodata read-only and implement _nofault accesses")
Tested-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Diffstat (limited to 'drivers/gpu/drm/lib/drm_random.c')
0 files changed, 0 insertions, 0 deletions