public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Ashish Singhal <ashishsingha@nvidia.com>
To: "Kinney, Michael D" <michael.d.kinney@intel.com>,
	"edk2-devel@lists.01.org" <edk2-devel@lists.01.org>
Cc: "Gao, Liming" <liming.gao@intel.com>,
	"Fu, Siyuan" <siyuan.fu@intel.com>,
	 "Wu, Jiaxin" <jiaxin.wu@intel.com>
Subject: Re: Uninstalling Invalid Protocol Interfaces
Date: Fri, 4 Jan 2019 00:16:05 +0000	[thread overview]
Message-ID: <BYAPR12MB27433BF9F7DB4382C597FE18BA8E0@BYAPR12MB2743.namprd12.prod.outlook.com> (raw)
In-Reply-To: <E92EE9817A31E24EB0585FDF735412F5B8B7119B@ORSMSX113.amr.corp.intel.com>

Hi Mike,

Call to UninstallMultipleProtocolInterfaces at https://github.com/tianocore/edk2/blob/master/NetworkPkg/IScsiDxe/IScsiDriver.c#L1864 fails because the component name interface may not be installed depending on the state of PCD.

Thanks
Ashish

From: Kinney, Michael D <michael.d.kinney@intel.com>
Sent: Thursday, January 3, 2019 5:09 PM
To: Ashish Singhal <ashishsingha@nvidia.com>; edk2-devel@lists.01.org; Kinney, Michael D <michael.d.kinney@intel.com>
Cc: Gao, Liming <liming.gao@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>; Wu, Jiaxin <jiaxin.wu@intel.com>
Subject: RE: Uninstalling Invalid Protocol Interfaces

Hi Ashish,

Can you provide a pointer to the UninstallMultipleProtocolInterfaces() call that is causing this failure?

I agree that the UefiLib could provide additional services to simplify the implementation of the unload handlers.  Matching the UefiLib APIs that install the Uefi Driver Model protocol would be useful, so the driver entry point and the driver unload functions can use matching APIs.

Mike

From: Ashish Singhal [mailto:ashishsingha@nvidia.com]
Sent: Thursday, January 3, 2019 3:39 PM
To: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>; Fu, Siyuan <siyuan.fu@intel.com<mailto:siyuan.fu@intel.com>>; Wu, Jiaxin <jiaxin.wu@intel.com<mailto:jiaxin.wu@intel.com>>
Subject: Uninstalling Invalid Protocol Interfaces

Hello,

As part of moving from MdeModulePkg implementation of IScsiDxe to the implementation in NetworkPkg, I started hitting exception in the driver loaded after IScsiDxe if IScsiDxe's installation fails for some reason. Upon debugging, I found out that calls to UninstallMultipleProtocolInterfaces as part of Error 2 as well Error 1 fail while trying to uninstall component name protocol-interface pair and return error code EFI_INVALID_PARAMETER. As per UninstallMultipleProtocolInterfaces's documentation, if uninstallation of any of the input protocol-interface pair fails, it will reinstall any just uninstalled protocol and return EFI_INVALID_PARAMETER which causes the cleanup of this driver corrupt leading to failure in next driver getting loaded. The reason of failure in UninstallMultipleProtocolInterfaces is because the driver uses EfiLibInstallDriverBindingComponentName2 to install interfaces which may not install component name interfaces depending on the value of PCDs PcdComponentNameDisable and PcdComponentName2Disable. I have the following proposals to get around this issue.


  1.  Instead of calling UninstallMultipleProtocolInterfaces once and list all protocol-interface pairs, do it sequentially for every pair so that the once which was installed correctly, gets uninstalled instead of getting reinstalled because of a failure uninstalling another pair. This would however make us not really use use UninstallMultipleProtocolInterfaces API to its full caliber.
  2.  In UEFILib, add a function EfiLibUninstallDriverBindingComponentName2 for uninstalling protocol interfaces taking into consideration the state of PCDs PcdComponentNameDisable and PcdComponentName2Disable.
  3.  In UEFILib, add uninstall functions for all corresponding install APIs to get coverage for all scenarios.

I would certainly prefer option 2 or 3 as they seem to be more correct and would provide a for all drivers which may hit the issue. I am happy to make the code changes as needed and suggested by the maintainers.

Thanks
Ashish
________________________________
This email message is for the sole use of the intended recipient(s) and may contain confidential information.  Any unauthorized review, use, disclosure or distribution is prohibited.  If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
________________________________


  reply	other threads:[~2019-01-04  0:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-03 23:38 Uninstalling Invalid Protocol Interfaces Ashish Singhal
2019-01-04  0:08 ` Kinney, Michael D
2019-01-04  0:16   ` Ashish Singhal [this message]
2019-01-04 17:15     ` Kinney, Michael D
2019-01-04 17:32       ` Ashish Singhal
2019-01-04 22:17         ` Ashish Singhal

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=BYAPR12MB27433BF9F7DB4382C597FE18BA8E0@BYAPR12MB2743.namprd12.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