public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* Sleep during spinlock in TPM driver
@ 2007-04-20 22:11 David Kyle
  2007-04-21 22:50 ` Andrew Morton
  0 siblings, 1 reply; 8+ messages in thread
From: David Kyle @ 2007-04-20 22:11 UTC (permalink / raw)
  To: linux-kernel

I've been working with the TPM driver, and I found that if I opened,
used, then closed the TPM char device very frequently, I would get a
kernel BUG message saying that the kernel tried to sleep while holding
a spinlock.  I think I've isolated the problem to this function, in
drivers/char/tpm/tpm.c:

int tpm_release(struct inode *inode, struct file *file)
{
        struct tpm_chip *chip = file->private_data;
        spin_lock(&driver_lock);
        file->private_data = NULL;
        chip->num_opens--;
        del_singleshot_timer_sync(&chip->user_read_timer);
        flush_scheduled_work();
        atomic_set(&chip->data_pending, 0);
        put_device(chip->dev);
        kfree(chip->data_buffer);
        spin_unlock(&driver_lock);
        return 0;
}
EXPORT_SYMBOL_GPL(tpm_release);

I believe that flush_scheduled_work can sleep, correct?  Does anyone
know why this function is called while the spinlock is held?

-David

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Sleep during spinlock in TPM driver
  2007-04-20 22:11 David Kyle
@ 2007-04-21 22:50 ` Andrew Morton
  0 siblings, 0 replies; 8+ messages in thread
From: Andrew Morton @ 2007-04-21 22:50 UTC (permalink / raw)
  To: David Kyle; +Cc: linux-kernel, Kylene Jo Hall, tpm, tpmdd-devel

On Fri, 20 Apr 2007 18:11:10 -0400 "David Kyle" <dsk6@pitt.edu> wrote:

> I've been working with the TPM driver, and I found that if I opened,
> used, then closed the TPM char device very frequently, I would get a
> kernel BUG message saying that the kernel tried to sleep while holding
> a spinlock.  I think I've isolated the problem to this function, in
> drivers/char/tpm/tpm.c:
> 
> int tpm_release(struct inode *inode, struct file *file)
> {
>         struct tpm_chip *chip = file->private_data;
>         spin_lock(&driver_lock);
>         file->private_data = NULL;
>         chip->num_opens--;
>         del_singleshot_timer_sync(&chip->user_read_timer);
>         flush_scheduled_work();
>         atomic_set(&chip->data_pending, 0);
>         put_device(chip->dev);
>         kfree(chip->data_buffer);
>         spin_unlock(&driver_lock);
>         return 0;
> }
> EXPORT_SYMBOL_GPL(tpm_release);
> 
> I believe that flush_scheduled_work can sleep, correct?  Does anyone
> know why this function is called while the spinlock is held?
> 

yup, that's a bug.  It's not immediately clear to e what driver_lock is
protecting.  Some global things, some per-device things, it appears.

