All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: Peter Huewe <peterhuewe@gmx.de>,
	Ashley Lai <ashley@ashleylai.com>,
	Marcel Selhorst <tpmdd@selhorst.net>,
	tpmdd-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org,
	josh.triplett@intel.com, christophe.ricard@gmail.com,
	jason.gunthorpe@obsidianresearch.com
Subject: Re: [PATCH v6 05/10] tpm: device class for tpm
Date: Tue, 11 Nov 2014 10:20:48 +0200	[thread overview]
Message-ID: <20141111082048.GB7088@intel.com> (raw)
In-Reply-To: <20141110180016.GB5296@obsidianresearch.com>

On Mon, Nov 10, 2014 at 11:00:16AM -0700, Jason Gunthorpe wrote:
> On Mon, Nov 10, 2014 at 02:49:49PM +0200, Jarkko Sakkinen wrote:
>   
> > +static void tpm_dev_release(struct device *dev)
> > +{
> > +}
> > +
> 
> These patches are so close to actually fixing many of the use-after-free
> problems too :)

Excellent!

> >  int tpm_dev_add_device(struct tpm_chip *chip)
> >  {
> >  	int rc;
> >  
> > -	chip->vendor.miscdev.fops = &tpm_fops;
> > +	chip->dev.class = tpm_class;
> > +	chip->dev.release = tpm_dev_release;
> > +	chip->dev.parent = chip->pdev;
> > +	dev_set_name(&chip->dev, chip->devname);
> > +	rc = device_register(&chip->dev);
> 
> I think all of this should live in tpm-chip.c
> 
> I would also suggest using device_initialize during tpmm_alloc_chip
> and device_add + cdev_add during tpm_register. That way the dev member
> is always valid and we can immediately use put_device to do the free and
> devm just does put_device.

Right. Makes sense. I'll do this change.

> >  void tpm_dev_del_device(struct tpm_chip *chip)
> >  {
> > -	if (chip->vendor.miscdev.name)
> > -		misc_deregister(&chip->vendor.miscdev);
> > +	if (get_device(&chip->dev) != NULL) {
> > +		cdev_del(&chip->cdev);
> > +		device_unregister(&chip->dev);
> > +		put_device(&chip->dev);
> > +	}
> 
> The get/put seems oddly placed - really the caller of del_device must
> be holding the ref I don't see that del_device needs it..

I checked from the source code and what you say is corrrect.

> Ultimately we want things so that when the ref count goes to 0 then
> the chip will be freed - this means that get_device can never fail
> since chip->dev will be deallocated memory.

This is again something that I acknowledge but did not want to bake into
patch set.

> > +struct class *tpm_class;
> > +dev_t tpm_devt;
> 
> Also makes more sense to me in chip-chip

Ack.

> Jason

/Jarkko

  reply	other threads:[~2014-11-11  8:23 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-10 12:49 [PATCH v6 00/10] TPM 2.0 support Jarkko Sakkinen
2014-11-10 12:49 ` [PATCH v6 01/10] tpm: merge duplicate transmit_cmd() functions Jarkko Sakkinen
2014-11-10 12:49 ` [PATCH v6 02/10] tpm: two-phase chip management functions Jarkko Sakkinen
2014-11-10 12:49 ` [PATCH v6 03/10] tpm: fix multiple race conditions in tpm_ppi.c Jarkko Sakkinen
2014-11-10 12:49 ` [PATCH v6 04/10] tpm: rename chip->dev to chip->pdev Jarkko Sakkinen
2014-11-10 17:45   ` Jason Gunthorpe
2014-11-11  8:13     ` Jarkko Sakkinen
2014-11-10 12:49 ` [PATCH v6 05/10] tpm: device class for tpm Jarkko Sakkinen
2014-11-10 18:00   ` Jason Gunthorpe
2014-11-11  8:20     ` Jarkko Sakkinen [this message]
2014-11-10 12:49 ` [PATCH v6 06/10] tpm: fix race condition with sysfs attributes Jarkko Sakkinen
2014-11-10 12:49 ` [PATCH v6 07/10] tpm: TPM 2.0 baseline support Jarkko Sakkinen
2014-11-10 12:49 ` [PATCH v6 08/10] tpm: TPM 2.0 CRB Interface Jarkko Sakkinen
2014-11-10 12:49 ` [PATCH v6 09/10] tpm: TPM 2.0 FIFO Interface Jarkko Sakkinen
2014-11-10 12:49 ` [PATCH v6 10/10] tpm: TPM 2.0 sysfs attributes Jarkko Sakkinen
2014-11-10 18:03   ` Jason Gunthorpe
2014-11-11  8:22     ` 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=20141111082048.GB7088@intel.com \
    --to=jarkko.sakkinen@linux.intel.com \
    --cc=ashley@ashleylai.com \
    --cc=christophe.ricard@gmail.com \
    --cc=jason.gunthorpe@obsidianresearch.com \
    --cc=jgunthorpe@obsidianresearch.com \
    --cc=josh.triplett@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterhuewe@gmx.de \
    --cc=tpmdd-devel@lists.sourceforge.net \
    --cc=tpmdd@selhorst.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.