diff options
author | Jesper Dangaard Brouer <brouer@redhat.com> | 2019-11-16 12:22:38 +0100 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2019-11-18 17:03:17 -0800 |
commit | c491eae8f9c0720520ebdeb4d335671f84b84b71 (patch) | |
tree | 1e73aa503c482accbead40e2d8fd28c78cfd0cf7 /net/core/xdp.c | |
parent | b95e86d846b63b02ecdc94802ddbeaf9005fb6d9 (diff) | |
download | linux-stable-c491eae8f9c0720520ebdeb4d335671f84b84b71.tar.gz linux-stable-c491eae8f9c0720520ebdeb4d335671f84b84b71.tar.bz2 linux-stable-c491eae8f9c0720520ebdeb4d335671f84b84b71.zip |
xdp: remove memory poison on free for struct xdp_mem_allocator
When looking at the details I realised that the memory poison in
__xdp_mem_allocator_rcu_free doesn't make sense. This is because the
SLUB allocator uses the first 16 bytes (on 64 bit), for its freelist,
which overlap with members in struct xdp_mem_allocator, that were
updated. Thus, SLUB already does the "poisoning" for us.
I still believe that poisoning memory make sense in other cases.
Kernel have gained different use-after-free detection mechanism, but
enabling those is associated with a huge overhead. Experience is that
debugging facilities can change the timing so much, that that a race
condition will not be provoked when enabled. Thus, I'm still in favour
of poisoning memory where it makes sense.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/core/xdp.c')
-rw-r--r-- | net/core/xdp.c | 5 |
1 files changed, 0 insertions, 5 deletions
diff --git a/net/core/xdp.c b/net/core/xdp.c index 8e405abaf05a..e334fad0a6b8 100644 --- a/net/core/xdp.c +++ b/net/core/xdp.c @@ -73,11 +73,6 @@ static void __xdp_mem_allocator_rcu_free(struct rcu_head *rcu) /* Allow this ID to be reused */ ida_simple_remove(&mem_id_pool, xa->mem.id); - /* Poison memory */ - xa->mem.id = 0xFFFF; - xa->mem.type = 0xF0F0; - xa->allocator = (void *)0xDEAD9001; - kfree(xa); } |