A suitable fix might be to make driver_lock a mutex.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Sleep during spinlock in TPM driver
@ 2007-04-22 19:06 Parag Warudkar
  2007-04-23  7:42 ` Jiri Kosina
  0 siblings, 1 reply; 8+ messages in thread
From: Parag Warudkar @ 2007-04-22 19:06 UTC (permalink / raw)
  To: akpm; +Cc: dsk6, linux-kernel

Andrew Morton <akpm <at> linux-foundation.org> writes:

>
> On Fri, 20 Apr 2007 18:11:10 -0400 "David Kyle" <dsk6 <at> pitt.edu> 
wrote:
>
> > int tpm_release(struct inode *inode, struct file *file)
> > {
> >         struct tpm_chip *chip = file->private_data;
> >         spin_lock(&driver_lock);
> >         file->private_data = NULL;
> >         chip->num_opens--;
> >         del_singleshot_timer_sync(&chip->user_read_timer);
> >         flush_scheduled_work();
> >         atomic_set(&chip->data_pending, 0);
> >         put_device(chip->dev);
> >         kfree(chip->data_buffer);
> >         spin_unlock(&driver_lock);
> >         return 0;
> > }
> > EXPORT_SYMBOL_GPL(tpm_release);
> >
> > I believe that flush_scheduled_work can sleep, correct?  Does anyone
> > know why this function is called while the spinlock is held?
> >
>
> yup, that's a bug.  It's not immediately clear to e what driver_lock is
> protecting.  Some global things, some per-device things, it appears.
>
> A suitable fix might be to make driver_lock a mutex.
>

AFAICS, moving flush_scheduled_work before spin_lock() should 
not cause any problems.

Reason being - The only thing that can race against tpm_release is 
tpm_open (tpm_release is called when last reference to the file is closed 
and only thing that can happen after that is tpm_open??) and tpm_open 
acquires driver_lock and more over it bails out with EBUSY if 
chip->num_opens is greater than 0.

I also moved chip->num_pending-- to after deleting timer and setting data 
pending as it looks more correct for the paranoid although it probably 
doesn't matter as it is guarded by driver_lock. None the less this change 
should not cause problems.

While I was at it I noticed a missing NULL check in tpm_register_hardware 
which is fixed with this patch as well.

David - could you please try the below patch and see if it works? Thanks.

Signed-off-by: Parag Warudkar <parag.warudkar@gmail.com>

--- linux-2.6-us/drivers/char/tpm/tpm.c	2007-04-21 14:55:03.134975360 -0400
+++ linux-2.6-wk/drivers/char/tpm/tpm.c	2007-04-22 14:58:51.957999963 -0400
@@ -942,12 +942,12 @@
   {
   	struct tpm_chip *chip = file->private_data;

+	flush_scheduled_work();
   	spin_lock(&driver_lock);
   	file->private_data = NULL;
-	chip->num_opens--;
   	del_singleshot_timer_sync(&chip->user_read_timer);
-	flush_scheduled_work();
   	atomic_set(&chip->data_pending, 0);
+	chip->num_opens--;
   	put_device(chip->dev);
   	kfree(chip->data_buffer);
   	spin_unlock(&driver_lock);
@@ -1097,8 +1097,13 @@

   	/* Driver specific per-device data */
   	chip = kzalloc(sizeof(*chip), GFP_KERNEL);
-	if (chip == NULL)
+	devname = kmalloc(DEVNAME_SIZE, GFP_KERNEL);
+ 
+	if (chip == NULL || devname == NULL) {
+		kfree(chip);
+		kfree(devname);
   		return NULL;
+	}

   	init_MUTEX(&chip->buffer_mutex);
   	init_MUTEX(&chip->tpm_mutex);
@@ -1124,7 +1129,6 @@

   	set_bit(chip->dev_num, dev_mask);

-	devname = kmalloc(DEVNAME_SIZE, GFP_KERNEL);
   	scnprintf(devname, DEVNAME_SIZE, "%s%d", "tpm", chip->dev_num);
   	chip->vendor.miscdev.name = devname;


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Sleep during spinlock in TPM driver
  2007-04-22 19:06 Sleep during spinlock in TPM driver Parag Warudkar
@ 2007-04-23  7:42 ` Jiri Kosina
  2007-04-23 12:04   ` Parag Warudkar
  0 siblings, 1 reply; 8+ messages in thread
From: Jiri Kosina @ 2007-04-23  7:42 UTC (permalink / raw)
  To: pwarudkar; +Cc: Andrew Morton, dsk6, linux-kernel

On Sun, 22 Apr 2007, Parag Warudkar wrote:

> @@ -1097,8 +1097,13 @@
> 
>   	/* Driver specific per-device data */
>   	chip = kzalloc(sizeof(*chip), GFP_KERNEL);
> -	if (chip == NULL)
> +	devname = kmalloc(DEVNAME_SIZE, GFP_KERNEL);
> + +	if (chip == NULL || devname == NULL) {

Hi,

this line looks bogus to me.

-- 
Jiri Kosina

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Sleep during spinlock in TPM driver
  2007-04-23  7:42 ` Jiri Kosina
