linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Berger <stefanb@linux.ibm.com>
To: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
	linux-integrity@vger.kernel.org
Cc: linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	Peter Huewe <PeterHuewe@gmx.de>, Jason Gunthorpe <jgg@ziepe.ca>,
	Stefan Berger <stefanb@linux.vnet.ibm.com>,
	Nayna Jain <nayna@linux.ibm.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH 1/2] tpm: Unify the send callback behaviour
Date: Fri, 8 Feb 2019 09:42:16 -0500	[thread overview]
Message-ID: <b53745b6-ed49-9e97-6f56-1378561888eb@linux.ibm.com> (raw)
In-Reply-To: <20190208140600.24996-2-jarkko.sakkinen@linux.intel.com>

On 2/8/19 9:05 AM, Jarkko Sakkinen wrote:
> The send() callback should never return length as it does not in every
> driver except tpm_crb in the success case. The reason is that the main
> transmit functionality only cares about whether the transmit was
> successful or not and ignores the count completely.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> ---
>   drivers/char/tpm/st33zp24/st33zp24.c | 2 +-
>   drivers/char/tpm/tpm_atmel.c         | 2 +-
>   drivers/char/tpm/tpm_i2c_atmel.c     | 6 +++++-
>   drivers/char/tpm/tpm_i2c_infineon.c  | 2 +-
>   drivers/char/tpm/tpm_i2c_nuvoton.c   | 2 +-
>   drivers/char/tpm/tpm_ibmvtpm.c       | 2 +-
>   drivers/char/tpm/tpm_vtpm_proxy.c    | 3 +--
>   drivers/char/tpm/xen-tpmfront.c      | 2 +-

At least tpm_nsc_send (tpm_nsc.c) and tpm_inf_send (tpm_infineon.c) are 
also returning the number of bytes sent. I would consider tpm_crb the 
outlier that returns 0 and should return the length even though we don't 
need it...


