Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 19 Jan 2017 01:03:31 +0000
From:      Rick Macklem <rmacklem@uoguelph.ca>
To:        Colin Percival <cperciva@tarsnap.com>, Konstantin Belousov <kostikbel@gmail.com>
Cc:        "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>
Subject:   Re: sosend returning ERESTART
Message-ID:  <YTXPR01MB01893CA6B58E2E42CE23F021DD7E0@YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM>
In-Reply-To: <01000159b390c409-5adcb488-67e8-4038-b9b0-5d4f33460205-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> <20170118103650.GE2349@kib.kiev.ua>, <01000159b390c409-5adcb488-67e8-4038-b9b0-5d4f33460205-000000@email.amazonses.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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 fu=
ll
>>> 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 looked and I think forced dismounts are broken when the thread is stuck i=
n
sosend(). (It assumes that the threads doing RPCs are waiting for replies.)
--> I think this can be fixed by posting a signal to the threads, but only =
if
      SB_NOINTR isn't used.
--> As such, I think looping on ERESTART when PCATCH isn't set in ct_waitfl=
ag
     is the better way to go. (At a glance, I think sosend_generic() will f=
ail with
     ERESTART before putting any data in the send queue. For NFS, it uses t=
he
     mbuf list "top" and is always "atomic".)

Kostik, Colin has already been testing the looping case.

>I'm not sure what you're getting at here.  The fact that "NFS mounted with=
out
>the intr flag" + "unresponsive NFS server" =3D "unkillable processes" has =
been
>a (mis)feature of NFS for decades.
As I already mentioned, I'd like to at least get forced dismounts to work, =
rick




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YTXPR01MB01893CA6B58E2E42CE23F021DD7E0>