public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Kinney, Michael D" <michael.d.kinney@intel.com>
To: Marvin H?user <Marvin.Haeuser@outlook.com>,
	"edk2-devel@lists.01.org" <edk2-devel@lists.01.org>,
	"Kinney, Michael D" <michael.d.kinney@intel.com>
Subject: Re: Regarding UefiDriverEntryPoint unload handler
Date: Thu, 15 Jun 2017 02:51:09 +0000	[thread overview]
Message-ID: <E92EE9817A31E24EB0585FDF735412F5A7D35B0E@ORSMSX113.amr.corp.intel.com> (raw)
In-Reply-To: <AM5PR0601MB25795863D62AA7223D980EB380C00@AM5PR0601MB2579.eurprd06.prod.outlook.com>

Hi Marvin,

Yes.  This is intentional.  If MODULE_UNLOAD is not provided, then the module can never be unloaded.  
The LoadImage() services initializes the Unload field to NULL, and if UnloadImage() is called and
the Unload field is NULL, it returns an EFI_UNSUPPORTED.

I do not think the case you describer is possible.  If ProcessModuleUnloadList() returns an error,
then ProcessLibraryDestructorList()is not called.

Since the module is not unloaded, it is still in allocated memory.  How would the protocol point
to a freed buffer?

Mike

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Marvin H?user
Sent: Wednesday, June 14, 2017 6:41 PM
To: edk2-devel@lists.01.org
Subject: [edk2] Regarding UefiDriverEntryPoint unload handler

Dear developers,

While performing some research tasks, I noticed that when UefiDriverEntryPoint's _gDriverUnloadImageCount is 0 (only MODULE_UNLOAD entries are count, DESTRUCTOR as they are used with libraries are not, as far as I can see), EFI_LOADED_IMAGE_PROTOCOL.Unload is not set, even if libraries with destructors are included by the built module.
Is this intentional, so, is a module without a MODULE_UNLOAD property in its build file considered a module that does not support being unloaded? If so, why is EFI_LOADED_IMAGE_PROTOCOL.Unload not set to a dummy that returns an EFI error code?

For example, DxeDebugPrintErrorLevelLib installs a protocol interface in its CONSTRUCTOR function. When this library is included in a module without a MODULE_UNLOAD property and that module is unloaded, the DxeDebugPrintErrorLevelLib DESTRUCTOR function, which uninstalls the interface, is never called and hence the interface remains in the protocol database, despite it pointing to a memory location that is now free. If it is called, the behavior is obviously undefined.

Did I understand something incorrectly, are these modules not supposed to be unloadable or is this a bug?

Thank you,
Marvin.
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


  reply	other threads:[~2017-06-15  2:49 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-15  1:41 Regarding UefiDriverEntryPoint unload handler Marvin H?user
2017-06-15  2:51 ` Kinney, Michael D [this message]
  -- strict thread matches above, loose matches on Subject: below --
2017-06-15  3:27 Marvin Häuser

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=E92EE9817A31E24EB0585FDF735412F5A7D35B0E@ORSMSX113.amr.corp.intel.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