From: Artur Paszkiewicz <artur.paszkiewicz@intel.com>
To: Jes Sorensen <Jes.Sorensen@redhat.com>
Cc: neilb@suse.de, 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 17:32:31 +0100 [thread overview]
Message-ID: <54EDF91F.40200@intel.com> (raw)
In-Reply-To: <wrfjvbiq2mzo.fsf@redhat.com>
On 02/25/2015 01:29 PM, Jes Sorensen wrote:
> Artur Paszkiewicz <artur.paszkiewicz@intel.com> writes:
>> 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,
>
> Then the code is fundamentally broken, since you end up comparing a
> stack variable against the oroms array when you call it from
> find_imsm_efi(). Worse you can end up returning the local stack variable
> declared in find_imsm_efi() to the calling function - there is no way
> that can be correct.
>
> Look at this:
>
> 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 (oroms[i].orom.signature[0] == 0) {
> oroms[i].orom = *orom;
> return &oroms[i].orom;
> }
> }
> return NULL;
> }
>
> const struct imsm_orom *find_imsm_efi(struct sys_dev *hba)
> {
> struct imsm_orom orom;
> const struct imsm_orom *ret;
> int err;
>
> ....
>
> ret = add_orom(&orom);
> add_orom_device_id(ret, hba->dev_id);
>
> return ret;
> }
I can't see how this can lead to returning a stack variable. The oroms
array is global and add_orom() will always return a pointer to a struct
in this array. This comparison will always fail when we pass a pointer
to a stack variable to add_orom():
if (&oroms[i].orom == orom)
return orom;
This was meant to prevent adding an orom again like this:
ret = add_orom(&orom);
add_orom(ret);
Maybe it would be more appropriate to return NULL to indicate that
nothing was added instead of returning back the same pointer. I can do a
patch for this. What do you think?
Regards,
Artur
next prev parent reply other threads:[~2015-02-25 16:32 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
2015-02-25 12:29 ` Jes Sorensen
2015-02-25 16:32 ` Artur Paszkiewicz [this message]
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=54EDF91F.40200@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).