All of lore.kernel.org
 help / color / mirror / Atom feed
From: gregkh@linuxfoundation.org (Greg Kroah-Hartman)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 3/5] tee: generic TEE subsystem
Date: Wed, 8 Jul 2015 14:11:29 -0700	[thread overview]
Message-ID: <20150708211129.GA29824@kroah.com> (raw)
In-Reply-To: <20150708171026.GA11740@obsidianresearch.com>

On Wed, Jul 08, 2015 at 11:10:26AM -0600, Jason Gunthorpe wrote:
> On Wed, Jul 08, 2015 at 12:16:30PM +0200, Jens Wiklander wrote:
> 
> > +static void tee_device_complete_unused(struct kref *kref)
> > +{
> > +	struct tee_device *teedev;
> > +
> > +	teedev = container_of(kref, struct tee_device, users);
> > +	/* When the mutex is released, no other tee_device_get() will succeed */
> > +	teedev->desc = NULL;
> > +	complete(&teedev->c_no_users);
> > +}
> > +
> > +void tee_device_put(struct tee_device *teedev)
> > +{
> > +	mutex_lock(&teedev->mutex);
> > +	/* Shouldn't put in this state */
> > +	if (!WARN_ON(!teedev->desc))
> > +		kref_put(&teedev->users, tee_device_complete_unused);
> > +	mutex_unlock(&teedev->mutex);
> > +}
> > +
> > +bool tee_device_get(struct tee_device *teedev)
> > +{
> > +	mutex_lock(&teedev->mutex);
> > +	if (!teedev->desc) {
> > +		mutex_unlock(&teedev->mutex);
> > +		return false;
> > +	}
> > +	kref_get(&teedev->users);
> > +	mutex_unlock(&teedev->mutex);
> > +	return true;
> > +}
> 
> If you are holding the mutex then you don't really need a kref, just a
> simple active count counter.
> 
> I've been a bit learly lately about seeing krefs used for something
> other than kfree, I've seen a few subtle mistakes in those schemes -
> yours looks OK, only because of the lock, and the lock makes the kref
> redundant..
> 
> > +       cdev_init(&teedev->cdev, &tee_fops);
> > +       teedev->cdev.owner = teedesc->owner;
> 
> This also needs to set teedev->cdev.kobj.parent.
> I'm guessing:
> 
>  teedev->cdev.kobj.parent = &teedev->dev.kobj;
> 
> TPM had the same mistake..

Really?  As of a few years ago, A cdev's kobject should not be touched
by anything other than the cdev core.  It's not a "real" kobject in that
it is never registered in sysfs, and no one sees it.  I keep meaning to
just use something else one of these days for that structure, as lots of
people get it wrong.  Or has things changed there?

thanks,

greg k-h

WARNING: multiple messages have this Message-ID (diff)
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: Jens Wiklander <jens.wiklander@linaro.org>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
	Arnd Bergmann <arnd@arndb.de>, Rob Herring <robh+dt@kernel.org>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	valentin.manea@huawei.com, jean-michel.delorme@st.com,
	emmanuel.michel@st.com, javier@javigon.com,
	Mark Rutland <mark.rutland@arm.com>,
	Michal Simek <michal.simek@xilinx.com>
Subject: Re: [PATCH v4 3/5] tee: generic TEE subsystem
Date: Wed, 8 Jul 2015 14:11:29 -0700	[thread overview]
Message-ID: <20150708211129.GA29824@kroah.com> (raw)
In-Reply-To: <20150708171026.GA11740@obsidianresearch.com>

