All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: Tadeusz Struk <tadeusz.struk@intel.com>
Cc: flihp@twobit.us, jgg@ziepe.ca, linux-integrity@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 2/2] tpm: add support for nonblocking operation
Date: Sun, 12 Aug 2018 13:39:55 +0300	[thread overview]
Message-ID: <20180812103955.GA4813@linux.intel.com> (raw)
In-Reply-To: <ad02d89f-31d3-7d9f-4580-daf759c8d837@intel.com>

On Fri, Aug 10, 2018 at 11:21:14AM -0700, Tadeusz Struk wrote:
> On 08/10/2018 10:43 AM, Jarkko Sakkinen wrote:
> >> +static struct workqueue_struct *tpm_dev_wq;
> > A naming contradiction with tpm_common_read() and tpm_common_write(). To
> > sort that up I would suggest adding a commit to the patch set that
> > renames these functions as tpm_dev_common_read() and
> > tpm_dev_common_write() and use the name tpm_common_dev_wq here.
> > 
> 
> Currently we have: tpm_open(), tpm_write(), tpm_release() in tpm-dev.c
> tpmrm_open(), tpmrm_read(), tpmrm_write(), tpmrm_release() in tpmrm-dev.c
> tpm_common_open(), tpm_common_read(), tpm_common_write(), tpm_common_release() in tpm-dev-common.c
> 
> I think that's pretty consistent. Do you want me to rename all of them to tpm_dev_*()?
> I don't see any value in doing this. What about if I just rename: 
> tpm_dev_wq_lock to tpm_common_wq_lock, and tpm_dev_wq to tpm_common_wq?

That is good enough. At least it is consistent.

> >> +static DEFINE_MUTEX(tpm_dev_wq_lock);
> > This is an unacceptable way to do it, Rather add:
> > 
> > int __init  tpm_dev_common_init(void)
> > {
> > 	tpm_dev_common_wq = alloc_workqueue("tpm_dev_wq", WQ_MEM_RECLAIM, 0);
> > 	if (!tpm_dev_common_wq)
> > 		return -ENOMEM;
> > 
> > 	return 0;
> > }
> > 
> > and call this in the driver initialization.
> > 
> That was the way it was implemented in v1 https://patchwork.kernel.org/patch/10442125/
> 
> See: static int __init tpm_dev_common_init(void)
> 
> and the feedback I got from Jason was:
> 
> "I wonder if it is worth creating this when the first file is
> opened.. Lots of systems have TPMs but few use the userspace.."
> 
> so I changed this to allocate the WQ on first open. I think it makes sense,
> but I leave it to you to decide.

Without a question I would go with tpm_common_init() for stability (one
less point of failure in open) and simplicity (no need for a locking
scheme).

> Tadeusz,
> -- 
> Tadeusz

/Jarkko

WARNING: multiple messages have this Message-ID (diff)
From: jarkko.sakkinen@linux.intel.com (Jarkko Sakkinen)
To: linux-security-module@vger.kernel.org
Subject: [PATCH v4 2/2] tpm: add support for nonblocking operation
Date: Sun, 12 Aug 2018 13:39:55 +0300	[thread overview]
Message-ID: <20180812103955.GA4813@linux.intel.com> (raw)
In-Reply-To: <ad02d89f-31d3-7d9f-4580-daf759c8d837@intel.com>

On Fri, Aug 10, 2018 at 11:21:14AM -0700, Tadeusz Struk wrote:
> On 08/10/2018 10:43 AM, Jarkko Sakkinen wrote:
> >> +static struct workqueue_struct *tpm_dev_wq;
> > A naming contradiction with tpm_common_read() and tpm_common_write(). To
> > sort that up I would suggest adding a commit to the patch set that
> > renames these functions as tpm_dev_common_read() and
> > tpm_dev_common_write() and use the name tpm_common_dev_wq here.
> > 
> 
> Currently we have: tpm_open(), tpm_write(), tpm_release() in tpm-dev.c
> tpmrm_open(), tpmrm_read(), tpmrm_write(), tpmrm_release() in tpmrm-dev.c
> tpm_common_open(), tpm_common_read(), tpm_common_write(), tpm_common_release() in tpm-dev-common.c
> 
> I think that's pretty consistent. Do you want me to rename all of them to tpm_dev_*()?
> I don't see any value in doing this. What about if I just rename: 
> tpm_dev_wq_lock to tpm_common_wq_lock, and tpm_dev_wq to tpm_common_wq?

That is good enough. At least it is consistent.

> >> +static DEFINE_MUTEX(tpm_dev_wq_lock);
> > This is an unacceptable way to do it, Rather add:
> > 
> > int __init  tpm_dev_common_init(void)
> > {
> > 	tpm_dev_common_wq = alloc_workqueue("tpm_dev_wq", WQ_MEM_RECLAIM, 0);
> > 	if (!tpm_dev_common_wq)
> > 		return -ENOMEM;
> > 
> > 	return 0;
> > }
> > 
> > and call this in the driver initialization.
> > 
> That was the way it was implemented in v1 https://patchwork.kernel.org/patch/10442125/
> 
> See: static int __init tpm_dev_common_init(void)
> 
> and the feedback I got from Jason was:
> 
> "I wonder if it is worth creating this when the first file is
> opened.. Lots of systems have TPMs but few use the userspace.."
> 
> so I changed this to allocate the WQ on first open. I think it makes sense,
> but I leave it to you to decide.

Without a question I would go with tpm_common_init() for stability (one
less point of failure in open) and simplicity (no need for a locking
scheme).

> Tadeusz,
> -- 
> Tadeusz

/Jarkko

  parent reply	other threads:[~2018-08-12 13:17 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-07 20:27 [PATCH v4 0/2] tpm: add support for nonblocking operation Tadeusz Struk
2018-08-07 20:27 ` Tadeusz Struk
2018-08-07 20:27 ` [PATCH v4 1/2] tpm: add ptr to the tpm_space struct to file_priv Tadeusz Struk
2018-08-07 20:27   ` Tadeusz Struk
2018-08-10 17:27   ` Jarkko Sakkinen
2018-08-10 17:27     ` Jarkko Sakkinen
2018-08-10 18:05     ` Tadeusz Struk
2018-08-10 18:05       ` Tadeusz Struk
2018-08-10 18:43       ` Jarkko Sakkinen
2018-08-10 18:43         ` Jarkko Sakkinen
2018-08-07 20:27 ` [PATCH v4 2/2] tpm: add support for nonblocking operation Tadeusz Struk
2018-08-07 20:27   ` Tadeusz Struk
2018-08-10 17:43   ` Jarkko Sakkinen
2018-08-10 17:43     ` Jarkko Sakkinen
2018-08-10 18:21     ` Tadeusz Struk
2018-08-10 18:21       ` Tadeusz Struk
2018-08-10 18:48       ` James Bottomley
2018-08-10 18:48         ` James Bottomley
2018-08-10 18:56         ` Tadeusz Struk
2018-08-10 18:56           ` Tadeusz Struk
2018-08-10 19:00           ` James Bottomley
2018-08-10 19:00             ` James Bottomley
2018-08-10 19:14             ` Tadeusz Struk
2018-08-10 19:14               ` Tadeusz Struk
2018-08-12 10:39       ` Jarkko Sakkinen [this message]
2018-08-12 10:39         ` 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=20180812103955.GA4813@linux.intel.com \
    --to=jarkko.sakkinen@linux.intel.com \
    --cc=flihp@twobit.us \
    --cc=jgg@ziepe.ca \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=tadeusz.struk@intel.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 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.