[PATCH v1 net] af_unix: Remove gc_in_progress check in unix_peek_fpl().

[Kuniyuki Iwashima <kuniyu@google.com>]

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 <q.h.hack.winter@gmail.com>
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
---
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