From: Leif Lindholm <leif.lindholm@linaro.org>
To: "Gao, Liming" <liming.gao@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>,
"Kinney, Michael D" <michael.d.kinney@intel.com>,
"edk2-devel@lists.01.org" <edk2-devel@lists.01.org>
Subject: Re: [patch] MdeModulePkg/DisplayEngine: Remove useless NULL ptr check for NewPos
Date: Fri, 9 Nov 2018 16:01:35 +0000 [thread overview]
Message-ID: <20181109160135.qvx5aznwr5mx2ten@bivouac.eciton.net> (raw)
In-Reply-To: <4A89E2EF3DFEDB4C8BFDE51014F606A14E3682A7@SHSMSX104.ccr.corp.intel.com>
On Fri, Nov 09, 2018 at 03:32:03PM +0000, Gao, Liming wrote:
> Laszlo and Leif:
> I suggest to continue to update wiki page with more
> information. If so, we can avoid such case again.
Agreed, we need to be able to interpret what the process says
identically.
> For this change, it has no real functionality impact.
But this is my point: we should not be making judgement calls this
late in the process. If I look at that patch, sure, it looks fine to
me. I still don't want it going in during freeze, because I don't
_know_ it has no real functionality impact. I may be missing
something. And even if I am not missing anything, the reshuffle may
still be sufficient to change compiler behaviour, exposing a
previously undetected bug.
> If you think roll back is better than keep it, I am OK.
That would be my preference. I have zero objection to it going back in
immediately after the stable tag is made.
Regards,
Leif
> Thanks
> Liming
> > -----Original Message-----
> > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Laszlo Ersek
> > Sent: Friday, November 9, 2018 7:02 PM
> > To: Leif Lindholm <leif.lindholm@linaro.org>; Gao, Liming <liming.gao@intel.com>
> > Cc: Kinney, Michael D <michael.d.kinney@intel.com>; edk2-devel@lists.01.org
> > Subject: Re: [edk2] [patch] MdeModulePkg/DisplayEngine: Remove useless NULL ptr check for NewPos
> >
> > On 11/09/18 11:49, Leif Lindholm wrote:
> > > On Fri, Nov 09, 2018 at 07:56:07AM +0100, Ard Biesheuvel wrote:
> > >> On 9 November 2018 at 01:19, Gao, Liming <liming.gao@intel.com> wrote:
> > >>> Ard:
> > >>> This is a small fix. And, this patch is sent before the hard
> > >>> freeze. It is the low risk for this release. So, I push it.
> > >>
> > >> OK, fair enough.
> > >
> > > I don't agree actually.
> > >
> > > https://github.com/tianocore/tianocore.github.io/wiki/HardFeatureFreeze
> > > specifies clearly that only bug fixes are permitted in during hard
> > > freeze. Maybe we could document that a bit more explicitly, but this
> > > patch was no bugfix. It should not have gone in.
> > >
> > > By my interpretation, it would not even fulfill the requirements for
> > > https://github.com/lersek/edk2/wiki/SoftFeatureFreeze:
> > > "By the date of the soft feature freeze, developers must have sent
> > > their patches to the mailing list and received positive maintainer
> > > reviews."
> > > Soft feature freeze was 1 November. The patch was sent out 7 November.
> > > It received reviews 8 November (after the start of the hard freeze).
> > >
> > > The point of these freezes is that sometimes patches are wrong. And
> > > sometimes patches that look correct, are not correct. If we start
> > > making exceptions because "oh, it's trivial", that means we get these
> > > patches into the tree with much reduced time for anyone to catch any
> > > adverse effects before we make the stable tag. And at that point, the
> > > stable tag no longer has value.
> > >
> > > (I am much more flexible on the topic of updating documentation, like
> > > Maintainers.txt, but even there we must be very careful.)
> >
> > I haven't been following this specific patch, but now it does not look
> > like a bugfix to me. Without applying the patch, there is no bug
> > actually, functional or performance. The subject says, "Remove useless ...".
> >
> > Optimizations, simplifications, refactorings, features, and so on, are
> > not bugfixes. They should not go in after the hard freeze. Even after
> > the soft freeze, they should only go in if the only remaining step is
> > the push (i.e. they should be ready for pushing before the soft freeze,
> > sufficiently reviewed.).
> >
> > Thanks
> > Laszlo
> >
> > >>>> -----Original Message-----
> > >>>> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
> > >>>> Sent: Friday, November 09, 2018 2:25 AM
> > >>>> To: Zeng, Star <star.zeng@intel.com>
> > >>>> Cc: Bi, Dandan <dandan.bi@intel.com>; edk2-devel@lists.01.org; Wu, Hao A
> > >>>> <hao.a.wu@intel.com>; Dong, Eric <eric.dong@intel.com>; Gao, Liming
> > >>>> <liming.gao@intel.com>
> > >>>> Subject: Re: [edk2] [patch] MdeModulePkg/DisplayEngine: Remove useless
> > >>>> NULL ptr check for NewPos
> > >>>>
> > >>>> On 8 November 2018 at 02:09, Zeng, Star <star.zeng@intel.com> wrote:
> > >>>>> Reviewed-by: Star Zeng <star.zeng@intel.com>
> > >>>>>
> > >>>>> -----Original Message-----
> > >>>>> From: Bi, Dandan
> > >>>>> Sent: Wednesday, November 7, 2018 10:53 PM
> > >>>>> To: edk2-devel@lists.01.org
> > >>>>> Cc: Gao, Liming <liming.gao@intel.com>; Dong, Eric <eric.dong@intel.com>;
> > >>>> Zeng, Star <star.zeng@intel.com>; Wu, Hao A <hao.a.wu@intel.com>
> > >>>>> Subject: [patch] MdeModulePkg/DisplayEngine: Remove useless NULL ptr
> > >>>> check for NewPos
> > >>>>>
> > >>>>> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1306
> > >>>>>
> > >>>>> In function UiDisplayMenu, the NewPos ptr which used to point to the
> > >>>> highlight menu entry. It will always point to the menu entry which need to be
> > >>>> highlighted or the gMenuOption menu if the highlight menu is not found.
> > >>>>> So we can remove the NULL ptr check for NewPos in this function.
> > >>>>> And add the ASSERT code to avoid if any false positive reports of NULL
> > >>>> pointer dereference issue raised from static analysis.
> > >>>>>
> > >>>>> Cc: Liming Gao <liming.gao@intel.com>
> > >>>>> Cc: Eric Dong <eric.dong@intel.com>
> > >>>>> Cc: Star Zeng <star.zeng@intel.com>
> > >>>>> Cc: Hao Wu <hao.a.wu@intel.com>
> > >>>>> Contributed-under: TianoCore Contribution Agreement 1.1
> > >>>>> Signed-off-by: Dandan Bi <dandan.bi@intel.com>
> > >>>>
> > >>>> Why was this patch merged today? Surely, this doesn't meet the hard
> > >>>> freeze requirements ?
> > >>>>
> > >>>>> ---
> > >>>>> MdeModulePkg/Universal/DisplayEngineDxe/FormDisplay.c | 3 ++-
> > >>>>> 1 file changed, 2 insertions(+), 1 deletion(-)
> > >>>>>
> > >>>>> diff --git a/MdeModulePkg/Universal/DisplayEngineDxe/FormDisplay.c
> > >>>> b/MdeModulePkg/Universal/DisplayEngineDxe/FormDisplay.c
> > >>>>> index 7390f954b6..44f087fe01 100644
> > >>>>> --- a/MdeModulePkg/Universal/DisplayEngineDxe/FormDisplay.c
> > >>>>> +++ b/MdeModulePkg/Universal/DisplayEngineDxe/FormDisplay.c
> > >>>>> @@ -2880,10 +2880,11 @@ UiDisplayMenu (
> > >>>>> // MenuOption is set to NULL in Repaint
> > >>>>> // NewPos: Current menu option that need to hilight
> > >>>>> //
> > >>>>> ControlFlag = CfUpdateHelpString;
> > >>>>>
> > >>>>> + ASSERT (NewPos != NULL);
> > >>>>> UpdateHighlightMenuInfo(NewPos, TopOfScreen, SkipValue);
> > >>>>>
> > >>>>> if (SkipHighLight) {
> > >>>>> SkipHighLight = FALSE;
> > >>>>> MenuOption = SavedMenuOption;
> > >>>>> @@ -2908,11 +2909,11 @@ UiDisplayMenu (
> > >>>>> Temp2 = SkipValue;
> > >>>>> } else {
> > >>>>> Temp2 = 0;
> > >>>>> }
> > >>>>>
> > >>>>> - if (NewPos != NULL && (MenuOption == NULL || NewPos !=
> > >>>> &MenuOption->Link)) {
> > >>>>> + if (MenuOption == NULL || NewPos != &MenuOption->Link) {
> > >>>>> if (MenuOption != NULL) {
> > >>>>> //
> > >>>>> // Remove the old highlight menu.
> > >>>>> //
> > >>>>> Status = DisplayOneMenu (MenuOption,
> > >>>>> --
> > >>>>> 2.18.0.windows.1
> > >>>>>
> > >>>>> _______________________________________________
> > >>>>> edk2-devel mailing list
> > >>>>> edk2-devel@lists.01.org
> > >>>>> https://lists.01.org/mailman/listinfo/edk2-devel
> > >> _______________________________________________
> > >> edk2-devel mailing list
> > >> edk2-devel@lists.01.org
> > >> https://lists.01.org/mailman/listinfo/edk2-devel
> >
> > _______________________________________________
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
next prev parent reply other threads:[~2018-11-09 16:01 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-07 14:53 [patch] MdeModulePkg/DisplayEngine: Remove useless NULL ptr check for NewPos Dandan Bi
2018-11-08 0:27 ` Gao, Liming
2018-11-08 1:09 ` Zeng, Star
2018-11-08 18:25 ` Ard Biesheuvel
2018-11-09 0:19 ` Gao, Liming
2018-11-09 6:56 ` Ard Biesheuvel
2018-11-09 10:49 ` Leif Lindholm
2018-11-09 11:01 ` Laszlo Ersek
2018-11-09 15:32 ` Gao, Liming
2018-11-09 16:01 ` Leif Lindholm [this message]
2018-11-09 16:33 ` Laszlo Ersek
2018-11-09 17:14 ` Kinney, Michael D
2018-11-09 17:24 ` Laszlo Ersek
2018-11-09 17:49 ` Kinney, Michael D
2018-11-09 20:07 ` Laszlo Ersek
2018-11-12 15:27 ` stephano
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=20181109160135.qvx5aznwr5mx2ten@bivouac.eciton.net \
--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