diff options
author | Linus Torvalds | 2023-05-02 12:35:01 -0700 |
---|---|---|
committer | Linus Torvalds | 2023-05-03 10:37:22 -0700 |
commit | 6ccdc91d6af922f3ded5de494ff27daedeb6d6c9 (patch) | |
tree | aaab70450c43bb25d0f4fd018654432b941efe59 /drivers/pwm | |
parent | 6014bc27561f2cc63e0acc18adbc4ed810834e32 (diff) |
x86: mm: remove architecture-specific 'access_ok()' define
There's already a generic definition of 'access_ok()' in the
asm-generic/access_ok.h header file, and the only difference bwteen that
and the x86-specific one is the added check for WARN_ON_IN_IRQ().
And it turns out that the reason for that check is long gone: it used to
use a "user_addr_max()" inline function that depended on the current
thread, and caused problems in non-thread contexts.
For details, see commits 7c4788950ba5 ("x86/uaccess, sched/preempt:
Verify access_ok() context") and in particular commit ae31fe51a3cc
("perf/x86: Restore TASK_SIZE check on frame pointer") about how and why
this came to be.
But that "current task" issue was removed in the big set_fs() removal by
Christoph Hellwig in commit 47058bb54b57 ("x86: remove address space
overrides using set_fs()").
So the reason for the test and the architecture-specific access_ok()
define no longer exists, and is actually harmful these days. For
example, it led various 'copy_from_user_nmi()' games (eg using
__range_not_ok() instead, and then later converted to __access_ok() when
that became ok).
And that in turn meant that LAM was broken for the frame following
before this series, because __access_ok() used to not do the address
untagging.
Accessing user state still needs care in many contexts, but access_ok()
is not the place for this test.
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Linus Torvalds torvalds@linux-foundation.org>
Diffstat (limited to 'drivers/pwm')
0 files changed, 0 insertions, 0 deletions