From owner-freebsd-net@freebsd.org Thu Jan 19 22:55:52 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 54137CB8F80 for ; Thu, 19 Jan 2017 22:55:52 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0069.outbound.protection.outlook.com [104.47.32.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0205E12DB for ; Thu, 19 Jan 2017 22:55:51 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0191.CANPRD01.PROD.OUTLOOK.COM (10.165.218.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.12; Thu, 19 Jan 2017 22:55:50 +0000 Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) with mapi id 15.01.0845.021; Thu, 19 Jan 2017 22:55:50 +0000 From: Rick Macklem To: FreeBSD Net Subject: Re: sosend returning ERESTART Thread-Topic: sosend returning ERESTART Thread-Index: AQHScXbGB6xwqeuR3ky6twdHVMq016E+x0oAgAAO/x2AAJOyAIAA/rNAgAACmls= Date: Thu, 19 Jan 2017 22:55:49 +0000 Message-ID: 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> , <20170119073424.GM2349@kib.kiev.ua>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-office365-filtering-correlation-id: 32a7f463-eaa1-4016-47cc-08d440be5053 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:YTXPR01MB0191; x-microsoft-exchange-diagnostics: 1; YTXPR01MB0191; 7:Buo3XuLb0USOL4l9tq3sTIwf4UVvISXYtM+WkKhwlxsocQ89NSeSUwusiYyEUvc6zgQ6nJGFNmqOn6dJmHMlCIT0mg/yIF2szdU35hI4xAF5YYqyFUEl0DEsMxM+WHsg8j4cv8K0BRwNpSwgO1rTVWb4utHWNBWTCXLjWvuy0d3llyC97Lw+oKlFWZz7RQRRovH5MPMWNCBdMkMCTyUVYWvcCDTNh5t5fG15pjhlXoXercESbXYQMxK9b+I7nOAAIX+cRFTLntVY3tZZhc5HgAdh+vwpD6tCEK0vqSM5SIEqg0N7BYiMcm6ZgU+mYlKW65MS5TOCiLehRACWjciJYtSnRZYA2CHW3HLHhNxSjPM5SmcZugsIf3wOiaEXI5Tbef8L2Yf7quZH+hl/UnXTL6iu9EUCuBDdUHH7UJqH4nfzNWCZDcXIsvIVtV8Ht0QssaZoAYPDB4fkA2VEASKEtw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(6072148); SRVR:YTXPR01MB0191; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0191; x-forefront-prvs: 0192E812EC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(189002)(199003)(24454002)(81166006)(81156014)(106356001)(8676002)(8936002)(3480700004)(38730400001)(33656002)(50986999)(105586002)(122556002)(9686003)(6436002)(102836003)(76176999)(54356999)(74482002)(6506006)(77096006)(55016002)(101416001)(450100001)(106116001)(229853002)(2906002)(92566002)(7696004)(110136003)(2950100002)(6916009)(74316002)(3660700001)(3280700002)(305945005)(2900100001)(107886002)(97736004)(189998001)(5660300001)(93886004)(86362001)(53936002)(7116003)(68736007); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0191; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jan 2017 22:55:50.0000 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0191 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 22:55:52 -0000 Konstantin Belousov wrote: >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 ERESTA= RT. >> >>> It looks like setting the SB_NOINTR flag will prevent this; I'm test= ing 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 w= ithout >> >the intr flag" + "unresponsive NFS server" =3D "unkillable processes" h= as been >> >a (mis)feature of NFS for decades. >> The case I would like to see work is the forced dismount. I need to go l= ook 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 pro= blem, 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. Right. But presumably if the TCP connection is still working, a subsequent attempt will not have to sleep in sblock() or sbwait() in sosend() and will succeed? I think Colin was already testing this looping version before SB_NOINTR and found it worked well for his case. --> I think this does imply that it should only loop N times and then give = up and reply RPC_CANTSEND (which is what it does the first time now). - The RPC_CANTSEND is what triggers the client to create a new TCP co= nnection and this is what causes grief for his mounts against the AmazonEFS = server (which is broken because the new TCP connection often results in a NFS4ERR_BAD_SESSION which should not happen.) Colin, have you tested the "loop on ERESTART" version of the patch? And maybe you could add a loop counter to limit the number of iterations? rick [stuff snipped]