Date: Thu, 30 Oct 2014 12:39:41 -0700 From: "K. Macy" <kmacy@freebsd.org> To: "De La Gueronniere, Marc" <mdelagueronniere@verisign.com> Cc: Ryan Stone <rysto32@gmail.com>, Oleg Bulyzhin <oleg@freebsd.org>, "Charbon, Julien" <jcharbon@verisign.com>, freebsd-net <freebsd-net@freebsd.org> Subject: Re: buf_ring in HEAD is racy Message-ID: <CAHM0Q_PCr=8e26E%2BsTM_9GSZe0uOQyEw_UeHyhpbF-J81-AXyw@mail.gmail.com> In-Reply-To: <D06D9912.1507F%mdelagueronniere@verisign.com> References: <CAFMmRNyJpvZ0AewWr62w16=qKer%2BFNXUJJy0Qc=EBqMnUV3OyQ@mail.gmail.com> <20131226175410.GA15332@lath.rinet.ru> <D06D9912.1507F%mdelagueronniere@verisign.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > I also suspect there are further problems with buf_ring. A full wrap > around of the atomically swapped value is possible. I.e. the code thinks > it just atomically updated a head/tail index when in fact a full wrap > around occurred leading to undefined land. A relatively simple way to > avoid this is to only mask on ring array access, and to let the > head/tail/prod/cons indices overflow the array. > Up until Rui Paulo complained to me of packet drops with buf_ring a couple of days ago I had thought that this patch had been committed. This patch (now 273866) fixes the problem for him. Without further scrutiny and testing I won't provide the UL guarantee for buf_ring_enqueue, but this is a clear improvement. -K
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAHM0Q_PCr=8e26E%2BsTM_9GSZe0uOQyEw_UeHyhpbF-J81-AXyw>