Tianocore/edk2.git/MdeModulePkg/Core/Dxe/Hand/Locate.c, branch master

MdeModulePkg: Fix memory leak in LocateHandleBuffer()

2023-08-31T19:35:19+00:00

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4543 REF: https://uefi.org/specs/UEFI/2.10/07_Services_Boot_Services.html#efi-boot-services-locatehandlebuffer CoreLocateHandleBuffer() can in certain cases, return an error and not free an allocated buffer. This scenario occurs if the first call to InternalCoreLocateHandle() returns success and the second call returns an error. On a successful return, LocateHandleBuffer() passes ownership of the buffer to the caller. However, the UEFI specification is not explicit about what the expected ownership of this buffer is in the case of an error. However, it is heavily implied by the code example given in section 7.3.15 of v2.10 of the UEFI specificaton that if LocateHandleBuffer() returns a non-successful status code then the ownership of the buffer does NOT transfer to the caller. This code example explicitly refrains from calling FreePool() if LocateHandleBuffer() returns an error. From a practical standpoint, it is logical to assume that a non-successful status code indicates that no buffer of handles was ever allocated. Indeed, in most error cases, LocateHandleBuffer() does not go far enough to get to the point where a buffer is allocated. Therefore, all existing users of this API must already be coded to support the case of a non-successful status code resulting in an invalid handle buffer being returned. Therefore, this change will not cause any backwards compatibility issues with existing code. In conclusion, this boils down to a fix for a memory leak that also brings the behavior of our LocateHandleBuffer() implementation into alignment with the original intentions of the UEFI specification authors. Reviewed-by: Michael D Kinney Cc: Liming Gao Cc: Jian J Wang Cc: Dandan Bi Signed-off-by: Nate DeSimone

MdeModulePkg: Apply uncrustify changes

2021-12-07T17:24:28+00:00

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3737 Apply uncrustify changes to .c/.h files in the MdeModulePkg package Cc: Andrew Fish Cc: Leif Lindholm Cc: Michael D Kinney Signed-off-by: Michael Kubacki Reviewed-by: Liming Gao

MdeModulePkg/Core/Dxe: Add lock protection in CoreLocateHandleBuffer()

2021-10-08T06:57:55+00:00

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3666 Currently, CoreLocateHandleBuffer() follows three steps: 1) get the size of protocol database firstly 2) allocate the buffer based on the size 3) get the protocol database into the buffer There is no lock protection for the whole three steps. If a new protocol added in step 2) by other task, e.g. (event timer handle USB device hotplug). The size of protocol database may be increased and cannot fit into the previous buffer in step 3). The protocol database cannot be returned successfully, EFI_BUFFER_TOO_SMALL error will be returned. This patch adds the lock to protect the whole three steps. It can make sure the correct protocol database be returned. Cc: Jian J Wang Cc: Liming Gao Cc: Dandan Bi Signed-off-by: Hua Ma Reviewed-by: Dandan Bi dandan.bi@intel.com Reviewed-by: Liming Gao gaoliming@byosoft.com.cn

MdeModulePkg: Replace BSD License with BSD+Patent License

2019-04-09T17:58:08+00:00

https://bugzilla.tianocore.org/show_bug.cgi?id=1373 Replace BSD 2-Clause License with BSD+Patent License. This change is based on the following emails: https://lists.01.org/pipermail/edk2-devel/2019-February/036260.html https://lists.01.org/pipermail/edk2-devel/2018-October/030385.html RFCs with detailed process for the license change: V3: https://lists.01.org/pipermail/edk2-devel/2019-March/038116.html V2: https://lists.01.org/pipermail/edk2-devel/2019-March/037669.html V1: https://lists.01.org/pipermail/edk2-devel/2019-March/037500.html Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney Reviewed-by: Hao Wu Reviewed-by: Jian J Wang

MdeModulePkg: Clean up source files

2018-06-28T03:19:45+00:00

1. Do not use tab characters 2. No trailing white space in one line 3. All files must end with CRLF Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao Reviewed-by: Star Zeng

MdeModulePkg: Return invalid param in LocateProtocol for Protocol==NULL

2017-06-21T13:37:34+00:00

Return EFI_INVALID_PARAMETER in LocateProtocol for Protocol==NULL to follow UEFI 2.7 spec PiSmmCore is also updated as the EFI_SMM_SYSTEM_TABLE2.SmmLocateProtocol is reusing the definition of EFI_LOCATE_PROTOCOL. Cc: Liming Gao Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng Reviewed-by: Liming Gao

MdeModulePkg/Core: Fix typos in comments

2016-10-27T01:11:17+00:00

- paramters -> parameters - funciton -> function - dependecy -> dependency - evauated -> evaluated - genric -> generic - retore -> restore - Protocl -> Protocol - availible -> available - elasped -> elapsed - sarted -> started - boundry -> boundary - permenent -> permanent - debuging -> debugging - availble -> available Cc: Feng Tian Cc: Star Zeng Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gary Lin Reviewed-by: Feng Tian Reviewed-by: Star Zeng

MdeModulePkg/DxeCore: Avoid assertion in CoreLocateProtocol

2016-04-25T05:36:37+00:00

The patch uses CoreAcquireLockOrFail() instead of CoreAcquireProtocolLock() in CoreLocateProtocol() to avoid assertion when CoreLocateProtocol() is called with the protocol database locked. The issue was found when changing PcdDebugPrintErrorLevel to enable page/pool allocation debug message. Nt32 platform hangs immediately after DxeCore is loaded. Investigation shows the following calling stacks: DxeCore entry point (Install a certain protocol) 0 DxeCore::CoreInstallProtocolInterface // Protocol DB is locked 1 DxeCore::AllocatePool 2 PeiDxeDebugLibReportStatusCode::DebugPrint 3 DxeReportStatusCodeLib::ReportStatusCodeEx // <-------------------| 4 DxeReportStatusCodeLib::InternalGetReportStatusCode | 5 DxeCore::LocateProtocol(StatusCodeRuntimeProtocol) | // Assertion when locking Protocol DB 2nd time | 6 DxeCore::CoreAcquireProtocolLock | 7 PeiDxeDebugLibReportStatusCode::DebugAssert | 8 DxeReportStatusCodeLib::ReportSatusCodeEx // loop begins --------- In frame #6 the assertion is triggered due to the protocol database is already locked. #8 calls #4 and the loop begins. After changing #6 to CoreAcquireLockOrFail(), the assertion is avoided and the loop is broken. With the fix, NT32 can boot to Shell even setting PcdDebugPrintErrorLevel to 0xFFFFFFFF, with all error levels turned on. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni Reviewed-by: Liming Gao

Update code to support VS2013 tool chain.

2014-07-28T07:52:57+00:00

Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Eric Dong Reviewed-by: Liming Gao git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15695 6f19259b-4bc3-4df7-8a09-765794883524

Fix LocateDevicePath() to return proper error status code. It was returning EFI_INVALID_PARAMETER if Device was NULL even if not handles matched the search criteria. The proper behavior is to return EFI_NOT_FOUND if not handles match the search criteria, and only return EFI_INVALID_PARAMETER if at least one match is found and Device is NULL.

2011-03-16T16:17:09+00:00

Also update function header comment block for LocateDevicePath() to match UEFI Specification. git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@11406 6f19259b-4bc3-4df7-8a09-765794883524