@ 2007-04-23 12:04   ` Parag Warudkar
  2007-04-23 12:14     ` Parag Warudkar
  2007-04-23 12:42     ` Jiri Slaby
  0 siblings, 2 replies; 8+ messages in thread
From: Parag Warudkar @ 2007-04-23 12:04 UTC (permalink / raw)
  To: Jiri Kosina; +Cc: Andrew Morton, dsk6, pwarudkar, linux-kernel



On Mon, 23 Apr 2007, Jiri Kosina wrote:

> On Sun, 22 Apr 2007, Parag Warudkar wrote:
>
>> @@ -1097,8 +1097,13 @@
>>
>>       /* Driver specific per-device data */
>>       chip = kzalloc(sizeof(*chip), GFP_KERNEL);
>> - if (chip == NULL)
>> + devname = kmalloc(DEVNAME_SIZE, GFP_KERNEL);
>> + +   if (chip == NULL || devname == NULL) {
>
> Hi,
>
> this line looks bogus to me.
>

Hi - Yep, thanks for catching. Really not sure how that extra + got in 
there - I diffed the exact same file this morning and it isn't there - new 
diff attached.

--- linux-2.6-us/drivers/char/tpm/tpm.c	2007-04-21 14:55:03.134975360 -0400
+++ linux-2.6-wk/drivers/char/tpm/tpm.c	2007-04-22 14:58:51.957999963 -0400
@@ -942,12 +942,12 @@
  {
  	struct tpm_chip *chip = file->private_data;

+	flush_scheduled_work();
  	spin_lock(&driver_lock);
  	file->private_data = NULL;
-	chip->num_opens--;
  	del_singleshot_timer_sync(&chip->user_read_timer);
-	flush_scheduled_work();
  	atomic_set(&chip->data_pending, 0);
+	chip->num_opens--;
  	put_device(chip->dev);
  	kfree(chip->data_buffer);
  	spin_unlock(&driver_lock);
@@ -1097,8 +1097,13 @@

  	/* Driver specific per-device data */
  	chip = kzalloc(sizeof(*chip), GFP_KERNEL);
-	if (chip == NULL)
+	devname = kmalloc(DEVNAME_SIZE, GFP_KERNEL);
+ 
+	if (chip == NULL || devname == NULL) {
+		kfree(chip);
+		kfree(devname);
  		return NULL;
+	}

  	init_MUTEX(&chip->buffer_mutex);
  	init_MUTEX(&chip->tpm_mutex);
@@ -1124,7 +1129,6 @@

  	set_bit(chip->dev_num, dev_mask);

-	devname = kmalloc(DEVNAME_SIZE, GFP_KERNEL);
  	scnprintf(devname, DEVNAME_SIZE, "%s%d", "tpm", chip->dev_num);
  	chip->vendor.miscdev.name = devname;


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Sleep during spinlock in TPM driver
  2007-04-23 12:04   ` Parag Warudkar
@ 2007-04-23 12:14     ` Parag Warudkar
  2007-04-26  1:33       ` Andrew Morton
  2007-04-23 12:42     ` Jiri Slaby
  1 sibling, 1 reply; 8+ messages in thread
From: Parag Warudkar @ 2007-04-23 12:14 UTC (permalink / raw)
  To: pwarudkar; +Cc: Jiri Kosina, Andrew Morton, dsk6, linux-kernel

[-- Attachment #1: Type: TEXT/PLAIN, Size: 274 bytes --]


Grrrr.. My email client was at it again. Sorry it messed up with the 
additonal + again.

Do not use Alpine - This is the first email client (alphas and betas 
included) which is buggy enough to change what you write!

Not taking chances this time - patch attached.

Parag

[-- Attachment #2: Type: TEXT/x-diff, Size: 1149 bytes --]

--- linux-2.6-us/drivers/char/tpm/tpm.c	2007-04-21 14:55:03.134975360 -0400
+++ linux-2.6-wk/drivers/char/tpm/tpm.c	2007-04-22 14:58:51.957999963 -0400
@@ -942,12 +942,12 @@
 {
 	struct tpm_chip *chip = file->private_data;
 
+	flush_scheduled_work();
 	spin_lock(&driver_lock);
 	file->private_data = NULL;
-	chip->num_opens--;
 	del_singleshot_timer_sync(&chip->user_read_timer);
-	flush_scheduled_work();
 	atomic_set(&chip->data_pending, 0);
+	chip->num_opens--;
 	put_device(chip->dev);
 	kfree(chip->data_buffer);
 	spin_unlock(&driver_lock);
@@ -1097,8 +1097,13 @@
 
 	/* Driver specific per-device data */
 	chip = kzalloc(sizeof(*chip), GFP_KERNEL);
-	if (chip == NULL)
+	devname = kmalloc(DEVNAME_SIZE, GFP_KERNEL);
+	
+	if (chip == NULL || devname == NULL) {
+		kfree(chip);
+		kfree(devname);
 		return NULL;
+	}
 
 	init_MUTEX(&chip->buffer_mutex);
 	init_MUTEX(&chip->tpm_mutex);
@@ -1124,7 +1129,6 @@
 
 	set_bit(chip->dev_num, dev_mask);
 
-	devname = kmalloc(DEVNAME_SIZE, GFP_KERNEL);
 	scnprintf(devname, DEVNAME_SIZE, "%s%d", "tpm", chip->dev_num);
 	chip->vendor.miscdev.name = devname;
 

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Sleep during spinlock in TPM driver
  2007-04-23 12:04   ` Parag Warudkar
  2007-04-23 12:14     ` Parag Warudkar
@ 2007-04-23 12:42     ` Jiri Slaby
  1 sibling, 0 replies; 8+ messages in thread
