From 51f4f2ed3d2464eee8acebdf58c1a2400c60911e Mon Sep 17 00:00:00 2001 From: Mateusz Guzik Date: Wed, 28 Mar 2018 03:15:42 +0000 Subject: [PATCH] seq: disable preemption around seq_write_* This is a long standing performance bug which happened to not cause trouble in practice due to rather limited use of these primitives. The read side expects the writer to finish soon(tm) hence it loops with one pause in-between. But it is possible the writer gets preempted in which case the waiting can take a long time, especially so if it got preempted by the reader. In principle this may never clean itself up. In the current kernel seq is only used to obtain stable fp + capabilities state. In order for looping at least once to occur there has to be a concurrent writer modifying the fd slot for the very fd we are trying to read. That is, for any looping to occur in the first place the program has to be multithreaded and be doing something fishy to begin with. As such, the indefinite looping is rather hard to run into unless you really try (and I did not). --- sys/sys/seq.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sys/sys/seq.h b/sys/sys/seq.h index 7e6de5bf7db2..5783fbe33d11 100644 --- a/sys/sys/seq.h +++ b/sys/sys/seq.h @@ -79,6 +79,7 @@ static __inline void seq_write_begin(seq_t *seqp) { + critical_enter(); MPASS(!seq_in_modify(*seqp)); *seqp += 1; atomic_thread_fence_rel(); @@ -90,6 +91,7 @@ seq_write_end(seq_t *seqp) atomic_store_rel_int(seqp, *seqp + 1); MPASS(!seq_in_modify(*seqp)); + critical_exit(); } static __inline seq_t