unix_vertex_dead() and unix_peek_fpl() are synchronised with unix_peek_seq to prevent GC from purging a live socket's recvq. unix_peek_fpl() skips the synchronisation if gc_in_progress is false. However, on weakly ordered arch, GC might have already started working while the write to gc_in_progress is buffered. This does not occur on x86. This is an unlikely path that happens only when AF_UNIX fd is peeked so not worth complicating. Instead of adding memory barriers in unix_gc() and unix_peek_fpl(), let's simply remove the broken short-circuit. Fixes: e5b31d988a41 ("af_unix: Give up GC if MSG_PEEK intervened.") Reported-by: Qihang Tang Signed-off-by: Kuniyuki Iwashima --- The reporter reproduced it on arm64 QEMU. --- net/unix/garbage.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/net/unix/garbage.c b/net/unix/garbage.c index a0b515354e8b..fbeabfb0db34 100644 --- a/net/unix/garbage.c +++ b/net/unix/garbage.c @@ -329,9 +329,6 @@ void unix_peek_fpl(struct scm_fp_list *fpl) if (!fpl || !fpl->count_unix) return; - if (!READ_ONCE(gc_in_progress)) - return; - /* Invalidate the final refcnt check in unix_vertex_dead(). */ spin_lock(&unix_peek_lock); raw_write_seqcount_barrier(&unix_peek_seq); -- 2.56.0.385.gac671c819a-goog