From: Artur Paszkiewicz <artur.paszkiewicz@intel.com>
To: Jes.Sorensen@redhat.com, neilb@suse.de
Cc: linux-raid@vger.kernel.org
Subject: Re: [PATCH 3/5] add_orom(): Compare content of struct imsm_orom rather than pointers to it
Date: Wed, 25 Feb 2015 11:51:10 +0100 [thread overview]
Message-ID: <54EDA91E.5050005@intel.com> (raw)
In-Reply-To: <1424811640-26569-4-git-send-email-Jes.Sorensen@redhat.com>
On 02/24/2015 10:00 PM, Jes.Sorensen@redhat.com wrote:
> From: Jes Sorensen <Jes.Sorensen@redhat.com>
>
> This avoids adding the same orom entry to the oroms list multiple
> times, as the comparison of pointers is never going to succeed, in
> particular when '*orom' points to a local stack variable in the
> calling function.
>
> Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
> ---
> platform-intel.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/platform-intel.c b/platform-intel.c
> index 37274da..a4ffa9f 100644
> --- a/platform-intel.c
> +++ b/platform-intel.c
> @@ -255,8 +255,8 @@ static const struct imsm_orom *add_orom(const struct imsm_orom *orom)
> int i;
>
> for (i = 0; i < SYS_DEV_MAX; i++) {
> - if (&oroms[i].orom == orom)
> - return orom;
> + if (!memcmp(&oroms[i].orom, orom, sizeof(struct imsm_orom)))
> + return &oroms[i].orom;
> if (oroms[i].orom.signature[0] == 0) {
> oroms[i].orom = *orom;
> return &oroms[i].orom;
>
Hi Jes,
You are right that this can add the same entry multiple times, but this
is how it is supposed to work. The oroms list should contain all the
platform's oroms and they can be the same, this is why memcmp() should
not be used here. We don't want to compare the contents of the
structure, just its address. Sorry if it's not clear.
Artur
next prev parent reply other threads:[~2015-02-25 10:51 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-24 21:00 [PATCH 0/5] Fix issues reported by covscan and newer GCC Jes.Sorensen
2015-02-24 21:00 ` [PATCH 1/5] Grow.c: Fix classic readlink() buffer overflow Jes.Sorensen
2015-02-24 21:00 ` [PATCH 2/5] Check return of stat() to avoid covscan complaining Jes.Sorensen
2015-02-24 21:12 ` NeilBrown
2015-02-24 21:56 ` Jes Sorensen
2015-02-24 22:03 ` NeilBrown
2015-02-25 0:13 ` Jes Sorensen
2015-02-24 21:00 ` [PATCH 3/5] add_orom(): Compare content of struct imsm_orom rather than pointers to it Jes.Sorensen
2015-02-25 10:51 ` Artur Paszkiewicz [this message]
2015-02-25 12:29 ` Jes Sorensen
2015-02-25 16:32 ` Artur Paszkiewicz
2015-02-25 17:15 ` Jes Sorensen
2015-02-27 13:39 ` Artur Paszkiewicz
2015-02-27 20:51 ` Jes Sorensen
2015-03-04 4:58 ` NeilBrown
2015-02-24 21:00 ` [PATCH 4/5] IncrementalScan(): Make sure 'st' is valid before dereferencing it Jes.Sorensen
2015-02-25 15:00 ` John Stoffel
2015-02-25 15:37 ` Jes Sorensen
2015-02-25 15:42 ` John Stoffel
2015-02-24 21:00 ` [PATCH 5/5] write_super_imsm_spares(): C statements are terminated by ; Jes.Sorensen
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=54EDA91E.5050005@intel.com \
--to=artur.paszkiewicz@intel.com \
--cc=Jes.Sorensen@redhat.com \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@suse.de \
/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;
as well as URLs for NNTP newsgroup(s).