From: Jiri Slaby @ 2007-04-23 12:42 UTC (permalink / raw)
  To: pwarudkar; +Cc: Jiri Kosina, Andrew Morton, dsk6, linux-kernel

Parag Warudkar napsal(a):
> On Mon, 23 Apr 2007, Jiri Kosina wrote:
> 
>> On Sun, 22 Apr 2007, Parag Warudkar wrote:
>>
>>> @@ -1097,8 +1097,13 @@
>>>
>>>       /* Driver specific per-device data */
>>>       chip = kzalloc(sizeof(*chip), GFP_KERNEL);
>>> - if (chip == NULL)
>>> + devname = kmalloc(DEVNAME_SIZE, GFP_KERNEL);
>>> + +   if (chip == NULL || devname == NULL) {
>>
>> Hi,
>>
>> this line looks bogus to me.
>>
> 
> Hi - Yep, thanks for catching. Really not sure how that extra + got in
> there - I diffed the exact same file this morning and it isn't there -
> new diff attached.
[...]
> @@ -1097,8 +1097,13 @@
> 
>      /* Driver specific per-device data */
>      chip = kzalloc(sizeof(*chip), GFP_KERNEL);
> -    if (chip == NULL)
> +    devname = kmalloc(DEVNAME_SIZE, GFP_KERNEL);
> + +    if (chip == NULL || devname == NULL) {

I see this here too, but there is no extra '+' here:
http://lkml.org/lkml/2007/4/22/172 and here
http://lkml.org/lkml/2007/4/23/125
not even in the source of this message, weird... (using thunderbird 2.0rc1)

regards,
-- 
http://www.fi.muni.cz/~xslaby/            Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Sleep during spinlock in TPM driver
  2007-04-23 12:14     ` Parag Warudkar
@ 2007-04-26  1:33       ` Andrew Morton
  0 siblings, 0 replies; 8+ messages in thread
From: Andrew Morton @ 2007-04-26  1:33 UTC (permalink / raw)
  To: pwarudkar; +Cc: Jiri Kosina, dsk6, linux-kernel

On Mon, 23 Apr 2007 08:14:03 -0400 (EDT) Parag Warudkar <pwarudkar@aol.com> wrote:

> --- linux-2.6-us/drivers/char/tpm/tpm.c	2007-04-21 14:55:03.134975360 -0400
> +++ linux-2.6-wk/drivers/char/tpm/tpm.c	2007-04-22 14:58:51.957999963 -0400
> @@ -942,12 +942,12 @@
>  {
>  	struct tpm_chip *chip = file->private_data;
>  
> +	flush_scheduled_work();
>  	spin_lock(&driver_lock);
>  	file->private_data = NULL;
> -	chip->num_opens--;
>  	del_singleshot_timer_sync(&chip->user_read_timer);
> -	flush_scheduled_work();
>  	atomic_set(&chip->data_pending, 0);

btw, this driver has a timer handler which does:

static void user_reader_timeout(unsigned long ptr)
{
        struct tpm_chip *chip = (struct tpm_chip *) ptr;

        schedule_work(&chip->work);
}

which appears to duplicate schedule_delayed_work()'s functionality.

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2007-04-26  1:34 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-04-22 19:06 Sleep during spinlock in TPM driver Parag Warudkar
2007-04-23  7:42 ` Jiri Kosina
2007-04-23 12:04   ` Parag Warudkar
2007-04-23 12:14     ` Parag Warudkar
2007-04-26  1:33       ` Andrew Morton
2007-04-23 12:42     ` Jiri Slaby
  -- strict thread matches above, loose matches on Subject: below --
2007-04-20 22:11 David Kyle
2007-04-21 22:50 ` Andrew Morton

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox