Date: Wed, 18 Jan 2017 12:36:50 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Colin Percival <cperciva@tarsnap.com> Cc: freebsd-net@freebsd.org Subject: Re: sosend returning ERESTART Message-ID: <20170118103650.GE2349@kib.kiev.ua> In-Reply-To: <01000159afddb7ce-064a5d17-4b81-4b2c-a9b4-3ddd2ad2e377-000000@email.amazonses.com> References: <01000159aac969e6-b2fc3913-d04e-42d4-befd-402ed0d830bf-000000@email.amazonses.com> <20170117100634.GS2349@kib.kiev.ua> <01000159afddb7ce-064a5d17-4b81-4b2c-a9b4-3ddd2ad2e377-000000@email.amazonses.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jan 18, 2017 at 04:37:40AM +0000, Colin Percival wrote: > On 01/17/17 02:06, Konstantin Belousov wrote: > > On Tue, Jan 17, 2017 at 04:57:23AM +0000, Colin Percival wrote: > >> I think I've tracked an NFS problem down to sosend returning ERESTART; it > >> looks like it's easy to work around this, but I'm not sure *why* sosend is > >> returning ERESTART... or for that matter *how* since I can't find anywhere > >> in relevant code where that gets returned. > > ERESTART is most likely returned by msleep(9) or similar call down the > > path when unblocked signal is pending with the restart disposition. > > Thanks, looks like that was exactly it -- if the TCP send buffer was full > we would call sbwait, and if a signal arrived it would return ERESTART. > It looks like setting the SB_NOINTR flag will prevent this; I'm testing a > patch right now. > > (Google bait in case anyone else trips over this: FreeBSD 11.0 NFS client > dropping TCP connections under concurrent I/O load.) Note that passing SB_NOINTR unconditionally or even only for mounts with nointr (default) option is wrong. You make the socket operation uninterruptible, process terminate-ability becomes depended on the external factor, the behaviour of the remote system.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170118103650.GE2349>