From owner-freebsd-net@freebsd.org Thu Jan 19 07:34:31 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1EC05CB7DFE for ; Thu, 19 Jan 2017 07:34:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BC61D198B for ; Thu, 19 Jan 2017 07:34:30 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v0J7YPNu065423 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 19 Jan 2017 09:34:25 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v0J7YPNu065423 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v0J7YOEw065422; Thu, 19 Jan 2017 09:34:24 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 19 Jan 2017 09:34:24 +0200 From: Konstantin Belousov To: Rick Macklem Cc: Colin Percival , "freebsd-net@freebsd.org" Subject: Re: sosend returning ERESTART Message-ID: <20170119073424.GM2349@kib.kiev.ua> 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> <20170118103650.GE2349@kib.kiev.ua> <01000159b390c409-5adcb488-67e8-4038-b9b0-5d4f33460205-000000@email.amazonses.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 07:34:31 -0000 On Wed, Jan 18, 2017 at 10:52:02PM +0000, Rick Macklem wrote: > Colin Percival wrote: > >On 01/18/17 02:36, Konstantin Belousov wrote: > >> On Wed, Jan 18, 2017 at 04:37:40AM +0000, Colin Percival wrote: > >>> 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. > >> > >> 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. > > > >I'm not sure what you're getting at here. The fact that "NFS mounted without > >the intr flag" + "unresponsive NFS server" = "unkillable processes" has been > >a (mis)feature of NFS for decades. > The case I would like to see work is the forced dismount. I need to go look at > what it does and see if SB_NOINTR would break it worse than it is broken now. > (It is currently broken when something like "umount" without -f is done, which > locks up the mounted on vnode so "umount -f" never gets to the umount(2) syscall. > I do plan on a "straight ot NFS" option for umount(8) to avoid this problem, but > haven't gotten around to it.) > > The alternative to SB_NOINTR is looping and doing the sosend() again for the > case where it returns ERESTART and "intr" wasn't set on the mount. Note that the condition of pending signal which triggered ERESTART is permanent until the signal is delivered or blocked. In other words, or future PCATCH sleeps will fail with ERESTART/EINTR. > --> For this to be ok, we must be sure that when sosend() returns ERESTART, > it has not queued the data for sending so it is safe to send it all again. > I think this is true for this case? > > rick