public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Marvin Häuser" <Marvin.Haeuser@outlook.com>
To: "edk2-devel@lists.01.org" <edk2-devel@lists.01.org>
Cc: "Kinney, Michael D" <michael.d.kinney@intel.com>
Subject: Re: Regarding UefiDriverEntryPoint unload handler
Date: Thu, 15 Jun 2017 03:27:49 +0000	[thread overview]
Message-ID: <AM5PR0601MB2579C44357EB290F0551CF0A80C00@AM5PR0601MB2579.eurprd06.prod.outlook.com> (raw)

Hey Mike,

"if UnloadImage() is called and the Unload field is NULL, it returns an EFI_UNSUPPORTED."
This is the part I missed, my example is impossible in this case.

Thanks,
Marvin.

-----Ursprüngliche Nachricht-----
Von: Kinney, Michael D [mailto:michael.d.kinney@intel.com] 
Gesendet: Donnerstag, 15. Juni 2017 04:51
An: Marvin H?user <Marvin.Haeuser@outlook.com>; edk2-devel@lists.01.org; Kinney, Michael D <michael.d.kinney@intel.com>
Betreff: RE: Regarding UefiDriverEntryPoint unload handler

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  3:26 UTC|newest]

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

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=AM5PR0601MB2579C44357EB290F0551CF0A80C00@AM5PR0601MB2579.eurprd06.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