Date: Wed, 18 Jan 2017 04:37:39 +0000 From: Colin Percival <cperciva@tarsnap.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-net@freebsd.org Subject: Re: sosend returning ERESTART Message-ID: <01000159afddb4bb-d78bc275-7ce9-41da-93bd-0a7445a74fa0-000000@email.amazonses.com> In-Reply-To: <20170117100634.GS2349@kib.kiev.ua> References: <01000159aac969e6-b2fc3913-d04e-42d4-befd-402ed0d830bf-000000@email.amazonses.com> <20170117100634.GS2349@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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.) -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?01000159afddb4bb-d78bc275-7ce9-41da-93bd-0a7445a74fa0-000000>