Date: Wed, 28 Mar 2018 03:15:43 +0000 (UTC) From: Mateusz Guzik <mjg@FreeBSD.org> To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r331659 - head/sys/sys Message-ID: <201803280315.w2S3FhNU060308@repo.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: mjg Date: Wed Mar 28 03:15:42 2018 New Revision: 331659 URL: https://svnweb.freebsd.org/changeset/base/331659 Log: 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). Modified: head/sys/sys/seq.h Modified: head/sys/sys/seq.h ============================================================================== --- head/sys/sys/seq.h Wed Mar 28 03:11:50 2018 (r331658) +++ head/sys/sys/seq.h Wed Mar 28 03:15:42 2018 (r331659) @@ -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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201803280315.w2S3FhNU060308>