From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Leif Lindholm <leif.lindholm@linaro.org>
Cc: "edk2-devel@lists.01.org" <edk2-devel@lists.01.org>,
"Lee, Terry Ping-Chung" <terry.lee@hpe.com>
Subject: Re: [PATCH] ArmPlatformPkg/PlatformIntelBdsLib: don't clobber ConSplitter handle
Date: Fri, 3 Mar 2017 21:32:42 +0000 [thread overview]
Message-ID: <CAKv+Gu98Z4rN_oVoeDQDiASvCSxp3H8+Ffyxw5zUT5J83mMfyw@mail.gmail.com> (raw)
In-Reply-To: <20170303212316.GS16034@bivouac.eciton.net>
On 3 March 2017 at 21:23, Leif Lindholm <leif.lindholm@linaro.org> wrote:
> On Wed, Mar 01, 2017 at 06:34:33PM +0000, Ard Biesheuvel wrote:
>> The InitializeConsolePipe() routine takes care to only set its output
>> argument *Interface if it is not already set, to prevent overwriting
>> the ConSplitter interface pointer that may have already been assigned.
>>
>> However, the associated OUT argument 'Handle' is clobbered by the
>> subsequent unnecessary LocateDevicePath() invocation, which should
>> similarly be made dependent on whether *Interface has been set
>> already.
>>
>> Reported-by: "Lee, Terry Ping-Chung" <terry.lee@hpe.com>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>
> This looks good. I'll make one non-functional ecomment, and you can
> decide whether to incorporate it before pushing or not.
>
> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
>
>> ---
>>
>> Terry: does this work for you? Thanks.
>>
>> ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c | 25 ++++++++++----------
>> 1 file changed, 13 insertions(+), 12 deletions(-)
>>
>> diff --git a/ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c b/ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c
>> index 885866854329..f8e04efea63d 100644
>> --- a/ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c
>> +++ b/ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c
>> @@ -148,12 +148,19 @@ InitializeConsolePipe (
>>
>> Status = BdsLibConnectDevicePath (DevicePath);
>> if (!EFI_ERROR (Status)) {
>> - //
>> - // If BdsLibConnectDevicePath () succeeded, *Handle must have a non-NULL
>> - // value. So ASSERT that this is the case.
>> - //
>> - gBS->LocateDevicePath (&gEfiDevicePathProtocolGuid, &DevicePath, Handle);
>> - ASSERT (*Handle != NULL);
>> +
>> + // If the console splitter driver is not supported by the platform then
>> + // use the first Device Path instance for the console interface.
>
> I realise this comment is just being moved, but it's confusing. It
> refers to a state that is only visible if you're already aware of 2 or
> 3 facts not visible at this point.
>
> If I understand the situation correctly, the following would be a more
> helpful description:
>
> // If the console splitter driver is supported by the platform, then
> // *Interface is already initialized. If it is not, use the first
> // successfully connected device as the console.
>
Not entirely. The consplitter is one example of where multiple
consoles may be available, but it really applies to any situation
where multiple device paths are provided. So it is not that the
function is *entered* with *Interface non-null, but that any
additional iterations of the loop will clobber *Handle whereas
*Interface will only be set in the first iteration.
I will go ahead and apply this with a clarified comment.
next prev parent reply other threads:[~2017-03-03 21:32 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-01 18:34 [PATCH] ArmPlatformPkg/PlatformIntelBdsLib: don't clobber ConSplitter handle Ard Biesheuvel
2017-03-03 21:23 ` Leif Lindholm
2017-03-03 21:32 ` Ard Biesheuvel [this message]
2017-03-03 21:37 ` Ard Biesheuvel
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-list 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=CAKv+Gu98Z4rN_oVoeDQDiASvCSxp3H8+Ffyxw5zUT5J83mMfyw@mail.gmail.com \
--to=devel@edk2.groups.io \
/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