Received: by 2002:ac0:950c:0:0:0:0:0 with SMTP id f12csp2020178imc; Tue, 12 Mar 2019 05:37:15 -0700 (PDT) X-Google-Smtp-Source: APXvYqxlflYKJ1QYEjQ+hLngM5/OBOWigQ8F212D4DNRltmeoY/oPT04OzmDlF0gS2UaWeaLs2IF X-Received: by 2002:aa7:8a81:: with SMTP id a1mr38394544pfc.246.1552394235863; Tue, 12 Mar 2019 05:37:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552394235; cv=none; d=google.com; s=arc-20160816; b=H58aKn/TOPxuSQ+MPOfNqbAg7lM3C6V6b3r5kRv5B0Q1xP2ticSQb0Mwf9tQCGw6eN lmVa4n6Kp8NlE7cIt5V64ivGm+tBHpHi1kmQIdbYLcNDUwsLXe3jdIuinWVzjPaEtLnG wPRUawoKdyYlOL1cmdiBZYa+WiDjaMKEED6qpR4FTxseMGXq20MofgsxzJzwXHU7Rloo 2apWXjFHPBvMwVqu0qkt5dXr9LwpCZX7Dea2ubxOLfveETP943P0H+BH9dFuBRAGYX56 M0PF0mJwrExul0rmlDTeWLzuO3rQg4SuapUc1ZDDsTpp5CUISNxi67zHW1oBhZxNOAO1 LW/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:organization:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=RBQ5e+OKCTB1xXGFw/r3A48GCaCz0abfyLBNh/zFoH8=; b=k8amBdWntDjhabrFHRTex1BzNyQrd2I/XoYO9puKYiB8VUsv7aLndgXvdPp3mATNyS 7tJ+C5OPIfLGWGBvneF+Gv9U5g/alEDomQr1Ua/YELOFW38TQuaX64g0Lv0+Bz9IOa52 2u1q0AHwa4JcviX3eHd5iUNiTmUIqCrY15tuEAyWz/Zhc5XbXNwIxOQTzHACw5fjrifk 6JSTmOUw7UNTDn4gzAYAvjq/QqxGlFO4LF9AfmepfzX1TbFqRxWcKuaKh3AztvhvmKeQ LvU9oT31Rid7Qkh6DPXak2vNn2Ii+7QwB1ym6fmvd4Ayzf8cM2MlIUiC3kHerp5SCDma y7OA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u7si1555118pfm.159.2019.03.12.05.36.59; Tue, 12 Mar 2019 05:37:15 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726330AbfCLMgk (ORCPT + 99 others); Tue, 12 Mar 2019 08:36:40 -0400 Received: from mga18.intel.com ([134.134.136.126]:20537 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725894AbfCLMgk (ORCPT ); Tue, 12 Mar 2019 08:36:40 -0400 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Mar 2019 05:36:39 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.58,471,1544515200"; d="scan'208";a="133617532" Received: from skalur-mobl.amr.corp.intel.com (HELO localhost) ([10.249.254.173]) by fmsmga007.fm.intel.com with ESMTP; 12 Mar 2019 05:36:34 -0700 Date: Tue, 12 Mar 2019 14:36:32 +0200 From: Jarkko Sakkinen To: Calvin Owens Cc: Peter Huewe , Jason Gunthorpe , Arnd Bergmann , Greg Kroah-Hartman , linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@fb.com Subject: Re: [PATCH] tpm: Make timeout logic simpler and more robust Message-ID: <20190312123632.GB9243@linux.intel.com> References: <358e89ed2b766d51b5f57abf31ab7a925ac63379.1552348123.git.calvinowens@fb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <358e89ed2b766d51b5f57abf31ab7a925ac63379.1552348123.git.calvinowens@fb.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 11, 2019 at 04:54:04PM -0700, Calvin Owens wrote: > We're having lots of problems with TPM commands timing out, and we're > seeing these problems across lots of different hardware (both v1/v2). > > I instrumented the driver to collect latency data, but I wasn't able to > find any specific timeout to fix: it seems like many of them are too > aggressive. So I tried replacing all the timeout logic with a single > universal long timeout, and found that makes our TPMs 100% reliable. > > Given that this timeout logic is very complex, problematic, and appears > to serve no real purpose, I propose simply deleting all of it. > > Signed-off-by: Calvin Owens Have been thinking about this and I do agree. It has been like that before my times with this subsystem so when I did the original TPM2 patches I carried this logic albeit even at that point I did not get it. Now that I've been maintaining for over three years I'm confident that this the Right Thing to do. /Jarkko