Received: by 2002:a25:ef43:0:0:0:0:0 with SMTP id w3csp265862ybm; Tue, 26 May 2020 16:25:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz4b7s3i8+hkBW6i1dON27tzC/ljv/KRCXH0HIlLvQYHmW2oH4FsnicocSXp0W9IRHPc4Ly X-Received: by 2002:a17:906:938a:: with SMTP id l10mr3128266ejx.186.1590535513742; Tue, 26 May 2020 16:25:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590535513; cv=none; d=google.com; s=arc-20160816; b=X86Id6J5XyIvLHabYkD7w9c+Xo+aqIdGL8DJbUo9ufGBbQKOXT9kapvVLgp5YvFLLu Z7IiVFBkJ2jBMVgb/uIhS4jgLsHfMeow0TG24NQ9z8vpqB85dk5lEX4siej3zxByZJ8/ R9uANIh2cm38XPxvRc8V78LqmR9klqXnhLi7bdfxT5aC4llYZKosSoBsXxws1QKZ6biY nOzLhI/Wvi784lYYHH21+hxuIRSd8qQwlun3jwu2r6Y0wRc9h2TXjCGQb4yEEc3yEDoE afKA4s6ILIqjyIkZG86snkodX2QKlkktiWgLvijcxVbCc0vWP+NLlyXzS4CRdg6aUg2A iv7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id :dkim-signature:dkim-signature; bh=AhOnJA1s/HgcuJF7Id40WmcmaFC/RHd38wcHoy7PNpA=; b=mJe+rN6vk4MEVFz8hnJNN+95tzn8a9p2Kxb7mEqU+RJTgu+nDO8tVycvLDVHuJMA1n RfnbzXT0x9oMMmJPJiqsmqfNTzv5hSOX7F/LMdhIAb1ZQVUPrLzCQ3e74/VT7bxJc4aN Pk4Gw/ED5Z1IT8X0HGMKk2AC+39dz23Hqj0hb962Ph/xNFzeWQx0jm0s20MnGFQ6x3oc xzee+WNKBMOMiPtJ4WU+lz4OIPDiMBbIjunEi6a1bDdJbvshax9XTYfO+wWUYdBn6KQV grJ7Mk4NCLhK5p86UpFCHO+ciNHYhVaFxzHC8pfzkYM2ysEUBZR/lwwJSmVGluHo42MH gIHA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@hansenpartnership.com header.s=20151216 header.b=NLV22qvX; dkim=fail header.i=@hansenpartnership.com header.s=20151216 header.b=afcg++KY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=hansenpartnership.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i10si741408ejz.535.2020.05.26.16.24.50; Tue, 26 May 2020 16:25:13 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=fail header.i=@hansenpartnership.com header.s=20151216 header.b=NLV22qvX; dkim=fail header.i=@hansenpartnership.com header.s=20151216 header.b=afcg++KY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=hansenpartnership.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390770AbgEZUAS (ORCPT + 99 others); Tue, 26 May 2020 16:00:18 -0400 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:40278 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389192AbgEZUAR (ORCPT ); Tue, 26 May 2020 16:00:17 -0400 Received: from localhost (localhost [127.0.0.1]) by bedivere.hansenpartnership.com (Postfix) with ESMTP id D37D98EE181; Tue, 26 May 2020 13:00:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hansenpartnership.com; s=20151216; t=1590523216; bh=EZt3MAAU3Hg10i9FE752yd5IDT4uWKbN7LKCv9x0GPQ=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=NLV22qvXsh6issMEiflCG1YvaON1vKnS1OOLXctGyovv8WJlNWckH6sgvDdN1U/iM iNIKgzqlL1ICZ7B/kN43Ry0hTmQSVQ5J1cKMU42liF2Ys1h/I1m5mEmCZLpdWm4BDv QvJ03f0NvwQrsEpff8/BxBMdHqN7ZgW5fkW0anp4= Received: from bedivere.hansenpartnership.com ([127.0.0.1]) by localhost (bedivere.hansenpartnership.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JoFa7QQodzZs; Tue, 26 May 2020 13:00:15 -0700 (PDT) Received: from [153.66.254.194] (unknown [50.35.76.230]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bedivere.hansenpartnership.com (Postfix) with ESMTPSA id 3E1088EE0D4; Tue, 26 May 2020 13:00:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hansenpartnership.com; s=20151216; t=1590523215; bh=EZt3MAAU3Hg10i9FE752yd5IDT4uWKbN7LKCv9x0GPQ=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=afcg++KYC4Z2n+x94LoS83eoHa6xVTQH/ThpIcfUJw490XnywifB+paixbtoxXZkr /SRGkFY0ddZ2KSAJcYOoDIbdesWLODByAkpqRiBWyXEF3jber4Lhj0TSC7913uCJLs AW8ndfCSbzt+latxR8khWR3zjUo/HoUS62nm6Sf4= Message-ID: <1590523214.15108.4.camel@HansenPartnership.com> Subject: Re: [PATCH] tpm: Revert "tpm: fix invalid locking in NONBLOCKING mode" From: James Bottomley To: Tadeusz Struk , Mario Limonciello , Peter Huewe , Jarkko Sakkinen , Jason Gunthorpe Cc: Arnd Bergmann , Greg Kroah-Hartman , linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org, Jeffrin Jose T , Alex Guzman Date: Tue, 26 May 2020 13:00:14 -0700 In-Reply-To: References: <20200526183213.20720-1-mario.limonciello@dell.com> <1590520454.11810.40.camel@HansenPartnership.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.6 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2020-05-26 at 12:39 -0700, Tadeusz Struk wrote: > On 5/26/20 12:14 PM, James Bottomley wrote: > > + /* atomic tpm command send and result receive. We only > > hold the ops > > + * lock during this period so that the tpm can be > > unregistered even if > > + * the char dev is held open. > > + */ > > + if (tpm_try_get_ops(priv->chip)) { > > + ret = -EPIPE; > > + goto out; > > + } > > + > > Hi James, > This won't help if the message is read by an async tcti. Why not? It moves the ops get underneath the async path, so it's now all done in the direct read or the async read. That seems to be more efficient. > If the problem lies in the chip get locality code, perhaps this > could help to debug the root-cause instead of masking it out in the > upper layer code: I don't think there is a root cause other than a TIS TPM is getting annoyed by us cycling localities too rapidly because we don't do an actual TPM operation between request and relinquish. Since the first request/relinquish seems unnecessary for the async case, moving the ops get eliminates the problem. James