Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp1650776imj; Fri, 8 Feb 2019 05:13:04 -0800 (PST) X-Google-Smtp-Source: AHgI3Ia1Cfl/Rrxt1HfXkFHm5LDQW9G65QacI3sPh/7Y5kuh7qoAknuPkphbktGLh7jYDonLWOX8 X-Received: by 2002:a62:53c5:: with SMTP id h188mr21808647pfb.190.1549631584208; Fri, 08 Feb 2019 05:13:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549631584; cv=none; d=google.com; s=arc-20160816; b=tcm+UETklv2rWbRm1OHsnsyJ7jDzFq0pASFCu+AQH0lalHafKQyYi+HKDN27bDACux 9YNXzxYqnTzS/YBe7n60PsoNOrRY+n3WH7E6MGnDnZV53rwObvO2Tdq2lDjR+0K0yhv2 aOFwHuZk8tRMWPTVAtR8x8nOP1QC71FUCe+ZXgIBqddP+G0C5SAjt4bNZSPKu5BxyQ5q ekYlLoNmkXVyeI7aJHoukPTKSz1nFkklCv8RFFryuA4EODdWxVDUadENYO+NoKoKZYOU LEsKRZrT7nRSTPbmzVPquC3cnTBzQKq0a89It+ucRc3JmsIV0jxX6FJXxO1rgotSu0xL 8EVw== 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-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=8uGXymOM675gYZjv9zbO9Msz9FxWVwkR788uXXBewiY=; b=ZVZL2gfkX//CdrJw2O2fRDsj7Rg7KnWgrDa/Rhq/9x1XPUjfRhran+V/2cnjHcmFXA Wfsp9tOSqannuZqZpqW2j7X2V8oto4zyOyBwaKNmNjQCuW74A/Sz+EA6LmBOTUuLAcYA 86/gej9Ecl8p0zQSgyIPN1gpQa832fHVzIUrNkkUb1pArang2tfkgnccuD5UKeNAIe96 W9IyhE9W4h+sqYtRp1MxnlcSha67HkjICIepatSIC3tY7uJrD8Gi6bmz9gWpNYMFVXWc WMi6CSmWG94OZaTk3+79xvfB2NMs4rYTMnbKKtwRrtFFI+4AhY9dgeSnqWzYRDc0TbkL dpJQ== 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 f144si607851pfa.148.2019.02.08.05.12.46; Fri, 08 Feb 2019 05:13:04 -0800 (PST) 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 S1727021AbfBHNMg (ORCPT + 99 others); Fri, 8 Feb 2019 08:12:36 -0500 Received: from mga04.intel.com ([192.55.52.120]:13877 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726465AbfBHNMf (ORCPT ); Fri, 8 Feb 2019 08:12:35 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Feb 2019 05:12:35 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.58,347,1544515200"; d="scan'208";a="142658643" Received: from jsakkine-mobl1.tm.intel.com (HELO localhost) ([10.237.50.115]) by fmsmga004.fm.intel.com with ESMTP; 08 Feb 2019 05:12:32 -0800 Date: Fri, 8 Feb 2019 15:12:31 +0200 From: Jarkko Sakkinen To: Stefan Berger Cc: Alexander Steffen , linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, Peter Huewe , Jason Gunthorpe , Tomas Winkler , Tadeusz Struk , Stefan Berger , Nayna Jain Subject: Re: [PATCH v11 00/16] Remove nested TPM operations Message-ID: <20190208131231.GB16679@linux.intel.com> References: <20190205224723.19671-1-jarkko.sakkinen@linux.intel.com> <20190206120634.GA4680@linux.intel.com> <3d6fdcc1-8221-2137-fc82-596377cc2fdc@infineon.com> <20190207212912.GD23906@linux.intel.com> <0af40351-91d5-d0a7-2965-0a9c6505af79@linux.ibm.com> <20190208003314.GB7202@linux.intel.com> <1fbd29ad-1005-8450-4c39-00974468183b@linux.ibm.com> <9cd734ad-ea9d-77f7-b657-3f0910a9d92f@linux.ibm.com> <20190208115031.GB11755@linux.intel.com> <8aecea14-cf0a-da6b-305c-c61ae03214be@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8aecea14-cf0a-da6b-305c-c61ae03214be@linux.ibm.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 Fri, Feb 08, 2019 at 07:22:48AM -0500, Stefan Berger wrote: > On 2/8/19 6:50 AM, Jarkko Sakkinen wrote: > > On Thu, Feb 07, 2019 at 09:14:54PM -0500, Stefan Berger wrote: > > > > > ???? chip->ops = NULL; > > > ???? up_write(&chip->ops_sem); > > > ?} > > > diff --git a/drivers/char/tpm/tpm-interface.c > > > b/drivers/char/tpm/tpm-interface.c > > > index 02e8cffd1163..fcd845ad8c3c 100644 > > > --- a/drivers/char/tpm/tpm-interface.c > > > +++ b/drivers/char/tpm/tpm-interface.c > > > @@ -124,6 +124,8 @@ static ssize_t tpm_try_transmit(struct tpm_chip *chip, > > > void *buf, size_t bufsiz) > > > ???? ??? dev_err(&chip->dev, "tpm_transmit: tpm_recv: error %d\n", rc); > > > ???? } else if (len < TPM_HEADER_SIZE || len != be32_to_cpu(header->length)) > > > ???? ??? rc = -EFAULT; > > > +??? else > > > +??? ??? rc = 0; > > Why is this needed? > > Because it holds a non-zero value, which is wrong at this point. Below it > is: > > return rc ? rc : len; > > It will always return that rc and never 'len'. > > It's not just needed for bisecting. I still need it with your latest tree. > That's the only change I need with my current testing of tpm_vtpm_proxy, TIS > + TPM 1.2 , TIS + TPM 2.0 , and CRB + TPM 2.0 (with QEMU :-) ). The code is unchaged. If there was a regression that would have been ages. /Jarkko