All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rajiv Andrade <srajiv@linux.vnet.ibm.com>
To: "Serge E. Hallyn" <serue@us.ibm.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	linux-kernel@vger.kernel.org, zohar@us.ibm.com,
	dvelarde@us.ibm.com, safford@us.ibm.com
Subject: Re: [PATCH][resubmit] TPM: update char dev BKL pushdown
Date: Wed, 27 Aug 2008 11:32:15 -0300	[thread overview]
Message-ID: <1219847535.4768.18.camel@blackbox> (raw)
In-Reply-To: <20080827031948.GA5184@us.ibm.com>

It was all about this section:

>       chip->data_buffer = kmalloc(TPM_BUFSIZE * sizeof(u8),
GFP_KERNEL);
>       if (chip->data_buffer == NULL) {
> -             chip->num_opens--;
> +             atomic_set(&chip->is_open, 0);
>               put_device(chip->dev);

num_opens wasn't protected by driver_lock, so we made num_opens/is_open
atomic_t. But an int seems too much for just a flag (as Serge pointed),
and the code would be cleaner if we make only this line atomic, by using
test_and_set_bit(). Thanks Alan.
I'll rewrite it.

Rajiv


On Tue, 2008-08-26 at 22:19 -0500, Serge E. Hallyn wrote:
> Quoting Alan Cox (alan@lxorguk.ukuu.org.uk):
> > > +	atomic_set(&chip->is_open, 1);
> > > +	get_device(chip->dev); /* protect from chip disappearing */
> > 
> > Why not just use test_and_set_bit() ? You seem to be abusing atomic_t to
> > achieve this.
> 
> Good point.  Or heck just make it a simple flag.  Earlier I thought there
> was a place where driver_lock was taken just to do num_opens--, and so
> replacing the int num_opens with an atomic_t seemed worthwhile.  But since
> is_open is a boolean and now seems to be always protected by driver_lock,
> a flag seems best.
> 
> -serge
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


  reply	other threads:[~2008-08-27 14:37 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-26 20:56 [PATCH][resubmit] TPM: update char dev BKL pushdown Rajiv Andrade
2008-08-26 21:08 ` Alan Cox
2008-08-27  3:19   ` Serge E. Hallyn
2008-08-27 14:32     ` Rajiv Andrade [this message]
2008-08-26 21:29 ` Serge E. Hallyn

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=1219847535.4768.18.camel@blackbox \
    --to=srajiv@linux.vnet.ibm.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=dvelarde@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=safford@us.ibm.com \
    --cc=serue@us.ibm.com \
    --cc=zohar@us.ibm.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.