public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Marcel Selhorst <tpm@selhorst.net>
To: Richard MUSIL <richard.musil@st.com>
Cc: linux-kernel@vger.kernel.org, tpmdd-devel@lists.sourceforge.net,
	Greg KH <greg@kroah.com>
Subject: Re: [tpmdd-devel] [PATCH] - TPM device driver layer (tpm.c|h)
Date: Mon, 19 Nov 2007 00:13:19 +0100	[thread overview]
Message-ID: <4740C70F.8050407@selhorst.net> (raw)
In-Reply-To: <46CD497F.8030207@st.com>

Dear all,

sorry for the delay. The patch below was posted 3 months ago and fixes
 possible problems during unloading of TPM device drivers.

Acked by: Marcel Selhorst <tpm@selhorst.net>
---

Richard MUSIL wrote:
> Dear all,
> 
> I am currently writing virtual TPM device driver. This driver exposes
> itself and behaves like regular TPM device (i.e. uses TPM layer which is
> already present in kernel), but instead of talking to hardware it talks
> to user space.
> 
> In my setup, I can create several virtual devices and delete them in
> runtime. During this I noticed that current implementation is prone to
> segfault when tpm_remove_hardware is called while the device is in its
> receiving routine.
> 
> The problem is in tpm_remove_hardware which does all necessary steps to
> remove the device, but it does not wait for the device being actually
> removed and kfrees tpm_chip struct right away. If the device is at this
> time in its receiving routine (through read call, for example) it blocks
> the device removal until the call is completed. The call cannot be
> completed though because tpm_chip struct was already kfreed.
> 
> Since there is significant timeout and it is possible to meet that
> timeout in normal operation this situation is quite easily reproducible.
> 
> What I present below is rather quickfix with least impact on other TPM
> parts (drivers). The patch uses device->remove callback (of
> platform_device device) and reroutes this to itself. In this
> callback it eventually calls vendor callback and finally kfrees all
> memory resources allocated on its own.
> 
> The correct solution for this I believe would require removing TPM
> hardware (as it is done by tpm_remove_hardware right now) in two steps
> both called by vendor driver. In the first one vendor driver will just
> "unregister" the hardware. In the second step vendor driver will call
> tpm_release_resources routine which kfrees all resources allocated by
> tpm.c. In order to be able to call tpm_release_resources, vendor driver
> will have to register as platform driver and handle
> platform_driver.probe and platform_driver.remove.
> 
> This will however require some changes in all drivers, which I cannot
> test (but I could eventually write the patch). Also I see some "issues"
> in tpm_tis which will have to be clarified.
> 
> --
> Richard
> 
> 
>> >From bd80b63ca2e1edb761a3ffcf87bd86c30a44ca5f Mon Sep 17 00:00:00 2001
> From: Richard Musil <richard.musil@st.com>
> Date: Tue, 21 Aug 2007 16:46:06 +0200
> Subject: [PATCH] Change in TPM module:
> 
> The clean up procedure now uses platform device "release" callback to
> handle memory clean up. For this purpose "release" function callback was
> added to struct tpm_vendor_specific, so hw device driver provider can get
> called when it is safe to remove all allocated resources.
> 
> This is supposed to fix a bug in device removal, where device while in
> receive function (waiting on timeout) was prone to segfault, if the
> tpm_chip struct was unallocated before the timeout expired (in
> tpm_remove_hardware).
> ---
>  drivers/char/tpm/tpm.c |   46 +++++++++++++++++++++++++++++-----------------
>  drivers/char/tpm/tpm.h |    2 ++
>  2 files changed, 31 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/char/tpm/tpm.c b/drivers/char/tpm/tpm.c
> index 9bb5429..41eba7e 100644
> --- a/drivers/char/tpm/tpm.c
> +++ b/drivers/char/tpm/tpm.c
> @@ -1031,18 +1031,13 @@ void tpm_remove_hardware(struct device *dev)
>  
>  	spin_unlock(&driver_lock);
>  
> -	dev_set_drvdata(dev, NULL);
>  	misc_deregister(&chip->vendor.miscdev);
> -	kfree(chip->vendor.miscdev.name);
>  
>  	sysfs_remove_group(&dev->kobj, chip->vendor.attr_group);
>  	tpm_bios_log_teardown(chip->bios_dir);
>  
> -	clear_bit(chip->dev_num, dev_mask);
> -
> -	kfree(chip);
> -
> -	put_device(dev);
> +	/* write it this way to be explicit (chip->dev == dev) */
> +	put_device(chip->dev);
>  }
>  EXPORT_SYMBOL_GPL(tpm_remove_hardware);
>  
> @@ -1083,6 +1078,28 @@ int tpm_pm_resume(struct device *dev)
>  EXPORT_SYMBOL_GPL(tpm_pm_resume);
>  
>  /*
> + * Once all references to platform device are down to 0,
> + * release all allocated structures.
> + * In case vendor provided release function,
> + * call it too.
> + */
> +static void tpm_dev_release(struct device *dev)
> +{
> +	struct tpm_chip *chip = dev_get_drvdata(dev);
> +	/* call vendor release, if defined */
> +	if (chip->vendor.release)
> +		chip->vendor.release(dev);
> +
> +	/* it *should* be: chip->release != NULL */
> +	if (likely(chip->release))
> +		chip->release(dev);
> +
> +	clear_bit(chip->dev_num, dev_mask);
> +	kfree(chip->vendor.miscdev.name);
> +	kfree(chip);
> +}
> +
> +/*
>   * Called from tpm_<specific>.c probe function only for devices 
>   * the driver has determined it should claim.  Prior to calling
>   * this function the specific probe function has called pci_enable_device
> @@ -1136,23 +1153,21 @@ struct tpm_chip *tpm_register_hardware(struct device *dev, const struct tpm_vend
>  
>  	chip->vendor.miscdev.parent = dev;
>  	chip->dev = get_device(dev);
> +	chip->release = dev->release;
> +	dev->release = tpm_dev_release;
> +	dev_set_drvdata(dev, chip);
>  
>  	if (misc_register(&chip->vendor.miscdev)) {
>  		dev_err(chip->dev,
>  			"unable to misc_register %s, minor %d\n",
>  			chip->vendor.miscdev.name,
>  			chip->vendor.miscdev.minor);
> -		put_device(dev);
> -		clear_bit(chip->dev_num, dev_mask);
> -		kfree(chip);
> -		kfree(devname);
> +		put_device(chip->dev);
>  		return NULL;
>  	}
>  
>  	spin_lock(&driver_lock);
>  
> -	dev_set_drvdata(dev, chip);
> -
>  	list_add(&chip->list, &tpm_chip_list);
>  
>  	spin_unlock(&driver_lock);
> @@ -1160,10 +1175,7 @@ struct tpm_chip *tpm_register_hardware(struct device *dev, const struct tpm_vend
>  	if (sysfs_create_group(&dev->kobj, chip->vendor.attr_group)) {
>  		list_del(&chip->list);
>  		misc_deregister(&chip->vendor.miscdev);
> -		put_device(dev);
> -		clear_bit(chip->dev_num, dev_mask);
> -		kfree(chip);
> -		kfree(devname);
> +		put_device(chip->dev);
>  		return NULL;
>  	}
>  
> diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
> index b2e2b00..f1c265e 100644
> --- a/drivers/char/tpm/tpm.h
> +++ b/drivers/char/tpm/tpm.h
> @@ -74,6 +74,7 @@ struct tpm_vendor_specific {
>  	int (*send) (struct tpm_chip *, u8 *, size_t);
>  	void (*cancel) (struct tpm_chip *);
>  	u8 (*status) (struct tpm_chip *);
> +	void (*release) (struct device *);
>  	struct miscdevice miscdev;
>  	struct attribute_group *attr_group;
>  	struct list_head list;
> @@ -106,6 +107,7 @@ struct tpm_chip {
>  	struct dentry **bios_dir;
>  
>  	struct list_head list;
> +	void (*release) (struct device *);
>  };
>  
>  #define to_tpm_chip(n) container_of(n, struct tpm_chip, vendor)

  parent reply	other threads:[~2007-11-18 23:23 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-23  8:46 [PATCH] - TPM device driver layer (tpm.c|h) Richard MUSIL
2007-08-23  9:26 ` Greg KH
2007-09-25 13:14   ` [PATCH] - TPM device driver layer (tpm.c|h) - repost Richard MUSIL
2007-09-25 14:11     ` Greg KH
2007-09-28  8:08       ` [tpmdd-devel] " Marcel Selhorst
2007-11-20  6:37     ` Andrew Morton
2007-11-20 12:32       ` [PATCH] - TPM device driver layer (tpm.c|h) - 2nd repost Richard MUSIL
2007-11-20 12:53         ` Richard MUSIL
2007-11-20 20:06         ` Andrew Morton
2007-11-18 23:13 ` Marcel Selhorst [this message]
2007-11-19  5:09   ` [tpmdd-devel] [PATCH] - TPM device driver layer (tpm.c|h) Greg KH
2007-11-19  6:42     ` Marcel Selhorst

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=4740C70F.8050407@selhorst.net \
    --to=tpm@selhorst.net \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=richard.musil@st.com \
    --cc=tpmdd-devel@lists.sourceforge.net \
    /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