public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Wang, Sunny (HPS SW)" <sunnywang@hpe.com>
To: Guo Heyi <heyi.guo@linaro.org>
Cc: "edk2-devel@lists.01.org" <edk2-devel@lists.01.org>,
	Ruiyu Ni <ruiyu.ni@intel.com>, Eric Dong <eric.dong@intel.com>,
	Star Zeng <star.zeng@intel.com>,
	"Wang, Sunny (HPS SW)" <sunnywang@hpe.com>
Subject: Re: [PATCH 1/1] MdeModulePkg/UefiBootManagerLib: limit recursive call depth
Date: Tue, 27 Feb 2018 02:47:19 +0000	[thread overview]
Message-ID: <DF4PR8401MB065078DED97329B9C8FBAAE5A8C00@DF4PR8401MB0650.NAMPRD84.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <20180226113427.GA113703@SZX1000114654>

Hi Heyi, 
Thanks for looking into my suggestion. You already mentioned the value I thought. :) The value is to get better boot performance by setting the MAX_RECONNECT_REPAIR to a smaller number. 10 times reconnect may be suitable for consumer products like laptop. However, it may be not suitable for server. For example, user installs a problematic NIC 4-port card and its OPROM produced 4 driver handles to manage 4 ports. For this case, 10 times reconnect may take much longer time.  
If you think it's still not worth adding a PCD for this or have other concern about adding a PCD, I'm fine with dropping this suggestion.   

Regards,
Sunny Wang

-----Original Message-----
From: Guo Heyi [mailto:heyi.guo@linaro.org] 
Sent: Monday, February 26, 2018 7:34 PM
To: Wang, Sunny (HPS SW) <sunnywang@hpe.com>
Cc: Heyi Guo <heyi.guo@linaro.org>; edk2-devel@lists.01.org; Ruiyu Ni <ruiyu.ni@intel.com>; Eric Dong <eric.dong@intel.com>; Star Zeng <star.zeng@intel.com>
Subject: Re: [edk2] [PATCH 1/1] MdeModulePkg/UefiBootManagerLib: limit recursive call depth
Importance: High

Hi Sunny,

I didn't consider it as a value necessary for platform override, for the retry count should only have some impact on boot performance and it only happens when there is something wrong.

May I know what value you will use for your platform and why?

Thanks and regards,

Gary (Heyi Guo)

On Mon, Feb 26, 2018 at 08:56:50AM +0000, Wang, Sunny (HPS SW) wrote:
> Hi Heyi,
> Just a suggestion. 
> Is it better to use a PCD instead of a define for MAX_RECONNECT_REPAIR? So that we can easily override it in our platform dsc file.
> 
> Regards,
> Sunny Wang
> 
> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of 
> Heyi Guo
> Sent: Monday, February 26, 2018 4:30 PM
> To: edk2-devel@lists.01.org
> Cc: Ruiyu Ni <ruiyu.ni@intel.com>; Heyi Guo <heyi.guo@linaro.org>; 
> Eric Dong <eric.dong@intel.com>; Star Zeng <star.zeng@intel.com>
> Subject: [edk2] [PATCH 1/1] MdeModulePkg/UefiBootManagerLib: limit 
> recursive call depth
> 
> Function BmRepairAllControllers may recursively call itself if some driver health protocol returns EfiDriverHealthStatusReconnectRequired.
> However, driver health protocol of some buggy third party driver may always return such status even after one and another reconnect. The endless iteration will cause stack overflow and then system exception, and it may be not easy to find that the exception is actually caused by stack overflow.
> 
> So we limit the number of reconnect retry to 10 to improve code robustness.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Heyi Guo <heyi.guo@linaro.org>
> Cc: Star Zeng <star.zeng@intel.com>
> Cc: Eric Dong <eric.dong@intel.com>
> Cc: Ruiyu Ni <ruiyu.ni@intel.com>
> ---
>  MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h     |  6 ++++++
>  MdeModulePkg/Library/UefiBootManagerLib/BmDriverHealth.c | 17 
> ++++++++++++++++-
>  2 files changed, 22 insertions(+), 1 deletion(-)
> 
> diff --git a/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h 
> b/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h
> index 25a1d522fe84..9aa86b096525 100644
> --- a/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h
> +++ b/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h
> @@ -108,6 +108,12 @@ CHAR16 *
>  #define BM_OPTION_NAME_LEN                          sizeof ("PlatformRecovery####")
>  extern CHAR16  *mBmLoadOptionName[];
>  
> +//
> +// Maximum number of reconnect retry to repair controller; it is to 
> +limit the // number of recursive call of BmRepairAllControllers.
> +//
> +#define MAX_RECONNECT_REPAIR                        10
> +
>  /**
>    Visitor function to be called by BmForEachVariable for each variable
>    in variable storage.
> diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmDriverHealth.c 
> b/MdeModulePkg/Library/UefiBootManagerLib/BmDriverHealth.c
> index ddcee8b0676f..30d70f32af84 100644
> --- a/MdeModulePkg/Library/UefiBootManagerLib/BmDriverHealth.c
> +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmDriverHealth.c
> @@ -26,6 +26,12 @@ GLOBAL_REMOVE_IF_UNREFERENCED
>      L"Reboot Required"
>      };
>  
> +//
> +// Counter of reconnect retry to repair controller; it is to limit 
> +the // number of recursive call of BmRepairAllControllers.
> +//
> +STATIC UINTN mReconnectRepairCount;
> +
>  /**
>    Return the controller name.
>  
> @@ -549,7 +555,16 @@ BmRepairAllControllers (
>  
>  
>    if (ReconnectRequired) {
> -    BmRepairAllControllers ();
> +    if (mReconnectRepairCount < MAX_RECONNECT_REPAIR) {
> +      mReconnectRepairCount++;
> +      BmRepairAllControllers ();
> +    } else {
> +      DEBUG ((DEBUG_ERROR, "[%a:%d] Repair failed after %d retries.\n",
> +        __FUNCTION__, __LINE__, mReconnectRepairCount));
> +      // Reset counter so that it will not affect calling
> +      // BmRepairAllControllers() somewhere else
> +      mReconnectRepairCount = 0;
> +    }
>    }
>  
>    DEBUG_CODE (
> --
> 2.7.4
> 
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel


  reply	other threads:[~2018-02-27  2:41 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-26  8:29 [PATCH 1/1] MdeModulePkg/UefiBootManagerLib: limit recursive call depth Heyi Guo
2018-02-26  8:56 ` Wang, Sunny (HPS SW)
2018-02-26 11:34   ` Guo Heyi
2018-02-27  2:47     ` Wang, Sunny (HPS SW) [this message]
2018-02-26 16:23 ` Laszlo Ersek
2018-02-27  0:48   ` Guo Heyi
2018-02-27  5:48     ` Ni, Ruiyu
2018-02-27 10:29       ` Laszlo Ersek
2018-02-27 10:39         ` Guo Heyi
  -- strict thread matches above, loose matches on Subject: below --
2018-03-01  2:39 Heyi Guo
2018-03-01  2:43 ` Guo Heyi
2018-03-01  4:46 ` Ni, Ruiyu
2018-03-07  1:54   ` Guo Heyi
2018-03-08  2:53     ` Ni, Ruiyu

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=DF4PR8401MB065078DED97329B9C8FBAAE5A8C00@DF4PR8401MB0650.NAMPRD84.PROD.OUTLOOK.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