From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=134.134.136.65; helo=mga03.intel.com; envelope-from=michael.d.kinney@intel.com; receiver=edk2-devel@lists.01.org Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id CE22A210F75CE for ; Thu, 3 Jan 2019 16:08:50 -0800 (PST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Jan 2019 16:08:50 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,436,1539673200"; d="scan'208,217";a="105360431" Received: from orsmsx105.amr.corp.intel.com ([10.22.225.132]) by orsmga006.jf.intel.com with ESMTP; 03 Jan 2019 16:08:50 -0800 Received: from orsmsx114.amr.corp.intel.com (10.22.240.10) by ORSMSX105.amr.corp.intel.com (10.22.225.132) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 3 Jan 2019 16:08:49 -0800 Received: from orsmsx113.amr.corp.intel.com ([169.254.9.240]) by ORSMSX114.amr.corp.intel.com ([169.254.8.248]) with mapi id 14.03.0415.000; Thu, 3 Jan 2019 16:08:49 -0800 From: "Kinney, Michael D" To: Ashish Singhal , "edk2-devel@lists.01.org" , "Kinney, Michael D" CC: "Gao, Liming" , "Fu, Siyuan" , "Wu, Jiaxin" Thread-Topic: Uninstalling Invalid Protocol Interfaces Thread-Index: AdSjtn8ScFpTlPkrTXiCI2Fb6Dn4GwACtD8Q Date: Fri, 4 Jan 2019 00:08:49 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [10.22.254.138] MIME-Version: 1.0 X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: Re: Uninstalling Invalid Protocol Interfaces X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2019 00:08:51 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 inst= all the Uefi Driver Model protocol would be useful, so the driver entry poi= nt 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 Cc: Kinney, Michael D ; Gao, Liming ; Fu, Siyuan ; Wu, Jiaxin Subject: Uninstalling Invalid Protocol Interfaces Hello, As part of moving from MdeModulePkg implementation of IScsiDxe to the imple= mentation in NetworkPkg, I started hitting exception in the driver loaded a= fter IScsiDxe if IScsiDxe's installation fails for some reason. Upon debugg= ing, I found out that calls to UninstallMultipleProtocolInterfaces as part = of Error 2 as well Error 1 fail while trying to uninstall component name pr= otocol-interface pair and return error code EFI_INVALID_PARAMETER. As per U= ninstallMultipleProtocolInterfaces's documentation, if uninstallation of an= y of the input protocol-interface pair fails, it will reinstall any just un= installed protocol and return EFI_INVALID_PARAMETER which causes the cleanu= p 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 follo= wing 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 re= installed because of a failure uninstalling another pair. This would howeve= r 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 o= f PCDs PcdComponentNameDisable and PcdComponentName2Disable. 3. In UEFILib, add uninstall functions for all corresponding install API= s 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, disclosur= e or distribution is prohibited. If you are not the intended recipient, pl= ease contact the sender by reply email and destroy all copies of the origin= al message. ________________________________