summaryrefslogtreecommitdiffstats
path: root/kernel/trace/trace_kprobe.c
diff options
context:
space:
mode:
authorMikulas Patocka <mpatocka@redhat.com>2014-04-14 16:58:55 -0400
committerLinus Torvalds <torvalds@linux-foundation.org>2014-04-14 16:03:02 -0700
commite79323bd87808fdfbc68ce6c5371bd224d9672ee (patch)
tree8aeb1f4915b3474277a2b5ea9e3b9e04da88b384 /kernel/trace/trace_kprobe.c
parentc9eaa447e77efe77b7fa4c953bd62de8297fd6c5 (diff)
downloadlinux-e79323bd87808fdfbc68ce6c5371bd224d9672ee.tar.bz2
user namespace: fix incorrect memory barriers
smp_read_barrier_depends() can be used if there is data dependency between the readers - i.e. if the read operation after the barrier uses address that was obtained from the read operation before the barrier. In this file, there is only control dependency, no data dependecy, so the use of smp_read_barrier_depends() is incorrect. The code could fail in the following way: * the cpu predicts that idx < entries is true and starts executing the body of the for loop * the cpu fetches map->extent[0].first and map->extent[0].count * the cpu fetches map->nr_extents * the cpu verifies that idx < extents is true, so it commits the instructions in the body of the for loop The problem is that in this scenario, the cpu read map->extent[0].first and map->nr_extents in the wrong order. We need a full read memory barrier to prevent it. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'kernel/trace/trace_kprobe.c')
0 files changed, 0 insertions, 0 deletions