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/
next prev parent 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.