From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932119AbcGAXCe (ORCPT ); Fri, 1 Jul 2016 19:02:34 -0400 Received: from us-smtp-delivery-194.mimecast.com ([216.205.24.194]:57291 "EHLO us-smtp-delivery-194.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932070AbcGAXCb (ORCPT ); Fri, 1 Jul 2016 19:02:31 -0400 From: Trond Myklebust To: Rostedt Steven CC: LKML , Linux NFS Mailing List , Jeff Layton , "Eric Dumazet" , Schumaker Anna , Andrew Morton , Fields Bruce , Torvalds Linus Subject: Re: Revert: SUNRPC: xs_sock_mark_closed() does not need to trigger socket autoclose Thread-Topic: Revert: SUNRPC: xs_sock_mark_closed() does not need to trigger socket autoclose Thread-Index: AQHR097ndG9IyZ2G60iHt4SA1K9CTqAEKZUAgAABdACAAAZ3gA== Date: Fri, 1 Jul 2016 23:02:23 +0000 Message-ID: References: <20160701172401.3ba89015@gandalf.local.home> <0A51DE9E-81B2-474A-BA07-55C3BE19629A@primarydata.com> <20160701183912.1f9d376b@gandalf.local.home> In-Reply-To: <20160701183912.1f9d376b@gandalf.local.home> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [68.49.162.121] x-ms-office365-filtering-correlation-id: b1100ae8-473f-4c4a-53ce-08d3a203c38e x-microsoft-exchange-diagnostics: 1;CY1PR11MB0313;20:fTE0lOguR56V6OObgK+qZS2K2XVskwxyC9RZdQIC7dBSp7D2mz0AvN+Xh09c/cozAviNvprfYLC3bR+dtEPjIcN6VXf6z2GuTTaU3eIYqkS742Js5S6II6L0MNr0JxyrTjiWoHMKO+lcWFKYjdZBHop2Iw4nG6XWtI/Du/sWNpY= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR11MB0313; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040130)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041072)(6043046);SRVR:CY1PR11MB0313;BCL:0;PCL:0;RULEID:;SRVR:CY1PR11MB0313; x-forefront-prvs: 0990C54589 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(7916002)(199003)(189002)(24454002)(83716003)(7846002)(10400500002)(110136002)(189998001)(33656002)(66066001)(105586002)(99286002)(50986999)(106116001)(106356001)(87936001)(3846002)(76176999)(586003)(54356999)(102836003)(6116002)(2950100001)(86362001)(77096005)(2900100001)(81156014)(5002640100001)(122556002)(36756003)(8676002)(101416001)(92566002)(97736004)(2906002)(81166006)(4326007)(11100500001)(68736007)(3660700001)(7736002)(305945005)(19580395003)(19580405001)(3280700002)(8936002)(82746002)(104396002);DIR:OUT;SFP:1102;SCL:1;SRVR:CY1PR11MB0313;H:CY1PR11MB0316.namprd11.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <124CC41D3C9D90419107C4750428D8B7@namprd11.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: primarydata.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jul 2016 23:02:23.0361 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 03193ed6-8726-4bb3-a832-18ab0d28adb7 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR11MB0313 X-MC-Unique: TWp2lOT2OYuQj_HGQi4TYg-1 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id u61N2ex5004428 > On Jul 1, 2016, at 18:39, Steven Rostedt wrote: > > On Fri, 1 Jul 2016 22:34:02 +0000 > Trond Myklebust wrote: > > >> NACK. This ocde was removed on purpose because it is dangerous to >> have the TCP state change callbacks queue up a new close(). The >> connect code sometimes has to close sockets that are misbehaving, and >> so we’ve seen races whereby the old socket closes and triggers an >> autoclose for the new socket while it is connecting. > > OK fine. But can we please come up with a solution to get rid of the > hidden port issue. It's very annoying that I get a message from > rkhunter ever morning telling me "Please inspect this machine, because > it may be infected.” > Can we look into why the socket disconnect is happening in the first place? It’s presumably not the server, since that _would_ trigger an autoclose when the socket hits TCP_CLOSE_WAIT. That puts the two top suspects being the TCP keepalive and the TCP_USER_TIMEOUT. Are there any tracepoints we could use to look at whether or not they are triggering a close? Thanks Trond