mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: minyard@acm.org
Cc: linux-kernel@vger.kernel.org, openipmi-developer@lists.sourceforge.net
Subject: Re: [PATCH 7/8] IPMI: convert locked counters to atomics
Date: Wed, 13 Feb 2008 15:26:45 -0800	[thread overview]
Message-ID: <20080213152645.9e589d0c.akpm@linux-foundation.org> (raw)
In-Reply-To: <20080213163220.GG9830@minyard.local>

On Wed, 13 Feb 2008 10:32:20 -0600
Corey Minyard <minyard@acm.org> wrote:

> From: Konstantin Baydarov <kbaidarov@ru.mvista.com>
> 
> Atomics are a lot more efficient and neat than using a lock.
>   

Yes, but...

> +struct ipmi_stats
> +{
> +	/* Commands we got that were invalid. */
> +	atomic_t sent_invalid_commands;
> +
> +	/* Commands we sent to the MC. */
> +	atomic_t sent_local_commands;
> +	/* Responses from the MC that were delivered to a user. */
> +	atomic_t handled_local_responses;
> +	/* Responses from the MC that were not delivered to a user. */
> +	atomic_t unhandled_local_responses;
> +
> +	/* Commands we sent out to the IPMB bus. */
> +	atomic_t sent_ipmb_commands;
> +	/* Commands sent on the IPMB that had errors on the SEND CMD */
> +	atomic_t sent_ipmb_command_errs;
> +	/* Each retransmit increments this count. */
> +	atomic_t retransmitted_ipmb_commands;
> +	/* When a message times out (runs out of retransmits) this is
> +           incremented. */
> +	atomic_t timed_out_ipmb_commands;
> +
> +	/* This is like above, but for broadcasts.  Broadcasts are
> +           *not* included in the above count (they are expected to
> +           time out). */
> +	atomic_t timed_out_ipmb_broadcasts;
> +
> +	/* Responses I have sent to the IPMB bus. */
> +	atomic_t sent_ipmb_responses;
> +
> +	/* The response was delivered to the user. */
> +	atomic_t handled_ipmb_responses;
> +	/* The response had invalid data in it. */
> +	atomic_t invalid_ipmb_responses;
> +	/* The response didn't have anyone waiting for it. */
> +	atomic_t unhandled_ipmb_responses;
> +
> +	/* Commands we sent out to the IPMB bus. */
> +	atomic_t sent_lan_commands;
> +	/* Commands sent on the IPMB that had errors on the SEND CMD */
> +	atomic_t sent_lan_command_errs;
> +	/* Each retransmit increments this count. */
> +	atomic_t retransmitted_lan_commands;
> +	/* When a message times out (runs out of retransmits) this is
> +           incremented. */
> +	atomic_t timed_out_lan_commands;
> +
> +	/* Responses I have sent to the IPMB bus. */
> +	atomic_t sent_lan_responses;
> +
> +	/* The response was delivered to the user. */
> +	atomic_t handled_lan_responses;
> +	/* The response had invalid data in it. */
> +	atomic_t invalid_lan_responses;
> +	/* The response didn't have anyone waiting for it. */
> +	atomic_t unhandled_lan_responses;
> +
> +	/* The command was delivered to the user. */
> +	atomic_t handled_commands;
> +	/* The command had invalid data in it. */
> +	atomic_t invalid_commands;
> +	/* The command didn't have anyone waiting for it. */
> +	atomic_t unhandled_commands;
> +
> +	/* Invalid data in an event. */
> +	atomic_t invalid_events;
> +	/* Events that were received with the proper format. */
> +	atomic_t events;
> +};

The code forgot to initialise all of these.

It just so happens that the all-bits-zero pattern works correctly for all
current architectures, so the code should work OK.  But there is no reason
(I hope) why an architecture cannot implement atomic_t as

struct atomic_t {
	int counter;
	spinlock_t lock;
};

in which case the results of ATOMIC_INIT() may _not_ be all-zeroes, in
which case the code will deadlock.

So.  It works, but it's grubby.   Do you still wish to proceed?

  reply	other threads:[~2008-02-13 23:27 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-13 16:32 Corey Minyard
2008-02-13 23:26 ` Andrew Morton [this message]
2008-02-14  0:19   ` Corey Minyard

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=20080213152645.9e589d0c.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=minyard@acm.org \
    --cc=openipmi-developer@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

Powered by JetHome