* MdeModulePkg/UefiBootManagerLib: recursive call of BmRepairAllControllers @ 2018-02-24 6:23 Guo Heyi 2018-02-24 8:20 ` Ni, Ruiyu 0 siblings, 1 reply; 5+ messages in thread From: Guo Heyi @ 2018-02-24 6:23 UTC (permalink / raw) To: edk2-devel; +Cc: Star Zeng, Eric Dong, Ruiyu Ni Hi folks, In BmDriverHealth.c, function BmRepairAllControllers may recursively call itself if some driver health protocol returns EfiDriverHealthStatusReconnectRequired. However, if there is something wrong in some 3rd party driver (e.g. PCI oprom), the driver health protocol of that 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 does it make sense to set a maximum count of this recursive call to avoid whole system hang even there is a buggy 3rd party driver? Thanks, Gary (Heyi Guo) ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: MdeModulePkg/UefiBootManagerLib: recursive call of BmRepairAllControllers 2018-02-24 6:23 MdeModulePkg/UefiBootManagerLib: recursive call of BmRepairAllControllers Guo Heyi @ 2018-02-24 8:20 ` Ni, Ruiyu 2018-02-24 8:28 ` Guo Heyi 0 siblings, 1 reply; 5+ messages in thread From: Ni, Ruiyu @ 2018-02-24 8:20 UTC (permalink / raw) To: Guo Heyi, edk2-devel; +Cc: Star Zeng, Eric Dong On 2/24/2018 2:23 PM, Guo Heyi wrote: > Hi folks, > > In BmDriverHealth.c, function BmRepairAllControllers may recursively call itself > if some driver health protocol returns EfiDriverHealthStatusReconnectRequired. > However, if there is something wrong in some 3rd party driver (e.g. PCI oprom), > the driver health protocol of that 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. yes. I agree. If a buggy PCI oprom always return ReconnectRequired, the stack overflow will happen. How about we choose maximum recursive call depth as 10 and continue to boot if call depth reaches 11? > > So does it make sense to set a maximum count of this recursive call to avoid > whole system hang even there is a buggy 3rd party driver? > > Thanks, > > Gary (Heyi Guo) > -- Thanks, Ray ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: MdeModulePkg/UefiBootManagerLib: recursive call of BmRepairAllControllers 2018-02-24 8:20 ` Ni, Ruiyu @ 2018-02-24 8:28 ` Guo Heyi 2018-02-24 8:40 ` Ni, Ruiyu 0 siblings, 1 reply; 5+ messages in thread From: Guo Heyi @ 2018-02-24 8:28 UTC (permalink / raw) To: Ni, Ruiyu; +Cc: Guo Heyi, edk2-devel, Star Zeng, Eric Dong On Sat, Feb 24, 2018 at 04:20:52PM +0800, Ni, Ruiyu wrote: > On 2/24/2018 2:23 PM, Guo Heyi wrote: > >Hi folks, > > > >In BmDriverHealth.c, function BmRepairAllControllers may recursively call itself > >if some driver health protocol returns EfiDriverHealthStatusReconnectRequired. > >However, if there is something wrong in some 3rd party driver (e.g. PCI oprom), > >the driver health protocol of that 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. > > yes. I agree. > If a buggy PCI oprom always return ReconnectRequired, the stack overflow > will happen. > > How about we choose maximum recursive call depth as 10 and continue to > boot if call depth reaches 11? That's fine for me :) Thanks, Gary (Heyi Guo) > > > > >So does it make sense to set a maximum count of this recursive call to avoid > >whole system hang even there is a buggy 3rd party driver? > > > >Thanks, > > > >Gary (Heyi Guo) > > > > > -- > Thanks, > Ray ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: MdeModulePkg/UefiBootManagerLib: recursive call of BmRepairAllControllers 2018-02-24 8:28 ` Guo Heyi @ 2018-02-24 8:40 ` Ni, Ruiyu 2018-02-24 8:47 ` Guo Heyi 0 siblings, 1 reply; 5+ messages in thread From: Ni, Ruiyu @ 2018-02-24 8:40 UTC (permalink / raw) To: Guo Heyi; +Cc: edk2-devel@lists.01.org, Zeng, Star, Dong, Eric Will you submit a patch for this change? Thanks/Ray > -----Original Message----- > From: Guo Heyi [mailto:heyi.guo@linaro.org] > Sent: Saturday, February 24, 2018 4:29 PM > To: Ni, Ruiyu <ruiyu.ni@intel.com> > Cc: Guo Heyi <heyi.guo@linaro.org>; edk2-devel@lists.01.org; Zeng, Star > <star.zeng@intel.com>; Dong, Eric <eric.dong@intel.com> > Subject: Re: MdeModulePkg/UefiBootManagerLib: recursive call of > BmRepairAllControllers > > On Sat, Feb 24, 2018 at 04:20:52PM +0800, Ni, Ruiyu wrote: > > On 2/24/2018 2:23 PM, Guo Heyi wrote: > > >Hi folks, > > > > > >In BmDriverHealth.c, function BmRepairAllControllers may recursively > > >call itself if some driver health protocol returns > EfiDriverHealthStatusReconnectRequired. > > >However, if there is something wrong in some 3rd party driver (e.g. > > >PCI oprom), the driver health protocol of that 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. > > > > yes. I agree. > > If a buggy PCI oprom always return ReconnectRequired, the stack > > overflow will happen. > > > > How about we choose maximum recursive call depth as 10 and continue to > > boot if call depth reaches 11? > > That's fine for me :) > > Thanks, > > Gary (Heyi Guo) > > > > > > > > >So does it make sense to set a maximum count of this recursive call > > >to avoid whole system hang even there is a buggy 3rd party driver? > > > > > >Thanks, > > > > > >Gary (Heyi Guo) > > > > > > > > > -- > > Thanks, > > Ray ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: MdeModulePkg/UefiBootManagerLib: recursive call of BmRepairAllControllers 2018-02-24 8:40 ` Ni, Ruiyu @ 2018-02-24 8:47 ` Guo Heyi 0 siblings, 0 replies; 5+ messages in thread From: Guo Heyi @ 2018-02-24 8:47 UTC (permalink / raw) To: Ni, Ruiyu; +Cc: Guo Heyi, edk2-devel@lists.01.org, Zeng, Star, Dong, Eric Sure. On Sat, Feb 24, 2018 at 08:40:20AM +0000, Ni, Ruiyu wrote: > Will you submit a patch for this change? > > Thanks/Ray > > > -----Original Message----- > > From: Guo Heyi [mailto:heyi.guo@linaro.org] > > Sent: Saturday, February 24, 2018 4:29 PM > > To: Ni, Ruiyu <ruiyu.ni@intel.com> > > Cc: Guo Heyi <heyi.guo@linaro.org>; edk2-devel@lists.01.org; Zeng, Star > > <star.zeng@intel.com>; Dong, Eric <eric.dong@intel.com> > > Subject: Re: MdeModulePkg/UefiBootManagerLib: recursive call of > > BmRepairAllControllers > > > > On Sat, Feb 24, 2018 at 04:20:52PM +0800, Ni, Ruiyu wrote: > > > On 2/24/2018 2:23 PM, Guo Heyi wrote: > > > >Hi folks, > > > > > > > >In BmDriverHealth.c, function BmRepairAllControllers may recursively > > > >call itself if some driver health protocol returns > > EfiDriverHealthStatusReconnectRequired. > > > >However, if there is something wrong in some 3rd party driver (e.g. > > > >PCI oprom), the driver health protocol of that 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. > > > > > > yes. I agree. > > > If a buggy PCI oprom always return ReconnectRequired, the stack > > > overflow will happen. > > > > > > How about we choose maximum recursive call depth as 10 and continue to > > > boot if call depth reaches 11? > > > > That's fine for me :) > > > > Thanks, > > > > Gary (Heyi Guo) > > > > > > > > > > > > >So does it make sense to set a maximum count of this recursive call > > > >to avoid whole system hang even there is a buggy 3rd party driver? > > > > > > > >Thanks, > > > > > > > >Gary (Heyi Guo) > > > > > > > > > > > > > -- > > > Thanks, > > > Ray ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2018-02-24 8:41 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-02-24 6:23 MdeModulePkg/UefiBootManagerLib: recursive call of BmRepairAllControllers Guo Heyi 2018-02-24 8:20 ` Ni, Ruiyu 2018-02-24 8:28 ` Guo Heyi 2018-02-24 8:40 ` Ni, Ruiyu 2018-02-24 8:47 ` Guo Heyi
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox