From owner-freebsd-net@freebsd.org Wed Jan 18 22:52:05 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 13206CB6500 for ; Wed, 18 Jan 2017 22:52:05 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0048.outbound.protection.outlook.com [104.47.42.48]) (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 810D81501 for ; Wed, 18 Jan 2017 22:52:03 +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; Wed, 18 Jan 2017 22:52:02 +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.014; Wed, 18 Jan 2017 22:52:02 +0000 From: Rick Macklem To: Colin Percival , Konstantin Belousov CC: "freebsd-net@freebsd.org" Subject: Re: sosend returning ERESTART Thread-Topic: sosend returning ERESTART Thread-Index: AQHScXbGB6xwqeuR3ky6twdHVMq016E+x0oAgAAO/x0= Date: Wed, 18 Jan 2017 22:52:02 +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> In-Reply-To: <01000159b390c409-5adcb488-67e8-4038-b9b0-5d4f33460205-000000@email.amazonses.com> 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: 24ab3f7a-da3b-49f0-576c-08d43ff49e65 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:YTXPR01MB0191; x-microsoft-exchange-diagnostics: 1; YTXPR01MB0191; 7:tjvcnfLnOLwHfHmewaD7MpVcJH9l5lNzyqwGz0hHjUcKV4UmCJPMoLhj9ljJL5QGOvU+I3FyPgNLOvp8N2xIg/pdwE9zzKgdDygHp5ZSsiBf7wMTkPnJJsOl4LqMog783bE1mZslvrgtOe2EjLtj6QUaZ52Vu7l3NEJDroBgFPiKXlbPhoY8UQAwrEw1fxvtw7lLZZjcuzCYe9MWJCJh7F1QF9QCFpMgs1VmJAttLGzobhB2W8mkpVzSLCoWbwygBf/2xR127Zf2HwpeAz3rpk2HXPHvyYf2UErnzoU4zZZ3MdfpLCEKQvGNOTlqKPGN0F7/xXM1jvZGz88yufkyqApXz47yDFwXlIDVhC8TmMvnX8CmtECFQjdh9FKPpVMW+CU5RkfhEJ9Qk8WYDufMs+Y8xWXkWXMDP08BHPhZthJ5QLXMUoAmQpFMXNfbB6p4FTeA2nxGO1Ya3j5nuvhGLA== 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)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(6072148); SRVR:YTXPR01MB0191; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0191; x-forefront-prvs: 01917B1794 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(24454002)(199003)(189002)(229853002)(33656002)(5660300001)(102836003)(77096006)(305945005)(38730400001)(74316002)(6436002)(50986999)(8676002)(7696004)(39060400001)(106356001)(97736004)(68736007)(74482002)(189998001)(101416001)(81166006)(6506006)(5001770100001)(76176999)(7116003)(54356999)(2950100002)(106116001)(3480700004)(8936002)(81156014)(105586002)(93886004)(55016002)(4326007)(9686003)(92566002)(2906002)(3660700001)(53936002)(122556002)(3280700002)(86362001)(2900100001); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0191; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX: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: 18 Jan 2017 22:52:02.7293 (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: Wed, 18 Jan 2017 22:52:05 -0000 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'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. 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 no= w. (It is currently broken when something like "umount" without -f is done, wh= ich locks up the mounted on vnode so "umount -f" never gets to the umount(2) s= yscall. I do plan on a "straight ot NFS" option for umount(8) to avoid this proble= m, but haven't gotten around to it.) The alternative to SB_NOINTR is looping and doing the sosend() again for th= e case where it returns ERESTART and "intr" wasn't set on the mount. --> 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 a= gain. I think this is true for this case? rick