From: Arjan van de Ven <arjan@infradead.org>
To: Kylene Hall <kjhall@us.ibm.com>
Cc: linux-kernel@vger.kernel.org, greg@kroah.com,
sailer@watson.ibm.com, leendert@watson.ibm.com,
emilyr@us.ibm.com, toml@us.ibm.com,
tpmdd-devel@lists.sourceforge.net
Subject: Re: [PATCH 1/1] driver: Tpm hardware enablement
Date: Thu, 09 Dec 2004 10:48:29 -0500 [thread overview]
Message-ID: <1102607309.2784.40.camel@laptop.fenrus.org> (raw)
In-Reply-To: <Pine.LNX.4.58.0412081546470.24510@jo.austin.ibm.com>
On Thu, 2004-12-09 at 09:25 -0600, Kylene Hall wrote:
> + /* wait for status */
> + add_timer(&status_timer);
> + do {
> + schedule();
> + *data = inb(chip->base + 1);
> + if ((*data & mask) == val) {
> + del_singleshot_timer_sync(&status_timer);
> + return 0;
> + }
> + } while (!expired);
this is busy waiting. Can't you do it with msleep() or some such ?
Or like 100 iterations without delays (in case the chip returns fast),
and then start sleeping, but please do sleep for a real time, not just
yield the cpu. Powermanagement and lots of other things really like to
see that.
> + /* wait for status */
> + add_timer(&status_timer);
> + do {
> + schedule();
> + status = inb(chip->base + NSC_STATUS);
> + if (status & NSC_STATUS_OBF)
> + status = inb(chip->base + NSC_DATA);
> + if (status & NSC_STATUS_RDY) {
> + del_singleshot_timer_sync(&status_timer);
> + return 0;
> + }
> + } while (!expired);
same comment. Also the timer handling looks suspect... can you guarantee
100% sure that the timer is gone when the while falls through ?
> + chip->userspace_buffer =
> + kmalloc(TPM_BUFSIZE * sizeof(u8), GFP_KERNEL);
that sounds like a really deceptive name to me ... since it's kernel
memory ;)
> +static int tpm_release(struct inode *inode, struct file *file)
> +{
> + struct tpm_chip *chip = file->private_data;
> +
> + if (chip == NULL)
> + return -ENODEV;
> +
> + spin_lock(&driver_lock);
> + chip->num_opens--;
why do you need to keep track of the number of openers? Can't you have
the kernel fs layer keep track of this ?
> + chip->user_read_timer.function = user_reader_timeout;
> + chip->user_read_timer.data = (unsigned long) chip;
> + chip->user_read_timer.expires = jiffies + (60 * HZ);
> + add_timer(&chip->user_read_timer);
> +
> + atomic_set(&chip->data_pending, out_size);
> +
> + return size;
what prevents the module from being unloaded ?
(eg user calls write(); close(); and then does rmmod before the timer
expires )
> +/*
> + * Resume from a power safe. The BIOS already restored
> + * the TPM state.
> + */
are there any special security things needed after resume ?
Or maybe at suspend time, to wipe secrets from the TPM or somesuch..
next prev parent reply other threads:[~2004-12-09 15:49 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-09 15:25 Kylene Hall
2004-12-09 15:48 ` Arjan van de Ven [this message]
2004-12-09 17:06 ` Kylie Hall
2004-12-11 8:31 ` Nish Aravamudan
2004-12-10 20:45 ` Alan Cox
2004-12-10 10:56 ` Ian Campbell
2004-12-10 15:28 ` Kylene Hall
2004-12-10 15:41 ` Ian Campbell
2004-12-10 18:39 ` [tpmdd-devel] " Kylene Hall
2004-12-14 9:59 ` Ian Campbell
2004-12-16 22:37 ` [PATCH 1/1] driver: Tpm hardware enablement --updated version Kylene Hall
2004-12-16 22:48 ` Greg KH
2004-12-17 22:47 ` [tpmdd-devel] " Kylene Hall
2004-12-17 0:53 ` Chris Wright
2004-12-17 22:47 ` [tpmdd-devel] " Kylene Hall
2004-12-17 22:47 ` Kylene Hall
2004-12-17 22:59 ` Greg KH
2004-12-20 17:50 ` Kylene Hall
2004-12-21 16:51 ` Nish Aravamudan
2004-12-21 18:19 ` Kylene Hall
2005-01-12 18:45 ` Kylene Hall
2005-01-12 23:28 ` Greg KH
2005-01-18 22:29 ` [PATCH 1/1] tpm: fix cause of SMP stack traces Kylene Hall
2005-01-18 22:37 ` Chris Wright
2005-01-18 22:44 ` Kylene Hall
2005-01-18 22:47 ` Chris Wright
2005-01-18 22:47 ` Greg KH
2005-01-18 23:07 ` Kylene Hall
2005-01-18 23:39 ` [PATCH 1/1] tpm: fix cause of SMP stack traces -- updated version Kylene Hall
2005-01-28 21:45 ` [PATCH 1/1] tpm: insert missing up mutex in an error path Kylene Hall
2005-01-31 19:27 ` [PATCH 1/1] tpm: insert missing up mutex in an error path, typo build fix -- updated version Kylene Hall
2005-02-03 16:40 ` [PATCH 1/1] tpm: remove pci specific stuff from the underlying generic driver Kylene Hall
2005-02-04 20:12 ` [PATCH 1/1] tpm: implement use of sysfs classes Kylene Hall
2005-02-04 20:52 ` Greg KH
2005-02-04 21:37 ` Kylene Hall
2005-02-04 21:51 ` Greg KH
2005-02-09 18:05 ` [PATCH 1/1] tpm: update tpm sysfs file ownership Kylene Hall
2005-02-09 18:17 ` Greg KH
2005-02-09 20:35 ` [tpmdd-devel] Re: [PATCH 1/1] tpm: update tpm sysfs file ownership - updated version Kylene Hall
2005-02-09 22:04 ` Chris Wright
2005-02-10 15:40 ` Kylene Hall
2005-02-01 8:28 ` [PATCH 1/1] tpm: fix cause of SMP stack traces -- " Greg KH
2004-12-19 19:48 ` [PATCH 1/1] driver: Tpm hardware enablement --updated version Pavel Machek
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=1102607309.2784.40.camel@laptop.fenrus.org \
--to=arjan@infradead.org \
--cc=emilyr@us.ibm.com \
--cc=greg@kroah.com \
--cc=kjhall@us.ibm.com \
--cc=leendert@watson.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sailer@watson.ibm.com \
--cc=toml@us.ibm.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
all inboxes | Powered by JetHome®