Tianocore/edk2.git/MdeModulePkg/Core/Dxe/Hand, branch trunk

Renormalized end-of-lines from master@27b044605cd5f6b33a3d231576003850b3fe305b

2024-06-04T03:43:08+00:00

MdeModulePkg: Optimize CoreConnectSingleController

2024-02-06T17:54:53+00:00

CoreConnectSingleController() searches for the Driver Family Override Protocol drivers by looping and checking each Driver Binding Handles. This loop can be skipped by checking if any Driver Family Override Protocol installed in the platform first, to improve the performance. Cc: Ray Ni Reviewed-by: Liming Gao Reviewed-by: Michael D Kinney Signed-off-by: Zhi Jin

MdeModulePkg: Remove handle validation check in CoreGetProtocolInterface

2024-02-06T17:54:53+00:00

CoreGetProtocolInterface() is called by CoreOpenProtocol(), CoreCloseProtocol() and CoreOpenProtocolInformation(). Before CoreOpenProtocol() calls CoreGetProtocolInterface(), the input parameter UserHandle has been already checked for validation. So does CoreCloseProtocol(). Removing the handle validation check in CoreGetProtocolInterface() could improve the performance, as CoreOpenProtocol() is called very frequently. To ensure the assumption that the caller of CoreGetProtocolInterface() must pass in a valid UserHandle that is checked with CoreValidateHandle(), add the parameter check in CoreOpenProtocolInformation(), and declare CoreGetProtocolInterface() as static. Reviewed-by: Ray Ni Reviewed-by: Liming Gao Reviewed-by: Michael D Kinney Signed-off-by: Zhi Jin

MdeModulePkg: Optimize CoreInstallMultipleProtocolInterfaces

2023-12-01T00:53:56+00:00

CoreLocateDevicePath is used in CoreInstallMultipleProtocolInterfaces to check if a Device Path Protocol instance with the same device path is alreay installed. CoreLocateDevicePath is a generic API, and would introduce some unnecessary overhead for such usage. The optimization is: 1. Implement IsDevicePathInstalled to loop all the Device Path Protocols installed and check if any of them matchs the given device path. 2. Replace CoreLocateDevicePath with IsDevicePathInstalled in CoreInstallMultipleProtocolInterfaces. This optimization could save several seconds in PCI enumeration on a system with many PCI devices. Cc: Jian J Wang Cc: Liming Gao Cc: Dandan Bi Cc: Ray Ni Signed-off-by: Zhi Jin Reviewed-by: Ray Ni Reviewed-by: Liming Gao

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: Acquire a lock when iterating gHandleList

2021-10-14T03:27:20+00:00

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3680 This patch fixes the following issue: The global variable gHandleList is a linked list. This list is locked when a entry is added or removed from the list, but there is no lock when iterating this list in function CoreValidateHandle(). It can lead to "Handle.c (76): CR has Bad Signature" assertion if the iterated entry in the list is just removed by other task during iterating. Currently some caller functions of CoreValidateHandle() have CoreAcquireProtocolLock(), but some caller functions of CoreValidateHandle() do not CoreAcquireProtocolLock(). Add CoreAcquireProtocolLock() always when CoreValidateHandle() is called, Also, A lock check is added in the CoreValidateHandle(). Cc: Jian J Wang Cc: Liming Gao Cc: Dandan Bi Cc: Ray Ni Signed-off-by: Hua Ma Reviewed-by: Dandan Bi Reviewed-by: Jian J Wang

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: Make retval in UninstallMultipleProtocol follow Spec

2020-02-19T14:43:25+00:00

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1869 The UEFI spec requires that if any error occurs in UninstallMultipleProtocolInterfaces(), EFI_INVALID_PARAMETER is returned and not the return code of UninstallProtocolInterface(). Signed-off-by: Heinrich Schuchardt Reviewed-by: Dandan Bi

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