On Wed, Jul 08, 2015 at 11:10:26AM -0600, Jason Gunthorpe wrote:
> On Wed, Jul 08, 2015 at 12:16:30PM +0200, Jens Wiklander wrote:
> 
> > +static void tee_device_complete_unused(struct kref *kref)
> > +{
> > +	struct tee_device *teedev;
> > +
> > +	teedev = container_of(kref, struct tee_device, users);
> > +	/* When the mutex is released, no other tee_device_get() will succeed */
> > +	teedev->desc = NULL;
> > +	complete(&teedev->c_no_users);
> > +}
> > +
> > +void tee_device_put(struct tee_device *teedev)
> > +{
> > +	mutex_lock(&teedev->mutex);
> > +	/* Shouldn't put in this state */
> > +	if (!WARN_ON(!teedev->desc))
> > +		kref_put(&teedev->users, tee_device_complete_unused);
> > +	mutex_unlock(&teedev->mutex);
> > +}
> > +
> > +bool tee_device_get(struct tee_device *teedev)
> > +{
> > +	mutex_lock(&teedev->mutex);
> > +	if (!teedev->desc) {
> > +		mutex_unlock(&teedev->mutex);
> > +		return false;
> > +	}
> > +	kref_get(&teedev->users);
> > +	mutex_unlock(&teedev->mutex);
> > +	return true;
> > +}
> 
> If you are holding the mutex then you don't really need a kref, just a
> simple active count counter.
> 
> I've been a bit learly lately about seeing krefs used for something
> other than kfree, I've seen a few subtle mistakes in those schemes -
> yours looks OK, only because of the lock, and the lock makes the kref
> redundant..
> 
> > +       cdev_init(&teedev->cdev, &tee_fops);
> > +       teedev->cdev.owner = teedesc->owner;
> 
> This also needs to set teedev->cdev.kobj.parent.
> I'm guessing:
> 
>  teedev->cdev.kobj.parent = &teedev->dev.kobj;
> 
> TPM had the same mistake..

Really?  As of a few years ago, A cdev's kobject should not be touched
by anything other than the cdev core.  It's not a "real" kobject in that
it is never registered in sysfs, and no one sees it.  I keep meaning to
just use something else one of these days for that structure, as lots of
people get it wrong.  Or has things changed there?

thanks,

greg k-h

  reply	other threads:[~2015-07-08 21:11 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-08 10:16 [PATCH v4 0/5] generic TEE subsystem Jens Wiklander
2015-07-08 10:16 ` Jens Wiklander
2015-07-08 10:16 ` [PATCH v4 1/5] arm/arm64: add smccc ARCH32 Jens Wiklander
2015-07-08 10:16   ` Jens Wiklander
2015-07-08 10:16   ` Jens Wiklander
2015-07-08 10:16 ` [PATCH v4 2/5] dt/bindings: add bindings for optee Jens Wiklander
2015-07-08 10:16   ` Jens Wiklander
2015-07-08 10:16   ` Jens Wiklander
2015-07-08 10:16 ` [PATCH v4 3/5] tee: generic TEE subsystem Jens Wiklander
2015-07-08 10:16   ` Jens Wiklander
2015-07-08 17:10   ` Jason Gunthorpe
2015-07-08 17:10     ` Jason Gunthorpe
2015-07-08 21:11     ` Greg Kroah-Hartman [this message]
2015-07-08 21:11       ` Greg Kroah-Hartman
2015-07-08 22:26       ` Jason Gunthorpe
2015-07-08 22:26         ` Jason Gunthorpe
2015-07-08 22:26         ` Jason Gunthorpe
2015-07-08 22:33         ` Greg Kroah-Hartman
2015-07-08 22:33           ` Greg Kroah-Hartman
2015-07-08 22:33           ` Greg Kroah-Hartman
2015-07-08 23:16           ` Jason Gunthorpe
2015-07-08 23:16             ` Jason Gunthorpe
2015-07-08 23:16             ` Jason Gunthorpe
2015-07-08 23:53             ` Greg Kroah-Hartman
2015-07-08 23:53               ` Greg Kroah-Hartman
2015-07-09  0:47               ` Dmitry Torokhov
2015-07-09  0:47                 ` Dmitry Torokhov
2015-07-08 23:28           ` Dmitry Torokhov
2015-07-08 23:28             ` Dmitry Torokhov
2015-07-08 23:28             ` Dmitry Torokhov
2015-07-08 23:52             ` Greg Kroah-Hartman
2015-07-08 23:52               ` Greg Kroah-Hartman
2015-07-09  0:56               ` Dmitry Torokhov
2015-07-09  0:56                 ` Dmitry Torokhov
2015-07-09  0:56                 ` Dmitry Torokhov
2015-07-09 12:49     ` Jens Wiklander
2015-07-09 12:49       ` Jens Wiklander
2015-07-09 18:25       ` Jason Gunthorpe
2015-07-09 18:25         ` Jason Gunthorpe
2015-07-08 10:16 ` [PATCH v4 4/5] tee: add OP-TEE driver Jens Wiklander
2015-07-08 10:16   ` Jens Wiklander
2015-07-08 10:16 ` [PATCH v4 5/5] Documentation: tee subsystem and op-tee driver Jens Wiklander
2015-07-08 10:16   ` Jens Wiklander

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=20150708211129.GA29824@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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.