>   8 files changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/char/tpm/st33zp24/st33zp24.c b/drivers/char/tpm/st33zp24/st33zp24.c
> index 64dc560859f2..13dc614b7ebc 100644
> --- a/drivers/char/tpm/st33zp24/st33zp24.c
> +++ b/drivers/char/tpm/st33zp24/st33zp24.c
> @@ -436,7 +436,7 @@ static int st33zp24_send(struct tpm_chip *chip, unsigned char *buf,
>   			goto out_err;
>   	}
>
> -	return len;
> +	return 0;
>   out_err:
>   	st33zp24_cancel(chip);
>   	release_locality(chip);
> diff --git a/drivers/char/tpm/tpm_atmel.c b/drivers/char/tpm/tpm_atmel.c
> index 66a14526aaf4..a290b30a0c35 100644
> --- a/drivers/char/tpm/tpm_atmel.c
> +++ b/drivers/char/tpm/tpm_atmel.c
> @@ -105,7 +105,7 @@ static int tpm_atml_send(struct tpm_chip *chip, u8 *buf, size_t count)
>   		iowrite8(buf[i], priv->iobase);
>   	}
>
> -	return count;
> +	return 0;
>   }
>
>   static void tpm_atml_cancel(struct tpm_chip *chip)
> diff --git a/drivers/char/tpm/tpm_i2c_atmel.c b/drivers/char/tpm/tpm_i2c_atmel.c
> index 4720b2442ffe..aa11c8a1df5e 100644
> --- a/drivers/char/tpm/tpm_i2c_atmel.c
> +++ b/drivers/char/tpm/tpm_i2c_atmel.c
> @@ -65,7 +65,11 @@ static int i2c_atmel_send(struct tpm_chip *chip, u8 *buf, size_t len)
>   	dev_dbg(&chip->dev,
>   		"%s(buf=%*ph len=%0zx) -> sts=%d\n", __func__,
>   		(int)min_t(size_t, 64, len), buf, len, status);
> -	return status;
> +
> +	if (status < 0)
> +		return status;
> +
> +	return 0;
>   }
>
>   static int i2c_atmel_recv(struct tpm_chip *chip, u8 *buf, size_t count)
> diff --git a/drivers/char/tpm/tpm_i2c_infineon.c b/drivers/char/tpm/tpm_i2c_infineon.c
> index 3b490d9d90e7..3b4e9672ff6c 100644
> --- a/drivers/char/tpm/tpm_i2c_infineon.c
> +++ b/drivers/char/tpm/tpm_i2c_infineon.c
> @@ -588,7 +588,7 @@ static int tpm_tis_i2c_send(struct tpm_chip *chip, u8 *buf, size_t len)
>   	/* go and do it */
>   	iic_tpm_write(TPM_STS(tpm_dev.locality), &sts, 1);
>
> -	return len;
> +	return 0;
>   out_err:
>   	tpm_tis_i2c_ready(chip);
>   	/* The TPM needs some time to clean up here,
> diff --git a/drivers/char/tpm/tpm_i2c_nuvoton.c b/drivers/char/tpm/tpm_i2c_nuvoton.c
> index 5700cc2ddee1..315a3b4548f7 100644
> --- a/drivers/char/tpm/tpm_i2c_nuvoton.c
> +++ b/drivers/char/tpm/tpm_i2c_nuvoton.c
> @@ -465,7 +465,7 @@ static int i2c_nuvoton_send(struct tpm_chip *chip, u8 *buf, size_t len)
>   	}
>
>   	dev_dbg(dev, "%s() -> %zd\n", __func__, len);
> -	return len;
> +	return 0;
>   }
>
>   static bool i2c_nuvoton_req_canceled(struct tpm_chip *chip, u8 status)
> diff --git a/drivers/char/tpm/tpm_ibmvtpm.c b/drivers/char/tpm/tpm_ibmvtpm.c
> index 07b5a487d0c8..aeae3222723c 100644
> --- a/drivers/char/tpm/tpm_ibmvtpm.c
> +++ b/drivers/char/tpm/tpm_ibmvtpm.c
> @@ -192,7 +192,7 @@ static int tpm_ibmvtpm_send(struct tpm_chip *chip, u8 *buf, size_t count)
>   		rc = 0;
>   		ibmvtpm->tpm_processing_cmd = false;
>   	} else
> -		rc = count;
> +		rc = 0;
>
>   	spin_unlock(&ibmvtpm->rtce_lock);
>   	return rc;
> diff --git a/drivers/char/tpm/tpm_vtpm_proxy.c b/drivers/char/tpm/tpm_vtpm_proxy.c
> index 26a2be555288..d74f3de74ae6 100644
> --- a/drivers/char/tpm/tpm_vtpm_proxy.c
> +++ b/drivers/char/tpm/tpm_vtpm_proxy.c
> @@ -335,7 +335,6 @@ static int vtpm_proxy_is_driver_command(struct tpm_chip *chip,
>   static int vtpm_proxy_tpm_op_send(struct tpm_chip *chip, u8 *buf, size_t count)
>   {
>   	struct proxy_dev *proxy_dev = dev_get_drvdata(&chip->dev);
> -	int rc = 0;
>
>   	if (count > sizeof(proxy_dev->buffer)) {
>   		dev_err(&chip->dev,
> @@ -366,7 +365,7 @@ static int vtpm_proxy_tpm_op_send(struct tpm_chip *chip, u8 *buf, size_t count)
>
>   	wake_up_interruptible(&proxy_dev->wq);
>
> -	return rc;
> +	return 0;
>   }
>
>   static void vtpm_proxy_tpm_op_cancel(struct tpm_chip *chip)
> diff --git a/drivers/char/tpm/xen-tpmfront.c b/drivers/char/tpm/xen-tpmfront.c
> index 1259e935fd58..4e2d00cb0d81 100644
> --- a/drivers/char/tpm/xen-tpmfront.c
> +++ b/drivers/char/tpm/xen-tpmfront.c
> @@ -173,7 +173,7 @@ static int vtpm_send(struct tpm_chip *chip, u8 *buf, size_t count)
>   		return -ETIME;
>   	}
>
> -	return count;
> +	return 0;
>   }
>
>   static int vtpm_recv(struct tpm_chip *chip, u8 *buf, size_t count)



  reply	other threads:[~2019-02-08 14:42 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-08 14:05 [PATCH 0/2] Unify send() callbacks Jarkko Sakkinen
2019-02-08 14:05 ` [PATCH 1/2] tpm: Unify the send callback behaviour Jarkko Sakkinen
2019-02-08 14:42   ` Stefan Berger [this message]
2019-02-08 15:42     ` Jarkko Sakkinen
2019-02-08 15:45       ` Stefan Berger
2019-02-08 16:07         ` Jarkko Sakkinen
2019-02-08 16:19           ` Stefan Berger
2019-02-08 16:26             ` Jarkko Sakkinen
2019-02-08 16:28               ` Jarkko Sakkinen
2019-02-08 14:06 ` [PATCH 2/2] tpm/tpm_i2c_atmel: Return -E2BIG when the transfer is incomplete Jarkko Sakkinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b53745b6-ed49-9e97-6f56-1378561888eb@linux.ibm.com \
    --to=stefanb@linux.ibm.com \
    --cc=PeterHuewe@gmx.de \
    --cc=jarkko.sakkinen@linux.intel.com \
    --cc=jgg@ziepe.ca \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=nayna@linux.ibm.com \
    --cc=stable@vger.kernel.org \
    --cc=stefanb@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).