* [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs
@ 2019-09-17 19:49 Laszlo Ersek
2019-09-17 19:49 ` [PATCH 01/35] DO NOT APPLY: edk2: turn standard handle types into pointers to non-VOID Laszlo Ersek
` (37 more replies)
0 siblings, 38 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-17 19:49 UTC (permalink / raw)
To: edk2-devel-groups-io
Cc: Achin Gupta, Andrew Fish, Anthony Perard, Ard Biesheuvel,
Benjamin You, Chao Zhang, Dandan Bi, David Woodhouse, Eric Dong,
Guo Dong, Hao A Wu, Jaben Carsey, Jian J Wang, Jiaxin Wu,
Jiewen Yao, Jordan Justen, Julien Grall, Leif Lindholm,
Liming Gao, Maurice Ma, Michael D Kinney, Ray Ni, Siyuan Fu,
Supreeth Venkatesh, Zhichao Gao
Repository: https://github.com/lersek/edk2.git
Branch: voidptr
The UEFI / PI / Shell specifications define a number of standard types
as pointers to VOID. This is arguably a design mistake; those types
should have been pointers to distinct incomplete union or structure
types. Here's why:
Roughly paraphrasing the constraints from ISO C99 "6.5.16.1 Simple
assignment" and "6.5.4 Cast operators", any pointer-to-object type
converts implicitly to, and from, pointer-to-void, provided const /
volatile qualifications are not relaxed. Such implicit conversions
prevent compilers from catching at least the following two kinds of
coding mistakes:
- mixing up one type with another (for example, EFI_HANDLE with
EFI_EVENT),
- getting the depth of indirection wrong (for example, mixing up
(EFI_HANDLE*) with EFI_HANDLE).
This series first separates these standard types from each other, in the
first patch, which is *not* being proposed for merging. This unmasks a
number of warts (semantic issues, or actual bugs) in the source code, in
the form of build breakages. The rest of the series works through those
breakages, cleaning and fixing the code.
Every DSC file in the edk2 tree was built for at least one of the NOOPT,
DEBUG, RELEASE targets (NOOPT being preferred), with the GCC48 toolchain
(for IA32 / X64) and the GCC5 toolchain (for ARM / AARCH64). Of course,
the build arches were restricted to the SUPPORTED_ARCHITECTURES stated
in the individual DSC files.
There were two exceptions to the above rule: DynamicTablesPkg was only
build-tested with AARCH64 (despite its SUPPORTED_ARCHITECTURES), given
that 32-bit ARM has no ACPI bindings. StandaloneMmPkg too was only
build-tested with AARCH64; it doesn't actually support IA32/X64 yet.
Regarding boot & runtime tests, ArmVirtQemu on AARCH64 was tested with
booting to the OS (RHEL7). Furthermore, I exercised OVMF with my usual
boot and S3 tests, covering IA32, IA32X64, and X64. Finally, some other
individual tests (noted per patch) were done with OVMF.
Cc: Achin Gupta <achin.gupta@arm.com>
Cc: Andrew Fish <afish@apple.com>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Benjamin You <benjamin.you@intel.com>
Cc: Chao Zhang <chao.b.zhang@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Guo Dong <guo.dong@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Jian Wang <jian.j.wang@intel.com>
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien.grall@arm.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Cc: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Thanks
Laszlo
Laszlo Ersek (35):
DO NOT APPLY: edk2: turn standard handle types into pointers to
non-VOID
EmbeddedPkg: add missing EFIAPI calling convention specifiers
EmbeddedPkg/AndroidFastbootTransportTcpDxe: fix DestroyChild() call
EmbeddedPkg/Universal/MmcDxe: "fix" CloseProtocol() call in
BindingStop()
EmulatorPkg/DxeTimerLib: drop superfluous cast
EmulatorPkg: stop abusing EFI_HANDLE for keystroke notify registration
MdeModulePkg: fix cast in GetModuleInfoFromHandle() calls
MdeModulePkg/UefiHiiLib: stop using EFI_HANDLE in place of
EFI_HII_HANDLE
MdeModulePkg: stop abusing EFI_EVENT for protocol notify registration
MdeModulePkg/PlatformVarCleanupLib: fix HiiConstructConfigHdr() call
MdeModulePkg: document workaround for EFI_RUNTIME_EVENT_ENTRY PI spec
bug
MdeModulePkg: stop abusing EFI_HANDLE for keystroke notify
registration
MdeModulePkg: PEI Core: clean up "AprioriFile" handling in
FindFileEx()
MdeModulePkg: fix UninstallMultipleProtocolInterfaces() calls
MdeModulePkg/PiSmmCore: make type punning consistent
MdeModulePkg/S3SaveState: cast Position for S3BootScriptLib explicitly
MdePkg/DxeServicesLib: remove bogus cast
NetworkPkg/DxeNetLib: fix type typo in NetLibGetMacAddress()
NetworkPkg: fix CloseProtocol & UninstallMultipleProtocolInterfaces
calls
NetworkPkg/Ip4Dxe: fix NetLibDestroyServiceChild() call
NetworkPkg/TcpDxe: fix SockFreeFoo() parameter list
OvmfPkg/XenBusDxe: fix UninstallMultipleProtocolInterfaces() call
OvmfPkg/VirtioNetDxe: fix SignalEvent() call
OvmfPkg/PlatformDxe: fix EFI_HII_HANDLE parameters of internal
functions
OvmfPkg/VideoDxe: document EFI_EDID_OVERRIDE_PROTOCOL.GetEdid() call
SecurityPkg: fix UninstallMultipleProtocolInterfaces() calls
SecurityPkg: stop abusing EFI_EVENT for protocol notify registration
ShellPkg/UefiShellDriver1CommandsLib: fix parameter list typo
ShellPkg: stop using EFI_HANDLE in place of EFI_HII_HANDLE
ShellPkg: stop taking EFI_HANDLE in place of SHELL_FILE_HANDLE
ShellPkg/UefiShellDebug1CommandsLib: fix ShellCloseFile() call
ShellPkg/UefiShellLib: clarify workaround for unfixable EdkShell bug
StandaloneMmPkg/Core: stop abusing EFI_HANDLE for FwVolHeader tracking
UefiPayloadPkg/BlSupportPei: fix MMCONFIG assignment from XSDT
UefiPayloadPkg/BlSupportDxe: fix ReserveResourceInGcd() calls
EmbeddedPkg/Drivers/AndroidFastbootTransportTcpDxe/FastbootTransportTcp.c | 2 +-
EmbeddedPkg/Drivers/ConsolePrefDxe/ConsolePrefDxe.c | 1 +
EmbeddedPkg/Drivers/Lan9118Dxe/Lan9118Dxe.c | 1 +
EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.h | 32 ++++++--
EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c | 8 ++
EmbeddedPkg/GdbStub/GdbStubInternal.h | 9 +++
EmbeddedPkg/MetronomeDxe/Metronome.c | 1 +
EmbeddedPkg/Universal/MmcDxe/Mmc.c | 5 +-
EmulatorPkg/EmuGopDxe/GopInput.c | 4 +-
EmulatorPkg/Library/DxeTimerLib/DxeTimerLib.c | 2 +-
MdeModulePkg/Bus/I2c/I2cDxe/I2cBus.c | 2 +-
MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c | 2 +-
MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c | 6 +-
MdeModulePkg/Bus/Pci/PciSioSerialDxe/Serial.c | 2 +-
MdeModulePkg/Bus/Sd/EmmcDxe/EmmcDxe.c | 2 +-
MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c | 2 +-
MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassImpl.c | 2 +-
MdeModulePkg/Core/Dxe/Event/Event.c | 8 ++
MdeModulePkg/Core/Dxe/Event/Event.h | 2 +-
MdeModulePkg/Core/Dxe/Hand/Handle.h | 2 +-
MdeModulePkg/Core/Pei/FwVol/FwVol.c | 2 +-
MdeModulePkg/Core/Pei/FwVol/FwVol.h | 2 +-
MdeModulePkg/Core/PiSmmCore/PiSmmCore.h | 2 +-
MdeModulePkg/Core/PiSmmCore/Smi.c | 8 +-
MdeModulePkg/Core/RuntimeDxe/Runtime.c | 10 ++-
MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c | 12 +--
MdeModulePkg/Library/PlatformVarCleanupLib/PlatVarCleanupLib.c | 6 +-
MdeModulePkg/Library/SmmCorePerformanceLib/SmmCorePerformanceLib.c | 8 +-
MdeModulePkg/Library/UefiHiiLib/HiiString.c | 4 +-
MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h | 2 +-
MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c | 4 +-
MdeModulePkg/Universal/Acpi/SmmS3SaveState/SmmS3SaveState.c | 4 +-
MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c | 2 +-
MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c | 4 +-
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c | 2 +-
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c | 2 +-
MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabase.h | 2 +-
MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.c | 2 +-
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c | 2 +-
MdePkg/Include/Pi/PiPeiCis.h | 6 +-
MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h | 3 +-
MdePkg/Include/Protocol/Bis.h | 3 +-
MdePkg/Include/Protocol/Eap.h | 3 +-
MdePkg/Include/Protocol/HiiFont.h | 3 +-
MdePkg/Include/Protocol/MmMp.h | 3 +-
MdePkg/Include/Protocol/S3SaveState.h | 2 +-
MdePkg/Include/Protocol/Shell.h | 3 +-
MdePkg/Include/Protocol/UserManager.h | 9 ++-
MdePkg/Include/Uefi/UefiBaseType.h | 6 +-
MdePkg/Include/Uefi/UefiInternalFormRepresentation.h | 3 +-
MdePkg/Library/DxeServicesLib/DxeServicesLib.c | 2 +-
NetworkPkg/DnsDxe/DnsDriver.c | 4 +-
NetworkPkg/IScsiDxe/IScsiConfig.c | 2 +-
NetworkPkg/Ip4Dxe/Ip4Driver.c | 2 +-
NetworkPkg/Ip4Dxe/Ip4If.c | 4 +-
NetworkPkg/Ip6Dxe/Ip6Driver.c | 2 +-
NetworkPkg/Library/DxeNetLib/DxeNetLib.c | 2 +-
NetworkPkg/Mtftp4Dxe/Mtftp4Driver.c | 2 +-
NetworkPkg/TcpDxe/SockImpl.c | 4 +-
NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.c | 2 +-
OvmfPkg/Csm/BiosThunk/VideoDxe/BiosVideo.c | 6 +-
OvmfPkg/PlatformDxe/Platform.c | 4 +-
OvmfPkg/VirtioNetDxe/Events.c | 2 +-
OvmfPkg/XenBusDxe/XenBus.c | 2 +-
SecurityPkg/HddPassword/HddPasswordDxe.c | 2 +-
SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c | 2 +-
SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c | 2 +-
SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDriver.c | 2 +-
ShellPkg/DynamicCommand/DpDynamicCommand/Dp.c | 6 +-
ShellPkg/DynamicCommand/DpDynamicCommand/Dp.h | 4 +-
ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c | 6 +-
ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.h | 4 +-
ShellPkg/Include/Library/ShellCommandLib.h | 2 +-
ShellPkg/Include/Library/ShellLib.h | 4 +-
ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c | 2 +-
ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c | 2 +-
ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c | 2 +-
ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.h | 2 +-
ShellPkg/Library/UefiShellDebug1CommandsLib/Edit/FileBuffer.c | 2 +-
ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.c | 2 +-
ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.h | 2 +-
ShellPkg/Library/UefiShellDriver1CommandsLib/Connect.c | 4 +-
ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.c | 2 +-
ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.h | 2 +-
ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.c | 2 +-
ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.h | 2 +-
ShellPkg/Library/UefiShellLevel2CommandsLib/Rm.c | 2 +-
ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.c | 2 +-
ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.h | 2 +-
ShellPkg/Library/UefiShellLevel3CommandsLib/Touch.c | 2 +-
ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.c | 2 +-
ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.h | 2 +-
ShellPkg/Library/UefiShellLib/UefiShellLib.c | 26 ++++++-
ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.c | 2 +-
ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.h | 2 +-
ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.c | 2 +-
ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.h | 2 +-
StandaloneMmPkg/Core/Dispatcher.c | 80 +++++++++++---------
StandaloneMmPkg/Core/FwVol.c | 16 ++--
StandaloneMmPkg/Core/StandaloneMmCore.h | 4 +-
UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c | 4 +-
UefiPayloadPkg/BlSupportPei/BlSupportPei.c | 19 +++--
102 files changed, 294 insertions(+), 194 deletions(-)
--
2.19.1.3.g30247aa5d201
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 01/35] DO NOT APPLY: edk2: turn standard handle types into pointers to non-VOID
2019-09-17 19:49 [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs Laszlo Ersek
@ 2019-09-17 19:49 ` Laszlo Ersek
2019-09-17 20:06 ` [edk2-devel] " Ni, Ray
2019-09-17 19:49 ` [PATCH 02/35] EmbeddedPkg: add missing EFIAPI calling convention specifiers Laszlo Ersek
` (36 subsequent siblings)
37 siblings, 1 reply; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-17 19:49 UTC (permalink / raw)
To: edk2-devel-groups-io
Cc: Achin Gupta, Andrew Fish, Anthony Perard, Ard Biesheuvel,
Benjamin You, Chao Zhang, Dandan Bi, David Woodhouse, Eric Dong,
Guo Dong, Hao A Wu, Jaben Carsey, Jian J Wang, Jiaxin Wu,
Jiewen Yao, Jordan Justen, Julien Grall, Leif Lindholm,
Liming Gao, Maurice Ma, Michael D Kinney, Ray Ni, Siyuan Fu,
Supreeth Venkatesh, Zhichao Gao
Unfortunately, the UEFI / PI / Shell specs define a number of handle types
as pointers to VOID. This is a design mistake; those types should have
been pointers to incomplete union or structure types. Any
pointer-to-object type converts implicitly to, and from, pointer-to-void,
which prevents compilers from catching at least the following two types of
mistakes:
- mixing up one handle type with another (for example, EFI_HANDLE with
EFI_EVENT),
- getting the depth of indirection wrong (for example, mixing up
(EFI_HANDLE*) with EFI_HANDLE).
In order to root out such mistakes in the edk2 codebase, introduce
incomplete structure types with unique tags, such as:
struct EFI_FOOBAR_OBJECT;
typedef struct EFI_FOOBAR_OBJECT *EFI_FOOBAR_HANDLE;
replacing the spec mandated
typedef VOID *EFI_FOOBAR_HANDLE;
(For some types, such as:
- EFI_ACPI_HANDLE,
- EFI_EVENT,
- EFI_FONT_HANDLE,
- EFI_HANDLE,
- EFI_HII_HANDLE,
- EFI_S3_BOOT_SCRIPT_POSITION,
- SHELL_FILE_HANDLE,
we connect the actual complete type (the internal, implementation-specific
type) to the typedef. Some of these also demonstrate how the code could
have looked in practice if the specs had used proper opaque (=incomplete)
types.)
Then, unleash "build" on the package DSC files. This causes the compiler
to warn about incompatible pointer assignments, and to stop the build.
The rest of the series addresses the resultant warnings. Each patch
belongs in one of two categories:
- semantic cleanups (no functional / behavioral changes),
- actual bugfixes.
As the subject line of this patch states, this specific patch is *not*
meant to be applied. It is just a "what if" patch that temporarily
isolates the standard types from each other, the way the specs should
have, so that the compiler have more information to work with.
Cc: Achin Gupta <achin.gupta@arm.com>
Cc: Andrew Fish <afish@apple.com>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Benjamin You <benjamin.you@intel.com>
Cc: Chao Zhang <chao.b.zhang@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Guo Dong <guo.dong@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Jian Wang <jian.j.wang@intel.com>
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien.grall@arm.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Cc: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
MdePkg/Include/Pi/PiPeiCis.h | 6 ++++--
MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h | 3 ++-
MdePkg/Include/Protocol/Bis.h | 3 ++-
MdePkg/Include/Protocol/Eap.h | 3 ++-
MdePkg/Include/Protocol/HiiFont.h | 3 +--
MdePkg/Include/Protocol/MmMp.h | 3 ++-
MdePkg/Include/Protocol/S3SaveState.h | 2 +-
MdePkg/Include/Protocol/Shell.h | 3 ++-
MdePkg/Include/Protocol/UserManager.h | 9 ++++++---
MdePkg/Include/Uefi/UefiBaseType.h | 6 ++++--
MdePkg/Include/Uefi/UefiInternalFormRepresentation.h | 3 ++-
MdeModulePkg/Core/Dxe/Event/Event.h | 2 +-
MdeModulePkg/Core/Dxe/Hand/Handle.h | 2 +-
MdeModulePkg/Core/PiSmmCore/PiSmmCore.h | 2 +-
MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h | 2 +-
MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabase.h | 2 +-
StandaloneMmPkg/Core/StandaloneMmCore.h | 2 +-
17 files changed, 34 insertions(+), 22 deletions(-)
diff --git a/MdePkg/Include/Pi/PiPeiCis.h b/MdePkg/Include/Pi/PiPeiCis.h
index d9d4ed7d413a..3e9e82b62ae9 100644
--- a/MdePkg/Include/Pi/PiPeiCis.h
+++ b/MdePkg/Include/Pi/PiPeiCis.h
@@ -18,12 +18,14 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
///
/// The handles of EFI FV.
///
-typedef VOID *EFI_PEI_FV_HANDLE;
+struct EFI_PEI_FV_OBJECT;
+typedef struct EFI_PEI_FV_OBJECT *EFI_PEI_FV_HANDLE;
///
/// The handles of EFI FFS.
///
-typedef VOID *EFI_PEI_FILE_HANDLE;
+struct EFI_PEI_FILE_OBJECT;
+typedef struct EFI_PEI_FILE_OBJECT *EFI_PEI_FILE_HANDLE;
///
/// Declare the forward reference data structure for EFI_PEI_SERVICE.
diff --git a/MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h b/MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h
index a8e0b24c6c8d..8a1863f3e03d 100644
--- a/MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h
+++ b/MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h
@@ -16,7 +16,8 @@
{ 0xeb97088e, 0xcfdf, 0x49c6, { 0xbe, 0x4b, 0xd9, 0x6, 0xa5, 0xb2, 0xe, 0x86 }}
typedef UINT32 EFI_ACPI_TABLE_VERSION;
-typedef VOID *EFI_ACPI_HANDLE;
+struct EFI_ACPI_OBJECT;
+typedef struct EFI_ACPI_OBJECT *EFI_ACPI_HANDLE;
#define EFI_ACPI_TABLE_VERSION_NONE (1 << 0)
#define EFI_ACPI_TABLE_VERSION_1_0B (1 << 1)
diff --git a/MdePkg/Include/Protocol/Bis.h b/MdePkg/Include/Protocol/Bis.h
index 2be6718f4bc2..8eca94512d03 100644
--- a/MdePkg/Include/Protocol/Bis.h
+++ b/MdePkg/Include/Protocol/Bis.h
@@ -37,7 +37,8 @@ typedef struct _EFI_BIS_PROTOCOL EFI_BIS_PROTOCOL;
//
// Basic types
//
-typedef VOID *BIS_APPLICATION_HANDLE;
+struct BIS_APPLICATION_OBJECT;
+typedef struct BIS_APPLICATION_OBJECT *BIS_APPLICATION_HANDLE;
typedef UINT16 BIS_ALG_ID;
typedef UINT32 BIS_CERT_ID;
diff --git a/MdePkg/Include/Protocol/Eap.h b/MdePkg/Include/Protocol/Eap.h
index 203d0f40b0dd..06584ef409d0 100644
--- a/MdePkg/Include/Protocol/Eap.h
+++ b/MdePkg/Include/Protocol/Eap.h
@@ -28,7 +28,8 @@ typedef struct _EFI_EAP_PROTOCOL EFI_EAP_PROTOCOL;
/// Type for the identification number assigned to the Port by the
/// System in which the Port resides.
///
-typedef VOID * EFI_PORT_HANDLE;
+struct EFI_PORT_OBJECT;
+typedef struct EFI_PORT_OBJECT *EFI_PORT_HANDLE;
///
/// EAP Authentication Method Type (RFC 3748)
diff --git a/MdePkg/Include/Protocol/HiiFont.h b/MdePkg/Include/Protocol/HiiFont.h
index 1f2e321ea4e2..450cad9ada70 100644
--- a/MdePkg/Include/Protocol/HiiFont.h
+++ b/MdePkg/Include/Protocol/HiiFont.h
@@ -19,8 +19,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
{ 0xe9ca4775, 0x8657, 0x47fc, { 0x97, 0xe7, 0x7e, 0xd6, 0x5a, 0x8, 0x43, 0x24 } }
typedef struct _EFI_HII_FONT_PROTOCOL EFI_HII_FONT_PROTOCOL;
-
-typedef VOID *EFI_FONT_HANDLE;
+typedef LIST_ENTRY *EFI_FONT_HANDLE;
///
/// EFI_HII_OUT_FLAGS.
diff --git a/MdePkg/Include/Protocol/MmMp.h b/MdePkg/Include/Protocol/MmMp.h
index beace1386cbe..cd4e0db47e08 100644
--- a/MdePkg/Include/Protocol/MmMp.h
+++ b/MdePkg/Include/Protocol/MmMp.h
@@ -36,7 +36,8 @@
//
// Completion token
//
-typedef VOID* MM_COMPLETION;
+struct MM_COMPLETION_OBJECT;
+typedef struct MM_COMPLETION_OBJECT* MM_COMPLETION;
typedef struct {
MM_COMPLETION Completion;
diff --git a/MdePkg/Include/Protocol/S3SaveState.h b/MdePkg/Include/Protocol/S3SaveState.h
index c1b8f8b9e08d..235c36be6737 100644
--- a/MdePkg/Include/Protocol/S3SaveState.h
+++ b/MdePkg/Include/Protocol/S3SaveState.h
@@ -21,7 +21,7 @@
{ 0xe857caf6, 0xc046, 0x45dc, { 0xbe, 0x3f, 0xee, 0x7, 0x65, 0xfb, 0xa8, 0x87 }}
-typedef VOID *EFI_S3_BOOT_SCRIPT_POSITION;
+typedef UINT8 *EFI_S3_BOOT_SCRIPT_POSITION;
typedef struct _EFI_S3_SAVE_STATE_PROTOCOL EFI_S3_SAVE_STATE_PROTOCOL;
diff --git a/MdePkg/Include/Protocol/Shell.h b/MdePkg/Include/Protocol/Shell.h
index cfb7878228c5..bf791792b4f2 100644
--- a/MdePkg/Include/Protocol/Shell.h
+++ b/MdePkg/Include/Protocol/Shell.h
@@ -11,12 +11,13 @@
#define __EFI_SHELL_PROTOCOL_H__
#include <Guid/FileInfo.h>
+#include <Protocol/SimpleFileSystem.h>
#define EFI_SHELL_PROTOCOL_GUID \
{ \
0x6302d008, 0x7f9b, 0x4f30, { 0x87, 0xac, 0x60, 0xc9, 0xfe, 0xf5, 0xda, 0x4e } \
}
-typedef VOID *SHELL_FILE_HANDLE;
+typedef EFI_FILE_PROTOCOL *SHELL_FILE_HANDLE;
typedef enum {
///
diff --git a/MdePkg/Include/Protocol/UserManager.h b/MdePkg/Include/Protocol/UserManager.h
index 26ac4955f1ec..9abfcffbeebf 100644
--- a/MdePkg/Include/Protocol/UserManager.h
+++ b/MdePkg/Include/Protocol/UserManager.h
@@ -24,8 +24,10 @@
0xbaf1e6de, 0x209e, 0x4adb, { 0x8d, 0x96, 0xfd, 0x8b, 0x71, 0xf3, 0xf6, 0x83 } \
}
-typedef VOID *EFI_USER_PROFILE_HANDLE;
-typedef VOID *EFI_USER_INFO_HANDLE;
+struct EFI_USER_PROFILE_OBJECT;
+typedef struct EFI_USER_PROFILE_OBJECT *EFI_USER_PROFILE_HANDLE;
+struct EFI_USER_INFO_OBJECT;
+typedef struct EFI_USER_INFO_OBJECT *EFI_USER_INFO_HANDLE;
///
/// The attributes of the user profile information.
@@ -157,7 +159,8 @@ typedef CHAR16 *EFI_USER_INFO_CREDENTIAL_PROVIDER_NAME;
/// Biometric Exchange Formats Framework) specification.
///
#define EFI_USER_INFO_CBEFF_RECORD 0x0B
-typedef VOID *EFI_USER_INFO_CBEFF;
+struct EFI_USER_INFO_CBEFF_OBJECT;
+typedef struct EFI_USER_INFO_CBEFF_OBJECT *EFI_USER_INFO_CBEFF;
///
/// Indicates how close of a match the fingerprint must be in order to be considered a match.
///
diff --git a/MdePkg/Include/Uefi/UefiBaseType.h b/MdePkg/Include/Uefi/UefiBaseType.h
index a62f13dd064f..be5831991b52 100644
--- a/MdePkg/Include/Uefi/UefiBaseType.h
+++ b/MdePkg/Include/Uefi/UefiBaseType.h
@@ -28,11 +28,13 @@ typedef RETURN_STATUS EFI_STATUS;
///
/// A collection of related interfaces.
///
-typedef VOID *EFI_HANDLE;
+struct EFI_OBJECT;
+typedef struct EFI_OBJECT *EFI_HANDLE;
///
/// Handle to an event structure.
///
-typedef VOID *EFI_EVENT;
+struct EFI_EVENT_OBJECT;
+typedef struct EFI_EVENT_OBJECT *EFI_EVENT;
///
/// Task priority level.
///
diff --git a/MdePkg/Include/Uefi/UefiInternalFormRepresentation.h b/MdePkg/Include/Uefi/UefiInternalFormRepresentation.h
index 4a1346a599d0..93bf9e9e0f13 100644
--- a/MdePkg/Include/Uefi/UefiInternalFormRepresentation.h
+++ b/MdePkg/Include/Uefi/UefiInternalFormRepresentation.h
@@ -20,7 +20,8 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
///
/// The following types are currently defined:
///
-typedef VOID* EFI_HII_HANDLE;
+struct EFI_HII_OBJECT;
+typedef struct EFI_HII_OBJECT* EFI_HII_HANDLE;
typedef CHAR16* EFI_STRING;
typedef UINT16 EFI_IMAGE_ID;
typedef UINT16 EFI_QUESTION_ID;
diff --git a/MdeModulePkg/Core/Dxe/Event/Event.h b/MdeModulePkg/Core/Dxe/Event/Event.h
index 8141c5003eec..42590cb1dd09 100644
--- a/MdeModulePkg/Core/Dxe/Event/Event.h
+++ b/MdeModulePkg/Core/Dxe/Event/Event.h
@@ -37,7 +37,7 @@ typedef struct {
} TIMER_EVENT_INFO;
#define EVENT_SIGNATURE SIGNATURE_32('e','v','n','t')
-typedef struct {
+typedef struct EFI_EVENT_OBJECT {
UINTN Signature;
UINT32 Type;
UINT32 SignalCount;
diff --git a/MdeModulePkg/Core/Dxe/Hand/Handle.h b/MdeModulePkg/Core/Dxe/Hand/Handle.h
index 83eb2b9f3afe..1f1ab3274e8a 100644
--- a/MdeModulePkg/Core/Dxe/Hand/Handle.h
+++ b/MdeModulePkg/Core/Dxe/Hand/Handle.h
@@ -15,7 +15,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
///
/// IHANDLE - contains a list of protocol handles
///
-typedef struct {
+typedef struct EFI_OBJECT {
UINTN Signature;
/// All handles list of IHANDLE
LIST_ENTRY AllHandles;
diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
index 0908e7f4e9e7..c55da58d465e 100644
--- a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
+++ b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
@@ -145,7 +145,7 @@ typedef struct {
///
/// IHANDLE - contains a list of protocol handles
///
-typedef struct {
+typedef struct EFI_OBJECT {
UINTN Signature;
/// All handles list of IHANDLE
LIST_ENTRY AllHandles;
diff --git a/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h b/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h
index 50d4c96edb63..bfebbb1f8182 100644
--- a/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h
+++ b/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h
@@ -88,7 +88,7 @@ struct _EFI_AML_NODE_LIST {
// This buffer should not be freed.
// Size is the total size of this ACPI node buffer.
//
-typedef struct {
+typedef struct EFI_ACPI_OBJECT {
UINT32 Signature;
UINT8 *Buffer;
UINTN Size;
diff --git a/MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabase.h b/MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabase.h
index 4a3feab94df5..48972d0fcad6 100644
--- a/MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabase.h
+++ b/MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabase.h
@@ -274,7 +274,7 @@ typedef struct _HII_DATABASE_PACKAGE_LIST_INSTANCE {
#define HII_HANDLE_SIGNATURE SIGNATURE_32 ('h','i','h','l')
-typedef struct {
+typedef struct EFI_HII_OBJECT {
UINTN Signature;
LIST_ENTRY Handle;
UINTN Key;
diff --git a/StandaloneMmPkg/Core/StandaloneMmCore.h b/StandaloneMmPkg/Core/StandaloneMmCore.h
index 4d0eed273f50..dcf91bc5e916 100644
--- a/StandaloneMmPkg/Core/StandaloneMmCore.h
+++ b/StandaloneMmPkg/Core/StandaloneMmCore.h
@@ -105,7 +105,7 @@ typedef struct {
///
/// IHANDLE - contains a list of protocol handles
///
-typedef struct {
+typedef struct EFI_OBJECT {
UINTN Signature;
/// All handles list of IHANDLE
LIST_ENTRY AllHandles;
--
2.19.1.3.g30247aa5d201
^ permalink raw reply related [flat|nested] 155+ messages in thread
* [PATCH 02/35] EmbeddedPkg: add missing EFIAPI calling convention specifiers
2019-09-17 19:49 [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs Laszlo Ersek
2019-09-17 19:49 ` [PATCH 01/35] DO NOT APPLY: edk2: turn standard handle types into pointers to non-VOID Laszlo Ersek
@ 2019-09-17 19:49 ` Laszlo Ersek
2019-09-18 17:41 ` Leif Lindholm
2019-09-17 19:49 ` [PATCH 03/35] EmbeddedPkg/AndroidFastbootTransportTcpDxe: fix DestroyChild() call Laszlo Ersek
` (35 subsequent siblings)
37 siblings, 1 reply; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-17 19:49 UTC (permalink / raw)
To: edk2-devel-groups-io; +Cc: Ard Biesheuvel, Leif Lindholm
This patch is unrelated to the rest of the series; it just makes sure that
"EmbeddedPkg/EmbeddedPkg.dsc" builds for all platforms advertised in
SUPPORTED_ARCHITECTURES (in particular, X64).
No functional changes.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
build-tested only
EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.h | 32 +++++++++++++++-----
EmbeddedPkg/GdbStub/GdbStubInternal.h | 9 ++++++
EmbeddedPkg/Drivers/ConsolePrefDxe/ConsolePrefDxe.c | 1 +
EmbeddedPkg/Drivers/Lan9118Dxe/Lan9118Dxe.c | 1 +
EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c | 8 +++++
EmbeddedPkg/MetronomeDxe/Metronome.c | 1 +
6 files changed, 44 insertions(+), 8 deletions(-)
diff --git a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.h b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.h
index e3db0821c38f..20636574c271 100644
--- a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.h
+++ b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.h
@@ -205,7 +205,9 @@ SataSiI3132DriverBindingStop (
IN EFI_HANDLE *ChildHandleBuffer
);
-EFI_STATUS SiI3132AtaPassThruCommand (
+EFI_STATUS
+EFIAPI
+SiI3132AtaPassThruCommand (
IN SATA_SI3132_INSTANCE *pSataSiI3132Instance,
IN SATA_SI3132_PORT *pSataPort,
IN UINT16 PortMultiplierPort,
@@ -216,7 +218,9 @@ EFI_STATUS SiI3132AtaPassThruCommand (
/**
* EFI ATA Pass Thru Protocol
*/
-EFI_STATUS SiI3132AtaPassThru (
+EFI_STATUS
+EFIAPI
+SiI3132AtaPassThru (
IN EFI_ATA_PASS_THRU_PROTOCOL *This,
IN UINT16 Port,
IN UINT16 PortMultiplierPort,
@@ -224,37 +228,49 @@ EFI_STATUS SiI3132AtaPassThru (
IN EFI_EVENT Event OPTIONAL
);
-EFI_STATUS SiI3132GetNextPort (
+EFI_STATUS
+EFIAPI
+SiI3132GetNextPort (
IN EFI_ATA_PASS_THRU_PROTOCOL *This,
IN OUT UINT16 *Port
);
-EFI_STATUS SiI3132GetNextDevice (
+EFI_STATUS
+EFIAPI
+SiI3132GetNextDevice (
IN EFI_ATA_PASS_THRU_PROTOCOL *This,
IN UINT16 Port,
IN OUT UINT16 *PortMultiplierPort
);
-EFI_STATUS SiI3132BuildDevicePath (
+EFI_STATUS
+EFIAPI
+SiI3132BuildDevicePath (
IN EFI_ATA_PASS_THRU_PROTOCOL *This,
IN UINT16 Port,
IN UINT16 PortMultiplierPort,
IN OUT EFI_DEVICE_PATH_PROTOCOL **DevicePath
);
-EFI_STATUS SiI3132GetDevice (
+EFI_STATUS
+EFIAPI
+SiI3132GetDevice (
IN EFI_ATA_PASS_THRU_PROTOCOL *This,
IN EFI_DEVICE_PATH_PROTOCOL *DevicePath,
OUT UINT16 *Port,
OUT UINT16 *PortMultiplierPort
);
-EFI_STATUS SiI3132ResetPort (
+EFI_STATUS
+EFIAPI
+SiI3132ResetPort (
IN EFI_ATA_PASS_THRU_PROTOCOL *This,
IN UINT16 Port
);
-EFI_STATUS SiI3132ResetDevice (
+EFI_STATUS
+EFIAPI
+SiI3132ResetDevice (
IN EFI_ATA_PASS_THRU_PROTOCOL *This,
IN UINT16 Port,
IN UINT16 PortMultiplierPort
diff --git a/EmbeddedPkg/GdbStub/GdbStubInternal.h b/EmbeddedPkg/GdbStub/GdbStubInternal.h
index b8346d7a545f..b08159302cfa 100644
--- a/EmbeddedPkg/GdbStub/GdbStubInternal.h
+++ b/EmbeddedPkg/GdbStub/GdbStubInternal.h
@@ -323,6 +323,7 @@ SendError (
Send 'OK' when the function is done executing successfully.
**/
VOID
+EFIAPI
SendSuccess (
VOID
);
@@ -332,6 +333,7 @@ SendSuccess (
Send empty packet to specify that particular command/functionality is not supported.
**/
VOID
+EFIAPI
SendNotSupported (
VOID
);
@@ -353,6 +355,7 @@ ReadNthRegister (
@param SystemContext Register content at time of the exception
**/
VOID
+EFIAPI
ReadGeneralRegisters (
IN EFI_SYSTEM_CONTEXT SystemContext
);
@@ -364,6 +367,7 @@ ReadGeneralRegisters (
@param InBuffer This is the input buffer received from gdb server
**/
VOID
+EFIAPI
WriteNthRegister (
IN EFI_SYSTEM_CONTEXT SystemContext,
IN CHAR8 *InBuffer
@@ -377,6 +381,7 @@ WriteNthRegister (
**/
VOID
+EFIAPI
WriteGeneralRegisters (
IN EFI_SYSTEM_CONTEXT SystemContext,
IN CHAR8 *InBuffer
@@ -391,6 +396,7 @@ WriteGeneralRegisters (
@param *PacketData Pointer to Payload data for the packet
**/
VOID
+EFIAPI
ReadFromMemory (
IN CHAR8 *PacketData
);
@@ -404,6 +410,7 @@ ReadFromMemory (
@param PacketData Pointer to Payload data for the packet
**/
VOID
+EFIAPI
WriteToMemory (
IN CHAR8 *PacketData
);
@@ -418,6 +425,7 @@ WriteToMemory (
**/
VOID
+EFIAPI
ContinueAtAddress (
IN EFI_SYSTEM_CONTEXT SystemContext,
IN CHAR8 *PacketData
@@ -432,6 +440,7 @@ ContinueAtAddress (
@param PacketData Pointer to Payload data for the packet
**/
VOID
+EFIAPI
SingleStep (
IN EFI_SYSTEM_CONTEXT SystemContext,
IN CHAR8 *PacketData
diff --git a/EmbeddedPkg/Drivers/ConsolePrefDxe/ConsolePrefDxe.c b/EmbeddedPkg/Drivers/ConsolePrefDxe/ConsolePrefDxe.c
index c250844eda74..08bba1bbf111 100644
--- a/EmbeddedPkg/Drivers/ConsolePrefDxe/ConsolePrefDxe.c
+++ b/EmbeddedPkg/Drivers/ConsolePrefDxe/ConsolePrefDxe.c
@@ -174,6 +174,7 @@ RemoveSpcrTable (
STATIC
VOID
+EFIAPI
OnReadyToBoot (
IN EFI_EVENT Event,
IN VOID *Context
diff --git a/EmbeddedPkg/Drivers/Lan9118Dxe/Lan9118Dxe.c b/EmbeddedPkg/Drivers/Lan9118Dxe/Lan9118Dxe.c
index a0fca4d6a335..2138f7576bec 100644
--- a/EmbeddedPkg/Drivers/Lan9118Dxe/Lan9118Dxe.c
+++ b/EmbeddedPkg/Drivers/Lan9118Dxe/Lan9118Dxe.c
@@ -34,6 +34,7 @@ LAN9118_DEVICE_PATH Lan9118PathTemplate = {
**
*/
EFI_STATUS
+EFIAPI
Lan9118DxeEntry (
IN EFI_HANDLE Handle,
IN EFI_SYSTEM_TABLE *SystemTable
diff --git a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c
index f6a723adfb28..0e2905c1ebb0 100644
--- a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c
+++ b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c
@@ -39,6 +39,7 @@ GetSataDevice (
}
EFI_STATUS
+EFIAPI
SiI3132AtaPassThruCommand (
IN SATA_SI3132_INSTANCE *SataSiI3132Instance,
IN SATA_SI3132_PORT *SataPort,
@@ -310,6 +311,7 @@ SiI3132AtaPassThruCommand (
**/
EFI_STATUS
+EFIAPI
SiI3132AtaPassThru (
IN EFI_ATA_PASS_THRU_PROTOCOL *This,
IN UINT16 Port,
@@ -371,6 +373,7 @@ SiI3132AtaPassThru (
**/
EFI_STATUS
+EFIAPI
SiI3132GetNextPort (
IN EFI_ATA_PASS_THRU_PROTOCOL *This,
IN OUT UINT16 *Port
@@ -442,6 +445,7 @@ SiI3132GetNextPort (
**/
EFI_STATUS
+EFIAPI
SiI3132GetNextDevice (
IN EFI_ATA_PASS_THRU_PROTOCOL *This,
IN UINT16 Port,
@@ -523,6 +527,7 @@ SiI3132GetNextDevice (
**/
EFI_STATUS
+EFIAPI
SiI3132BuildDevicePath (
IN EFI_ATA_PASS_THRU_PROTOCOL *This,
IN UINT16 Port,
@@ -601,6 +606,7 @@ SiI3132BuildDevicePath (
port number does not exist.
**/
EFI_STATUS
+EFIAPI
SiI3132GetDevice (
IN EFI_ATA_PASS_THRU_PROTOCOL *This,
IN EFI_DEVICE_PATH_PROTOCOL *DevicePath,
@@ -717,6 +723,7 @@ SiI3132HwResetPort (
**/
EFI_STATUS
+EFIAPI
SiI3132ResetPort (
IN EFI_ATA_PASS_THRU_PROTOCOL *This,
IN UINT16 Port
@@ -772,6 +779,7 @@ SiI3132ResetPort (
**/
EFI_STATUS
+EFIAPI
SiI3132ResetDevice (
IN EFI_ATA_PASS_THRU_PROTOCOL *This,
IN UINT16 Port,
diff --git a/EmbeddedPkg/MetronomeDxe/Metronome.c b/EmbeddedPkg/MetronomeDxe/Metronome.c
index 579332169507..13db25168fac 100644
--- a/EmbeddedPkg/MetronomeDxe/Metronome.c
+++ b/EmbeddedPkg/MetronomeDxe/Metronome.c
@@ -110,6 +110,7 @@ EFI_HANDLE gMetronomeHandle = NULL;
**/
EFI_STATUS
+EFIAPI
MetronomeInitialize (
IN EFI_HANDLE ImageHandle,
IN EFI_SYSTEM_TABLE *SystemTable
--
2.19.1.3.g30247aa5d201
^ permalink raw reply related [flat|nested] 155+ messages in thread
* [PATCH 03/35] EmbeddedPkg/AndroidFastbootTransportTcpDxe: fix DestroyChild() call
2019-09-17 19:49 [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs Laszlo Ersek
2019-09-17 19:49 ` [PATCH 01/35] DO NOT APPLY: edk2: turn standard handle types into pointers to non-VOID Laszlo Ersek
2019-09-17 19:49 ` [PATCH 02/35] EmbeddedPkg: add missing EFIAPI calling convention specifiers Laszlo Ersek
@ 2019-09-17 19:49 ` Laszlo Ersek
2019-09-24 10:47 ` [edk2-devel] " Philippe Mathieu-Daudé
` (2 more replies)
2019-09-17 19:49 ` [PATCH 04/35] EmbeddedPkg/Universal/MmcDxe: "fix" CloseProtocol() call in BindingStop() Laszlo Ersek
` (34 subsequent siblings)
37 siblings, 3 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-17 19:49 UTC (permalink / raw)
To: edk2-devel-groups-io; +Cc: Ard Biesheuvel, Leif Lindholm
- The 2nd parameter of EFI_SERVICE_BINDING_CREATE_CHILD is:
IN OUT EFI_HANDLE *ChildHandle
- The 2nd parameter of EFI_SERVICE_BINDING_DESTROY_CHILD is:
IN EFI_HANDLE ChildHandle
Fix the DestroyChild() call in TcpFastbootTransportStop().
This is an actual bugfix; I don't know why the current code doesn't crash.
Perhaps the function is never reached in practice? (It could be tied to an
error path.)
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
build-tested only
EmbeddedPkg/Drivers/AndroidFastbootTransportTcpDxe/FastbootTransportTcp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/EmbeddedPkg/Drivers/AndroidFastbootTransportTcpDxe/FastbootTransportTcp.c b/EmbeddedPkg/Drivers/AndroidFastbootTransportTcpDxe/FastbootTransportTcp.c
index 29f23a82c75f..34f9ba74e4db 100644
--- a/EmbeddedPkg/Drivers/AndroidFastbootTransportTcpDxe/FastbootTransportTcp.c
+++ b/EmbeddedPkg/Drivers/AndroidFastbootTransportTcpDxe/FastbootTransportTcp.c
@@ -503,7 +503,7 @@ TcpFastbootTransportStop (
Status = mTcpListener->Configure (mTcpListener, NULL);
ASSERT_EFI_ERROR (Status);
- Status = mTcpServiceBinding->DestroyChild (mTcpServiceBinding, &mTcpHandle);
+ Status = mTcpServiceBinding->DestroyChild (mTcpServiceBinding, mTcpHandle);
// Free any data the user didn't pick up
Entry = (FASTBOOT_TCP_PACKET_LIST *) GetFirstNode (&mPacketListHead);
--
2.19.1.3.g30247aa5d201
^ permalink raw reply related [flat|nested] 155+ messages in thread
* [PATCH 04/35] EmbeddedPkg/Universal/MmcDxe: "fix" CloseProtocol() call in BindingStop()
2019-09-17 19:49 [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs Laszlo Ersek
` (2 preceding siblings ...)
2019-09-17 19:49 ` [PATCH 03/35] EmbeddedPkg/AndroidFastbootTransportTcpDxe: fix DestroyChild() call Laszlo Ersek
@ 2019-09-17 19:49 ` Laszlo Ersek
2019-09-25 15:52 ` Ard Biesheuvel
2019-09-17 19:49 ` [PATCH 05/35] EmulatorPkg/DxeTimerLib: drop superfluous cast Laszlo Ersek
` (33 subsequent siblings)
37 siblings, 1 reply; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-17 19:49 UTC (permalink / raw)
To: edk2-devel-groups-io; +Cc: Ard Biesheuvel, Leif Lindholm
The 3rd and 4th parameters of the CloseProtocol() call are wrong.
Given that we're not dissociating a child controller from a parent
controller (= closing a BY_CHILD_CONTROLLER open), but closing a BY_DRIVER
open, the 4th parameter (ControllerHandle) should equal the 1st parameter
(Handle).
It's unclear why this code hasn't crashed before.
Note that the patch doesn't fix the underlying driver model bug. I don't
understand what the loop in MmcDriverBindingStop() attempts to do. Is this
driver supposed to be a bus driver? It seems to create new handles, and to
append device path nodes. But it doesn't set up proper parent/child
protocol opens, and it doesn't close them.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
build-tested only
EmbeddedPkg/Universal/MmcDxe/Mmc.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/EmbeddedPkg/Universal/MmcDxe/Mmc.c b/EmbeddedPkg/Universal/MmcDxe/Mmc.c
index 2f9ec9c7e7c1..c6170880debd 100644
--- a/EmbeddedPkg/Universal/MmcDxe/Mmc.c
+++ b/EmbeddedPkg/Universal/MmcDxe/Mmc.c
@@ -329,8 +329,9 @@ MmcDriverBindingStop (
// Close gEfiMmcHostProtocolGuid
Status = gBS->CloseProtocol (
Controller,
- &gEfiMmcHostProtocolGuid,(VOID **) &MmcHostInstance->MmcHost,
- This->DriverBindingHandle
+ &gEfiMmcHostProtocolGuid,
+ This->DriverBindingHandle,
+ Controller
);
// Remove MMC Host Instance from the pool
--
2.19.1.3.g30247aa5d201
^ permalink raw reply related [flat|nested] 155+ messages in thread
* [PATCH 05/35] EmulatorPkg/DxeTimerLib: drop superfluous cast
2019-09-17 19:49 [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs Laszlo Ersek
` (3 preceding siblings ...)
2019-09-17 19:49 ` [PATCH 04/35] EmbeddedPkg/Universal/MmcDxe: "fix" CloseProtocol() call in BindingStop() Laszlo Ersek
@ 2019-09-17 19:49 ` Laszlo Ersek
2019-09-17 20:02 ` Ni, Ray
2019-09-20 15:00 ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-17 19:49 ` [PATCH 06/35] EmulatorPkg: stop abusing EFI_HANDLE for keystroke notify registration Laszlo Ersek
` (32 subsequent siblings)
37 siblings, 2 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-17 19:49 UTC (permalink / raw)
To: edk2-devel-groups-io; +Cc: Andrew Fish, Jordan Justen, Ray Ni
"gTimerEvent" has type EFI_EVENT already, drop the superfluous cast.
Cc: Andrew Fish <afish@apple.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
build-tested only
EmulatorPkg/Library/DxeTimerLib/DxeTimerLib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/EmulatorPkg/Library/DxeTimerLib/DxeTimerLib.c b/EmulatorPkg/Library/DxeTimerLib/DxeTimerLib.c
index 14cae4214c66..6fb5d8f3aaea 100644
--- a/EmulatorPkg/Library/DxeTimerLib/DxeTimerLib.c
+++ b/EmulatorPkg/Library/DxeTimerLib/DxeTimerLib.c
@@ -40,7 +40,7 @@ RegisterTimerArchProtocol (
gTimerPeriod = MultU64x32 (gTimerPeriod, 100);
if (gTimerEvent == NULL) {
- Status = gBS->CreateEvent (EVT_TIMER, 0, NULL, NULL, (VOID **)&gTimerEvent);
+ Status = gBS->CreateEvent (EVT_TIMER, 0, NULL, NULL, &gTimerEvent);
ASSERT_EFI_ERROR (Status);
}
}
--
2.19.1.3.g30247aa5d201
^ permalink raw reply related [flat|nested] 155+ messages in thread
* [PATCH 06/35] EmulatorPkg: stop abusing EFI_HANDLE for keystroke notify registration
2019-09-17 19:49 [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs Laszlo Ersek
` (4 preceding siblings ...)
2019-09-17 19:49 ` [PATCH 05/35] EmulatorPkg/DxeTimerLib: drop superfluous cast Laszlo Ersek
@ 2019-09-17 19:49 ` Laszlo Ersek
2019-09-17 20:01 ` Ni, Ray
2019-09-24 10:44 ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-17 19:49 ` [PATCH 07/35] MdeModulePkg: fix cast in GetModuleInfoFromHandle() calls Laszlo Ersek
` (31 subsequent siblings)
37 siblings, 2 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-17 19:49 UTC (permalink / raw)
To: edk2-devel-groups-io; +Cc: Andrew Fish, Jordan Justen, Ray Ni
EFI_REGISTER_KEYSTROKE_NOTIFY and EFI_UNREGISTER_KEYSTROKE_NOTIFY require
the notification handle to have type (VOID*). The notification handle has
nothing to do with the EFI_HANDLE type.
This change is a semantic fix; functionally, it's a no-op.
Cc: Andrew Fish <afish@apple.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
build-tested only
EmulatorPkg/EmuGopDxe/GopInput.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/EmulatorPkg/EmuGopDxe/GopInput.c b/EmulatorPkg/EmuGopDxe/GopInput.c
index fdd0b4911555..2a23564a2173 100644
--- a/EmulatorPkg/EmuGopDxe/GopInput.c
+++ b/EmulatorPkg/EmuGopDxe/GopInput.c
@@ -517,7 +517,7 @@ EmuGopSimpleTextInExRegisterKeyNotify (
IN EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL *This,
IN EFI_KEY_DATA *KeyData,
IN EFI_KEY_NOTIFY_FUNCTION KeyNotificationFunction,
- OUT EFI_HANDLE *NotifyHandle
+ OUT VOID **NotifyHandle
)
{
EFI_STATUS Status;
@@ -600,7 +600,7 @@ EFI_STATUS
EFIAPI
EmuGopSimpleTextInExUnregisterKeyNotify (
IN EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL *This,
- IN EFI_HANDLE NotificationHandle
+ IN VOID *NotificationHandle
)
/*++
--
2.19.1.3.g30247aa5d201
^ permalink raw reply related [flat|nested] 155+ messages in thread
* [PATCH 07/35] MdeModulePkg: fix cast in GetModuleInfoFromHandle() calls
2019-09-17 19:49 [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs Laszlo Ersek
` (5 preceding siblings ...)
2019-09-17 19:49 ` [PATCH 06/35] EmulatorPkg: stop abusing EFI_HANDLE for keystroke notify registration Laszlo Ersek
@ 2019-09-17 19:49 ` Laszlo Ersek
2019-09-19 1:46 ` Dandan Bi
2019-09-24 10:43 ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-17 19:49 ` [PATCH 08/35] MdeModulePkg/UefiHiiLib: stop using EFI_HANDLE in place of EFI_HII_HANDLE Laszlo Ersek
` (30 subsequent siblings)
37 siblings, 2 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-17 19:49 UTC (permalink / raw)
To: edk2-devel-groups-io
Cc: Dandan Bi, Eric Dong, Hao A Wu, Jian J Wang, Liming Gao, Ray Ni
GetModuleInfoFromHandle() takes an EFI_HANDLE -- (VOID*) -- as first
parameter, but InsertFpdtRecord() passes (EFI_HANDLE*) -- (VOID**).
(VOID**) converts silently to (VOID*), which is why the wrong cast is
masked.
Note that the *value* that is passed is alright -- therefore this patch
does not change behavior --, it's just semantically wrong to pass an
(EFI_HANDLE*) where an EFI_HANDLE is expected.
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
lightly tested, as DxeCorePerformanceLib is linked into ArmVirtQemu's
DxeCore
MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c | 12 ++++++------
MdeModulePkg/Library/SmmCorePerformanceLib/SmmCorePerformanceLib.c | 8 ++++----
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c b/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c
index 0d507c445210..f500e20b320b 100644
--- a/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c
+++ b/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c
@@ -998,7 +998,7 @@ InsertFpdtRecord (
switch (PerfId) {
case MODULE_START_ID:
case MODULE_END_ID:
- GetModuleInfoFromHandle ((EFI_HANDLE *)CallerIdentifier, ModuleName, sizeof (ModuleName), &ModuleGuid);
+ GetModuleInfoFromHandle ((EFI_HANDLE)CallerIdentifier, ModuleName, sizeof (ModuleName), &ModuleGuid);
StringPtr = ModuleName;
//
// Cache the offset of start image start record and use to update the start image end record if needed.
@@ -1031,7 +1031,7 @@ InsertFpdtRecord (
case MODULE_LOADIMAGE_START_ID:
case MODULE_LOADIMAGE_END_ID:
- GetModuleInfoFromHandle ((EFI_HANDLE *)CallerIdentifier, ModuleName, sizeof (ModuleName), &ModuleGuid);
+ GetModuleInfoFromHandle ((EFI_HANDLE)CallerIdentifier, ModuleName, sizeof (ModuleName), &ModuleGuid);
StringPtr = ModuleName;
if (PerfId == MODULE_LOADIMAGE_START_ID) {
mLoadImageCount ++;
@@ -1071,7 +1071,7 @@ InsertFpdtRecord (
case MODULE_DB_SUPPORT_END_ID:
case MODULE_DB_STOP_START_ID:
case MODULE_DB_STOP_END_ID:
- GetModuleInfoFromHandle ((EFI_HANDLE *)CallerIdentifier, ModuleName, sizeof (ModuleName), &ModuleGuid);
+ GetModuleInfoFromHandle ((EFI_HANDLE)CallerIdentifier, ModuleName, sizeof (ModuleName), &ModuleGuid);
StringPtr = ModuleName;
if (!PcdGetBool (PcdEdkiiFpdtStringRecordEnableOnly)) {
FpdtRecordPtr.GuidQwordEvent->Header.Type = FPDT_GUID_QWORD_EVENT_TYPE;
@@ -1085,7 +1085,7 @@ InsertFpdtRecord (
break;
case MODULE_DB_END_ID:
- GetModuleInfoFromHandle ((EFI_HANDLE *)CallerIdentifier, ModuleName, sizeof (ModuleName), &ModuleGuid);
+ GetModuleInfoFromHandle ((EFI_HANDLE)CallerIdentifier, ModuleName, sizeof (ModuleName), &ModuleGuid);
StringPtr = ModuleName;
if (!PcdGetBool (PcdEdkiiFpdtStringRecordEnableOnly)) {
FpdtRecordPtr.GuidQwordStringEvent->Header.Type = FPDT_GUID_QWORD_STRING_EVENT_TYPE;
@@ -1131,7 +1131,7 @@ InsertFpdtRecord (
case PERF_INMODULE_END_ID:
case PERF_CROSSMODULE_START_ID:
case PERF_CROSSMODULE_END_ID:
- GetModuleInfoFromHandle ((EFI_HANDLE *)CallerIdentifier, ModuleName, sizeof (ModuleName), &ModuleGuid);
+ GetModuleInfoFromHandle ((EFI_HANDLE)CallerIdentifier, ModuleName, sizeof (ModuleName), &ModuleGuid);
if (String != NULL) {
StringPtr = String;
} else {
@@ -1153,7 +1153,7 @@ InsertFpdtRecord (
default:
if (Attribute != PerfEntry) {
- GetModuleInfoFromHandle ((EFI_HANDLE *)CallerIdentifier, ModuleName, sizeof (ModuleName), &ModuleGuid);
+ GetModuleInfoFromHandle ((EFI_HANDLE)CallerIdentifier, ModuleName, sizeof (ModuleName), &ModuleGuid);
if (String != NULL) {
StringPtr = String;
} else {
diff --git a/MdeModulePkg/Library/SmmCorePerformanceLib/SmmCorePerformanceLib.c b/MdeModulePkg/Library/SmmCorePerformanceLib/SmmCorePerformanceLib.c
index 5f07464c4ec7..b4f22c14ae73 100644
--- a/MdeModulePkg/Library/SmmCorePerformanceLib/SmmCorePerformanceLib.c
+++ b/MdeModulePkg/Library/SmmCorePerformanceLib/SmmCorePerformanceLib.c
@@ -587,7 +587,7 @@ InsertFpdtRecord (
switch (PerfId) {
case MODULE_START_ID:
case MODULE_END_ID:
- GetModuleInfoFromHandle ((EFI_HANDLE *)CallerIdentifier, ModuleName, sizeof (ModuleName), &ModuleGuid);
+ GetModuleInfoFromHandle ((EFI_HANDLE)CallerIdentifier, ModuleName, sizeof (ModuleName), &ModuleGuid);
StringPtr = ModuleName;
//
// Cache the offset of start image start record and use to update the start image end record if needed.
@@ -612,7 +612,7 @@ InsertFpdtRecord (
case MODULE_LOADIMAGE_START_ID:
case MODULE_LOADIMAGE_END_ID:
- GetModuleInfoFromHandle ((EFI_HANDLE *)CallerIdentifier, ModuleName, sizeof (ModuleName), &ModuleGuid);
+ GetModuleInfoFromHandle ((EFI_HANDLE)CallerIdentifier, ModuleName, sizeof (ModuleName), &ModuleGuid);
StringPtr = ModuleName;
if (PerfId == MODULE_LOADIMAGE_START_ID) {
mLoadImageCount++;
@@ -669,7 +669,7 @@ InsertFpdtRecord (
case PERF_INMODULE_END_ID:
case PERF_CROSSMODULE_START_ID:
case PERF_CROSSMODULE_END_ID:
- GetModuleInfoFromHandle ((EFI_HANDLE *)CallerIdentifier, ModuleName, sizeof (ModuleName), &ModuleGuid);
+ GetModuleInfoFromHandle ((EFI_HANDLE)CallerIdentifier, ModuleName, sizeof (ModuleName), &ModuleGuid);
if (String != NULL) {
StringPtr = String;
} else {
@@ -691,7 +691,7 @@ InsertFpdtRecord (
default:
if (Attribute != PerfEntry) {
- GetModuleInfoFromHandle ((EFI_HANDLE *)CallerIdentifier, ModuleName, sizeof (ModuleName), &ModuleGuid);
+ GetModuleInfoFromHandle ((EFI_HANDLE)CallerIdentifier, ModuleName, sizeof (ModuleName), &ModuleGuid);
if (String != NULL) {
StringPtr = String;
} else {
--
2.19.1.3.g30247aa5d201
^ permalink raw reply related [flat|nested] 155+ messages in thread
* [PATCH 08/35] MdeModulePkg/UefiHiiLib: stop using EFI_HANDLE in place of EFI_HII_HANDLE
2019-09-17 19:49 [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs Laszlo Ersek
` (6 preceding siblings ...)
2019-09-17 19:49 ` [PATCH 07/35] MdeModulePkg: fix cast in GetModuleInfoFromHandle() calls Laszlo Ersek
@ 2019-09-17 19:49 ` Laszlo Ersek
2019-09-19 1:46 ` Dandan Bi
2019-09-24 10:49 ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-17 19:49 ` [PATCH 09/35] MdeModulePkg: stop abusing EFI_EVENT for protocol notify registration Laszlo Ersek
` (29 subsequent siblings)
37 siblings, 2 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-17 19:49 UTC (permalink / raw)
To: edk2-devel-groups-io; +Cc: Dandan Bi, Eric Dong, Hao A Wu, Jian J Wang
HiiGetHiiHandles() returns an array of EFI_HII_HANDLEs, not EFI_HANDLEs.
HiiGetString() takes an EFI_HII_HANDLE, not an EFI_HANDLE.
This change is a no-op in practice; it's a semantic improvement.
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
lightly tested, as UefiHiiLib is used by both ArmVirt and OVMF
MdeModulePkg/Library/UefiHiiLib/HiiString.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/MdeModulePkg/Library/UefiHiiLib/HiiString.c b/MdeModulePkg/Library/UefiHiiLib/HiiString.c
index 498f245dce1f..95229f8a8c9f 100644
--- a/MdeModulePkg/Library/UefiHiiLib/HiiString.c
+++ b/MdeModulePkg/Library/UefiHiiLib/HiiString.c
@@ -173,8 +173,8 @@ HiiGetPackageString (
IN CONST CHAR8 *Language OPTIONAL
)
{
- EFI_HANDLE *HiiHandleBuffer;
- EFI_HANDLE HiiHandle;
+ EFI_HII_HANDLE *HiiHandleBuffer;
+ EFI_HII_HANDLE HiiHandle;
ASSERT (PackageListGuid != NULL);
--
2.19.1.3.g30247aa5d201
^ permalink raw reply related [flat|nested] 155+ messages in thread
* [PATCH 09/35] MdeModulePkg: stop abusing EFI_EVENT for protocol notify registration
2019-09-17 19:49 [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs Laszlo Ersek
` (7 preceding siblings ...)
2019-09-17 19:49 ` [PATCH 08/35] MdeModulePkg/UefiHiiLib: stop using EFI_HANDLE in place of EFI_HII_HANDLE Laszlo Ersek
@ 2019-09-17 19:49 ` Laszlo Ersek
2019-09-17 20:17 ` Ni, Ray
2019-09-25 16:02 ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-17 19:49 ` [PATCH 10/35] MdeModulePkg/PlatformVarCleanupLib: fix HiiConstructConfigHdr() call Laszlo Ersek
` (28 subsequent siblings)
37 siblings, 2 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-17 19:49 UTC (permalink / raw)
To: edk2-devel-groups-io
Cc: Hao A Wu, Jian J Wang, Liming Gao, Ray Ni, Zhichao Gao
EfiCreateProtocolNotifyEvent() takes a (VOID**) for "Registration",
similarly to gBS->RegisterProtocolNotify(). We should pass the address of
an actual pointer-to-VOID, and not the address of an EFI_EVENT. EFI_EVENT
just happens to be specified as (VOID*), and has nothing to do with the
registration.
The same applies to gMmst->MmRegisterProtocolNotify().
"mFtwRegistration", "mFvRegistration", and "mFvbRegistration" are used for
nothing else.
This change is a no-op in practice; it's a semantic improvement.
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
lightly tested, as these modules (except LoadFileOnFv2) are part of the
ArmVirt and/or OVMF platforms
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c | 2 +-
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c | 2 +-
MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.c | 2 +-
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c
index ae8f117905cd..de38ea028af1 100644
--- a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c
+++ b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c
@@ -47,7 +47,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
#include <Library/UefiBootServicesTableLib.h>
#include "FaultTolerantWrite.h"
-EFI_EVENT mFvbRegistration = NULL;
+VOID *mFvbRegistration = NULL;
/**
diff --git a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c
index e8e935a85b5b..9612b394865b 100644
--- a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c
+++ b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c
@@ -56,7 +56,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
#include "FaultTolerantWriteSmmCommon.h"
#include <Protocol/MmEndOfDxe.h>
-EFI_EVENT mFvbRegistration = NULL;
+VOID *mFvbRegistration = NULL;
EFI_FTW_DEVICE *mFtwDevice = NULL;
///
diff --git a/MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.c b/MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.c
index 4af2da05e145..43fa6ce12875 100644
--- a/MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.c
+++ b/MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.c
@@ -36,7 +36,7 @@ typedef struct {
#define LOAD_FILE_ON_FV2_PRIVATE_DATA_FROM_THIS(a) CR (a, LOAD_FILE_ON_FV2_PRIVATE_DATA, LoadFile, LOAD_FILE_ON_FV2_PRIVATE_DATA_SIGNATURE)
#define LOAD_FILE_ON_FV2_PRIVATE_DATA_FROM_LINK(a) CR (a, LOAD_FILE_ON_FV2_PRIVATE_DATA, Link, LOAD_FILE_ON_FV2_PRIVATE_DATA_SIGNATURE)
-EFI_EVENT mFvRegistration;
+VOID *mFvRegistration;
LIST_ENTRY mPrivateDataList;
/**
diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
index 3d232bb36cb4..7d2b6c8e1fad 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
@@ -13,7 +13,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
EFI_HANDLE mHandle = NULL;
EFI_EVENT mVirtualAddressChangeEvent = NULL;
-EFI_EVENT mFtwRegistration = NULL;
+VOID *mFtwRegistration = NULL;
VOID ***mVarCheckAddressPointer = NULL;
UINTN mVarCheckAddressPointerCount = 0;
EDKII_VARIABLE_LOCK_PROTOCOL mVariableLock = { VariableLockRequestToLock };
--
2.19.1.3.g30247aa5d201
^ permalink raw reply related [flat|nested] 155+ messages in thread
* [PATCH 10/35] MdeModulePkg/PlatformVarCleanupLib: fix HiiConstructConfigHdr() call
2019-09-17 19:49 [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs Laszlo Ersek
` (8 preceding siblings ...)
2019-09-17 19:49 ` [PATCH 09/35] MdeModulePkg: stop abusing EFI_EVENT for protocol notify registration Laszlo Ersek
@ 2019-09-17 19:49 ` Laszlo Ersek
2019-09-23 11:45 ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-17 19:49 ` [PATCH 11/35] MdeModulePkg: document workaround for EFI_RUNTIME_EVENT_ENTRY PI spec bug Laszlo Ersek
` (27 subsequent siblings)
37 siblings, 1 reply; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-17 19:49 UTC (permalink / raw)
To: edk2-devel-groups-io; +Cc: Hao A Wu, Jian J Wang, Liming Gao
The HiiConstructConfigHdr() function takes the "DriverHandle" parameter in
order to fetch the device path from it, and then turn the device path into
PATH routing information.
The HiiConstructConfigHdr() function is called from
VariableCleanupHiiExtractConfig(), which is only installed when "Type" is
"VarCleanupManually" in PlatformVarCleanup().
In that case, we create "Private->DriverHandle" as a new handle, and
install "mVarCleanupHiiVendorDevicePath" on it. Then we pass
"Private->DriverHandle" to HiiAddPackages(), which consumes the device
path for routing purposes.
It follows that the "DriverHandle" argument pased to
HiiConstructConfigHdr() should be the same driver handle, for matching
routing.
Currently we pass "Private->HiiHandle", which is clearly a typo, because
it is the return value of HiiAddPackages(), and stands for the published
HII package list.
Therefore this patch addresses an actual bug.
The typo has not been flagged by compilers because the UEFI spec
regrettably defines both EFI_HANDLE and EFI_HII_HANDLE as (VOID*).
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
build-tested only
MdeModulePkg/Library/PlatformVarCleanupLib/PlatVarCleanupLib.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/MdeModulePkg/Library/PlatformVarCleanupLib/PlatVarCleanupLib.c b/MdeModulePkg/Library/PlatformVarCleanupLib/PlatVarCleanupLib.c
index 968c044a316a..3875d614bb41 100644
--- a/MdeModulePkg/Library/PlatformVarCleanupLib/PlatVarCleanupLib.c
+++ b/MdeModulePkg/Library/PlatformVarCleanupLib/PlatVarCleanupLib.c
@@ -609,7 +609,11 @@ VariableCleanupHiiExtractConfig (
// Allocate and fill a buffer large enough to hold the <ConfigHdr> template
// followed by "&OFFSET=0&WIDTH=WWWWWWWWWWWWWWWW" followed by a Null-terminator.
//
- ConfigRequestHdr = HiiConstructConfigHdr (&mVariableCleanupHiiGuid, mVarStoreName, Private->HiiHandle);
+ ConfigRequestHdr = HiiConstructConfigHdr (
+ &mVariableCleanupHiiGuid,
+ mVarStoreName,
+ Private->DriverHandle
+ );
Size = (StrLen (ConfigRequestHdr) + 32 + 1) * sizeof (CHAR16);
ConfigRequest = AllocateZeroPool (Size);
ASSERT (ConfigRequest != NULL);
--
2.19.1.3.g30247aa5d201
^ permalink raw reply related [flat|nested] 155+ messages in thread
* [PATCH 11/35] MdeModulePkg: document workaround for EFI_RUNTIME_EVENT_ENTRY PI spec bug
2019-09-17 19:49 [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs Laszlo Ersek
` (9 preceding siblings ...)
2019-09-17 19:49 ` [PATCH 10/35] MdeModulePkg/PlatformVarCleanupLib: fix HiiConstructConfigHdr() call Laszlo Ersek
@ 2019-09-17 19:49 ` Laszlo Ersek
2019-09-19 1:47 ` Dandan Bi
2019-09-17 19:49 ` [PATCH 12/35] MdeModulePkg: stop abusing EFI_HANDLE for keystroke notify registration Laszlo Ersek
` (26 subsequent siblings)
37 siblings, 1 reply; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-17 19:49 UTC (permalink / raw)
To: edk2-devel-groups-io; +Cc: Dandan Bi, Hao A Wu, Jian J Wang, Liming Gao
The PI spec (v1.7) correctly specifies "EFI_RUNTIME_EVENT_ENTRY.Event" in
natural language, but the field type in the structure definition itself is
wrong -- it should be EFI_EVENT, not (EFI_EVENT*).
This spec bug is likely unfixable for compatibility reasons, and so edk2
works it around already. We should clearly document the workaround.
Functionally, this patch is a no-op.
(I've also requested a non-normative (informative) clarification for the
PI spec: <https://mantis.uefi.org/mantis/view.php?id=2017>.)
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
lightly tested, as these modules are part of the ArmVirt and/or OVMF
platforms
MdeModulePkg/Core/Dxe/Event/Event.c | 8 ++++++++
MdeModulePkg/Core/RuntimeDxe/Runtime.c | 10 +++++++++-
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/MdeModulePkg/Core/Dxe/Event/Event.c b/MdeModulePkg/Core/Dxe/Event/Event.c
index 21db38aaf037..c83c572c8f84 100644
--- a/MdeModulePkg/Core/Dxe/Event/Event.c
+++ b/MdeModulePkg/Core/Dxe/Event/Event.c
@@ -485,6 +485,14 @@ CoreCreateEventInternal (
IEvent->RuntimeData.NotifyTpl = NotifyTpl;
IEvent->RuntimeData.NotifyFunction = NotifyFunction;
IEvent->RuntimeData.NotifyContext = (VOID *) NotifyContext;
+ //
+ // Work around the bug in the Platform Init specification (v1.7), reported
+ // as Mantis#2017: "EFI_RUNTIME_EVENT_ENTRY.Event" should have type
+ // EFI_EVENT, not (EFI_EVENT*). The PI spec documents the field correctly
+ // as "The EFI_EVENT returned by CreateEvent()", but the type of the field
+ // doesn't match the natural language description. Therefore we need an
+ // explicit cast here.
+ //
IEvent->RuntimeData.Event = (EFI_EVENT *) IEvent;
InsertTailList (&gRuntime->EventHead, &IEvent->RuntimeData.Link);
}
diff --git a/MdeModulePkg/Core/RuntimeDxe/Runtime.c b/MdeModulePkg/Core/RuntimeDxe/Runtime.c
index c52b2b7ecf68..f7220a205d1e 100644
--- a/MdeModulePkg/Core/RuntimeDxe/Runtime.c
+++ b/MdeModulePkg/Core/RuntimeDxe/Runtime.c
@@ -285,8 +285,16 @@ RuntimeDriverSetVirtualAddressMap (
for (Link = mRuntime.EventHead.ForwardLink; Link != &mRuntime.EventHead; Link = Link->ForwardLink) {
RuntimeEvent = BASE_CR (Link, EFI_RUNTIME_EVENT_ENTRY, Link);
if ((RuntimeEvent->Type & EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE) == EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE) {
+ //
+ // Work around the bug in the Platform Init specification (v1.7),
+ // reported as Mantis#2017: "EFI_RUNTIME_EVENT_ENTRY.Event" should have
+ // type EFI_EVENT, not (EFI_EVENT*). The PI spec documents the field
+ // correctly as "The EFI_EVENT returned by CreateEvent()", but the type
+ // of the field doesn't match the natural language description. Therefore
+ // we need an explicit cast here.
+ //
RuntimeEvent->NotifyFunction (
- RuntimeEvent->Event,
+ (EFI_EVENT) RuntimeEvent->Event,
RuntimeEvent->NotifyContext
);
}
--
2.19.1.3.g30247aa5d201
^ permalink raw reply related [flat|nested] 155+ messages in thread
* [PATCH 12/35] MdeModulePkg: stop abusing EFI_HANDLE for keystroke notify registration
2019-09-17 19:49 [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs Laszlo Ersek
` (10 preceding siblings ...)
2019-09-17 19:49 ` [PATCH 11/35] MdeModulePkg: document workaround for EFI_RUNTIME_EVENT_ENTRY PI spec bug Laszlo Ersek
@ 2019-09-17 19:49 ` Laszlo Ersek
2019-09-17 20:16 ` [edk2-devel] " Ni, Ray
` (2 more replies)
2019-09-17 19:49 ` [PATCH 13/35] MdeModulePkg: PEI Core: clean up "AprioriFile" handling in FindFileEx() Laszlo Ersek
` (25 subsequent siblings)
37 siblings, 3 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-17 19:49 UTC (permalink / raw)
To: edk2-devel-groups-io
Cc: Dandan Bi, Eric Dong, Hao A Wu, Jian J Wang, Ray Ni, Zhichao Gao
EFI_REGISTER_KEYSTROKE_NOTIFY and EFI_UNREGISTER_KEYSTROKE_NOTIFY require
the notification handle to have type (VOID*). The notification handle has
nothing to do with the EFI_HANDLE type.
This change is a semantic fix; functionally, it's a no-op.
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
lightly tested: ConSplitterDxe is part of the ArmVirt and OVMF platforms
MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c | 2 +-
MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c b/MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c
index 63c814ae1816..9c38271b65f9 100644
--- a/MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c
+++ b/MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c
@@ -4026,7 +4026,7 @@ ConSplitterTextInRegisterKeyNotify (
if (NewNotify == NULL) {
return EFI_OUT_OF_RESOURCES;
}
- NewNotify->NotifyHandleList = (EFI_HANDLE *) AllocateZeroPool (sizeof (EFI_HANDLE) * Private->TextInExListCount);
+ NewNotify->NotifyHandleList = (VOID **) AllocateZeroPool (sizeof (VOID *) * Private->TextInExListCount);
if (NewNotify->NotifyHandleList == NULL) {
gBS->FreePool (NewNotify);
return EFI_OUT_OF_RESOURCES;
diff --git a/MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c b/MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c
index 7cfd5c178861..f98797225b63 100644
--- a/MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c
+++ b/MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c
@@ -143,7 +143,7 @@ InternalStartMonitor(
EFI_HANDLE *Handles;
UINTN HandleCount;
UINTN HandleIndex;
- EFI_HANDLE NotifyHandle;
+ VOID *NotifyHandle;
Status = gBS->LocateHandleBuffer (
ByProtocol,
@@ -202,7 +202,7 @@ InternalStopMonitor(
EFI_KEY_DATA KeyData;
UINTN HandleCount;
UINTN HandleIndex;
- EFI_HANDLE NotifyHandle;
+ VOID *NotifyHandle;
Status = gBS->LocateHandleBuffer (
ByProtocol,
--
2.19.1.3.g30247aa5d201
^ permalink raw reply related [flat|nested] 155+ messages in thread
* [PATCH 13/35] MdeModulePkg: PEI Core: clean up "AprioriFile" handling in FindFileEx()
2019-09-17 19:49 [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs Laszlo Ersek
` (11 preceding siblings ...)
2019-09-17 19:49 ` [PATCH 12/35] MdeModulePkg: stop abusing EFI_HANDLE for keystroke notify registration Laszlo Ersek
@ 2019-09-17 19:49 ` Laszlo Ersek
2019-09-19 1:46 ` Dandan Bi
2019-09-24 15:40 ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-17 19:49 ` [PATCH 14/35] MdeModulePkg: fix UninstallMultipleProtocolInterfaces() calls Laszlo Ersek
` (24 subsequent siblings)
37 siblings, 2 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-17 19:49 UTC (permalink / raw)
To: edk2-devel-groups-io; +Cc: Dandan Bi, Hao A Wu, Jian J Wang, Liming Gao
Clean up two issues around FindFileEx():
- The "AprioriFile" parameter's type differs between the function
declaration and the function definition. The correct type is
(EFI_PEI_FILE_HANDLE*).
- "FfsFileHeader" has type (EFI_FFS_FILE_HEADER*); for clarity, we should
cast it explicitly to EFI_PEI_FILE_HANDLE when assigning it to
(*AprioriFile).
This is a semantic cleanup, there is no functional change.
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
lightly tested: OVMF uses APRIORI PEI in the FDF files
MdeModulePkg/Core/Pei/FwVol/FwVol.h | 2 +-
MdeModulePkg/Core/Pei/FwVol/FwVol.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/MdeModulePkg/Core/Pei/FwVol/FwVol.h b/MdeModulePkg/Core/Pei/FwVol/FwVol.h
index 4082cfbec1f8..ca80e84e0fcb 100644
--- a/MdeModulePkg/Core/Pei/FwVol/FwVol.h
+++ b/MdeModulePkg/Core/Pei/FwVol/FwVol.h
@@ -299,7 +299,7 @@ FindFileEx (
IN CONST EFI_GUID *FileName, OPTIONAL
IN EFI_FV_FILETYPE SearchType,
IN OUT EFI_PEI_FILE_HANDLE *FileHandle,
- IN OUT EFI_PEI_FV_HANDLE *AprioriFile OPTIONAL
+ IN OUT EFI_PEI_FILE_HANDLE *AprioriFile OPTIONAL
);
/**
diff --git a/MdeModulePkg/Core/Pei/FwVol/FwVol.c b/MdeModulePkg/Core/Pei/FwVol/FwVol.c
index 709db00694c2..f4642c47c13a 100644
--- a/MdeModulePkg/Core/Pei/FwVol/FwVol.c
+++ b/MdeModulePkg/Core/Pei/FwVol/FwVol.c
@@ -407,7 +407,7 @@ FindFileEx (
} else if (AprioriFile != NULL) {
if (FfsFileHeader->Type == EFI_FV_FILETYPE_FREEFORM) {
if (CompareGuid (&FfsFileHeader->Name, &gPeiAprioriFileNameGuid)) {
- *AprioriFile = FfsFileHeader;
+ *AprioriFile = (EFI_PEI_FILE_HANDLE)FfsFileHeader;
}
}
}
--
2.19.1.3.g30247aa5d201
^ permalink raw reply related [flat|nested] 155+ messages in thread
* [PATCH 14/35] MdeModulePkg: fix UninstallMultipleProtocolInterfaces() calls
2019-09-17 19:49 [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs Laszlo Ersek
` (12 preceding siblings ...)
2019-09-17 19:49 ` [PATCH 13/35] MdeModulePkg: PEI Core: clean up "AprioriFile" handling in FindFileEx() Laszlo Ersek
@ 2019-09-17 19:49 ` Laszlo Ersek
2019-09-17 20:16 ` Ni, Ray
2019-09-17 19:49 ` [PATCH 15/35] MdeModulePkg/PiSmmCore: make type punning consistent Laszlo Ersek
` (23 subsequent siblings)
37 siblings, 1 reply; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-17 19:49 UTC (permalink / raw)
To: edk2-devel-groups-io; +Cc: Hao A Wu, Jian J Wang, Ray Ni
Unlike the InstallMultipleProtocolInterfaces() boot service, which takes
an (EFI_HANDLE*) as first parameter, the
UninstallMultipleProtocolInterfaces() boot service takes an EFI_HANDLE as
first parameter.
These are actual bugs. They must have remained hidden until now because
they are on error paths. Fix the UninstallMultipleProtocolInterfaces()
calls.
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
build-tested only
MdeModulePkg/Bus/I2c/I2cDxe/I2cBus.c | 2 +-
MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c | 2 +-
MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c | 6 +++---
MdeModulePkg/Bus/Pci/PciSioSerialDxe/Serial.c | 2 +-
MdeModulePkg/Bus/Sd/EmmcDxe/EmmcDxe.c | 2 +-
MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c | 2 +-
MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassImpl.c | 2 +-
7 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/MdeModulePkg/Bus/I2c/I2cDxe/I2cBus.c b/MdeModulePkg/Bus/I2c/I2cDxe/I2cBus.c
index 2b54ec51dca0..ed33a51da252 100644
--- a/MdeModulePkg/Bus/I2c/I2cDxe/I2cBus.c
+++ b/MdeModulePkg/Bus/I2c/I2cDxe/I2cBus.c
@@ -720,7 +720,7 @@ Error:
if (I2cBusContext != NULL) {
Status = gBS->UninstallMultipleProtocolInterfaces (
- &Controller,
+ Controller,
gEfiCallerIdGuid,
I2cBusContext,
NULL
diff --git a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c
index c6e401176a4b..3bde96bc9576 100644
--- a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c
+++ b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c
@@ -244,7 +244,7 @@ EnumerateNvmeDevNamespace (
);
if(EFI_ERROR(Status)) {
gBS->UninstallMultipleProtocolInterfaces (
- &Device->DeviceHandle,
+ Device->DeviceHandle,
&gEfiDevicePathProtocolGuid,
Device->DevicePath,
&gEfiBlockIoProtocolGuid,
diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c b/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c
index b7832c6970ad..292dd25da817 100644
--- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c
+++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c
@@ -313,7 +313,7 @@ RegisterPciDevice (
);
if (EFI_ERROR (Status)) {
gBS->UninstallMultipleProtocolInterfaces (
- &PciIoDevice->Handle,
+ PciIoDevice->Handle,
&gEfiDevicePathProtocolGuid,
PciIoDevice->DevicePath,
&gEfiPciIoProtocolGuid,
@@ -351,7 +351,7 @@ RegisterPciDevice (
);
if (EFI_ERROR (Status)) {
gBS->UninstallMultipleProtocolInterfaces (
- &PciIoDevice->Handle,
+ PciIoDevice->Handle,
&gEfiDevicePathProtocolGuid,
PciIoDevice->DevicePath,
&gEfiPciIoProtocolGuid,
@@ -360,7 +360,7 @@ RegisterPciDevice (
);
if (HasEfiImage) {
gBS->UninstallMultipleProtocolInterfaces (
- &PciIoDevice->Handle,
+ PciIoDevice->Handle,
&gEfiLoadFile2ProtocolGuid,
&PciIoDevice->LoadFile2,
NULL
diff --git a/MdeModulePkg/Bus/Pci/PciSioSerialDxe/Serial.c b/MdeModulePkg/Bus/Pci/PciSioSerialDxe/Serial.c
index 82db93a8b117..9fe8a482e067 100644
--- a/MdeModulePkg/Bus/Pci/PciSioSerialDxe/Serial.c
+++ b/MdeModulePkg/Bus/Pci/PciSioSerialDxe/Serial.c
@@ -665,7 +665,7 @@ CreateSerialDevice (
if (EFI_ERROR (Status)) {
gBS->UninstallMultipleProtocolInterfaces (
- &SerialDevice->Handle,
+ SerialDevice->Handle,
&gEfiDevicePathProtocolGuid, SerialDevice->DevicePath,
&gEfiSerialIoProtocolGuid, &SerialDevice->SerialIo,
NULL
diff --git a/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcDxe.c b/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcDxe.c
index 62f18d1878bd..e2ae56c5058a 100644
--- a/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcDxe.c
+++ b/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcDxe.c
@@ -475,7 +475,7 @@ InstallProtocolOnPartition (
);
if (EFI_ERROR (Status)) {
gBS->UninstallMultipleProtocolInterfaces (
- &Partition->Handle,
+ Partition->Handle,
&gEfiDevicePathProtocolGuid,
Partition->DevicePath,
&gEfiBlockIoProtocolGuid,
diff --git a/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c b/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c
index eaa0d70024bb..cc0de52de411 100644
--- a/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c
+++ b/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c
@@ -159,7 +159,7 @@ UsbCreateInterface (
if (EFI_ERROR (Status)) {
gBS->UninstallMultipleProtocolInterfaces (
- &UsbIf->Handle,
+ UsbIf->Handle,
&gEfiDevicePathProtocolGuid,
UsbIf->DevicePath,
&gEfiUsbIoProtocolGuid,
diff --git a/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassImpl.c b/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassImpl.c
index 8c27e18cdb87..0dcbc5da2cb8 100644
--- a/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassImpl.c
+++ b/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassImpl.c
@@ -575,7 +575,7 @@ UsbMassInitMultiLun (
if (EFI_ERROR (Status)) {
DEBUG ((EFI_D_ERROR, "UsbMassInitMultiLun: OpenUsbIoProtocol By Child (%r)\n", Status));
gBS->UninstallMultipleProtocolInterfaces (
- &UsbMass->Controller,
+ UsbMass->Controller,
&gEfiDevicePathProtocolGuid,
UsbMass->DevicePath,
&gEfiBlockIoProtocolGuid,
--
2.19.1.3.g30247aa5d201
^ permalink raw reply related [flat|nested] 155+ messages in thread
* [PATCH 15/35] MdeModulePkg/PiSmmCore: make type punning consistent
2019-09-17 19:49 [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs Laszlo Ersek
` (13 preceding siblings ...)
2019-09-17 19:49 ` [PATCH 14/35] MdeModulePkg: fix UninstallMultipleProtocolInterfaces() calls Laszlo Ersek
@ 2019-09-17 19:49 ` Laszlo Ersek
2019-09-18 2:38 ` Dong, Eric
2019-09-17 19:49 ` [PATCH 16/35] MdeModulePkg/S3SaveState: cast Position for S3BootScriptLib explicitly Laszlo Ersek
` (22 subsequent siblings)
37 siblings, 1 reply; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-17 19:49 UTC (permalink / raw)
To: edk2-devel-groups-io; +Cc: Eric Dong, Hao A Wu, Jian J Wang, Ray Ni
The SmiHandlerRegister() function explicitly casts "SmiHandler" (of type
(SMI_HANDLER*)) to EFI_HANDLE, when outputting "DispatchHandle".
Apply the same cast in the counterpart function SmiHandlerUnRegister(),
which compares multiple "SmiHandler"s against the input "DispatchHandle".
This is a semantic cleanup; there is no functional change.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
build-tested only, most likely -- I'm unaware of any code paths in OVMF
that would lead to SmiHandlerUnRegister()
MdeModulePkg/Core/PiSmmCore/Smi.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/MdeModulePkg/Core/PiSmmCore/Smi.c b/MdeModulePkg/Core/PiSmmCore/Smi.c
index f8bd9f49ee3c..488af6754faf 100644
--- a/MdeModulePkg/Core/PiSmmCore/Smi.c
+++ b/MdeModulePkg/Core/PiSmmCore/Smi.c
@@ -282,7 +282,7 @@ SmiHandlerUnRegister (
//
SmiHandler = NULL;
for ( HandlerLink = GetFirstNode (&mRootSmiEntry.SmiHandlers)
- ; !IsNull (&mRootSmiEntry.SmiHandlers, HandlerLink) && (SmiHandler != DispatchHandle)
+ ; !IsNull (&mRootSmiEntry.SmiHandlers, HandlerLink) && ((EFI_HANDLE) SmiHandler != DispatchHandle)
; HandlerLink = GetNextNode (&mRootSmiEntry.SmiHandlers, HandlerLink)
) {
SmiHandler = CR (HandlerLink, SMI_HANDLER, Link, SMI_HANDLER_SIGNATURE);
@@ -292,19 +292,19 @@ SmiHandlerUnRegister (
// Look for it in non-root SMI handlers
//
for ( EntryLink = GetFirstNode (&mSmiEntryList)
- ; !IsNull (&mSmiEntryList, EntryLink) && (SmiHandler != DispatchHandle)
+ ; !IsNull (&mSmiEntryList, EntryLink) && ((EFI_HANDLE) SmiHandler != DispatchHandle)
; EntryLink = GetNextNode (&mSmiEntryList, EntryLink)
) {
SmiEntry = CR (EntryLink, SMI_ENTRY, AllEntries, SMI_ENTRY_SIGNATURE);
for ( HandlerLink = GetFirstNode (&SmiEntry->SmiHandlers)
- ; !IsNull (&SmiEntry->SmiHandlers, HandlerLink) && (SmiHandler != DispatchHandle)
+ ; !IsNull (&SmiEntry->SmiHandlers, HandlerLink) && ((EFI_HANDLE) SmiHandler != DispatchHandle)
; HandlerLink = GetNextNode (&SmiEntry->SmiHandlers, HandlerLink)
) {
SmiHandler = CR (HandlerLink, SMI_HANDLER, Link, SMI_HANDLER_SIGNATURE);
}
}
- if (SmiHandler != DispatchHandle) {
+ if ((EFI_HANDLE) SmiHandler != DispatchHandle) {
return EFI_INVALID_PARAMETER;
}
--
2.19.1.3.g30247aa5d201
^ permalink raw reply related [flat|nested] 155+ messages in thread
* [PATCH 16/35] MdeModulePkg/S3SaveState: cast Position for S3BootScriptLib explicitly
2019-09-17 19:49 [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs Laszlo Ersek
` (14 preceding siblings ...)
2019-09-17 19:49 ` [PATCH 15/35] MdeModulePkg/PiSmmCore: make type punning consistent Laszlo Ersek
@ 2019-09-17 19:49 ` Laszlo Ersek
2019-09-19 1:47 ` [edk2-devel] " Dandan Bi
2019-09-17 19:49 ` [PATCH 17/35] MdePkg/DxeServicesLib: remove bogus cast Laszlo Ersek
` (21 subsequent siblings)
37 siblings, 1 reply; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-17 19:49 UTC (permalink / raw)
To: edk2-devel-groups-io
Cc: Dandan Bi, Eric Dong, Hao A Wu, Jian J Wang, Liming Gao, Ray Ni
The BootScriptInsert() and BootScriptLabel() functions take the in/out
parameter "Position" as (EFI_S3_BOOT_SCRIPT_POSITION*), and pass it to
S3BootScriptMoveLastOpcode() and S3BootScriptLabel(), respectively.
The callees take the in/out parameter "Position" as (VOID**). Add explicit
casts for clarity.
There is no change in functionality.
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
lightly tested: multiple drivers in OVMF write S3 boot script fragments
MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c | 4 ++--
MdeModulePkg/Universal/Acpi/SmmS3SaveState/SmmS3SaveState.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c b/MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c
index e94d15772d78..cfa8ebbd2f5d 100644
--- a/MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c
+++ b/MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c
@@ -810,7 +810,7 @@ BootScriptInsert (
}
if (!EFI_ERROR (Status)) {
- Status = S3BootScriptMoveLastOpcode (BeforeOrAfter, Position);
+ Status = S3BootScriptMoveLastOpcode (BeforeOrAfter, (VOID **)Position);
}
return Status;
}
@@ -851,7 +851,7 @@ BootScriptLabel (
IN CONST CHAR8 *Label
)
{
- return S3BootScriptLabel (BeforeOrAfter, CreateIfNotFound, Position, Label);
+ return S3BootScriptLabel (BeforeOrAfter, CreateIfNotFound, (VOID **)Position, Label);
}
/**
Compare two positions in the boot script table and return their relative position.
diff --git a/MdeModulePkg/Universal/Acpi/SmmS3SaveState/SmmS3SaveState.c b/MdeModulePkg/Universal/Acpi/SmmS3SaveState/SmmS3SaveState.c
index 9637df4fb82a..fc6d29e48ba9 100644
--- a/MdeModulePkg/Universal/Acpi/SmmS3SaveState/SmmS3SaveState.c
+++ b/MdeModulePkg/Universal/Acpi/SmmS3SaveState/SmmS3SaveState.c
@@ -808,7 +808,7 @@ BootScriptInsert (
}
if (!EFI_ERROR (Status)) {
- Status = S3BootScriptMoveLastOpcode (BeforeOrAfter, Position);
+ Status = S3BootScriptMoveLastOpcode (BeforeOrAfter, (VOID **)Position);
}
return Status;
}
@@ -849,7 +849,7 @@ BootScriptLabel (
IN CONST CHAR8 *Label
)
{
- return S3BootScriptLabel (BeforeOrAfter, CreateIfNotFound, Position, Label);
+ return S3BootScriptLabel (BeforeOrAfter, CreateIfNotFound, (VOID **)Position, Label);
}
/**
Compare two positions in the boot script table and return their relative position.
--
2.19.1.3.g30247aa5d201
^ permalink raw reply related [flat|nested] 155+ messages in thread
* [PATCH 17/35] MdePkg/DxeServicesLib: remove bogus cast
2019-09-17 19:49 [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs Laszlo Ersek
` (15 preceding siblings ...)
2019-09-17 19:49 ` [PATCH 16/35] MdeModulePkg/S3SaveState: cast Position for S3BootScriptLib explicitly Laszlo Ersek
@ 2019-09-17 19:49 ` Laszlo Ersek
2019-09-18 4:47 ` [edk2-devel] " Liming Gao
2019-09-24 15:38 ` Philippe Mathieu-Daudé
2019-09-17 19:49 ` [PATCH 18/35] NetworkPkg/DxeNetLib: fix type typo in NetLibGetMacAddress() Laszlo Ersek
` (20 subsequent siblings)
37 siblings, 2 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-17 19:49 UTC (permalink / raw)
To: edk2-devel-groups-io; +Cc: Liming Gao, Michael D Kinney
The HandleProtocol() boot service takes an EFI_HANDLE, not an
(EFI_HANDLE*). Remove the bogus cast in the
InternalImageHandleToFvHandle() function.
This is a semantic cleanup; there is no change in behavior.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
lightly tested, most probably: it's practically impossible to build a
platform without consuming DxeServicesLib
MdePkg/Library/DxeServicesLib/DxeServicesLib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MdePkg/Library/DxeServicesLib/DxeServicesLib.c b/MdePkg/Library/DxeServicesLib/DxeServicesLib.c
index c416b2dd8c65..0735b2f80400 100644
--- a/MdePkg/Library/DxeServicesLib/DxeServicesLib.c
+++ b/MdePkg/Library/DxeServicesLib/DxeServicesLib.c
@@ -49,7 +49,7 @@ InternalImageHandleToFvHandle (
ASSERT (ImageHandle != NULL);
Status = gBS->HandleProtocol (
- (EFI_HANDLE *) ImageHandle,
+ ImageHandle,
&gEfiLoadedImageProtocolGuid,
(VOID **) &LoadedImage
);
--
2.19.1.3.g30247aa5d201
^ permalink raw reply related [flat|nested] 155+ messages in thread
* [PATCH 18/35] NetworkPkg/DxeNetLib: fix type typo in NetLibGetMacAddress()
2019-09-17 19:49 [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs Laszlo Ersek
` (16 preceding siblings ...)
2019-09-17 19:49 ` [PATCH 17/35] MdePkg/DxeServicesLib: remove bogus cast Laszlo Ersek
@ 2019-09-17 19:49 ` Laszlo Ersek
2019-09-24 11:00 ` [edk2-devel] " Philippe Mathieu-Daudé
` (2 more replies)
2019-09-17 19:49 ` [PATCH 19/35] NetworkPkg: fix CloseProtocol & UninstallMultipleProtocolInterfaces calls Laszlo Ersek
` (19 subsequent siblings)
37 siblings, 3 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-17 19:49 UTC (permalink / raw)
To: edk2-devel-groups-io; +Cc: Jiaxin Wu, Siyuan Fu
NetLibGetSnpHandle() returns an EFI_HANDLE, not an (EFI_HANDLE*).
NetLibGetMacAddress() only uses the return value ("SnpHandle") for a
NULL-check. Fix the type of "SnpHandle".
This patch is a no-op.
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
lightly tested: MAC strings are displayed in UiApp
NetworkPkg/Library/DxeNetLib/DxeNetLib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/NetworkPkg/Library/DxeNetLib/DxeNetLib.c b/NetworkPkg/Library/DxeNetLib/DxeNetLib.c
index 8e2f720666ea..a39c20be3d34 100644
--- a/NetworkPkg/Library/DxeNetLib/DxeNetLib.c
+++ b/NetworkPkg/Library/DxeNetLib/DxeNetLib.c
@@ -2182,7 +2182,7 @@ NetLibGetMacAddress (
EFI_SIMPLE_NETWORK_MODE SnpModeData;
EFI_MANAGED_NETWORK_PROTOCOL *Mnp;
EFI_SERVICE_BINDING_PROTOCOL *MnpSb;
- EFI_HANDLE *SnpHandle;
+ EFI_HANDLE SnpHandle;
EFI_HANDLE MnpChildHandle;
ASSERT (MacAddress != NULL);
--
2.19.1.3.g30247aa5d201
^ permalink raw reply related [flat|nested] 155+ messages in thread
* [PATCH 19/35] NetworkPkg: fix CloseProtocol & UninstallMultipleProtocolInterfaces calls
2019-09-17 19:49 [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs Laszlo Ersek
` (17 preceding siblings ...)
2019-09-17 19:49 ` [PATCH 18/35] NetworkPkg/DxeNetLib: fix type typo in NetLibGetMacAddress() Laszlo Ersek
@ 2019-09-17 19:49 ` Laszlo Ersek
2019-09-26 12:14 ` [edk2-devel] " Laszlo Ersek
` (2 more replies)
2019-09-17 19:49 ` [PATCH 20/35] NetworkPkg/Ip4Dxe: fix NetLibDestroyServiceChild() call Laszlo Ersek
` (18 subsequent siblings)
37 siblings, 3 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-17 19:49 UTC (permalink / raw)
To: edk2-devel-groups-io; +Cc: Jiaxin Wu, Siyuan Fu
Both the "ControllerHandle" parameter of CloseProtocol() and the "Handle"
parameter of UninstallMultipleProtocolInterfaces() have type EFI_HANDLE,
not (EFI_HANDLE*).
This patch fixes actual bugs. The issues have been dormant likely because
they are on error paths. (Or, in case of TlsAuthConfigDxe, because the
driver is unloaded likely very infrequently.)
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
build-tested only
NetworkPkg/DnsDxe/DnsDriver.c | 4 ++--
NetworkPkg/IScsiDxe/IScsiConfig.c | 2 +-
NetworkPkg/Ip4Dxe/Ip4Driver.c | 2 +-
NetworkPkg/Ip6Dxe/Ip6Driver.c | 2 +-
NetworkPkg/Mtftp4Dxe/Mtftp4Driver.c | 2 +-
NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.c | 2 +-
6 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/NetworkPkg/DnsDxe/DnsDriver.c b/NetworkPkg/DnsDxe/DnsDriver.c
index 94d072159a4d..ad007da8b7d6 100644
--- a/NetworkPkg/DnsDxe/DnsDriver.c
+++ b/NetworkPkg/DnsDxe/DnsDriver.c
@@ -1145,7 +1145,7 @@ Dns4ServiceBindingCreateChild (
DnsSb->ConnectUdp->UdpHandle,
&gEfiUdp4ProtocolGuid,
gDns4DriverBinding.DriverBindingHandle,
- ChildHandle
+ *ChildHandle
);
gBS->UninstallMultipleProtocolInterfaces (
@@ -1388,7 +1388,7 @@ Dns6ServiceBindingCreateChild (
DnsSb->ConnectUdp->UdpHandle,
&gEfiUdp6ProtocolGuid,
gDns6DriverBinding.DriverBindingHandle,
- ChildHandle
+ *ChildHandle
);
gBS->UninstallMultipleProtocolInterfaces (
diff --git a/NetworkPkg/IScsiDxe/IScsiConfig.c b/NetworkPkg/IScsiDxe/IScsiConfig.c
index b876da7f5ccd..d773849fd3b0 100644
--- a/NetworkPkg/IScsiDxe/IScsiConfig.c
+++ b/NetworkPkg/IScsiDxe/IScsiConfig.c
@@ -3852,7 +3852,7 @@ IScsiConfigFormInit (
);
if (CallbackInfo->RegisteredHandle == NULL) {
gBS->UninstallMultipleProtocolInterfaces (
- &CallbackInfo->DriverHandle,
+ CallbackInfo->DriverHandle,
&gEfiDevicePathProtocolGuid,
&mIScsiHiiVendorDevicePath,
&gEfiHiiConfigAccessProtocolGuid,
diff --git a/NetworkPkg/Ip4Dxe/Ip4Driver.c b/NetworkPkg/Ip4Dxe/Ip4Driver.c
index ebd4dec1dfe4..62be8b681a18 100644
--- a/NetworkPkg/Ip4Dxe/Ip4Driver.c
+++ b/NetworkPkg/Ip4Dxe/Ip4Driver.c
@@ -891,7 +891,7 @@ Ip4ServiceBindingCreateChild (
);
if (EFI_ERROR (Status)) {
gBS->UninstallMultipleProtocolInterfaces (
- ChildHandle,
+ *ChildHandle,
&gEfiIp4ProtocolGuid,
&IpInstance->Ip4Proto,
NULL
diff --git a/NetworkPkg/Ip6Dxe/Ip6Driver.c b/NetworkPkg/Ip6Dxe/Ip6Driver.c
index 7dc9e45af7b6..63d8428dbced 100644
--- a/NetworkPkg/Ip6Dxe/Ip6Driver.c
+++ b/NetworkPkg/Ip6Dxe/Ip6Driver.c
@@ -888,7 +888,7 @@ Ip6ServiceBindingCreateChild (
);
if (EFI_ERROR (Status)) {
gBS->UninstallMultipleProtocolInterfaces (
- ChildHandle,
+ *ChildHandle,
&gEfiIp6ProtocolGuid,
&IpInstance->Ip6Proto,
NULL
diff --git a/NetworkPkg/Mtftp4Dxe/Mtftp4Driver.c b/NetworkPkg/Mtftp4Dxe/Mtftp4Driver.c
index ae9e65544a86..06c4e202d3ef 100644
--- a/NetworkPkg/Mtftp4Dxe/Mtftp4Driver.c
+++ b/NetworkPkg/Mtftp4Dxe/Mtftp4Driver.c
@@ -592,7 +592,7 @@ Mtftp4ServiceBindingCreateChild (
MtftpSb->ConnectUdp->UdpHandle,
&gEfiUdp4ProtocolGuid,
gMtftp4DriverBinding.DriverBindingHandle,
- ChildHandle
+ *ChildHandle
);
goto ON_ERROR;
}
diff --git a/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.c b/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.c
index 18ee763002b4..c0870ab9979c 100644
--- a/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.c
+++ b/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.c
@@ -39,7 +39,7 @@ TlsAuthConfigDxeUnload (
ASSERT (PrivateData->Signature == TLS_AUTH_CONFIG_PRIVATE_DATA_SIGNATURE);
gBS->UninstallMultipleProtocolInterfaces (
- &ImageHandle,
+ ImageHandle,
&gEfiCallerIdGuid,
PrivateData,
NULL
--
2.19.1.3.g30247aa5d201
^ permalink raw reply related [flat|nested] 155+ messages in thread
* [PATCH 20/35] NetworkPkg/Ip4Dxe: fix NetLibDestroyServiceChild() call
2019-09-17 19:49 [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs Laszlo Ersek
` (18 preceding siblings ...)
2019-09-17 19:49 ` [PATCH 19/35] NetworkPkg: fix CloseProtocol & UninstallMultipleProtocolInterfaces calls Laszlo Ersek
@ 2019-09-17 19:49 ` Laszlo Ersek
2019-09-23 16:03 ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-26 12:14 ` Laszlo Ersek
2019-09-17 19:49 ` [PATCH 21/35] NetworkPkg/TcpDxe: fix SockFreeFoo() parameter list Laszlo Ersek
` (17 subsequent siblings)
37 siblings, 2 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-17 19:49 UTC (permalink / raw)
To: edk2-devel-groups-io; +Cc: Jiaxin Wu, Siyuan Fu
Both NetLibDestroyServiceChild() and EFI_SERVICE_BINDING_DESTROY_CHILD
take an EFI_HANDLE for the "ChildHandle" parameter, not an (EFI_HANDLE*).
This patch fixes a real bug.
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
possibly only build-tested
NetworkPkg/Ip4Dxe/Ip4If.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/NetworkPkg/Ip4Dxe/Ip4If.c b/NetworkPkg/Ip4Dxe/Ip4If.c
index 44b8d9fc8faf..53a333037f94 100644
--- a/NetworkPkg/Ip4Dxe/Ip4If.c
+++ b/NetworkPkg/Ip4Dxe/Ip4If.c
@@ -592,7 +592,7 @@ Ip4SetAddress (
Interface->Controller,
Interface->Image,
&gEfiArpServiceBindingProtocolGuid,
- &Interface->ArpHandle
+ Interface->ArpHandle
);
Interface->ArpHandle = NULL;
@@ -657,7 +657,7 @@ ON_ERROR:
Interface->Controller,
Interface->Image,
&gEfiArpServiceBindingProtocolGuid,
- &Interface->ArpHandle
+ Interface->ArpHandle
);
return Status;
--
2.19.1.3.g30247aa5d201
^ permalink raw reply related [flat|nested] 155+ messages in thread
* [PATCH 21/35] NetworkPkg/TcpDxe: fix SockFreeFoo() parameter list
2019-09-17 19:49 [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs Laszlo Ersek
` (19 preceding siblings ...)
2019-09-17 19:49 ` [PATCH 20/35] NetworkPkg/Ip4Dxe: fix NetLibDestroyServiceChild() call Laszlo Ersek
@ 2019-09-17 19:49 ` Laszlo Ersek
2019-09-23 15:09 ` [edk2-devel] " Philippe Mathieu-Daudé
` (2 more replies)
2019-09-17 19:49 ` [PATCH 22/35] OvmfPkg/XenBusDxe: fix UninstallMultipleProtocolInterfaces() call Laszlo Ersek
` (16 subsequent siblings)
37 siblings, 3 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-17 19:49 UTC (permalink / raw)
To: edk2-devel-groups-io; +Cc: Jiaxin Wu, Siyuan Fu
The SockFreeFoo() callback function for NetbufFromExt() has to match the
NET_VECTOR_EXT_FREE prototype, which takes a (VOID*) as callback argument
(Arg). EFI_EVENT has nothing to do with NET_VECTOR_EXT_FREE. Fix the
SockFreeFoo() parameter list.
This change is a no-op in practice.
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
build-tested only
NetworkPkg/TcpDxe/SockImpl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/NetworkPkg/TcpDxe/SockImpl.c b/NetworkPkg/TcpDxe/SockImpl.c
index f5e01771e2a8..fb28e2ed40d3 100644
--- a/NetworkPkg/TcpDxe/SockImpl.c
+++ b/NetworkPkg/TcpDxe/SockImpl.c
@@ -67,13 +67,13 @@ SockBufNext (
/**
User provided callback function for NetbufFromExt.
- @param[in] Event The Event this notify function registered to, ignored.
+ @param[in] Arg The Arg parameter forwarded by NetbufFromExt(). Ignored.
**/
VOID
EFIAPI
SockFreeFoo (
- IN EFI_EVENT Event
+ IN VOID *Arg
)
{
return;
--
2.19.1.3.g30247aa5d201
^ permalink raw reply related [flat|nested] 155+ messages in thread
* [PATCH 22/35] OvmfPkg/XenBusDxe: fix UninstallMultipleProtocolInterfaces() call
2019-09-17 19:49 [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs Laszlo Ersek
` (20 preceding siblings ...)
2019-09-17 19:49 ` [PATCH 21/35] NetworkPkg/TcpDxe: fix SockFreeFoo() parameter list Laszlo Ersek
@ 2019-09-17 19:49 ` Laszlo Ersek
2019-09-18 9:32 ` Anthony PERARD
` (2 more replies)
2019-09-17 19:49 ` [PATCH 23/35] OvmfPkg/VirtioNetDxe: fix SignalEvent() call Laszlo Ersek
` (15 subsequent siblings)
37 siblings, 3 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-17 19:49 UTC (permalink / raw)
To: edk2-devel-groups-io
Cc: Anthony Perard, Ard Biesheuvel, Jordan Justen, Julien Grall
Unlike the InstallMultipleProtocolInterfaces() boot service, which takes
an (EFI_HANDLE*) as first parameter, the
UninstallMultipleProtocolInterfaces() boot service takes an EFI_HANDLE as
first parameter.
This is an actual bug. It must have remained hidden until now because it's
on an error path. Fix the UninstallMultipleProtocolInterfaces() call.
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien.grall@arm.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
build-tested only
OvmfPkg/XenBusDxe/XenBus.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/OvmfPkg/XenBusDxe/XenBus.c b/OvmfPkg/XenBusDxe/XenBus.c
index bb8ddbc4d44d..2451e58a5961 100644
--- a/OvmfPkg/XenBusDxe/XenBus.c
+++ b/OvmfPkg/XenBusDxe/XenBus.c
@@ -210,7 +210,7 @@ XenBusAddDevice (
ErrorOpenProtocolByChild:
gBS->UninstallMultipleProtocolInterfaces (
- &Private->Handle,
+ Private->Handle,
&gEfiDevicePathProtocolGuid, Private->DevicePath,
&gXenBusProtocolGuid, &Private->XenBusIo,
NULL);
--
2.19.1.3.g30247aa5d201
^ permalink raw reply related [flat|nested] 155+ messages in thread
* [PATCH 23/35] OvmfPkg/VirtioNetDxe: fix SignalEvent() call
2019-09-17 19:49 [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs Laszlo Ersek
` (21 preceding siblings ...)
2019-09-17 19:49 ` [PATCH 22/35] OvmfPkg/XenBusDxe: fix UninstallMultipleProtocolInterfaces() call Laszlo Ersek
@ 2019-09-17 19:49 ` Laszlo Ersek
2019-09-20 14:59 ` [edk2-devel] " Philippe Mathieu-Daudé
` (2 more replies)
2019-09-17 19:49 ` [PATCH 24/35] OvmfPkg/PlatformDxe: fix EFI_HII_HANDLE parameters of internal functions Laszlo Ersek
` (14 subsequent siblings)
37 siblings, 3 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-17 19:49 UTC (permalink / raw)
To: edk2-devel-groups-io; +Cc: Ard Biesheuvel, Jordan Justen
The SignalEvent() boot service takes an EFI_EVENT, not an (EFI_EVENT*).
Fix the call in the notification function of
"EFI_SIMPLE_NETWORK_PROTOCOL.WaitForPacket".
This is an actual bug. The reason it's never been triggered is likely that
the "SNP.WaitForPacket" event is rarely waited for by applications -- edk2
itself has zero instances of that, for example.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
build-tested only
OvmfPkg/VirtioNetDxe/Events.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/OvmfPkg/VirtioNetDxe/Events.c b/OvmfPkg/VirtioNetDxe/Events.c
index 620910774bc5..83e96e5e5d91 100644
--- a/OvmfPkg/VirtioNetDxe/Events.c
+++ b/OvmfPkg/VirtioNetDxe/Events.c
@@ -58,7 +58,7 @@ VirtioNetIsPacketAvailable (
MemoryFence ();
if (Dev->RxLastUsed != RxCurUsed) {
- gBS->SignalEvent (&Dev->Snp.WaitForPacket);
+ gBS->SignalEvent (Dev->Snp.WaitForPacket);
}
}
--
2.19.1.3.g30247aa5d201
^ permalink raw reply related [flat|nested] 155+ messages in thread
* [PATCH 24/35] OvmfPkg/PlatformDxe: fix EFI_HII_HANDLE parameters of internal functions
2019-09-17 19:49 [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs Laszlo Ersek
` (22 preceding siblings ...)
2019-09-17 19:49 ` [PATCH 23/35] OvmfPkg/VirtioNetDxe: fix SignalEvent() call Laszlo Ersek
@ 2019-09-17 19:49 ` Laszlo Ersek
2019-09-20 14:56 ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-25 15:57 ` Ard Biesheuvel
2019-09-17 19:49 ` [PATCH 25/35] OvmfPkg/VideoDxe: document EFI_EDID_OVERRIDE_PROTOCOL.GetEdid() call Laszlo Ersek
` (13 subsequent siblings)
37 siblings, 2 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-17 19:49 UTC (permalink / raw)
To: edk2-devel-groups-io; +Cc: Ard Biesheuvel, Jordan Justen
In the following call tree:
PlatformInit ()
mInstalledPackages = HiiAddPackages ()
GopInstalled ()
PopulateForm (PackageList = mInstalledPackages)
CreateResolutionOptions (PackageList)
HiiSetString (PackageList
HiiUpdateForm (PackageList)
PlatformDxe passes around an EFI_HII_HANDLE that (a) originates from
HiiAddPackages() and (b) is ultimately passed to HiiSetString() and
HiiUpdateForm(). The intermediate functions PopulateForm() and
CreateResolutionOptions() however take that parameter as an
(EFI_HII_HANDLE*).
There is no bug in practice (because the affected functions never try to
de-reference the "PackageList" parameter, they just pass it on), but the
function prototypes are semantically wrong. Fix that.
This could remain hidden so long because pointer-to-VOID silently converts
to/from any pointer-to-object type, and the UEFI spec mandates that
EFI_HII_HANDLE be a typedef to (VOID*).
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
tested in UiApp
OvmfPkg/PlatformDxe/Platform.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/OvmfPkg/PlatformDxe/Platform.c b/OvmfPkg/PlatformDxe/Platform.c
index 09181769babf..23ad43901f66 100644
--- a/OvmfPkg/PlatformDxe/Platform.c
+++ b/OvmfPkg/PlatformDxe/Platform.c
@@ -486,7 +486,7 @@ STATIC
EFI_STATUS
EFIAPI
CreateResolutionOptions (
- IN EFI_HII_HANDLE *PackageList,
+ IN EFI_HII_HANDLE PackageList,
OUT VOID **OpCodeBuffer,
IN UINTN NumGopModes,
IN GOP_MODE *GopModes
@@ -547,7 +547,7 @@ STATIC
EFI_STATUS
EFIAPI
PopulateForm (
- IN EFI_HII_HANDLE *PackageList,
+ IN EFI_HII_HANDLE PackageList,
IN EFI_GUID *FormSetGuid,
IN EFI_FORM_ID FormId,
IN UINTN NumGopModes,
--
2.19.1.3.g30247aa5d201
^ permalink raw reply related [flat|nested] 155+ messages in thread
* [PATCH 25/35] OvmfPkg/VideoDxe: document EFI_EDID_OVERRIDE_PROTOCOL.GetEdid() call
2019-09-17 19:49 [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs Laszlo Ersek
` (23 preceding siblings ...)
2019-09-17 19:49 ` [PATCH 24/35] OvmfPkg/PlatformDxe: fix EFI_HII_HANDLE parameters of internal functions Laszlo Ersek
@ 2019-09-17 19:49 ` Laszlo Ersek
2019-09-23 15:59 ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-17 19:49 ` [PATCH 26/35] SecurityPkg: fix UninstallMultipleProtocolInterfaces() calls Laszlo Ersek
` (12 subsequent siblings)
37 siblings, 1 reply; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-17 19:49 UTC (permalink / raw)
To: edk2-devel-groups-io; +Cc: Ard Biesheuvel, David Woodhouse, Jordan Justen
According to the UEFI spec -- and to the edk2 header
"MdePkg/Include/Protocol/EdidOverride.h" too --,
EFI_EDID_OVERRIDE_PROTOCOL_GET_EDID takes an (EFI_HANDLE*), and not an
EFI_HANDLE, as second parameter ("ChildHandle").
This is probably [*] a bug in the UEFI spec. Given that this CSM module
(VideoDxe) had been used for a long time on physical platforms before it
was moved to OvmfPkg, keep the current "ChildHandle" argument, just cast
it explicitly.
[*] The edk2 tree contains no other GetEdid() call, and also no GetEdid()
implementation.
The edk2-platforms tree contains two GetEdid() calls, at commit
022c212167e0, in files
- "Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/Edid.c",
- "Drivers/OptionRomPkg/CirrusLogic5430Dxe/Edid.c".
From these, the first passes an (EFI_HANDLE*) as "ChildHandle", the
second passes an EFI_HANDLE. It's difficult to draw a conclusion. :/
No functional changes.
(I've also requested a non-normative (informative) clarification for the
UEFI spec: <https://mantis.uefi.org/mantis/view.php?id=2018>, in the
direction that matches this patch.)
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
build-tested only
OvmfPkg/Csm/BiosThunk/VideoDxe/BiosVideo.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/OvmfPkg/Csm/BiosThunk/VideoDxe/BiosVideo.c b/OvmfPkg/Csm/BiosThunk/VideoDxe/BiosVideo.c
index 0640656dba14..995136adee27 100644
--- a/OvmfPkg/Csm/BiosThunk/VideoDxe/BiosVideo.c
+++ b/OvmfPkg/Csm/BiosThunk/VideoDxe/BiosVideo.c
@@ -1402,9 +1402,13 @@ BiosVideoCheckForVbe (
goto Done;
}
+ //
+ // Cast "ChildHandle" to (EFI_HANDLE*) in order to work around the spec bug
+ // in UEFI v2.8, reported as Mantis#2018.
+ //
Status = EdidOverride->GetEdid (
EdidOverride,
- BiosVideoPrivate->Handle,
+ (EFI_HANDLE *) BiosVideoPrivate->Handle,
&EdidAttributes,
&EdidOverrideDataSize,
(UINT8 **) &EdidOverrideDataBlock
--
2.19.1.3.g30247aa5d201
^ permalink raw reply related [flat|nested] 155+ messages in thread
* [PATCH 26/35] SecurityPkg: fix UninstallMultipleProtocolInterfaces() calls
2019-09-17 19:49 [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs Laszlo Ersek
` (24 preceding siblings ...)
2019-09-17 19:49 ` [PATCH 25/35] OvmfPkg/VideoDxe: document EFI_EDID_OVERRIDE_PROTOCOL.GetEdid() call Laszlo Ersek
@ 2019-09-17 19:49 ` Laszlo Ersek
2019-09-23 9:55 ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-26 12:45 ` Laszlo Ersek
2019-09-17 19:49 ` [PATCH 27/35] SecurityPkg: stop abusing EFI_EVENT for protocol notify registration Laszlo Ersek
` (11 subsequent siblings)
37 siblings, 2 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-17 19:49 UTC (permalink / raw)
To: edk2-devel-groups-io; +Cc: Chao Zhang, Jian Wang, Jiewen Yao
Unlike the InstallMultipleProtocolInterfaces() boot service, which takes
an (EFI_HANDLE*) as first parameter, the
UninstallMultipleProtocolInterfaces() boot service takes an EFI_HANDLE as
first parameter.
These are actual bugs. They must have remained hidden until now because
they are all in Unload() functions, which are probably exercised
infrequently. Fix the UninstallMultipleProtocolInterfaces() calls.
Cc: Chao Zhang <chao.b.zhang@intel.com>
Cc: Jian Wang <jian.j.wang@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
build-tested only
SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c | 2 +-
SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c | 2 +-
SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDriver.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c b/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c
index 54155a338100..9052eced757d 100644
--- a/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c
+++ b/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c
@@ -443,7 +443,7 @@ Tcg2ConfigDriverUnload (
ASSERT (PrivateData->Signature == TCG2_CONFIG_PRIVATE_DATA_SIGNATURE);
gBS->UninstallMultipleProtocolInterfaces (
- &ImageHandle,
+ ImageHandle,
&gEfiCallerIdGuid,
PrivateData,
NULL
diff --git a/SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c b/SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c
index 341879e4c4ba..fb06624fdb8f 100644
--- a/SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c
+++ b/SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c
@@ -138,7 +138,7 @@ TcgConfigDriverUnload (
ASSERT (PrivateData->Signature == TCG_CONFIG_PRIVATE_DATA_SIGNATURE);
gBS->UninstallMultipleProtocolInterfaces (
- &ImageHandle,
+ ImageHandle,
&gEfiCallerIdGuid,
PrivateData,
NULL
diff --git a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDriver.c b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDriver.c
index 798ef9cfbc01..6c0294151e6c 100644
--- a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDriver.c
+++ b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDriver.c
@@ -115,7 +115,7 @@ SecureBootConfigDriverUnload (
ASSERT (PrivateData->Signature == SECUREBOOT_CONFIG_PRIVATE_DATA_SIGNATURE);
gBS->UninstallMultipleProtocolInterfaces (
- &ImageHandle,
+ ImageHandle,
&gEfiCallerIdGuid,
PrivateData,
NULL
--
2.19.1.3.g30247aa5d201
^ permalink raw reply related [flat|nested] 155+ messages in thread
* [PATCH 27/35] SecurityPkg: stop abusing EFI_EVENT for protocol notify registration
2019-09-17 19:49 [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs Laszlo Ersek
` (25 preceding siblings ...)
2019-09-17 19:49 ` [PATCH 26/35] SecurityPkg: fix UninstallMultipleProtocolInterfaces() calls Laszlo Ersek
@ 2019-09-17 19:49 ` Laszlo Ersek
2019-09-23 9:56 ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-26 12:46 ` Laszlo Ersek
2019-09-17 19:49 ` [PATCH 28/35] ShellPkg/UefiShellDriver1CommandsLib: fix parameter list typo Laszlo Ersek
` (10 subsequent siblings)
37 siblings, 2 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-17 19:49 UTC (permalink / raw)
To: edk2-devel-groups-io; +Cc: Chao Zhang, Jian Wang, Jiewen Yao
EfiCreateProtocolNotifyEvent() takes a (VOID**) for "Registration",
similarly to gBS->RegisterProtocolNotify(). We should pass the address of
an actual pointer-to-VOID, and not the address of an EFI_EVENT. EFI_EVENT
just happens to be specified as (VOID*), and has nothing to do with the
registration.
This change is a no-op in practice; it's a semantic improvement.
Cc: Chao Zhang <chao.b.zhang@intel.com>
Cc: Jian Wang <jian.j.wang@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
build-tested only
SecurityPkg/HddPassword/HddPasswordDxe.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/SecurityPkg/HddPassword/HddPasswordDxe.c b/SecurityPkg/HddPassword/HddPasswordDxe.c
index b0d795b6597f..051e64091d7f 100644
--- a/SecurityPkg/HddPassword/HddPasswordDxe.c
+++ b/SecurityPkg/HddPassword/HddPasswordDxe.c
@@ -2770,7 +2770,7 @@ HddPasswordDxeInit (
{
EFI_STATUS Status;
HDD_PASSWORD_DXE_PRIVATE_DATA *Private;
- EFI_EVENT Registration;
+ VOID *Registration;
EFI_EVENT EndOfDxeEvent;
EDKII_VARIABLE_LOCK_PROTOCOL *VariableLock;
--
2.19.1.3.g30247aa5d201
^ permalink raw reply related [flat|nested] 155+ messages in thread
* [PATCH 28/35] ShellPkg/UefiShellDriver1CommandsLib: fix parameter list typo
2019-09-17 19:49 [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs Laszlo Ersek
` (26 preceding siblings ...)
2019-09-17 19:49 ` [PATCH 27/35] SecurityPkg: stop abusing EFI_EVENT for protocol notify registration Laszlo Ersek
@ 2019-09-17 19:49 ` Laszlo Ersek
2019-09-24 15:44 ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-26 2:46 ` Gao, Zhichao
2019-09-17 19:49 ` [PATCH 29/35] ShellPkg: stop using EFI_HANDLE in place of EFI_HII_HANDLE Laszlo Ersek
` (9 subsequent siblings)
37 siblings, 2 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-17 19:49 UTC (permalink / raw)
To: edk2-devel-groups-io; +Cc: Jaben Carsey, Ray Ni, Zhichao Gao
The ShellCommandRunConnect() function passes EFI_HANDLE -- (VOID*) --
objects to ConvertAndConnectControllers(), and
ConvertAndConnectControllers() passes those to gBS->OpenProtocol().
Accordingly, ConvertAndConnectControllers() should specify EFI_HANDLE
parameter types, not (EFI_HANDLE*) -- (VOID**) -- types.
This typo is masked because (VOID*) converts to and from any
pointer-to-object type silently.
Note that functionally speaking there is no problem, so this patch does
not change beavior, only cleans up the code.
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
tested with "connect -r"
ShellPkg/Library/UefiShellDriver1CommandsLib/Connect.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/ShellPkg/Library/UefiShellDriver1CommandsLib/Connect.c b/ShellPkg/Library/UefiShellDriver1CommandsLib/Connect.c
index 359394dfd291..3f4e132674ea 100644
--- a/ShellPkg/Library/UefiShellDriver1CommandsLib/Connect.c
+++ b/ShellPkg/Library/UefiShellDriver1CommandsLib/Connect.c
@@ -346,8 +346,8 @@ ShellConnectFromDevPaths (
**/
EFI_STATUS
ConvertAndConnectControllers (
- IN EFI_HANDLE *Handle1 OPTIONAL,
- IN EFI_HANDLE *Handle2 OPTIONAL,
+ IN EFI_HANDLE Handle1 OPTIONAL,
+ IN EFI_HANDLE Handle2 OPTIONAL,
IN CONST BOOLEAN Recursive,
IN CONST BOOLEAN Output
)
--
2.19.1.3.g30247aa5d201
^ permalink raw reply related [flat|nested] 155+ messages in thread
* [PATCH 29/35] ShellPkg: stop using EFI_HANDLE in place of EFI_HII_HANDLE
2019-09-17 19:49 [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs Laszlo Ersek
` (27 preceding siblings ...)
2019-09-17 19:49 ` [PATCH 28/35] ShellPkg/UefiShellDriver1CommandsLib: fix parameter list typo Laszlo Ersek
@ 2019-09-17 19:49 ` Laszlo Ersek
2019-09-25 18:04 ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-26 2:43 ` Gao, Zhichao
2019-09-17 19:49 ` [PATCH 30/35] ShellPkg: stop taking EFI_HANDLE in place of SHELL_FILE_HANDLE Laszlo Ersek
` (8 subsequent siblings)
37 siblings, 2 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-17 19:49 UTC (permalink / raw)
To: edk2-devel-groups-io; +Cc: Jaben Carsey, Ray Ni, Zhichao Gao
The UefiShell*CommandsLib instances have constructor functions that do
something like:
gHiiHandle = HiiAddPackages (...);
...
ShellCommandRegisterCommandName (..., gHiiHandle, ...);
and destructor functions that implement the following pattern:
HiiRemovePackages (gHiiHandle);
The -- semantic, not functional -- problem is that "gHiiHandle" is
declared with type EFI_HANDLE, and not EFI_HII_HANDLE, in all of these
library instances, even though HiiAddPackages() correctly returns
EFI_HII_HANDLE, and HiiRemovePackages() takes EFI_HII_HANDLE.
Once we fix the type of "gHiiHandle", it causes sort of a butterfly
effect, because it is passed around widely. Track down and update all of
those locations.
The DynamicCommand lib instances use a similar pattern, so they are
affected too.
NOTE: in practice, this patch is a no-op, as both EFI_HII_HANDLE and
EFI_HANDLE are typedefs to (VOID*). However, we shouldn't use EFI_HANDLE
where semantically EFI_HII_HANDLE is passed around.
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
tested with:
- level 1: stall, exit
- level 2: ls
- level 3: pause
- dynamic command: tftp
- handle parsing: drivers, devices, dh
ShellPkg/Include/Library/ShellCommandLib.h | 2 +-
ShellPkg/Include/Library/ShellLib.h | 4 ++--
ShellPkg/DynamicCommand/DpDynamicCommand/Dp.h | 4 ++--
ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.h | 4 ++--
ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.h | 2 +-
ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.h | 2 +-
ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.h | 2 +-
ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.h | 2 +-
ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.h | 2 +-
ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.h | 2 +-
ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.h | 2 +-
ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.h | 2 +-
ShellPkg/DynamicCommand/DpDynamicCommand/Dp.c | 6 +++---
ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c | 6 +++---
ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c | 2 +-
ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c | 2 +-
ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c | 2 +-
ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.c | 2 +-
ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.c | 2 +-
ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.c | 2 +-
ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.c | 2 +-
ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.c | 2 +-
ShellPkg/Library/UefiShellLib/UefiShellLib.c | 4 ++--
ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.c | 2 +-
ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.c | 2 +-
25 files changed, 33 insertions(+), 33 deletions(-)
diff --git a/ShellPkg/Include/Library/ShellCommandLib.h b/ShellPkg/Include/Library/ShellCommandLib.h
index 287bc0eba7f9..63fcac82a2de 100644
--- a/ShellPkg/Include/Library/ShellCommandLib.h
+++ b/ShellPkg/Include/Library/ShellCommandLib.h
@@ -136,7 +136,7 @@ ShellCommandRegisterCommandName (
IN UINT32 ShellMinSupportLevel,
IN CONST CHAR16 *ProfileName,
IN CONST BOOLEAN CanAffectLE,
- IN CONST EFI_HANDLE HiiHandle,
+ IN CONST EFI_HII_HANDLE HiiHandle,
IN CONST EFI_STRING_ID ManFormatHelp
);
diff --git a/ShellPkg/Include/Library/ShellLib.h b/ShellPkg/Include/Library/ShellLib.h
index 31594796cd21..1dc41f2cc11b 100644
--- a/ShellPkg/Include/Library/ShellLib.h
+++ b/ShellPkg/Include/Library/ShellLib.h
@@ -965,7 +965,7 @@ ShellPrintHiiEx(
IN INT32 Row OPTIONAL,
IN CONST CHAR8 *Language OPTIONAL,
IN CONST EFI_STRING_ID HiiFormatStringId,
- IN CONST EFI_HANDLE HiiFormatHandle,
+ IN CONST EFI_HII_HANDLE HiiFormatHandle,
...
);
@@ -1260,7 +1260,7 @@ EFIAPI
ShellPromptForResponseHii (
IN SHELL_PROMPT_REQUEST_TYPE Type,
IN CONST EFI_STRING_ID HiiFormatStringId,
- IN CONST EFI_HANDLE HiiFormatHandle,
+ IN CONST EFI_HII_HANDLE HiiFormatHandle,
IN OUT VOID **Response
);
diff --git a/ShellPkg/DynamicCommand/DpDynamicCommand/Dp.h b/ShellPkg/DynamicCommand/DpDynamicCommand/Dp.h
index 43aa4505ee37..e446cccde923 100644
--- a/ShellPkg/DynamicCommand/DpDynamicCommand/Dp.h
+++ b/ShellPkg/DynamicCommand/DpDynamicCommand/Dp.h
@@ -36,7 +36,7 @@
#include <Library/UefiHiiServicesLib.h>
#include <Library/PerformanceLib.h>
-extern EFI_HANDLE mDpHiiHandle;
+extern EFI_HII_HANDLE mDpHiiHandle;
#define DP_MAJOR_VERSION 2
#define DP_MINOR_VERSION 5
@@ -133,7 +133,7 @@ RunDp (
@return HII handle.
**/
-EFI_HANDLE
+EFI_HII_HANDLE
InitializeHiiPackage (
EFI_HANDLE ImageHandle
);
diff --git a/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.h b/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.h
index 7a9ed4724e1f..4cd778436813 100644
--- a/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.h
+++ b/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.h
@@ -30,7 +30,7 @@
#include <Library/PrintLib.h>
#include <Library/UefiHiiServicesLib.h>
-extern EFI_HANDLE mTftpHiiHandle;
+extern EFI_HII_HANDLE mTftpHiiHandle;
typedef struct {
UINTN FileSize;
@@ -62,7 +62,7 @@ RunTftp (
@return HII handle.
**/
-EFI_HANDLE
+EFI_HII_HANDLE
InitializeHiiPackage (
EFI_HANDLE ImageHandle
);
diff --git a/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.h b/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.h
index 36fe628a8c68..8ecc2f6bf5a2 100644
--- a/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.h
+++ b/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.h
@@ -46,7 +46,7 @@ typedef struct{
SHELL_GET_MAN_FILENAME GetManFileName;
SHELL_RUN_COMMAND CommandHandler;
BOOLEAN LastError;
- EFI_HANDLE HiiHandle;
+ EFI_HII_HANDLE HiiHandle;
EFI_STRING_ID ManFormatHelp;
} SHELL_COMMAND_INTERNAL_LIST_ENTRY;
diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.h b/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.h
index 32a933b9f062..082d488cb283 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.h
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.h
@@ -52,7 +52,7 @@
#include <Library/HandleParsingLib.h>
-extern EFI_HANDLE gShellDebug1HiiHandle;
+extern EFI_HII_HANDLE gShellDebug1HiiHandle;
/**
Function returns a system configuration table that is stored in the
diff --git a/ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.h b/ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.h
index 7e0b8b094057..ee795c4ce024 100644
--- a/ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.h
+++ b/ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.h
@@ -58,7 +58,7 @@
#include <Library/HandleParsingLib.h>
-extern EFI_HANDLE gShellDriver1HiiHandle;
+extern EFI_HII_HANDLE gShellDriver1HiiHandle;
extern BOOLEAN gInReconnect;
/**
diff --git a/ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.h b/ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.h
index 55acdd2b1f95..f2f9cc5dcf3b 100644
--- a/ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.h
+++ b/ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.h
@@ -33,7 +33,7 @@
#include <Library/HiiLib.h>
#include <Library/FileHandleLib.h>
-extern EFI_HANDLE gShellLevel1HiiHandle;
+extern EFI_HII_HANDLE gShellLevel1HiiHandle;
/**
Function for 'stall' command.
diff --git a/ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.h b/ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.h
index 6d522d4bb4a1..77be6f1a12c7 100644
--- a/ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.h
+++ b/ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.h
@@ -43,7 +43,7 @@
#include <Library/FileHandleLib.h>
extern CONST CHAR16 mFileName[];
-extern EFI_HANDLE gShellLevel2HiiHandle;
+extern EFI_HII_HANDLE gShellLevel2HiiHandle;
/**
Function for 'attrib' command.
diff --git a/ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.h b/ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.h
index 2d97ae4d3c91..c095b9275ed0 100644
--- a/ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.h
+++ b/ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.h
@@ -32,7 +32,7 @@
#include <Library/HiiLib.h>
#include <Library/FileHandleLib.h>
-extern EFI_HANDLE gShellLevel3HiiHandle;
+extern EFI_HII_HANDLE gShellLevel3HiiHandle;
/**
Function for 'type' command.
diff --git a/ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.h b/ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.h
index d4ed8c04652d..fddada2efa48 100644
--- a/ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.h
+++ b/ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.h
@@ -38,7 +38,7 @@
#include <Library/DevicePathLib.h>
#include <Library/PrintLib.h>
-extern EFI_HANDLE gShellNetwork1HiiHandle;
+extern EFI_HII_HANDLE gShellNetwork1HiiHandle;
/**
Function for 'ping' command.
diff --git a/ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.h b/ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.h
index 9a5db32f2b76..9ea42cf26d53 100644
--- a/ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.h
+++ b/ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.h
@@ -27,7 +27,7 @@
#include <Library/HiiLib.h>
#include <Library/NetLib.h>
-extern EFI_HANDLE gShellNetwork2HiiHandle;
+extern EFI_HII_HANDLE gShellNetwork2HiiHandle;
/**
Function for 'ping6' command.
diff --git a/ShellPkg/DynamicCommand/DpDynamicCommand/Dp.c b/ShellPkg/DynamicCommand/DpDynamicCommand/Dp.c
index 735cdcbcc018..4ec4c18348bd 100644
--- a/ShellPkg/DynamicCommand/DpDynamicCommand/Dp.c
+++ b/ShellPkg/DynamicCommand/DpDynamicCommand/Dp.c
@@ -36,7 +36,7 @@ typedef struct {
#pragma pack()
-EFI_HANDLE mDpHiiHandle;
+EFI_HII_HANDLE mDpHiiHandle;
typedef struct {
EFI_HANDLE Handle;
@@ -924,14 +924,14 @@ Done:
@return HII handle.
**/
-EFI_HANDLE
+EFI_HII_HANDLE
InitializeHiiPackage (
EFI_HANDLE ImageHandle
)
{
EFI_STATUS Status;
EFI_HII_PACKAGE_LIST_HEADER *PackageList;
- EFI_HANDLE HiiHandle;
+ EFI_HII_HANDLE HiiHandle;
//
// Retrieve HII package list from ImageHandle
diff --git a/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c b/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c
index 607899032e9d..f28da9af723c 100644
--- a/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c
+++ b/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c
@@ -11,7 +11,7 @@
#include "Tftp.h"
#define IP4_CONFIG2_INTERFACE_INFO_NAME_LENGTH 32
-EFI_HANDLE mTftpHiiHandle;
+EFI_HII_HANDLE mTftpHiiHandle;
/*
Constant strings and definitions related to the message indicating the amount of
@@ -1087,14 +1087,14 @@ CheckPacket (
@return HII handle.
**/
-EFI_HANDLE
+EFI_HII_HANDLE
InitializeHiiPackage (
EFI_HANDLE ImageHandle
)
{
EFI_STATUS Status;
EFI_HII_PACKAGE_LIST_HEADER *PackageList;
- EFI_HANDLE HiiHandle;
+ EFI_HII_HANDLE HiiHandle;
//
// Retrieve HII package list from ImageHandle
diff --git a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
index f179c4109223..f62d30ef677a 100644
--- a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
+++ b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
@@ -14,7 +14,7 @@
#include <PiDxe.h>
#include <Protocol/FirmwareVolume2.h>
-EFI_HANDLE mHandleParsingHiiHandle = NULL;
+EFI_HII_HANDLE mHandleParsingHiiHandle = NULL;
HANDLE_INDEX_LIST mHandleList = {{{NULL,NULL},0,0},0};
GUID_INFO_BLOCK *mGuidList;
UINTN mGuidListCount;
diff --git a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
index e8b48b4990dd..f8bcaebe46c8 100644
--- a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
+++ b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
@@ -38,7 +38,7 @@
#include <Library/UefiBootManagerLib.h>
STATIC CONST CHAR16 mFileName[] = L"ShellCommands";
-STATIC EFI_HANDLE gShellBcfgHiiHandle = NULL;
+STATIC EFI_HII_HANDLE gShellBcfgHiiHandle = NULL;
typedef enum {
BcfgTargetBootOrder = 0,
diff --git a/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c b/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c
index 826ced30a8c8..4c48b65fbc1d 100644
--- a/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c
+++ b/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c
@@ -554,7 +554,7 @@ ShellCommandRegisterCommandName (
IN UINT32 ShellMinSupportLevel,
IN CONST CHAR16 *ProfileName,
IN CONST BOOLEAN CanAffectLE,
- IN CONST EFI_HANDLE HiiHandle,
+ IN CONST EFI_HII_HANDLE HiiHandle,
IN CONST EFI_STRING_ID ManFormatHelp
)
{
diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.c b/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.c
index ddce3bef5a30..f918867f47af 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.c
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.c
@@ -10,7 +10,7 @@
#include <Library/BcfgCommandLib.h>
STATIC CONST CHAR16 mFileName[] = L"Debug1Commands";
-EFI_HANDLE gShellDebug1HiiHandle = NULL;
+EFI_HII_HANDLE gShellDebug1HiiHandle = NULL;
/**
Gets the debug file name. This will be used if HII is not working.
diff --git a/ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.c b/ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.c
index 4a05fa9942c4..e2219c62ec25 100644
--- a/ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.c
+++ b/ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.c
@@ -9,7 +9,7 @@
#include "UefiShellDriver1CommandsLib.h"
STATIC CONST CHAR16 mFileName[] = L"Driver1Commands";
-EFI_HANDLE gShellDriver1HiiHandle = NULL;
+EFI_HII_HANDLE gShellDriver1HiiHandle = NULL;
BOOLEAN gInReconnect = FALSE;
/**
diff --git a/ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.c b/ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.c
index ecbee99e3b3d..88cddd88ddc4 100644
--- a/ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.c
+++ b/ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.c
@@ -10,7 +10,7 @@
#include "UefiShellLevel1CommandsLib.h"
STATIC CONST CHAR16 mFileName[] = L"ShellCommands";
-EFI_HANDLE gShellLevel1HiiHandle = NULL;
+EFI_HII_HANDLE gShellLevel1HiiHandle = NULL;
/**
Return the help text filename. Only used if no HII information found.
diff --git a/ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.c b/ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.c
index c2a0bb492fbb..69427637bb87 100644
--- a/ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.c
+++ b/ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.c
@@ -29,7 +29,7 @@
#include "UefiShellLevel2CommandsLib.h"
CONST CHAR16 mFileName[] = L"ShellCommands";
-EFI_HANDLE gShellLevel2HiiHandle = NULL;
+EFI_HII_HANDLE gShellLevel2HiiHandle = NULL;
/**
Get the filename to get help text from if not using HII.
diff --git a/ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.c b/ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.c
index 7d2cc4a48371..ce4afd117aa1 100644
--- a/ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.c
+++ b/ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.c
@@ -9,7 +9,7 @@
#include "UefiShellLevel3CommandsLib.h"
CONST CHAR16 gShellLevel3FileName[] = L"ShellCommands";
-EFI_HANDLE gShellLevel3HiiHandle = NULL;
+EFI_HII_HANDLE gShellLevel3HiiHandle = NULL;
/**
return the filename to get help from is not using HII.
diff --git a/ShellPkg/Library/UefiShellLib/UefiShellLib.c b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
index 5be530092e1b..835d0f88ca74 100644
--- a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
+++ b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
@@ -2997,7 +2997,7 @@ ShellPrintHiiEx(
IN INT32 Row OPTIONAL,
IN CONST CHAR8 *Language OPTIONAL,
IN CONST EFI_STRING_ID HiiFormatStringId,
- IN CONST EFI_HANDLE HiiFormatHandle,
+ IN CONST EFI_HII_HANDLE HiiFormatHandle,
...
)
{
@@ -3609,7 +3609,7 @@ EFIAPI
ShellPromptForResponseHii (
IN SHELL_PROMPT_REQUEST_TYPE Type,
IN CONST EFI_STRING_ID HiiFormatStringId,
- IN CONST EFI_HANDLE HiiFormatHandle,
+ IN CONST EFI_HII_HANDLE HiiFormatHandle,
IN OUT VOID **Response
)
{
diff --git a/ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.c b/ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.c
index 7e823cabd2fe..9a2b23fdc5ba 100644
--- a/ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.c
+++ b/ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.c
@@ -8,7 +8,7 @@
#include "UefiShellNetwork1CommandsLib.h"
CONST CHAR16 gShellNetwork1FileName[] = L"ShellCommands";
-EFI_HANDLE gShellNetwork1HiiHandle = NULL;
+EFI_HII_HANDLE gShellNetwork1HiiHandle = NULL;
/**
return the file name of the help text file if not using HII.
diff --git a/ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.c b/ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.c
index 5a7ffbfa19eb..4aab4295c1ba 100644
--- a/ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.c
+++ b/ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.c
@@ -8,7 +8,7 @@
#include "UefiShellNetwork2CommandsLib.h"
CONST CHAR16 gShellNetwork2FileName[] = L"ShellCommands";
-EFI_HANDLE gShellNetwork2HiiHandle = NULL;
+EFI_HII_HANDLE gShellNetwork2HiiHandle = NULL;
/**
return the file name of the help text file if not using HII.
--
2.19.1.3.g30247aa5d201
^ permalink raw reply related [flat|nested] 155+ messages in thread
* [PATCH 30/35] ShellPkg: stop taking EFI_HANDLE in place of SHELL_FILE_HANDLE
2019-09-17 19:49 [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs Laszlo Ersek
` (28 preceding siblings ...)
2019-09-17 19:49 ` [PATCH 29/35] ShellPkg: stop using EFI_HANDLE in place of EFI_HII_HANDLE Laszlo Ersek
@ 2019-09-17 19:49 ` Laszlo Ersek
2019-09-23 9:58 ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-26 2:53 ` Gao, Zhichao
2019-09-17 19:49 ` [PATCH 31/35] ShellPkg/UefiShellDebug1CommandsLib: fix ShellCloseFile() call Laszlo Ersek
` (7 subsequent siblings)
37 siblings, 2 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-17 19:49 UTC (permalink / raw)
To: edk2-devel-groups-io; +Cc: Jaben Carsey, Ray Ni, Zhichao Gao
The TouchFileByHandle() and IsDirectoryEmpty() functions are passed
SHELL_FILE_HANDLE parameters, and they use those parameters correctly.
However, their parameter lists say EFI_HANDLE.
Spell out the right type in the parameter lists.
In practice, this change is a no-op (because, quite regrettably, both
EFI_HANDLE and SHELL_FILE_HANDLE are specified to be typedefs of (VOID*)).
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
tested: rm, touch
ShellPkg/Library/UefiShellLevel2CommandsLib/Rm.c | 2 +-
ShellPkg/Library/UefiShellLevel3CommandsLib/Touch.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/ShellPkg/Library/UefiShellLevel2CommandsLib/Rm.c b/ShellPkg/Library/UefiShellLevel2CommandsLib/Rm.c
index 3a1196f1529e..59f7eec376f2 100644
--- a/ShellPkg/Library/UefiShellLevel2CommandsLib/Rm.c
+++ b/ShellPkg/Library/UefiShellLevel2CommandsLib/Rm.c
@@ -24,7 +24,7 @@ STATIC CONST SHELL_PARAM_ITEM ParamList[] = {
**/
BOOLEAN
IsDirectoryEmpty (
- IN EFI_HANDLE FileHandle
+ IN SHELL_FILE_HANDLE FileHandle
)
{
EFI_STATUS Status;
diff --git a/ShellPkg/Library/UefiShellLevel3CommandsLib/Touch.c b/ShellPkg/Library/UefiShellLevel3CommandsLib/Touch.c
index 0f00344c815e..a215f5774c69 100644
--- a/ShellPkg/Library/UefiShellLevel3CommandsLib/Touch.c
+++ b/ShellPkg/Library/UefiShellLevel3CommandsLib/Touch.c
@@ -21,7 +21,7 @@
**/
EFI_STATUS
TouchFileByHandle (
- IN EFI_HANDLE Handle
+ IN SHELL_FILE_HANDLE Handle
)
{
EFI_STATUS Status;
--
2.19.1.3.g30247aa5d201
^ permalink raw reply related [flat|nested] 155+ messages in thread
* [PATCH 31/35] ShellPkg/UefiShellDebug1CommandsLib: fix ShellCloseFile() call
2019-09-17 19:49 [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs Laszlo Ersek
` (29 preceding siblings ...)
2019-09-17 19:49 ` [PATCH 30/35] ShellPkg: stop taking EFI_HANDLE in place of SHELL_FILE_HANDLE Laszlo Ersek
@ 2019-09-17 19:49 ` Laszlo Ersek
2019-09-23 10:01 ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-17 19:49 ` [PATCH 32/35] ShellPkg/UefiShellLib: clarify workaround for unfixable EdkShell bug Laszlo Ersek
` (6 subsequent siblings)
37 siblings, 1 reply; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-17 19:49 UTC (permalink / raw)
To: edk2-devel-groups-io; +Cc: Jaben Carsey, Ray Ni, Zhichao Gao
In the FileBufferSave() function, we invoke ShellCloseFile() if "Directory
Can Not Be Saved".
The ShellCloseFile() function takes a (SHELL_FILE_HANDLE*) parameter
called "FileHandle", and correctly passes the de-referenced (*FileHandle)
to EFI_SHELL_CLOSE_FILE, which takes a SHELL_FILE_HANDLE.
However, FileBufferSave() passes SHELL_FILE_HANDLE to ShellCloseFile(),
not the expected (SHELL_FILE_HANDLE*). Correct it.
This fixes an actual bug that has remained hidden for two reasons:
- pointer-to-VOID converts from/to any pointer-to-object type silently,
- the bug is on an error path which has likely never fired in practice.
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
tested: edit (saving a file)
ShellPkg/Library/UefiShellDebug1CommandsLib/Edit/FileBuffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/Edit/FileBuffer.c b/ShellPkg/Library/UefiShellDebug1CommandsLib/Edit/FileBuffer.c
index 464f9de38e52..fd324cc4a861 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/Edit/FileBuffer.c
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/Edit/FileBuffer.c
@@ -1462,7 +1462,7 @@ FileBufferSave (
if (Info != NULL && Info->Attribute & EFI_FILE_DIRECTORY) {
StatusBarSetStatusString (L"Directory Can Not Be Saved");
- ShellCloseFile(FileHandle);
+ ShellCloseFile (&FileHandle);
FreePool(Info);
return EFI_LOAD_ERROR;
}
--
2.19.1.3.g30247aa5d201
^ permalink raw reply related [flat|nested] 155+ messages in thread
* [PATCH 32/35] ShellPkg/UefiShellLib: clarify workaround for unfixable EdkShell bug
2019-09-17 19:49 [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs Laszlo Ersek
` (30 preceding siblings ...)
2019-09-17 19:49 ` [PATCH 31/35] ShellPkg/UefiShellDebug1CommandsLib: fix ShellCloseFile() call Laszlo Ersek
@ 2019-09-17 19:49 ` Laszlo Ersek
2019-09-26 12:47 ` [edk2-devel] " Laszlo Ersek
2019-09-17 19:49 ` [PATCH 33/35] StandaloneMmPkg/Core: stop abusing EFI_HANDLE for FwVolHeader tracking Laszlo Ersek
` (5 subsequent siblings)
37 siblings, 1 reply; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-17 19:49 UTC (permalink / raw)
To: edk2-devel-groups-io; +Cc: Jaben Carsey, Ray Ni, Zhichao Gao
The EDK 1 Shell (available at <https://github.com/tianocore/edk-Shell>)
has a bug in its EFI_SHELL_ENVIRONMENT2.Execute() implementation that
edk2's UefiShellLib has no choice but to work around.
Improve the explanation in the code. Also, document the implicit
EFI_HANDLE -> (EFI_HANDLE*) conversion, which happens implicitly after
dereferencing ParentHandle, with an explicit cast.
In practice, this patch is a no-op.
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
build-tested only
ShellPkg/Library/UefiShellLib/UefiShellLib.c | 22 ++++++++++++++++++--
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/ShellPkg/Library/UefiShellLib/UefiShellLib.c b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
index 835d0f88ca74..9f07a58eb23d 100644
--- a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
+++ b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
@@ -1291,9 +1291,27 @@ ShellExecute (
if (mEfiShellEnvironment2 != NULL) {
//
// Call EFI Shell version.
- // Due to oddity in the EFI shell we want to dereference the ParentHandle here
//
- CmdStatus = (mEfiShellEnvironment2->Execute(*ParentHandle,
+ // Due to an unfixable bug in the EdkShell implementation, we must
+ // dereference "ParentHandle" here:
+ //
+ // 1. The EFI shell installs the EFI_SHELL_ENVIRONMENT2 protocol,
+ // identified by gEfiShellEnvironment2Guid.
+ // 2. The Execute() member function takes "ParentImageHandle" as first
+ // parameter, with type (EFI_HANDLE*).
+ // 3. In the EdkShell implementation, SEnvExecute() implements the
+ // Execute() member function. It passes "ParentImageHandle" correctly to
+ // SEnvDoExecute().
+ // 4. SEnvDoExecute() takes the (EFI_HANDLE*), and passes it directly --
+ // without de-referencing -- to the HandleProtocol() boot service.
+ // 5. But HandleProtocol() takes an EFI_HANDLE.
+ //
+ // Therefore we must
+ // - de-reference "ParentHandle" here, to mask the bug in
+ // SEnvDoExecute(), and
+ // - pass the resultant EFI_HANDLE as an (EFI_HANDLE*).
+ //
+ CmdStatus = (mEfiShellEnvironment2->Execute((EFI_HANDLE *)*ParentHandle,
CommandLine,
Output));
//
--
2.19.1.3.g30247aa5d201
^ permalink raw reply related [flat|nested] 155+ messages in thread
* [PATCH 33/35] StandaloneMmPkg/Core: stop abusing EFI_HANDLE for FwVolHeader tracking
2019-09-17 19:49 [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs Laszlo Ersek
` (31 preceding siblings ...)
2019-09-17 19:49 ` [PATCH 32/35] ShellPkg/UefiShellLib: clarify workaround for unfixable EdkShell bug Laszlo Ersek
@ 2019-09-17 19:49 ` Laszlo Ersek
2019-09-26 12:48 ` [edk2-devel] " Laszlo Ersek
2019-09-17 19:49 ` [PATCH 34/35] UefiPayloadPkg/BlSupportPei: fix MMCONFIG assignment from XSDT Laszlo Ersek
` (4 subsequent siblings)
37 siblings, 1 reply; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-17 19:49 UTC (permalink / raw)
To: edk2-devel-groups-io; +Cc: Achin Gupta, Jiewen Yao, Supreeth Venkatesh
The FvHasBeenProcessed() and FvIsBeingProcesssed() functions make sure
that every firmware volume is processed only once (every driver in every
firmware volume should be discovered only once). For this, the functions
use a linked list.
In MdeModulePkg's DXE Core and SMM Core, the key used for identifying
those firmware volumes that have been processed is the EFI_HANDLE on which
the DXE or SMM firmware volume protocol is installed. In the
StandaloneMmPkg core however, the key is the address of the firmware
volume header; that is, it has type (EFI_FIRMWARE_VOLUME_HEADER*).
(EFI_FIRMWARE_VOLUME_HEADER*) has nothing to do with EFI_HANDLE.
EFI_HANDLE just happens to be specified as (VOID*), and therefore the
conversion between (EFI_FIRMWARE_VOLUME_HEADER*) and EFI_HANDLE is silent.
(The FvHasBeenProcessed() and FvIsBeingProcesssed() functions were likely
copied verbatim from MdeModulePkg's DXE Core and/or the SMM Core, and not
flagged by the compiler in StandaloneMmPkg due to UEFI regrettably
specifying EFI_HANDLE as (VOID*), thereby enabling the above implicit
conversion.)
We should not exploit this circumstance. Represent the key type faithfully
instead.
This is a semantic fix; there is no change in operation.
Cc: Achin Gupta <achin.gupta@arm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
build-tested only
StandaloneMmPkg/Core/StandaloneMmCore.h | 2 +-
StandaloneMmPkg/Core/Dispatcher.c | 80 +++++++++++---------
StandaloneMmPkg/Core/FwVol.c | 16 ++--
3 files changed, 52 insertions(+), 46 deletions(-)
diff --git a/StandaloneMmPkg/Core/StandaloneMmCore.h b/StandaloneMmPkg/Core/StandaloneMmCore.h
index dcf91bc5e916..23ddbe169faf 100644
--- a/StandaloneMmPkg/Core/StandaloneMmCore.h
+++ b/StandaloneMmPkg/Core/StandaloneMmCore.h
@@ -67,7 +67,7 @@ typedef struct {
LIST_ENTRY ScheduledLink; // mScheduledQueue
- EFI_HANDLE FvHandle;
+ EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader;
EFI_GUID FileName;
VOID *Pe32Data;
UINTN Pe32DataSize;
diff --git a/StandaloneMmPkg/Core/Dispatcher.c b/StandaloneMmPkg/Core/Dispatcher.c
index 3788389f95ed..9853445a64a1 100644
--- a/StandaloneMmPkg/Core/Dispatcher.c
+++ b/StandaloneMmPkg/Core/Dispatcher.c
@@ -5,7 +5,7 @@
is added to the mDiscoveredList. The Before, and After Depex are
pre-processed as drivers are added to the mDiscoveredList. If an Apriori
file exists in the FV those drivers are addeded to the
- mScheduledQueue. The mFvHandleList is used to make sure a
+ mScheduledQueue. The mFwVolList is used to make sure a
FV is only processed once.
Step #2 - Dispatch. Remove driver from the mScheduledQueue and load and
@@ -40,13 +40,13 @@
//
// MM Dispatcher Data structures
//
-#define KNOWN_HANDLE_SIGNATURE SIGNATURE_32('k','n','o','w')
+#define KNOWN_FWVOL_SIGNATURE SIGNATURE_32('k','n','o','w')
typedef struct {
- UINTN Signature;
- LIST_ENTRY Link; // mFvHandleList
- EFI_HANDLE Handle;
-} KNOWN_HANDLE;
+ UINTN Signature;
+ LIST_ENTRY Link; // mFwVolList
+ EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader;
+} KNOWN_FWVOL;
//
// Function Prototypes
@@ -86,9 +86,10 @@ LIST_ENTRY mDiscoveredList = INITIALIZE_LIST_HEAD_VARIABLE (mDiscoveredList);
LIST_ENTRY mScheduledQueue = INITIALIZE_LIST_HEAD_VARIABLE (mScheduledQueue);
//
-// List of handles who's Fv's have been parsed and added to the mFwDriverList.
+// List of firmware volume headers whose containing firmware volumes have been
+// parsed and added to the mFwDriverList.
//
-LIST_ENTRY mFvHandleList = INITIALIZE_LIST_HEAD_VARIABLE (mFvHandleList);
+LIST_ENTRY mFwVolList = INITIALIZE_LIST_HEAD_VARIABLE (mFwVolList);
//
// Flag for the MM Dispacher. TRUE if dispatcher is execuing.
@@ -769,26 +770,30 @@ MmInsertOnScheduledQueueWhileProcessingBeforeAndAfter (
}
/**
- Return TRUE if the Fv has been processed, FALSE if not.
+ Return TRUE if the firmware volume has been processed, FALSE if not.
- @param FvHandle The handle of a FV that's being tested
+ @param FwVolHeader The header of the firmware volume that's being
+ tested.
- @retval TRUE Fv protocol on FvHandle has been processed
- @retval FALSE Fv protocol on FvHandle has not yet been
- processed
+ @retval TRUE The firmware volume denoted by FwVolHeader has
+ been processed
+ @retval FALSE The firmware volume denoted by FwVolHeader has
+ not yet been processed
**/
BOOLEAN
FvHasBeenProcessed (
- IN EFI_HANDLE FvHandle
+ IN EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader
)
{
LIST_ENTRY *Link;
- KNOWN_HANDLE *KnownHandle;
+ KNOWN_FWVOL *KnownFwVol;
- for (Link = mFvHandleList.ForwardLink; Link != &mFvHandleList; Link = Link->ForwardLink) {
- KnownHandle = CR (Link, KNOWN_HANDLE, Link, KNOWN_HANDLE_SIGNATURE);
- if (KnownHandle->Handle == FvHandle) {
+ for (Link = mFwVolList.ForwardLink;
+ Link != &mFwVolList;
+ Link = Link->ForwardLink) {
+ KnownFwVol = CR (Link, KNOWN_FWVOL, Link, KNOWN_FWVOL_SIGNATURE);
+ if (KnownFwVol->FwVolHeader == FwVolHeader) {
return TRUE;
}
}
@@ -796,28 +801,29 @@ FvHasBeenProcessed (
}
/**
- Remember that Fv protocol on FvHandle has had it's drivers placed on the
- mDiscoveredList. This fucntion adds entries on the mFvHandleList. Items are
- never removed/freed from the mFvHandleList.
+ Remember that the firmware volume denoted by FwVolHeader has had its drivers
+ placed on mDiscoveredList. This function adds entries to mFwVolList. Items
+ are never removed/freed from mFwVolList.
- @param FvHandle The handle of a FV that has been processed
+ @param FwVolHeader The header of the firmware volume that's being
+ processed.
**/
VOID
FvIsBeingProcesssed (
- IN EFI_HANDLE FvHandle
+ IN EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader
)
{
- KNOWN_HANDLE *KnownHandle;
+ KNOWN_FWVOL *KnownFwVol;
- DEBUG ((DEBUG_INFO, "FvIsBeingProcesssed - 0x%08x\n", FvHandle));
+ DEBUG ((DEBUG_INFO, "FvIsBeingProcesssed - 0x%08x\n", KnownFwVol));
- KnownHandle = AllocatePool (sizeof (KNOWN_HANDLE));
- ASSERT (KnownHandle != NULL);
+ KnownFwVol = AllocatePool (sizeof (KNOWN_FWVOL));
+ ASSERT (KnownFwVol != NULL);
- KnownHandle->Signature = KNOWN_HANDLE_SIGNATURE;
- KnownHandle->Handle = FvHandle;
- InsertTailList (&mFvHandleList, &KnownHandle->Link);
+ KnownFwVol->Signature = KNOWN_FWVOL_SIGNATURE;
+ KnownFwVol->FwVolHeader = FwVolHeader;
+ InsertTailList (&mFwVolList, &KnownFwVol->Link);
}
/**
@@ -842,12 +848,12 @@ FvIsBeingProcesssed (
**/
EFI_STATUS
MmAddToDriverList (
- IN EFI_HANDLE FvHandle,
- IN VOID *Pe32Data,
- IN UINTN Pe32DataSize,
- IN VOID *Depex,
- IN UINTN DepexSize,
- IN EFI_GUID *DriverName
+ IN EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader,
+ IN VOID *Pe32Data,
+ IN UINTN Pe32DataSize,
+ IN VOID *Depex,
+ IN UINTN DepexSize,
+ IN EFI_GUID *DriverName
)
{
EFI_MM_DRIVER_ENTRY *DriverEntry;
@@ -863,7 +869,7 @@ MmAddToDriverList (
DriverEntry->Signature = EFI_MM_DRIVER_ENTRY_SIGNATURE;
CopyGuid (&DriverEntry->FileName, DriverName);
- DriverEntry->FvHandle = FvHandle;
+ DriverEntry->FwVolHeader = FwVolHeader;
DriverEntry->Pe32Data = Pe32Data;
DriverEntry->Pe32DataSize = Pe32DataSize;
DriverEntry->Depex = Depex;
diff --git a/StandaloneMmPkg/Core/FwVol.c b/StandaloneMmPkg/Core/FwVol.c
index 9fe0c257a43a..99ecf4af4714 100644
--- a/StandaloneMmPkg/Core/FwVol.c
+++ b/StandaloneMmPkg/Core/FwVol.c
@@ -24,22 +24,22 @@ EFI_FV_FILETYPE mMmFileTypes[] = {
EFI_STATUS
MmAddToDriverList (
- IN EFI_HANDLE FvHandle,
- IN VOID *Pe32Data,
- IN UINTN Pe32DataSize,
- IN VOID *Depex,
- IN UINTN DepexSize,
- IN EFI_GUID *DriverName
+ IN EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader,
+ IN VOID *Pe32Data,
+ IN UINTN Pe32DataSize,
+ IN VOID *Depex,
+ IN UINTN DepexSize,
+ IN EFI_GUID *DriverName
);
BOOLEAN
FvHasBeenProcessed (
- IN EFI_HANDLE FvHandle
+ IN EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader
);
VOID
FvIsBeingProcesssed (
- IN EFI_HANDLE FvHandle
+ IN EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader
);
EFI_STATUS
--
2.19.1.3.g30247aa5d201
^ permalink raw reply related [flat|nested] 155+ messages in thread
* [PATCH 34/35] UefiPayloadPkg/BlSupportPei: fix MMCONFIG assignment from XSDT
2019-09-17 19:49 [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs Laszlo Ersek
` (32 preceding siblings ...)
2019-09-17 19:49 ` [PATCH 33/35] StandaloneMmPkg/Core: stop abusing EFI_HANDLE for FwVolHeader tracking Laszlo Ersek
@ 2019-09-17 19:49 ` Laszlo Ersek
2019-09-23 2:30 ` Guo Dong
2019-09-26 13:17 ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-17 19:49 ` [PATCH 35/35] UefiPayloadPkg/BlSupportDxe: fix ReserveResourceInGcd() calls Laszlo Ersek
` (3 subsequent siblings)
37 siblings, 2 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-17 19:49 UTC (permalink / raw)
To: edk2-devel-groups-io; +Cc: Benjamin You, Guo Dong, Maurice Ma
(This patch is unrelated to the rest of this series; its purpose is to
enable building the UefiPayloadPkg DSC files with GCC.)
When building "UefiPayloadPkg/UefiPayloadPkgIa32.dsc" with GCC48 for the
DEBUG target, the compiler reports that "Entry32" may be used
uninitialized in ParseAcpiInfo(), in the XSDT branch.
Code inspection proves the compiler right. In the XSDT branch, the code
from the RSDT branch must have been duplicated, and "Entry32" references
were replaced with "Entry64" -- except where "MmCfgHdr" is assigned.
Fix this bug by introducing a helper variable called "Signature", so that
we have to refer to "Entry32" or "Entry64" only once per loop body.
Cc: Benjamin You <benjamin.you@intel.com>
Cc: Guo Dong <guo.dong@intel.com>
Cc: Maurice Ma <maurice.ma@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
build-tested only
UefiPayloadPkg/BlSupportPei/BlSupportPei.c | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/UefiPayloadPkg/BlSupportPei/BlSupportPei.c b/UefiPayloadPkg/BlSupportPei/BlSupportPei.c
index 90433b609f22..22972453117a 100644
--- a/UefiPayloadPkg/BlSupportPei/BlSupportPei.c
+++ b/UefiPayloadPkg/BlSupportPei/BlSupportPei.c
@@ -164,6 +164,7 @@ ParseAcpiInfo (
UINT64 *Entry64;
UINTN Entry64Num;
UINTN Idx;
+ UINT32 *Signature;
EFI_ACPI_MEMORY_MAPPED_CONFIGURATION_BASE_ADDRESS_TABLE_HEADER *MmCfgHdr;
EFI_ACPI_MEMORY_MAPPED_ENHANCED_CONFIGURATION_SPACE_BASE_ADDRESS_ALLOCATION_STRUCTURE *MmCfgBase;
@@ -181,13 +182,14 @@ ParseAcpiInfo (
Entry32 = (UINT32 *)(Rsdt + 1);
Entry32Num = (Rsdt->Length - sizeof(EFI_ACPI_DESCRIPTION_HEADER)) >> 2;
for (Idx = 0; Idx < Entry32Num; Idx++) {
- if (*(UINT32 *)(UINTN)(Entry32[Idx]) == EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE_SIGNATURE) {
- Fadt = (EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE *)(UINTN)(Entry32[Idx]);
+ Signature = (UINT32 *)(UINTN)Entry32[Idx];
+ if (*Signature == EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE_SIGNATURE) {
+ Fadt = (EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE *)Signature;
DEBUG ((DEBUG_INFO, "Found Fadt in Rsdt\n"));
}
- if (*(UINT32 *)(UINTN)(Entry32[Idx]) == EFI_ACPI_5_0_PCI_EXPRESS_MEMORY_MAPPED_CONFIGURATION_SPACE_BASE_ADDRESS_DESCRIPTION_TABLE_SIGNATURE) {
- MmCfgHdr = (EFI_ACPI_MEMORY_MAPPED_CONFIGURATION_BASE_ADDRESS_TABLE_HEADER *)(UINTN)(Entry32[Idx]);
+ if (*Signature == EFI_ACPI_5_0_PCI_EXPRESS_MEMORY_MAPPED_CONFIGURATION_SPACE_BASE_ADDRESS_DESCRIPTION_TABLE_SIGNATURE) {
+ MmCfgHdr = (EFI_ACPI_MEMORY_MAPPED_CONFIGURATION_BASE_ADDRESS_TABLE_HEADER *)Signature;
DEBUG ((DEBUG_INFO, "Found MM config address in Rsdt\n"));
}
@@ -205,13 +207,14 @@ ParseAcpiInfo (
Entry64 = (UINT64 *)(Xsdt + 1);
Entry64Num = (Xsdt->Length - sizeof(EFI_ACPI_DESCRIPTION_HEADER)) >> 3;
for (Idx = 0; Idx < Entry64Num; Idx++) {
- if (*(UINT32 *)(UINTN)(Entry64[Idx]) == EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE_SIGNATURE) {
- Fadt = (EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE *)(UINTN)(Entry64[Idx]);
+ Signature = (UINT32 *)(UINTN)Entry64[Idx];
+ if (*Signature == EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE_SIGNATURE) {
+ Fadt = (EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE *)Signature;
DEBUG ((DEBUG_INFO, "Found Fadt in Xsdt\n"));
}
- if (*(UINT32 *)(UINTN)(Entry64[Idx]) == EFI_ACPI_5_0_PCI_EXPRESS_MEMORY_MAPPED_CONFIGURATION_SPACE_BASE_ADDRESS_DESCRIPTION_TABLE_SIGNATURE) {
- MmCfgHdr = (EFI_ACPI_MEMORY_MAPPED_CONFIGURATION_BASE_ADDRESS_TABLE_HEADER *)(UINTN)(Entry32[Idx]);
+ if (*Signature == EFI_ACPI_5_0_PCI_EXPRESS_MEMORY_MAPPED_CONFIGURATION_SPACE_BASE_ADDRESS_DESCRIPTION_TABLE_SIGNATURE) {
+ MmCfgHdr = (EFI_ACPI_MEMORY_MAPPED_CONFIGURATION_BASE_ADDRESS_TABLE_HEADER *)Signature;
DEBUG ((DEBUG_INFO, "Found MM config address in Xsdt\n"));
}
--
2.19.1.3.g30247aa5d201
^ permalink raw reply related [flat|nested] 155+ messages in thread
* [PATCH 35/35] UefiPayloadPkg/BlSupportDxe: fix ReserveResourceInGcd() calls
2019-09-17 19:49 [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs Laszlo Ersek
` (33 preceding siblings ...)
2019-09-17 19:49 ` [PATCH 34/35] UefiPayloadPkg/BlSupportPei: fix MMCONFIG assignment from XSDT Laszlo Ersek
@ 2019-09-17 19:49 ` Laszlo Ersek
2019-09-23 2:28 ` [edk2-devel] " Guo Dong
2019-09-23 15:08 ` Philippe Mathieu-Daudé
2019-09-19 0:32 ` [edk2-devel] [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs Wu, Hao A
` (2 subsequent siblings)
37 siblings, 2 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-17 19:49 UTC (permalink / raw)
To: edk2-devel-groups-io; +Cc: Benjamin You, Guo Dong, Maurice Ma
The last parameter of ReserveResourceInGcd() is "ImageHandle", forwarded
in turn to gDS->AllocateMemorySpace() or gDS->AllocateIoSpace() as "owner"
image handle.
But BlDxeEntryPoint() passes "SystemTable" as "ImageHandle".
Compilers have not flagged it because EFI_HANDLE (the type of
"ImageHandle") is unfortunately specified as (VOID*), and
(EFI_SYSTEM_TABLE*) converts to (VOID*) silently.
Hand the entry point function's "ImageHandle" parameter to
ReserveResourceInGcd(). This fixes an actual bug.
Cc: Benjamin You <benjamin.you@intel.com>
Cc: Guo Dong <guo.dong@intel.com>
Cc: Maurice Ma <maurice.ma@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
build-tested only
UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c b/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c
index bcee4cd9bc41..28dfc8fc5545 100644
--- a/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c
+++ b/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c
@@ -106,10 +106,10 @@ BlDxeEntryPoint (
//
// Report MMIO/IO Resources
//
- Status = ReserveResourceInGcd (TRUE, EfiGcdMemoryTypeMemoryMappedIo, 0xFEC00000, SIZE_4KB, 0, SystemTable); // IOAPIC
+ Status = ReserveResourceInGcd (TRUE, EfiGcdMemoryTypeMemoryMappedIo, 0xFEC00000, SIZE_4KB, 0, ImageHandle); // IOAPIC
ASSERT_EFI_ERROR (Status);
- Status = ReserveResourceInGcd (TRUE, EfiGcdMemoryTypeMemoryMappedIo, 0xFED00000, SIZE_1KB, 0, SystemTable); // HPET
+ Status = ReserveResourceInGcd (TRUE, EfiGcdMemoryTypeMemoryMappedIo, 0xFED00000, SIZE_1KB, 0, ImageHandle); // HPET
ASSERT_EFI_ERROR (Status);
//
--
2.19.1.3.g30247aa5d201
^ permalink raw reply related [flat|nested] 155+ messages in thread
* Re: [PATCH 06/35] EmulatorPkg: stop abusing EFI_HANDLE for keystroke notify registration
2019-09-17 19:49 ` [PATCH 06/35] EmulatorPkg: stop abusing EFI_HANDLE for keystroke notify registration Laszlo Ersek
@ 2019-09-17 20:01 ` Ni, Ray
2019-09-24 10:44 ` [edk2-devel] " Philippe Mathieu-Daudé
1 sibling, 0 replies; 155+ messages in thread
From: Ni, Ray @ 2019-09-17 20:01 UTC (permalink / raw)
To: Laszlo Ersek, edk2-devel-groups-io; +Cc: Andrew Fish, Justen, Jordan L
Reviewed-by: Ray Ni <ray.ni@intel.com>
> -----Original Message-----
> From: Laszlo Ersek <lersek@redhat.com>
> Sent: Tuesday, September 17, 2019 12:49 PM
> To: edk2-devel-groups-io <devel@edk2.groups.io>
> Cc: Andrew Fish <afish@apple.com>; Justen, Jordan L <jordan.l.justen@intel.com>; Ni, Ray <ray.ni@intel.com>
> Subject: [PATCH 06/35] EmulatorPkg: stop abusing EFI_HANDLE for keystroke notify registration
>
> EFI_REGISTER_KEYSTROKE_NOTIFY and EFI_UNREGISTER_KEYSTROKE_NOTIFY require
> the notification handle to have type (VOID*). The notification handle has
> nothing to do with the EFI_HANDLE type.
>
> This change is a semantic fix; functionally, it's a no-op.
>
> Cc: Andrew Fish <afish@apple.com>
> Cc: Jordan Justen <jordan.l.justen@intel.com>
> Cc: Ray Ni <ray.ni@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> build-tested only
>
> EmulatorPkg/EmuGopDxe/GopInput.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/EmulatorPkg/EmuGopDxe/GopInput.c b/EmulatorPkg/EmuGopDxe/GopInput.c
> index fdd0b4911555..2a23564a2173 100644
> --- a/EmulatorPkg/EmuGopDxe/GopInput.c
> +++ b/EmulatorPkg/EmuGopDxe/GopInput.c
> @@ -517,7 +517,7 @@ EmuGopSimpleTextInExRegisterKeyNotify (
> IN EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL *This,
> IN EFI_KEY_DATA *KeyData,
> IN EFI_KEY_NOTIFY_FUNCTION KeyNotificationFunction,
> - OUT EFI_HANDLE *NotifyHandle
> + OUT VOID **NotifyHandle
> )
> {
> EFI_STATUS Status;
> @@ -600,7 +600,7 @@ EFI_STATUS
> EFIAPI
> EmuGopSimpleTextInExUnregisterKeyNotify (
> IN EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL *This,
> - IN EFI_HANDLE NotificationHandle
> + IN VOID *NotificationHandle
> )
> /*++
>
> --
> 2.19.1.3.g30247aa5d201
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 05/35] EmulatorPkg/DxeTimerLib: drop superfluous cast
2019-09-17 19:49 ` [PATCH 05/35] EmulatorPkg/DxeTimerLib: drop superfluous cast Laszlo Ersek
@ 2019-09-17 20:02 ` Ni, Ray
2019-09-20 15:00 ` [edk2-devel] " Philippe Mathieu-Daudé
1 sibling, 0 replies; 155+ messages in thread
From: Ni, Ray @ 2019-09-17 20:02 UTC (permalink / raw)
To: Laszlo Ersek, edk2-devel-groups-io; +Cc: Andrew Fish, Justen, Jordan L
Reviewed-by: Ray Ni <ray.ni@intel.com>
> -----Original Message-----
> From: Laszlo Ersek <lersek@redhat.com>
> Sent: Tuesday, September 17, 2019 12:49 PM
> To: edk2-devel-groups-io <devel@edk2.groups.io>
> Cc: Andrew Fish <afish@apple.com>; Justen, Jordan L <jordan.l.justen@intel.com>; Ni, Ray <ray.ni@intel.com>
> Subject: [PATCH 05/35] EmulatorPkg/DxeTimerLib: drop superfluous cast
>
> "gTimerEvent" has type EFI_EVENT already, drop the superfluous cast.
>
> Cc: Andrew Fish <afish@apple.com>
> Cc: Jordan Justen <jordan.l.justen@intel.com>
> Cc: Ray Ni <ray.ni@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> build-tested only
>
> EmulatorPkg/Library/DxeTimerLib/DxeTimerLib.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/EmulatorPkg/Library/DxeTimerLib/DxeTimerLib.c b/EmulatorPkg/Library/DxeTimerLib/DxeTimerLib.c
> index 14cae4214c66..6fb5d8f3aaea 100644
> --- a/EmulatorPkg/Library/DxeTimerLib/DxeTimerLib.c
> +++ b/EmulatorPkg/Library/DxeTimerLib/DxeTimerLib.c
> @@ -40,7 +40,7 @@ RegisterTimerArchProtocol (
> gTimerPeriod = MultU64x32 (gTimerPeriod, 100);
>
> if (gTimerEvent == NULL) {
> - Status = gBS->CreateEvent (EVT_TIMER, 0, NULL, NULL, (VOID **)&gTimerEvent);
> + Status = gBS->CreateEvent (EVT_TIMER, 0, NULL, NULL, &gTimerEvent);
> ASSERT_EFI_ERROR (Status);
> }
> }
> --
> 2.19.1.3.g30247aa5d201
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 01/35] DO NOT APPLY: edk2: turn standard handle types into pointers to non-VOID
2019-09-17 19:49 ` [PATCH 01/35] DO NOT APPLY: edk2: turn standard handle types into pointers to non-VOID Laszlo Ersek
@ 2019-09-17 20:06 ` Ni, Ray
2019-09-17 20:22 ` Andrew Fish
2019-09-18 8:36 ` Laszlo Ersek
0 siblings, 2 replies; 155+ messages in thread
From: Ni, Ray @ 2019-09-17 20:06 UTC (permalink / raw)
To: devel@edk2.groups.io, lersek@redhat.com
Cc: Achin Gupta, Andrew Fish, Anthony Perard, Ard Biesheuvel,
You, Benjamin, Zhang, Chao B, Bi, Dandan, David Woodhouse,
Dong, Eric, Dong, Guo, Wu, Hao A, Carsey, Jaben, Wang, Jian J,
Wu, Jiaxin, Yao, Jiewen, Justen, Jordan L, Julien Grall,
Leif Lindholm, Gao, Liming, Ma, Maurice, Kinney, Michael D,
Fu, Siyuan, Supreeth Venkatesh, Gao, Zhichao
Laszlo,
Thank you very much for this work.
They are quite helpful to detect potential issues.
But without this specific patch being checked in, future break will still happen.
I don't want it to be checked in ASAP because I know that there are quite a lot of close source code that may get build break due to this change.
Besides that, what prevent you make the decision to check in the changes?
Thanks,
Ray
> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Laszlo Ersek
> Sent: Tuesday, September 17, 2019 12:49 PM
> To: edk2-devel-groups-io <devel@edk2.groups.io>
> Cc: Achin Gupta <achin.gupta@arm.com>; Andrew Fish <afish@apple.com>; Anthony Perard <anthony.perard@citrix.com>;
> Ard Biesheuvel <ard.biesheuvel@linaro.org>; You, Benjamin <benjamin.you@intel.com>; Zhang, Chao B
> <chao.b.zhang@intel.com>; Bi, Dandan <dandan.bi@intel.com>; David Woodhouse <dwmw2@infradead.org>; Dong, Eric
> <eric.dong@intel.com>; Dong, Guo <guo.dong@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Carsey, Jaben
> <jaben.carsey@intel.com>; Wang, Jian J <jian.j.wang@intel.com>; Wu, Jiaxin <jiaxin.wu@intel.com>; Yao, Jiewen
> <jiewen.yao@intel.com>; Justen, Jordan L <jordan.l.justen@intel.com>; Julien Grall <julien.grall@arm.com>; Leif Lindholm
> <leif.lindholm@linaro.org>; Gao, Liming <liming.gao@intel.com>; Ma, Maurice <maurice.ma@intel.com>; Kinney, Michael
> D <michael.d.kinney@intel.com>; Ni, Ray <ray.ni@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>; Supreeth Venkatesh
> <supreeth.venkatesh@arm.com>; Gao, Zhichao <zhichao.gao@intel.com>
> Subject: [edk2-devel] [PATCH 01/35] DO NOT APPLY: edk2: turn standard handle types into pointers to non-VOID
>
> Unfortunately, the UEFI / PI / Shell specs define a number of handle types
> as pointers to VOID. This is a design mistake; those types should have
> been pointers to incomplete union or structure types. Any
> pointer-to-object type converts implicitly to, and from, pointer-to-void,
> which prevents compilers from catching at least the following two types of
> mistakes:
>
> - mixing up one handle type with another (for example, EFI_HANDLE with
> EFI_EVENT),
>
> - getting the depth of indirection wrong (for example, mixing up
> (EFI_HANDLE*) with EFI_HANDLE).
>
> In order to root out such mistakes in the edk2 codebase, introduce
> incomplete structure types with unique tags, such as:
>
> struct EFI_FOOBAR_OBJECT;
> typedef struct EFI_FOOBAR_OBJECT *EFI_FOOBAR_HANDLE;
>
> replacing the spec mandated
>
> typedef VOID *EFI_FOOBAR_HANDLE;
>
> (For some types, such as:
>
> - EFI_ACPI_HANDLE,
> - EFI_EVENT,
> - EFI_FONT_HANDLE,
> - EFI_HANDLE,
> - EFI_HII_HANDLE,
> - EFI_S3_BOOT_SCRIPT_POSITION,
> - SHELL_FILE_HANDLE,
>
> we connect the actual complete type (the internal, implementation-specific
> type) to the typedef. Some of these also demonstrate how the code could
> have looked in practice if the specs had used proper opaque (=incomplete)
> types.)
>
> Then, unleash "build" on the package DSC files. This causes the compiler
> to warn about incompatible pointer assignments, and to stop the build.
>
> The rest of the series addresses the resultant warnings. Each patch
> belongs in one of two categories:
>
> - semantic cleanups (no functional / behavioral changes),
> - actual bugfixes.
>
> As the subject line of this patch states, this specific patch is *not*
> meant to be applied. It is just a "what if" patch that temporarily
> isolates the standard types from each other, the way the specs should
> have, so that the compiler have more information to work with.
>
> Cc: Achin Gupta <achin.gupta@arm.com>
> Cc: Andrew Fish <afish@apple.com>
> Cc: Anthony Perard <anthony.perard@citrix.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Benjamin You <benjamin.you@intel.com>
> Cc: Chao Zhang <chao.b.zhang@intel.com>
> Cc: Dandan Bi <dandan.bi@intel.com>
> Cc: David Woodhouse <dwmw2@infradead.org>
> Cc: Eric Dong <eric.dong@intel.com>
> Cc: Guo Dong <guo.dong@intel.com>
> Cc: Hao A Wu <hao.a.wu@intel.com>
> Cc: Jaben Carsey <jaben.carsey@intel.com>
> Cc: Jian J Wang <jian.j.wang@intel.com>
> Cc: Jian Wang <jian.j.wang@intel.com>
> Cc: Jiaxin Wu <jiaxin.wu@intel.com>
> Cc: Jiewen Yao <jiewen.yao@intel.com>
> Cc: Jordan Justen <jordan.l.justen@intel.com>
> Cc: Julien Grall <julien.grall@arm.com>
> Cc: Leif Lindholm <leif.lindholm@linaro.org>
> Cc: Liming Gao <liming.gao@intel.com>
> Cc: Maurice Ma <maurice.ma@intel.com>
> Cc: Michael D Kinney <michael.d.kinney@intel.com>
> Cc: Ray Ni <ray.ni@intel.com>
> Cc: Siyuan Fu <siyuan.fu@intel.com>
> Cc: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
> Cc: Zhichao Gao <zhichao.gao@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
> MdePkg/Include/Pi/PiPeiCis.h | 6 ++++--
> MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h | 3 ++-
> MdePkg/Include/Protocol/Bis.h | 3 ++-
> MdePkg/Include/Protocol/Eap.h | 3 ++-
> MdePkg/Include/Protocol/HiiFont.h | 3 +--
> MdePkg/Include/Protocol/MmMp.h | 3 ++-
> MdePkg/Include/Protocol/S3SaveState.h | 2 +-
> MdePkg/Include/Protocol/Shell.h | 3 ++-
> MdePkg/Include/Protocol/UserManager.h | 9 ++++++---
> MdePkg/Include/Uefi/UefiBaseType.h | 6 ++++--
> MdePkg/Include/Uefi/UefiInternalFormRepresentation.h | 3 ++-
> MdeModulePkg/Core/Dxe/Event/Event.h | 2 +-
> MdeModulePkg/Core/Dxe/Hand/Handle.h | 2 +-
> MdeModulePkg/Core/PiSmmCore/PiSmmCore.h | 2 +-
> MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h | 2 +-
> MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabase.h | 2 +-
> StandaloneMmPkg/Core/StandaloneMmCore.h | 2 +-
> 17 files changed, 34 insertions(+), 22 deletions(-)
>
> diff --git a/MdePkg/Include/Pi/PiPeiCis.h b/MdePkg/Include/Pi/PiPeiCis.h
> index d9d4ed7d413a..3e9e82b62ae9 100644
> --- a/MdePkg/Include/Pi/PiPeiCis.h
> +++ b/MdePkg/Include/Pi/PiPeiCis.h
> @@ -18,12 +18,14 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> ///
> /// The handles of EFI FV.
> ///
> -typedef VOID *EFI_PEI_FV_HANDLE;
> +struct EFI_PEI_FV_OBJECT;
> +typedef struct EFI_PEI_FV_OBJECT *EFI_PEI_FV_HANDLE;
>
> ///
> /// The handles of EFI FFS.
> ///
> -typedef VOID *EFI_PEI_FILE_HANDLE;
> +struct EFI_PEI_FILE_OBJECT;
> +typedef struct EFI_PEI_FILE_OBJECT *EFI_PEI_FILE_HANDLE;
>
> ///
> /// Declare the forward reference data structure for EFI_PEI_SERVICE.
> diff --git a/MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h
> b/MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h
> index a8e0b24c6c8d..8a1863f3e03d 100644
> --- a/MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h
> +++ b/MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h
> @@ -16,7 +16,8 @@
> { 0xeb97088e, 0xcfdf, 0x49c6, { 0xbe, 0x4b, 0xd9, 0x6, 0xa5, 0xb2, 0xe, 0x86 }}
>
> typedef UINT32 EFI_ACPI_TABLE_VERSION;
> -typedef VOID *EFI_ACPI_HANDLE;
> +struct EFI_ACPI_OBJECT;
> +typedef struct EFI_ACPI_OBJECT *EFI_ACPI_HANDLE;
>
> #define EFI_ACPI_TABLE_VERSION_NONE (1 << 0)
> #define EFI_ACPI_TABLE_VERSION_1_0B (1 << 1)
> diff --git a/MdePkg/Include/Protocol/Bis.h b/MdePkg/Include/Protocol/Bis.h
> index 2be6718f4bc2..8eca94512d03 100644
> --- a/MdePkg/Include/Protocol/Bis.h
> +++ b/MdePkg/Include/Protocol/Bis.h
> @@ -37,7 +37,8 @@ typedef struct _EFI_BIS_PROTOCOL EFI_BIS_PROTOCOL;
> //
> // Basic types
> //
> -typedef VOID *BIS_APPLICATION_HANDLE;
> +struct BIS_APPLICATION_OBJECT;
> +typedef struct BIS_APPLICATION_OBJECT *BIS_APPLICATION_HANDLE;
> typedef UINT16 BIS_ALG_ID;
> typedef UINT32 BIS_CERT_ID;
>
> diff --git a/MdePkg/Include/Protocol/Eap.h b/MdePkg/Include/Protocol/Eap.h
> index 203d0f40b0dd..06584ef409d0 100644
> --- a/MdePkg/Include/Protocol/Eap.h
> +++ b/MdePkg/Include/Protocol/Eap.h
> @@ -28,7 +28,8 @@ typedef struct _EFI_EAP_PROTOCOL EFI_EAP_PROTOCOL;
> /// Type for the identification number assigned to the Port by the
> /// System in which the Port resides.
> ///
> -typedef VOID * EFI_PORT_HANDLE;
> +struct EFI_PORT_OBJECT;
> +typedef struct EFI_PORT_OBJECT *EFI_PORT_HANDLE;
>
> ///
> /// EAP Authentication Method Type (RFC 3748)
> diff --git a/MdePkg/Include/Protocol/HiiFont.h b/MdePkg/Include/Protocol/HiiFont.h
> index 1f2e321ea4e2..450cad9ada70 100644
> --- a/MdePkg/Include/Protocol/HiiFont.h
> +++ b/MdePkg/Include/Protocol/HiiFont.h
> @@ -19,8 +19,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> { 0xe9ca4775, 0x8657, 0x47fc, { 0x97, 0xe7, 0x7e, 0xd6, 0x5a, 0x8, 0x43, 0x24 } }
>
> typedef struct _EFI_HII_FONT_PROTOCOL EFI_HII_FONT_PROTOCOL;
> -
> -typedef VOID *EFI_FONT_HANDLE;
> +typedef LIST_ENTRY *EFI_FONT_HANDLE;
>
> ///
> /// EFI_HII_OUT_FLAGS.
> diff --git a/MdePkg/Include/Protocol/MmMp.h b/MdePkg/Include/Protocol/MmMp.h
> index beace1386cbe..cd4e0db47e08 100644
> --- a/MdePkg/Include/Protocol/MmMp.h
> +++ b/MdePkg/Include/Protocol/MmMp.h
> @@ -36,7 +36,8 @@
> //
> // Completion token
> //
> -typedef VOID* MM_COMPLETION;
> +struct MM_COMPLETION_OBJECT;
> +typedef struct MM_COMPLETION_OBJECT* MM_COMPLETION;
>
> typedef struct {
> MM_COMPLETION Completion;
> diff --git a/MdePkg/Include/Protocol/S3SaveState.h b/MdePkg/Include/Protocol/S3SaveState.h
> index c1b8f8b9e08d..235c36be6737 100644
> --- a/MdePkg/Include/Protocol/S3SaveState.h
> +++ b/MdePkg/Include/Protocol/S3SaveState.h
> @@ -21,7 +21,7 @@
> { 0xe857caf6, 0xc046, 0x45dc, { 0xbe, 0x3f, 0xee, 0x7, 0x65, 0xfb, 0xa8, 0x87 }}
>
>
> -typedef VOID *EFI_S3_BOOT_SCRIPT_POSITION;
> +typedef UINT8 *EFI_S3_BOOT_SCRIPT_POSITION;
>
> typedef struct _EFI_S3_SAVE_STATE_PROTOCOL EFI_S3_SAVE_STATE_PROTOCOL;
>
> diff --git a/MdePkg/Include/Protocol/Shell.h b/MdePkg/Include/Protocol/Shell.h
> index cfb7878228c5..bf791792b4f2 100644
> --- a/MdePkg/Include/Protocol/Shell.h
> +++ b/MdePkg/Include/Protocol/Shell.h
> @@ -11,12 +11,13 @@
> #define __EFI_SHELL_PROTOCOL_H__
>
> #include <Guid/FileInfo.h>
> +#include <Protocol/SimpleFileSystem.h>
>
> #define EFI_SHELL_PROTOCOL_GUID \
> { \
> 0x6302d008, 0x7f9b, 0x4f30, { 0x87, 0xac, 0x60, 0xc9, 0xfe, 0xf5, 0xda, 0x4e } \
> }
> -typedef VOID *SHELL_FILE_HANDLE;
> +typedef EFI_FILE_PROTOCOL *SHELL_FILE_HANDLE;
>
> typedef enum {
> ///
> diff --git a/MdePkg/Include/Protocol/UserManager.h b/MdePkg/Include/Protocol/UserManager.h
> index 26ac4955f1ec..9abfcffbeebf 100644
> --- a/MdePkg/Include/Protocol/UserManager.h
> +++ b/MdePkg/Include/Protocol/UserManager.h
> @@ -24,8 +24,10 @@
> 0xbaf1e6de, 0x209e, 0x4adb, { 0x8d, 0x96, 0xfd, 0x8b, 0x71, 0xf3, 0xf6, 0x83 } \
> }
>
> -typedef VOID *EFI_USER_PROFILE_HANDLE;
> -typedef VOID *EFI_USER_INFO_HANDLE;
> +struct EFI_USER_PROFILE_OBJECT;
> +typedef struct EFI_USER_PROFILE_OBJECT *EFI_USER_PROFILE_HANDLE;
> +struct EFI_USER_INFO_OBJECT;
> +typedef struct EFI_USER_INFO_OBJECT *EFI_USER_INFO_HANDLE;
>
> ///
> /// The attributes of the user profile information.
> @@ -157,7 +159,8 @@ typedef CHAR16 *EFI_USER_INFO_CREDENTIAL_PROVIDER_NAME;
> /// Biometric Exchange Formats Framework) specification.
> ///
> #define EFI_USER_INFO_CBEFF_RECORD 0x0B
> -typedef VOID *EFI_USER_INFO_CBEFF;
> +struct EFI_USER_INFO_CBEFF_OBJECT;
> +typedef struct EFI_USER_INFO_CBEFF_OBJECT *EFI_USER_INFO_CBEFF;
> ///
> /// Indicates how close of a match the fingerprint must be in order to be considered a match.
> ///
> diff --git a/MdePkg/Include/Uefi/UefiBaseType.h b/MdePkg/Include/Uefi/UefiBaseType.h
> index a62f13dd064f..be5831991b52 100644
> --- a/MdePkg/Include/Uefi/UefiBaseType.h
> +++ b/MdePkg/Include/Uefi/UefiBaseType.h
> @@ -28,11 +28,13 @@ typedef RETURN_STATUS EFI_STATUS;
> ///
> /// A collection of related interfaces.
> ///
> -typedef VOID *EFI_HANDLE;
> +struct EFI_OBJECT;
> +typedef struct EFI_OBJECT *EFI_HANDLE;
> ///
> /// Handle to an event structure.
> ///
> -typedef VOID *EFI_EVENT;
> +struct EFI_EVENT_OBJECT;
> +typedef struct EFI_EVENT_OBJECT *EFI_EVENT;
> ///
> /// Task priority level.
> ///
> diff --git a/MdePkg/Include/Uefi/UefiInternalFormRepresentation.h
> b/MdePkg/Include/Uefi/UefiInternalFormRepresentation.h
> index 4a1346a599d0..93bf9e9e0f13 100644
> --- a/MdePkg/Include/Uefi/UefiInternalFormRepresentation.h
> +++ b/MdePkg/Include/Uefi/UefiInternalFormRepresentation.h
> @@ -20,7 +20,8 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> ///
> /// The following types are currently defined:
> ///
> -typedef VOID* EFI_HII_HANDLE;
> +struct EFI_HII_OBJECT;
> +typedef struct EFI_HII_OBJECT* EFI_HII_HANDLE;
> typedef CHAR16* EFI_STRING;
> typedef UINT16 EFI_IMAGE_ID;
> typedef UINT16 EFI_QUESTION_ID;
> diff --git a/MdeModulePkg/Core/Dxe/Event/Event.h b/MdeModulePkg/Core/Dxe/Event/Event.h
> index 8141c5003eec..42590cb1dd09 100644
> --- a/MdeModulePkg/Core/Dxe/Event/Event.h
> +++ b/MdeModulePkg/Core/Dxe/Event/Event.h
> @@ -37,7 +37,7 @@ typedef struct {
> } TIMER_EVENT_INFO;
>
> #define EVENT_SIGNATURE SIGNATURE_32('e','v','n','t')
> -typedef struct {
> +typedef struct EFI_EVENT_OBJECT {
> UINTN Signature;
> UINT32 Type;
> UINT32 SignalCount;
> diff --git a/MdeModulePkg/Core/Dxe/Hand/Handle.h b/MdeModulePkg/Core/Dxe/Hand/Handle.h
> index 83eb2b9f3afe..1f1ab3274e8a 100644
> --- a/MdeModulePkg/Core/Dxe/Hand/Handle.h
> +++ b/MdeModulePkg/Core/Dxe/Hand/Handle.h
> @@ -15,7 +15,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> ///
> /// IHANDLE - contains a list of protocol handles
> ///
> -typedef struct {
> +typedef struct EFI_OBJECT {
> UINTN Signature;
> /// All handles list of IHANDLE
> LIST_ENTRY AllHandles;
> diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
> index 0908e7f4e9e7..c55da58d465e 100644
> --- a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
> +++ b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
> @@ -145,7 +145,7 @@ typedef struct {
> ///
> /// IHANDLE - contains a list of protocol handles
> ///
> -typedef struct {
> +typedef struct EFI_OBJECT {
> UINTN Signature;
> /// All handles list of IHANDLE
> LIST_ENTRY AllHandles;
> diff --git a/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h
> b/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h
> index 50d4c96edb63..bfebbb1f8182 100644
> --- a/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h
> +++ b/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h
> @@ -88,7 +88,7 @@ struct _EFI_AML_NODE_LIST {
> // This buffer should not be freed.
> // Size is the total size of this ACPI node buffer.
> //
> -typedef struct {
> +typedef struct EFI_ACPI_OBJECT {
> UINT32 Signature;
> UINT8 *Buffer;
> UINTN Size;
> diff --git a/MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabase.h
> b/MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabase.h
> index 4a3feab94df5..48972d0fcad6 100644
> --- a/MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabase.h
> +++ b/MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabase.h
> @@ -274,7 +274,7 @@ typedef struct _HII_DATABASE_PACKAGE_LIST_INSTANCE {
>
> #define HII_HANDLE_SIGNATURE SIGNATURE_32 ('h','i','h','l')
>
> -typedef struct {
> +typedef struct EFI_HII_OBJECT {
> UINTN Signature;
> LIST_ENTRY Handle;
> UINTN Key;
> diff --git a/StandaloneMmPkg/Core/StandaloneMmCore.h b/StandaloneMmPkg/Core/StandaloneMmCore.h
> index 4d0eed273f50..dcf91bc5e916 100644
> --- a/StandaloneMmPkg/Core/StandaloneMmCore.h
> +++ b/StandaloneMmPkg/Core/StandaloneMmCore.h
> @@ -105,7 +105,7 @@ typedef struct {
> ///
> /// IHANDLE - contains a list of protocol handles
> ///
> -typedef struct {
> +typedef struct EFI_OBJECT {
> UINTN Signature;
> /// All handles list of IHANDLE
> LIST_ENTRY AllHandles;
> --
> 2.19.1.3.g30247aa5d201
>
>
>
> -=-=-=-=-=-=
> Groups.io Links: You receive all messages sent to this group.
>
> View/Reply Online (#47388): https://edk2.groups.io/g/devel/message/47388
> Mute This Topic: https://groups.io/mt/34180199/1712937
> Group Owner: devel+owner@edk2.groups.io
> Unsubscribe: https://edk2.groups.io/g/devel/unsub [ray.ni@intel.com]
> -=-=-=-=-=-=
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 14/35] MdeModulePkg: fix UninstallMultipleProtocolInterfaces() calls
2019-09-17 19:49 ` [PATCH 14/35] MdeModulePkg: fix UninstallMultipleProtocolInterfaces() calls Laszlo Ersek
@ 2019-09-17 20:16 ` Ni, Ray
0 siblings, 0 replies; 155+ messages in thread
From: Ni, Ray @ 2019-09-17 20:16 UTC (permalink / raw)
To: Laszlo Ersek, edk2-devel-groups-io; +Cc: Wu, Hao A, Wang, Jian J
Reviewed-by: Ray Ni <ray.ni@intel.com>
> -----Original Message-----
> From: Laszlo Ersek <lersek@redhat.com>
> Sent: Tuesday, September 17, 2019 12:49 PM
> To: edk2-devel-groups-io <devel@edk2.groups.io>
> Cc: Wu, Hao A <hao.a.wu@intel.com>; Wang, Jian J <jian.j.wang@intel.com>; Ni, Ray <ray.ni@intel.com>
> Subject: [PATCH 14/35] MdeModulePkg: fix UninstallMultipleProtocolInterfaces() calls
>
> Unlike the InstallMultipleProtocolInterfaces() boot service, which takes
> an (EFI_HANDLE*) as first parameter, the
> UninstallMultipleProtocolInterfaces() boot service takes an EFI_HANDLE as
> first parameter.
>
> These are actual bugs. They must have remained hidden until now because
> they are on error paths. Fix the UninstallMultipleProtocolInterfaces()
> calls.
>
> Cc: Hao A Wu <hao.a.wu@intel.com>
> Cc: Jian J Wang <jian.j.wang@intel.com>
> Cc: Ray Ni <ray.ni@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> build-tested only
>
> MdeModulePkg/Bus/I2c/I2cDxe/I2cBus.c | 2 +-
> MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c | 2 +-
> MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c | 6 +++---
> MdeModulePkg/Bus/Pci/PciSioSerialDxe/Serial.c | 2 +-
> MdeModulePkg/Bus/Sd/EmmcDxe/EmmcDxe.c | 2 +-
> MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c | 2 +-
> MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassImpl.c | 2 +-
> 7 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/I2c/I2cDxe/I2cBus.c b/MdeModulePkg/Bus/I2c/I2cDxe/I2cBus.c
> index 2b54ec51dca0..ed33a51da252 100644
> --- a/MdeModulePkg/Bus/I2c/I2cDxe/I2cBus.c
> +++ b/MdeModulePkg/Bus/I2c/I2cDxe/I2cBus.c
> @@ -720,7 +720,7 @@ Error:
>
> if (I2cBusContext != NULL) {
> Status = gBS->UninstallMultipleProtocolInterfaces (
> - &Controller,
> + Controller,
> gEfiCallerIdGuid,
> I2cBusContext,
> NULL
> diff --git a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c
> b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c
> index c6e401176a4b..3bde96bc9576 100644
> --- a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c
> +++ b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c
> @@ -244,7 +244,7 @@ EnumerateNvmeDevNamespace (
> );
> if(EFI_ERROR(Status)) {
> gBS->UninstallMultipleProtocolInterfaces (
> - &Device->DeviceHandle,
> + Device->DeviceHandle,
> &gEfiDevicePathProtocolGuid,
> Device->DevicePath,
> &gEfiBlockIoProtocolGuid,
> diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c b/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c
> index b7832c6970ad..292dd25da817 100644
> --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c
> +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c
> @@ -313,7 +313,7 @@ RegisterPciDevice (
> );
> if (EFI_ERROR (Status)) {
> gBS->UninstallMultipleProtocolInterfaces (
> - &PciIoDevice->Handle,
> + PciIoDevice->Handle,
> &gEfiDevicePathProtocolGuid,
> PciIoDevice->DevicePath,
> &gEfiPciIoProtocolGuid,
> @@ -351,7 +351,7 @@ RegisterPciDevice (
> );
> if (EFI_ERROR (Status)) {
> gBS->UninstallMultipleProtocolInterfaces (
> - &PciIoDevice->Handle,
> + PciIoDevice->Handle,
> &gEfiDevicePathProtocolGuid,
> PciIoDevice->DevicePath,
> &gEfiPciIoProtocolGuid,
> @@ -360,7 +360,7 @@ RegisterPciDevice (
> );
> if (HasEfiImage) {
> gBS->UninstallMultipleProtocolInterfaces (
> - &PciIoDevice->Handle,
> + PciIoDevice->Handle,
> &gEfiLoadFile2ProtocolGuid,
> &PciIoDevice->LoadFile2,
> NULL
> diff --git a/MdeModulePkg/Bus/Pci/PciSioSerialDxe/Serial.c b/MdeModulePkg/Bus/Pci/PciSioSerialDxe/Serial.c
> index 82db93a8b117..9fe8a482e067 100644
> --- a/MdeModulePkg/Bus/Pci/PciSioSerialDxe/Serial.c
> +++ b/MdeModulePkg/Bus/Pci/PciSioSerialDxe/Serial.c
> @@ -665,7 +665,7 @@ CreateSerialDevice (
>
> if (EFI_ERROR (Status)) {
> gBS->UninstallMultipleProtocolInterfaces (
> - &SerialDevice->Handle,
> + SerialDevice->Handle,
> &gEfiDevicePathProtocolGuid, SerialDevice->DevicePath,
> &gEfiSerialIoProtocolGuid, &SerialDevice->SerialIo,
> NULL
> diff --git a/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcDxe.c b/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcDxe.c
> index 62f18d1878bd..e2ae56c5058a 100644
> --- a/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcDxe.c
> +++ b/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcDxe.c
> @@ -475,7 +475,7 @@ InstallProtocolOnPartition (
> );
> if (EFI_ERROR (Status)) {
> gBS->UninstallMultipleProtocolInterfaces (
> - &Partition->Handle,
> + Partition->Handle,
> &gEfiDevicePathProtocolGuid,
> Partition->DevicePath,
> &gEfiBlockIoProtocolGuid,
> diff --git a/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c b/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c
> index eaa0d70024bb..cc0de52de411 100644
> --- a/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c
> +++ b/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c
> @@ -159,7 +159,7 @@ UsbCreateInterface (
>
> if (EFI_ERROR (Status)) {
> gBS->UninstallMultipleProtocolInterfaces (
> - &UsbIf->Handle,
> + UsbIf->Handle,
> &gEfiDevicePathProtocolGuid,
> UsbIf->DevicePath,
> &gEfiUsbIoProtocolGuid,
> diff --git a/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassImpl.c
> b/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassImpl.c
> index 8c27e18cdb87..0dcbc5da2cb8 100644
> --- a/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassImpl.c
> +++ b/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassImpl.c
> @@ -575,7 +575,7 @@ UsbMassInitMultiLun (
> if (EFI_ERROR (Status)) {
> DEBUG ((EFI_D_ERROR, "UsbMassInitMultiLun: OpenUsbIoProtocol By Child (%r)\n", Status));
> gBS->UninstallMultipleProtocolInterfaces (
> - &UsbMass->Controller,
> + UsbMass->Controller,
> &gEfiDevicePathProtocolGuid,
> UsbMass->DevicePath,
> &gEfiBlockIoProtocolGuid,
> --
> 2.19.1.3.g30247aa5d201
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 12/35] MdeModulePkg: stop abusing EFI_HANDLE for keystroke notify registration
2019-09-17 19:49 ` [PATCH 12/35] MdeModulePkg: stop abusing EFI_HANDLE for keystroke notify registration Laszlo Ersek
@ 2019-09-17 20:16 ` Ni, Ray
2019-09-19 1:47 ` Dandan Bi
2019-09-24 10:54 ` [edk2-devel] " Philippe Mathieu-Daudé
2 siblings, 0 replies; 155+ messages in thread
From: Ni, Ray @ 2019-09-17 20:16 UTC (permalink / raw)
To: devel@edk2.groups.io, lersek@redhat.com
Cc: Bi, Dandan, Dong, Eric, Wu, Hao A, Wang, Jian J, Gao, Zhichao
Reviewed-by: Ray Ni <ray.ni@intel.com>
> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Laszlo Ersek
> Sent: Tuesday, September 17, 2019 12:49 PM
> To: edk2-devel-groups-io <devel@edk2.groups.io>
> Cc: Bi, Dandan <dandan.bi@intel.com>; Dong, Eric <eric.dong@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Wang, Jian J
> <jian.j.wang@intel.com>; Ni, Ray <ray.ni@intel.com>; Gao, Zhichao <zhichao.gao@intel.com>
> Subject: [edk2-devel] [PATCH 12/35] MdeModulePkg: stop abusing EFI_HANDLE for keystroke notify registration
>
> EFI_REGISTER_KEYSTROKE_NOTIFY and EFI_UNREGISTER_KEYSTROKE_NOTIFY require
> the notification handle to have type (VOID*). The notification handle has
> nothing to do with the EFI_HANDLE type.
>
> This change is a semantic fix; functionally, it's a no-op.
>
> Cc: Dandan Bi <dandan.bi@intel.com>
> Cc: Eric Dong <eric.dong@intel.com>
> Cc: Hao A Wu <hao.a.wu@intel.com>
> Cc: Jian J Wang <jian.j.wang@intel.com>
> Cc: Ray Ni <ray.ni@intel.com>
> Cc: Zhichao Gao <zhichao.gao@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> lightly tested: ConSplitterDxe is part of the ArmVirt and OVMF platforms
>
> MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c | 2 +-
> MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c
> b/MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c
> index 63c814ae1816..9c38271b65f9 100644
> --- a/MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c
> +++ b/MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c
> @@ -4026,7 +4026,7 @@ ConSplitterTextInRegisterKeyNotify (
> if (NewNotify == NULL) {
> return EFI_OUT_OF_RESOURCES;
> }
> - NewNotify->NotifyHandleList = (EFI_HANDLE *) AllocateZeroPool (sizeof (EFI_HANDLE) * Private->TextInExListCount);
> + NewNotify->NotifyHandleList = (VOID **) AllocateZeroPool (sizeof (VOID *) * Private->TextInExListCount);
> if (NewNotify->NotifyHandleList == NULL) {
> gBS->FreePool (NewNotify);
> return EFI_OUT_OF_RESOURCES;
> diff --git a/MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c
> b/MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c
> index 7cfd5c178861..f98797225b63 100644
> --- a/MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c
> +++ b/MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c
> @@ -143,7 +143,7 @@ InternalStartMonitor(
> EFI_HANDLE *Handles;
> UINTN HandleCount;
> UINTN HandleIndex;
> - EFI_HANDLE NotifyHandle;
> + VOID *NotifyHandle;
>
> Status = gBS->LocateHandleBuffer (
> ByProtocol,
> @@ -202,7 +202,7 @@ InternalStopMonitor(
> EFI_KEY_DATA KeyData;
> UINTN HandleCount;
> UINTN HandleIndex;
> - EFI_HANDLE NotifyHandle;
> + VOID *NotifyHandle;
>
> Status = gBS->LocateHandleBuffer (
> ByProtocol,
> --
> 2.19.1.3.g30247aa5d201
>
>
>
> -=-=-=-=-=-=
> Groups.io Links: You receive all messages sent to this group.
>
> View/Reply Online (#47399): https://edk2.groups.io/g/devel/message/47399
> Mute This Topic: https://groups.io/mt/34180213/1712937
> Group Owner: devel+owner@edk2.groups.io
> Unsubscribe: https://edk2.groups.io/g/devel/unsub [ray.ni@intel.com]
> -=-=-=-=-=-=
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 09/35] MdeModulePkg: stop abusing EFI_EVENT for protocol notify registration
2019-09-17 19:49 ` [PATCH 09/35] MdeModulePkg: stop abusing EFI_EVENT for protocol notify registration Laszlo Ersek
@ 2019-09-17 20:17 ` Ni, Ray
2019-09-25 16:02 ` [edk2-devel] " Philippe Mathieu-Daudé
1 sibling, 0 replies; 155+ messages in thread
From: Ni, Ray @ 2019-09-17 20:17 UTC (permalink / raw)
To: Laszlo Ersek, edk2-devel-groups-io
Cc: Wu, Hao A, Wang, Jian J, Gao, Liming, Gao, Zhichao
Reviewed-by: Ray Ni <ray.ni@intel.com>
> -----Original Message-----
> From: Laszlo Ersek <lersek@redhat.com>
> Sent: Tuesday, September 17, 2019 12:49 PM
> To: edk2-devel-groups-io <devel@edk2.groups.io>
> Cc: Wu, Hao A <hao.a.wu@intel.com>; Wang, Jian J <jian.j.wang@intel.com>; Gao, Liming <liming.gao@intel.com>; Ni, Ray
> <ray.ni@intel.com>; Gao, Zhichao <zhichao.gao@intel.com>
> Subject: [PATCH 09/35] MdeModulePkg: stop abusing EFI_EVENT for protocol notify registration
>
> EfiCreateProtocolNotifyEvent() takes a (VOID**) for "Registration",
> similarly to gBS->RegisterProtocolNotify(). We should pass the address of
> an actual pointer-to-VOID, and not the address of an EFI_EVENT. EFI_EVENT
> just happens to be specified as (VOID*), and has nothing to do with the
> registration.
>
> The same applies to gMmst->MmRegisterProtocolNotify().
>
> "mFtwRegistration", "mFvRegistration", and "mFvbRegistration" are used for
> nothing else.
>
> This change is a no-op in practice; it's a semantic improvement.
>
> Cc: Hao A Wu <hao.a.wu@intel.com>
> Cc: Jian J Wang <jian.j.wang@intel.com>
> Cc: Liming Gao <liming.gao@intel.com>
> Cc: Ray Ni <ray.ni@intel.com>
> Cc: Zhichao Gao <zhichao.gao@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> lightly tested, as these modules (except LoadFileOnFv2) are part of the
> ArmVirt and/or OVMF platforms
>
> MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c | 2 +-
> MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c | 2 +-
> MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.c | 2 +-
> MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c | 2 +-
> 4 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c
> b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c
> index ae8f117905cd..de38ea028af1 100644
> --- a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c
> +++ b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c
> @@ -47,7 +47,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>
> #include <Library/UefiBootServicesTableLib.h>
> #include "FaultTolerantWrite.h"
> -EFI_EVENT mFvbRegistration = NULL;
> +VOID *mFvbRegistration = NULL;
>
>
> /**
> diff --git a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c
> b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c
> index e8e935a85b5b..9612b394865b 100644
> --- a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c
> +++ b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c
> @@ -56,7 +56,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> #include "FaultTolerantWriteSmmCommon.h"
> #include <Protocol/MmEndOfDxe.h>
>
> -EFI_EVENT mFvbRegistration = NULL;
> +VOID *mFvbRegistration = NULL;
> EFI_FTW_DEVICE *mFtwDevice = NULL;
>
> ///
> diff --git a/MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.c
> b/MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.c
> index 4af2da05e145..43fa6ce12875 100644
> --- a/MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.c
> +++ b/MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.c
> @@ -36,7 +36,7 @@ typedef struct {
> #define LOAD_FILE_ON_FV2_PRIVATE_DATA_FROM_THIS(a) CR (a, LOAD_FILE_ON_FV2_PRIVATE_DATA, LoadFile,
> LOAD_FILE_ON_FV2_PRIVATE_DATA_SIGNATURE)
> #define LOAD_FILE_ON_FV2_PRIVATE_DATA_FROM_LINK(a) CR (a, LOAD_FILE_ON_FV2_PRIVATE_DATA, Link,
> LOAD_FILE_ON_FV2_PRIVATE_DATA_SIGNATURE)
>
> -EFI_EVENT mFvRegistration;
> +VOID *mFvRegistration;
> LIST_ENTRY mPrivateDataList;
>
> /**
> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
> index 3d232bb36cb4..7d2b6c8e1fad 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
> @@ -13,7 +13,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>
> EFI_HANDLE mHandle = NULL;
> EFI_EVENT mVirtualAddressChangeEvent = NULL;
> -EFI_EVENT mFtwRegistration = NULL;
> +VOID *mFtwRegistration = NULL;
> VOID ***mVarCheckAddressPointer = NULL;
> UINTN mVarCheckAddressPointerCount = 0;
> EDKII_VARIABLE_LOCK_PROTOCOL mVariableLock = { VariableLockRequestToLock };
> --
> 2.19.1.3.g30247aa5d201
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 01/35] DO NOT APPLY: edk2: turn standard handle types into pointers to non-VOID
2019-09-17 20:06 ` [edk2-devel] " Ni, Ray
@ 2019-09-17 20:22 ` Andrew Fish
2019-09-17 20:28 ` Ni, Ray
2019-09-18 8:41 ` Laszlo Ersek
2019-09-18 8:36 ` Laszlo Ersek
1 sibling, 2 replies; 155+ messages in thread
From: Andrew Fish @ 2019-09-17 20:22 UTC (permalink / raw)
To: Ni, Ray
Cc: devel@edk2.groups.io, lersek@redhat.com, Achin Gupta,
Anthony Perard, Ard Biesheuvel, You, Benjamin, Zhang, Chao B,
Bi, Dandan, David Woodhouse, Dong, Eric, Dong, Guo, Wu, Hao A,
Carsey, Jaben, Wang, Jian J, Wu, Jiaxin, Yao, Jiewen,
Jordan Justen, Julien Grall, Leif Lindholm, Gao, Liming,
Ma, Maurice, Mike Kinney, Fu, Siyuan, Supreeth Venkatesh,
Gao, Zhichao
> On Sep 17, 2019, at 1:06 PM, Ni, Ray <ray.ni@intel.com> wrote:
>
> Laszlo,
> Thank you very much for this work.
> They are quite helpful to detect potential issues.
>
> But without this specific patch being checked in, future break will still happen.
> I don't want it to be checked in ASAP because I know that there are quite a lot of close source code that may get build break due to this change.
> Besides that, what prevent you make the decision to check in the changes?
>
Ray,
I was thinking the same thing. Could we make this an optional feature via a #define? We could always default to the Spec Behavior, and new projects could opt into the stricter version.
#ifndef STRICTER_UEFI_TYPES
typedef VOID *EFI_PEI_FV_HANDLE;
#else
struct EFI_PEI_FV_OBJECT;
typedef struct EFI_PEI_FV_OBJECT *EFI_PEI_FV_HANDLE;
#endif
Thanks,
Andrew Fish
> Thanks,
> Ray
>
>
>> -----Original Message-----
>> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Laszlo Ersek
>> Sent: Tuesday, September 17, 2019 12:49 PM
>> To: edk2-devel-groups-io <devel@edk2.groups.io>
>> Cc: Achin Gupta <achin.gupta@arm.com>; Andrew Fish <afish@apple.com>; Anthony Perard <anthony.perard@citrix.com>;
>> Ard Biesheuvel <ard.biesheuvel@linaro.org>; You, Benjamin <benjamin.you@intel.com>; Zhang, Chao B
>> <chao.b.zhang@intel.com>; Bi, Dandan <dandan.bi@intel.com>; David Woodhouse <dwmw2@infradead.org>; Dong, Eric
>> <eric.dong@intel.com>; Dong, Guo <guo.dong@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Carsey, Jaben
>> <jaben.carsey@intel.com>; Wang, Jian J <jian.j.wang@intel.com>; Wu, Jiaxin <jiaxin.wu@intel.com>; Yao, Jiewen
>> <jiewen.yao@intel.com>; Justen, Jordan L <jordan.l.justen@intel.com>; Julien Grall <julien.grall@arm.com>; Leif Lindholm
>> <leif.lindholm@linaro.org>; Gao, Liming <liming.gao@intel.com>; Ma, Maurice <maurice.ma@intel.com>; Kinney, Michael
>> D <michael.d.kinney@intel.com>; Ni, Ray <ray.ni@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>; Supreeth Venkatesh
>> <supreeth.venkatesh@arm.com>; Gao, Zhichao <zhichao.gao@intel.com>
>> Subject: [edk2-devel] [PATCH 01/35] DO NOT APPLY: edk2: turn standard handle types into pointers to non-VOID
>>
>> Unfortunately, the UEFI / PI / Shell specs define a number of handle types
>> as pointers to VOID. This is a design mistake; those types should have
>> been pointers to incomplete union or structure types. Any
>> pointer-to-object type converts implicitly to, and from, pointer-to-void,
>> which prevents compilers from catching at least the following two types of
>> mistakes:
>>
>> - mixing up one handle type with another (for example, EFI_HANDLE with
>> EFI_EVENT),
>>
>> - getting the depth of indirection wrong (for example, mixing up
>> (EFI_HANDLE*) with EFI_HANDLE).
>>
>> In order to root out such mistakes in the edk2 codebase, introduce
>> incomplete structure types with unique tags, such as:
>>
>> struct EFI_FOOBAR_OBJECT;
>> typedef struct EFI_FOOBAR_OBJECT *EFI_FOOBAR_HANDLE;
>>
>> replacing the spec mandated
>>
>> typedef VOID *EFI_FOOBAR_HANDLE;
>>
>> (For some types, such as:
>>
>> - EFI_ACPI_HANDLE,
>> - EFI_EVENT,
>> - EFI_FONT_HANDLE,
>> - EFI_HANDLE,
>> - EFI_HII_HANDLE,
>> - EFI_S3_BOOT_SCRIPT_POSITION,
>> - SHELL_FILE_HANDLE,
>>
>> we connect the actual complete type (the internal, implementation-specific
>> type) to the typedef. Some of these also demonstrate how the code could
>> have looked in practice if the specs had used proper opaque (=incomplete)
>> types.)
>>
>> Then, unleash "build" on the package DSC files. This causes the compiler
>> to warn about incompatible pointer assignments, and to stop the build.
>>
>> The rest of the series addresses the resultant warnings. Each patch
>> belongs in one of two categories:
>>
>> - semantic cleanups (no functional / behavioral changes),
>> - actual bugfixes.
>>
>> As the subject line of this patch states, this specific patch is *not*
>> meant to be applied. It is just a "what if" patch that temporarily
>> isolates the standard types from each other, the way the specs should
>> have, so that the compiler have more information to work with.
>>
>> Cc: Achin Gupta <achin.gupta@arm.com>
>> Cc: Andrew Fish <afish@apple.com>
>> Cc: Anthony Perard <anthony.perard@citrix.com>
>> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> Cc: Benjamin You <benjamin.you@intel.com>
>> Cc: Chao Zhang <chao.b.zhang@intel.com>
>> Cc: Dandan Bi <dandan.bi@intel.com>
>> Cc: David Woodhouse <dwmw2@infradead.org>
>> Cc: Eric Dong <eric.dong@intel.com>
>> Cc: Guo Dong <guo.dong@intel.com>
>> Cc: Hao A Wu <hao.a.wu@intel.com>
>> Cc: Jaben Carsey <jaben.carsey@intel.com>
>> Cc: Jian J Wang <jian.j.wang@intel.com>
>> Cc: Jian Wang <jian.j.wang@intel.com>
>> Cc: Jiaxin Wu <jiaxin.wu@intel.com>
>> Cc: Jiewen Yao <jiewen.yao@intel.com>
>> Cc: Jordan Justen <jordan.l.justen@intel.com>
>> Cc: Julien Grall <julien.grall@arm.com>
>> Cc: Leif Lindholm <leif.lindholm@linaro.org>
>> Cc: Liming Gao <liming.gao@intel.com>
>> Cc: Maurice Ma <maurice.ma@intel.com>
>> Cc: Michael D Kinney <michael.d.kinney@intel.com>
>> Cc: Ray Ni <ray.ni@intel.com>
>> Cc: Siyuan Fu <siyuan.fu@intel.com>
>> Cc: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
>> Cc: Zhichao Gao <zhichao.gao@intel.com>
>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>> ---
>> MdePkg/Include/Pi/PiPeiCis.h | 6 ++++--
>> MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h | 3 ++-
>> MdePkg/Include/Protocol/Bis.h | 3 ++-
>> MdePkg/Include/Protocol/Eap.h | 3 ++-
>> MdePkg/Include/Protocol/HiiFont.h | 3 +--
>> MdePkg/Include/Protocol/MmMp.h | 3 ++-
>> MdePkg/Include/Protocol/S3SaveState.h | 2 +-
>> MdePkg/Include/Protocol/Shell.h | 3 ++-
>> MdePkg/Include/Protocol/UserManager.h | 9 ++++++---
>> MdePkg/Include/Uefi/UefiBaseType.h | 6 ++++--
>> MdePkg/Include/Uefi/UefiInternalFormRepresentation.h | 3 ++-
>> MdeModulePkg/Core/Dxe/Event/Event.h | 2 +-
>> MdeModulePkg/Core/Dxe/Hand/Handle.h | 2 +-
>> MdeModulePkg/Core/PiSmmCore/PiSmmCore.h | 2 +-
>> MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h | 2 +-
>> MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabase.h | 2 +-
>> StandaloneMmPkg/Core/StandaloneMmCore.h | 2 +-
>> 17 files changed, 34 insertions(+), 22 deletions(-)
>>
>> diff --git a/MdePkg/Include/Pi/PiPeiCis.h b/MdePkg/Include/Pi/PiPeiCis.h
>> index d9d4ed7d413a..3e9e82b62ae9 100644
>> --- a/MdePkg/Include/Pi/PiPeiCis.h
>> +++ b/MdePkg/Include/Pi/PiPeiCis.h
>> @@ -18,12 +18,14 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>> ///
>> /// The handles of EFI FV.
>> ///
>> -typedef VOID *EFI_PEI_FV_HANDLE;
>> +struct EFI_PEI_FV_OBJECT;
>> +typedef struct EFI_PEI_FV_OBJECT *EFI_PEI_FV_HANDLE;
>>
>> ///
>> /// The handles of EFI FFS.
>> ///
>> -typedef VOID *EFI_PEI_FILE_HANDLE;
>> +struct EFI_PEI_FILE_OBJECT;
>> +typedef struct EFI_PEI_FILE_OBJECT *EFI_PEI_FILE_HANDLE;
>>
>> ///
>> /// Declare the forward reference data structure for EFI_PEI_SERVICE.
>> diff --git a/MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h
>> b/MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h
>> index a8e0b24c6c8d..8a1863f3e03d 100644
>> --- a/MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h
>> +++ b/MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h
>> @@ -16,7 +16,8 @@
>> { 0xeb97088e, 0xcfdf, 0x49c6, { 0xbe, 0x4b, 0xd9, 0x6, 0xa5, 0xb2, 0xe, 0x86 }}
>>
>> typedef UINT32 EFI_ACPI_TABLE_VERSION;
>> -typedef VOID *EFI_ACPI_HANDLE;
>> +struct EFI_ACPI_OBJECT;
>> +typedef struct EFI_ACPI_OBJECT *EFI_ACPI_HANDLE;
>>
>> #define EFI_ACPI_TABLE_VERSION_NONE (1 << 0)
>> #define EFI_ACPI_TABLE_VERSION_1_0B (1 << 1)
>> diff --git a/MdePkg/Include/Protocol/Bis.h b/MdePkg/Include/Protocol/Bis.h
>> index 2be6718f4bc2..8eca94512d03 100644
>> --- a/MdePkg/Include/Protocol/Bis.h
>> +++ b/MdePkg/Include/Protocol/Bis.h
>> @@ -37,7 +37,8 @@ typedef struct _EFI_BIS_PROTOCOL EFI_BIS_PROTOCOL;
>> //
>> // Basic types
>> //
>> -typedef VOID *BIS_APPLICATION_HANDLE;
>> +struct BIS_APPLICATION_OBJECT;
>> +typedef struct BIS_APPLICATION_OBJECT *BIS_APPLICATION_HANDLE;
>> typedef UINT16 BIS_ALG_ID;
>> typedef UINT32 BIS_CERT_ID;
>>
>> diff --git a/MdePkg/Include/Protocol/Eap.h b/MdePkg/Include/Protocol/Eap.h
>> index 203d0f40b0dd..06584ef409d0 100644
>> --- a/MdePkg/Include/Protocol/Eap.h
>> +++ b/MdePkg/Include/Protocol/Eap.h
>> @@ -28,7 +28,8 @@ typedef struct _EFI_EAP_PROTOCOL EFI_EAP_PROTOCOL;
>> /// Type for the identification number assigned to the Port by the
>> /// System in which the Port resides.
>> ///
>> -typedef VOID * EFI_PORT_HANDLE;
>> +struct EFI_PORT_OBJECT;
>> +typedef struct EFI_PORT_OBJECT *EFI_PORT_HANDLE;
>>
>> ///
>> /// EAP Authentication Method Type (RFC 3748)
>> diff --git a/MdePkg/Include/Protocol/HiiFont.h b/MdePkg/Include/Protocol/HiiFont.h
>> index 1f2e321ea4e2..450cad9ada70 100644
>> --- a/MdePkg/Include/Protocol/HiiFont.h
>> +++ b/MdePkg/Include/Protocol/HiiFont.h
>> @@ -19,8 +19,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>> { 0xe9ca4775, 0x8657, 0x47fc, { 0x97, 0xe7, 0x7e, 0xd6, 0x5a, 0x8, 0x43, 0x24 } }
>>
>> typedef struct _EFI_HII_FONT_PROTOCOL EFI_HII_FONT_PROTOCOL;
>> -
>> -typedef VOID *EFI_FONT_HANDLE;
>> +typedef LIST_ENTRY *EFI_FONT_HANDLE;
>>
>> ///
>> /// EFI_HII_OUT_FLAGS.
>> diff --git a/MdePkg/Include/Protocol/MmMp.h b/MdePkg/Include/Protocol/MmMp.h
>> index beace1386cbe..cd4e0db47e08 100644
>> --- a/MdePkg/Include/Protocol/MmMp.h
>> +++ b/MdePkg/Include/Protocol/MmMp.h
>> @@ -36,7 +36,8 @@
>> //
>> // Completion token
>> //
>> -typedef VOID* MM_COMPLETION;
>> +struct MM_COMPLETION_OBJECT;
>> +typedef struct MM_COMPLETION_OBJECT* MM_COMPLETION;
>>
>> typedef struct {
>> MM_COMPLETION Completion;
>> diff --git a/MdePkg/Include/Protocol/S3SaveState.h b/MdePkg/Include/Protocol/S3SaveState.h
>> index c1b8f8b9e08d..235c36be6737 100644
>> --- a/MdePkg/Include/Protocol/S3SaveState.h
>> +++ b/MdePkg/Include/Protocol/S3SaveState.h
>> @@ -21,7 +21,7 @@
>> { 0xe857caf6, 0xc046, 0x45dc, { 0xbe, 0x3f, 0xee, 0x7, 0x65, 0xfb, 0xa8, 0x87 }}
>>
>>
>> -typedef VOID *EFI_S3_BOOT_SCRIPT_POSITION;
>> +typedef UINT8 *EFI_S3_BOOT_SCRIPT_POSITION;
>>
>> typedef struct _EFI_S3_SAVE_STATE_PROTOCOL EFI_S3_SAVE_STATE_PROTOCOL;
>>
>> diff --git a/MdePkg/Include/Protocol/Shell.h b/MdePkg/Include/Protocol/Shell.h
>> index cfb7878228c5..bf791792b4f2 100644
>> --- a/MdePkg/Include/Protocol/Shell.h
>> +++ b/MdePkg/Include/Protocol/Shell.h
>> @@ -11,12 +11,13 @@
>> #define __EFI_SHELL_PROTOCOL_H__
>>
>> #include <Guid/FileInfo.h>
>> +#include <Protocol/SimpleFileSystem.h>
>>
>> #define EFI_SHELL_PROTOCOL_GUID \
>> { \
>> 0x6302d008, 0x7f9b, 0x4f30, { 0x87, 0xac, 0x60, 0xc9, 0xfe, 0xf5, 0xda, 0x4e } \
>> }
>> -typedef VOID *SHELL_FILE_HANDLE;
>> +typedef EFI_FILE_PROTOCOL *SHELL_FILE_HANDLE;
>>
>> typedef enum {
>> ///
>> diff --git a/MdePkg/Include/Protocol/UserManager.h b/MdePkg/Include/Protocol/UserManager.h
>> index 26ac4955f1ec..9abfcffbeebf 100644
>> --- a/MdePkg/Include/Protocol/UserManager.h
>> +++ b/MdePkg/Include/Protocol/UserManager.h
>> @@ -24,8 +24,10 @@
>> 0xbaf1e6de, 0x209e, 0x4adb, { 0x8d, 0x96, 0xfd, 0x8b, 0x71, 0xf3, 0xf6, 0x83 } \
>> }
>>
>> -typedef VOID *EFI_USER_PROFILE_HANDLE;
>> -typedef VOID *EFI_USER_INFO_HANDLE;
>> +struct EFI_USER_PROFILE_OBJECT;
>> +typedef struct EFI_USER_PROFILE_OBJECT *EFI_USER_PROFILE_HANDLE;
>> +struct EFI_USER_INFO_OBJECT;
>> +typedef struct EFI_USER_INFO_OBJECT *EFI_USER_INFO_HANDLE;
>>
>> ///
>> /// The attributes of the user profile information.
>> @@ -157,7 +159,8 @@ typedef CHAR16 *EFI_USER_INFO_CREDENTIAL_PROVIDER_NAME;
>> /// Biometric Exchange Formats Framework) specification.
>> ///
>> #define EFI_USER_INFO_CBEFF_RECORD 0x0B
>> -typedef VOID *EFI_USER_INFO_CBEFF;
>> +struct EFI_USER_INFO_CBEFF_OBJECT;
>> +typedef struct EFI_USER_INFO_CBEFF_OBJECT *EFI_USER_INFO_CBEFF;
>> ///
>> /// Indicates how close of a match the fingerprint must be in order to be considered a match.
>> ///
>> diff --git a/MdePkg/Include/Uefi/UefiBaseType.h b/MdePkg/Include/Uefi/UefiBaseType.h
>> index a62f13dd064f..be5831991b52 100644
>> --- a/MdePkg/Include/Uefi/UefiBaseType.h
>> +++ b/MdePkg/Include/Uefi/UefiBaseType.h
>> @@ -28,11 +28,13 @@ typedef RETURN_STATUS EFI_STATUS;
>> ///
>> /// A collection of related interfaces.
>> ///
>> -typedef VOID *EFI_HANDLE;
>> +struct EFI_OBJECT;
>> +typedef struct EFI_OBJECT *EFI_HANDLE;
>> ///
>> /// Handle to an event structure.
>> ///
>> -typedef VOID *EFI_EVENT;
>> +struct EFI_EVENT_OBJECT;
>> +typedef struct EFI_EVENT_OBJECT *EFI_EVENT;
>> ///
>> /// Task priority level.
>> ///
>> diff --git a/MdePkg/Include/Uefi/UefiInternalFormRepresentation.h
>> b/MdePkg/Include/Uefi/UefiInternalFormRepresentation.h
>> index 4a1346a599d0..93bf9e9e0f13 100644
>> --- a/MdePkg/Include/Uefi/UefiInternalFormRepresentation.h
>> +++ b/MdePkg/Include/Uefi/UefiInternalFormRepresentation.h
>> @@ -20,7 +20,8 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>> ///
>> /// The following types are currently defined:
>> ///
>> -typedef VOID* EFI_HII_HANDLE;
>> +struct EFI_HII_OBJECT;
>> +typedef struct EFI_HII_OBJECT* EFI_HII_HANDLE;
>> typedef CHAR16* EFI_STRING;
>> typedef UINT16 EFI_IMAGE_ID;
>> typedef UINT16 EFI_QUESTION_ID;
>> diff --git a/MdeModulePkg/Core/Dxe/Event/Event.h b/MdeModulePkg/Core/Dxe/Event/Event.h
>> index 8141c5003eec..42590cb1dd09 100644
>> --- a/MdeModulePkg/Core/Dxe/Event/Event.h
>> +++ b/MdeModulePkg/Core/Dxe/Event/Event.h
>> @@ -37,7 +37,7 @@ typedef struct {
>> } TIMER_EVENT_INFO;
>>
>> #define EVENT_SIGNATURE SIGNATURE_32('e','v','n','t')
>> -typedef struct {
>> +typedef struct EFI_EVENT_OBJECT {
>> UINTN Signature;
>> UINT32 Type;
>> UINT32 SignalCount;
>> diff --git a/MdeModulePkg/Core/Dxe/Hand/Handle.h b/MdeModulePkg/Core/Dxe/Hand/Handle.h
>> index 83eb2b9f3afe..1f1ab3274e8a 100644
>> --- a/MdeModulePkg/Core/Dxe/Hand/Handle.h
>> +++ b/MdeModulePkg/Core/Dxe/Hand/Handle.h
>> @@ -15,7 +15,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>> ///
>> /// IHANDLE - contains a list of protocol handles
>> ///
>> -typedef struct {
>> +typedef struct EFI_OBJECT {
>> UINTN Signature;
>> /// All handles list of IHANDLE
>> LIST_ENTRY AllHandles;
>> diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
>> index 0908e7f4e9e7..c55da58d465e 100644
>> --- a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
>> +++ b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
>> @@ -145,7 +145,7 @@ typedef struct {
>> ///
>> /// IHANDLE - contains a list of protocol handles
>> ///
>> -typedef struct {
>> +typedef struct EFI_OBJECT {
>> UINTN Signature;
>> /// All handles list of IHANDLE
>> LIST_ENTRY AllHandles;
>> diff --git a/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h
>> b/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h
>> index 50d4c96edb63..bfebbb1f8182 100644
>> --- a/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h
>> +++ b/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h
>> @@ -88,7 +88,7 @@ struct _EFI_AML_NODE_LIST {
>> // This buffer should not be freed.
>> // Size is the total size of this ACPI node buffer.
>> //
>> -typedef struct {
>> +typedef struct EFI_ACPI_OBJECT {
>> UINT32 Signature;
>> UINT8 *Buffer;
>> UINTN Size;
>> diff --git a/MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabase.h
>> b/MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabase.h
>> index 4a3feab94df5..48972d0fcad6 100644
>> --- a/MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabase.h
>> +++ b/MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabase.h
>> @@ -274,7 +274,7 @@ typedef struct _HII_DATABASE_PACKAGE_LIST_INSTANCE {
>>
>> #define HII_HANDLE_SIGNATURE SIGNATURE_32 ('h','i','h','l')
>>
>> -typedef struct {
>> +typedef struct EFI_HII_OBJECT {
>> UINTN Signature;
>> LIST_ENTRY Handle;
>> UINTN Key;
>> diff --git a/StandaloneMmPkg/Core/StandaloneMmCore.h b/StandaloneMmPkg/Core/StandaloneMmCore.h
>> index 4d0eed273f50..dcf91bc5e916 100644
>> --- a/StandaloneMmPkg/Core/StandaloneMmCore.h
>> +++ b/StandaloneMmPkg/Core/StandaloneMmCore.h
>> @@ -105,7 +105,7 @@ typedef struct {
>> ///
>> /// IHANDLE - contains a list of protocol handles
>> ///
>> -typedef struct {
>> +typedef struct EFI_OBJECT {
>> UINTN Signature;
>> /// All handles list of IHANDLE
>> LIST_ENTRY AllHandles;
>> --
>> 2.19.1.3.g30247aa5d201
>>
>>
>>
>> -=-=-=-=-=-=
>> Groups.io Links: You receive all messages sent to this group.
>>
>> View/Reply Online (#47388): https://edk2.groups.io/g/devel/message/47388
>> Mute This Topic: https://groups.io/mt/34180199/1712937
>> Group Owner: devel+owner@edk2.groups.io
>> Unsubscribe: https://edk2.groups.io/g/devel/unsub [ray.ni@intel.com]
>> -=-=-=-=-=-=
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 01/35] DO NOT APPLY: edk2: turn standard handle types into pointers to non-VOID
2019-09-17 20:22 ` Andrew Fish
@ 2019-09-17 20:28 ` Ni, Ray
2019-09-17 21:07 ` Andrew Fish
2019-09-18 8:41 ` Laszlo Ersek
1 sibling, 1 reply; 155+ messages in thread
From: Ni, Ray @ 2019-09-17 20:28 UTC (permalink / raw)
To: devel@edk2.groups.io, afish@apple.com
Cc: lersek@redhat.com, Achin Gupta, Anthony Perard, Ard Biesheuvel,
You, Benjamin, Zhang, Chao B, Bi, Dandan, David Woodhouse,
Dong, Eric, Dong, Guo, Wu, Hao A, Carsey, Jaben, Wang, Jian J,
Wu, Jiaxin, Yao, Jiewen, Justen, Jordan L, Julien Grall,
Leif Lindholm, Gao, Liming, Ma, Maurice, Kinney, Michael D,
Fu, Siyuan, Supreeth Venkatesh, Gao, Zhichao
Andrew,
I agree. Your solution is like "use strict;" in Perl language. (https://perldoc.perl.org/strict.html)
Maybe "STRICT_UEFI_TYPES" without "ER". I don't see any strict in today's code. 😊
Thanks,
Ray
> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Andrew Fish via Groups.Io
> Sent: Tuesday, September 17, 2019 1:22 PM
> To: Ni, Ray <ray.ni@intel.com>
> Cc: devel@edk2.groups.io; lersek@redhat.com; Achin Gupta <achin.gupta@arm.com>; Anthony Perard
> <anthony.perard@citrix.com>; Ard Biesheuvel <ard.biesheuvel@linaro.org>; You, Benjamin <benjamin.you@intel.com>;
> Zhang, Chao B <chao.b.zhang@intel.com>; Bi, Dandan <dandan.bi@intel.com>; David Woodhouse
> <dwmw2@infradead.org>; Dong, Eric <eric.dong@intel.com>; Dong, Guo <guo.dong@intel.com>; Wu, Hao A
> <hao.a.wu@intel.com>; Carsey, Jaben <jaben.carsey@intel.com>; Wang, Jian J <jian.j.wang@intel.com>; Wu, Jiaxin
> <jiaxin.wu@intel.com>; Yao, Jiewen <jiewen.yao@intel.com>; Justen, Jordan L <jordan.l.justen@intel.com>; Julien Grall
> <julien.grall@arm.com>; Leif Lindholm <leif.lindholm@linaro.org>; Gao, Liming <liming.gao@intel.com>; Ma, Maurice
> <maurice.ma@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>; Supreeth
> Venkatesh <supreeth.venkatesh@arm.com>; Gao, Zhichao <zhichao.gao@intel.com>
> Subject: Re: [edk2-devel] [PATCH 01/35] DO NOT APPLY: edk2: turn standard handle types into pointers to non-VOID
>
>
>
> > On Sep 17, 2019, at 1:06 PM, Ni, Ray <ray.ni@intel.com> wrote:
> >
> > Laszlo,
> > Thank you very much for this work.
> > They are quite helpful to detect potential issues.
> >
> > But without this specific patch being checked in, future break will still happen.
> > I don't want it to be checked in ASAP because I know that there are quite a lot of close source code that may get build
> break due to this change.
> > Besides that, what prevent you make the decision to check in the changes?
> >
>
> Ray,
>
> I was thinking the same thing. Could we make this an optional feature via a #define? We could always default to the Spec
> Behavior, and new projects could opt into the stricter version.
>
> #ifndef STRICTER_UEFI_TYPES
> typedef VOID *EFI_PEI_FV_HANDLE;
> #else
> struct EFI_PEI_FV_OBJECT;
> typedef struct EFI_PEI_FV_OBJECT *EFI_PEI_FV_HANDLE;
> #endif
>
> Thanks,
>
> Andrew Fish
>
> > Thanks,
> > Ray
> >
> >
> >> -----Original Message-----
> >> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Laszlo Ersek
> >> Sent: Tuesday, September 17, 2019 12:49 PM
> >> To: edk2-devel-groups-io <devel@edk2.groups.io>
> >> Cc: Achin Gupta <achin.gupta@arm.com>; Andrew Fish <afish@apple.com>; Anthony Perard
> <anthony.perard@citrix.com>;
> >> Ard Biesheuvel <ard.biesheuvel@linaro.org>; You, Benjamin <benjamin.you@intel.com>; Zhang, Chao B
> >> <chao.b.zhang@intel.com>; Bi, Dandan <dandan.bi@intel.com>; David Woodhouse <dwmw2@infradead.org>; Dong,
> Eric
> >> <eric.dong@intel.com>; Dong, Guo <guo.dong@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Carsey, Jaben
> >> <jaben.carsey@intel.com>; Wang, Jian J <jian.j.wang@intel.com>; Wu, Jiaxin <jiaxin.wu@intel.com>; Yao, Jiewen
> >> <jiewen.yao@intel.com>; Justen, Jordan L <jordan.l.justen@intel.com>; Julien Grall <julien.grall@arm.com>; Leif
> Lindholm
> >> <leif.lindholm@linaro.org>; Gao, Liming <liming.gao@intel.com>; Ma, Maurice <maurice.ma@intel.com>; Kinney,
> Michael
> >> D <michael.d.kinney@intel.com>; Ni, Ray <ray.ni@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>; Supreeth Venkatesh
> >> <supreeth.venkatesh@arm.com>; Gao, Zhichao <zhichao.gao@intel.com>
> >> Subject: [edk2-devel] [PATCH 01/35] DO NOT APPLY: edk2: turn standard handle types into pointers to non-VOID
> >>
> >> Unfortunately, the UEFI / PI / Shell specs define a number of handle types
> >> as pointers to VOID. This is a design mistake; those types should have
> >> been pointers to incomplete union or structure types. Any
> >> pointer-to-object type converts implicitly to, and from, pointer-to-void,
> >> which prevents compilers from catching at least the following two types of
> >> mistakes:
> >>
> >> - mixing up one handle type with another (for example, EFI_HANDLE with
> >> EFI_EVENT),
> >>
> >> - getting the depth of indirection wrong (for example, mixing up
> >> (EFI_HANDLE*) with EFI_HANDLE).
> >>
> >> In order to root out such mistakes in the edk2 codebase, introduce
> >> incomplete structure types with unique tags, such as:
> >>
> >> struct EFI_FOOBAR_OBJECT;
> >> typedef struct EFI_FOOBAR_OBJECT *EFI_FOOBAR_HANDLE;
> >>
> >> replacing the spec mandated
> >>
> >> typedef VOID *EFI_FOOBAR_HANDLE;
> >>
> >> (For some types, such as:
> >>
> >> - EFI_ACPI_HANDLE,
> >> - EFI_EVENT,
> >> - EFI_FONT_HANDLE,
> >> - EFI_HANDLE,
> >> - EFI_HII_HANDLE,
> >> - EFI_S3_BOOT_SCRIPT_POSITION,
> >> - SHELL_FILE_HANDLE,
> >>
> >> we connect the actual complete type (the internal, implementation-specific
> >> type) to the typedef. Some of these also demonstrate how the code could
> >> have looked in practice if the specs had used proper opaque (=incomplete)
> >> types.)
> >>
> >> Then, unleash "build" on the package DSC files. This causes the compiler
> >> to warn about incompatible pointer assignments, and to stop the build.
> >>
> >> The rest of the series addresses the resultant warnings. Each patch
> >> belongs in one of two categories:
> >>
> >> - semantic cleanups (no functional / behavioral changes),
> >> - actual bugfixes.
> >>
> >> As the subject line of this patch states, this specific patch is *not*
> >> meant to be applied. It is just a "what if" patch that temporarily
> >> isolates the standard types from each other, the way the specs should
> >> have, so that the compiler have more information to work with.
> >>
> >> Cc: Achin Gupta <achin.gupta@arm.com>
> >> Cc: Andrew Fish <afish@apple.com>
> >> Cc: Anthony Perard <anthony.perard@citrix.com>
> >> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> >> Cc: Benjamin You <benjamin.you@intel.com>
> >> Cc: Chao Zhang <chao.b.zhang@intel.com>
> >> Cc: Dandan Bi <dandan.bi@intel.com>
> >> Cc: David Woodhouse <dwmw2@infradead.org>
> >> Cc: Eric Dong <eric.dong@intel.com>
> >> Cc: Guo Dong <guo.dong@intel.com>
> >> Cc: Hao A Wu <hao.a.wu@intel.com>
> >> Cc: Jaben Carsey <jaben.carsey@intel.com>
> >> Cc: Jian J Wang <jian.j.wang@intel.com>
> >> Cc: Jian Wang <jian.j.wang@intel.com>
> >> Cc: Jiaxin Wu <jiaxin.wu@intel.com>
> >> Cc: Jiewen Yao <jiewen.yao@intel.com>
> >> Cc: Jordan Justen <jordan.l.justen@intel.com>
> >> Cc: Julien Grall <julien.grall@arm.com>
> >> Cc: Leif Lindholm <leif.lindholm@linaro.org>
> >> Cc: Liming Gao <liming.gao@intel.com>
> >> Cc: Maurice Ma <maurice.ma@intel.com>
> >> Cc: Michael D Kinney <michael.d.kinney@intel.com>
> >> Cc: Ray Ni <ray.ni@intel.com>
> >> Cc: Siyuan Fu <siyuan.fu@intel.com>
> >> Cc: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
> >> Cc: Zhichao Gao <zhichao.gao@intel.com>
> >> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> >> ---
> >> MdePkg/Include/Pi/PiPeiCis.h | 6 ++++--
> >> MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h | 3 ++-
> >> MdePkg/Include/Protocol/Bis.h | 3 ++-
> >> MdePkg/Include/Protocol/Eap.h | 3 ++-
> >> MdePkg/Include/Protocol/HiiFont.h | 3 +--
> >> MdePkg/Include/Protocol/MmMp.h | 3 ++-
> >> MdePkg/Include/Protocol/S3SaveState.h | 2 +-
> >> MdePkg/Include/Protocol/Shell.h | 3 ++-
> >> MdePkg/Include/Protocol/UserManager.h | 9 ++++++---
> >> MdePkg/Include/Uefi/UefiBaseType.h | 6 ++++--
> >> MdePkg/Include/Uefi/UefiInternalFormRepresentation.h | 3 ++-
> >> MdeModulePkg/Core/Dxe/Event/Event.h | 2 +-
> >> MdeModulePkg/Core/Dxe/Hand/Handle.h | 2 +-
> >> MdeModulePkg/Core/PiSmmCore/PiSmmCore.h | 2 +-
> >> MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h | 2 +-
> >> MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabase.h | 2 +-
> >> StandaloneMmPkg/Core/StandaloneMmCore.h | 2 +-
> >> 17 files changed, 34 insertions(+), 22 deletions(-)
> >>
> >> diff --git a/MdePkg/Include/Pi/PiPeiCis.h b/MdePkg/Include/Pi/PiPeiCis.h
> >> index d9d4ed7d413a..3e9e82b62ae9 100644
> >> --- a/MdePkg/Include/Pi/PiPeiCis.h
> >> +++ b/MdePkg/Include/Pi/PiPeiCis.h
> >> @@ -18,12 +18,14 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> >> ///
> >> /// The handles of EFI FV.
> >> ///
> >> -typedef VOID *EFI_PEI_FV_HANDLE;
> >> +struct EFI_PEI_FV_OBJECT;
> >> +typedef struct EFI_PEI_FV_OBJECT *EFI_PEI_FV_HANDLE;
> >>
> >> ///
> >> /// The handles of EFI FFS.
> >> ///
> >> -typedef VOID *EFI_PEI_FILE_HANDLE;
> >> +struct EFI_PEI_FILE_OBJECT;
> >> +typedef struct EFI_PEI_FILE_OBJECT *EFI_PEI_FILE_HANDLE;
> >>
> >> ///
> >> /// Declare the forward reference data structure for EFI_PEI_SERVICE.
> >> diff --git a/MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h
> >> b/MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h
> >> index a8e0b24c6c8d..8a1863f3e03d 100644
> >> --- a/MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h
> >> +++ b/MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h
> >> @@ -16,7 +16,8 @@
> >> { 0xeb97088e, 0xcfdf, 0x49c6, { 0xbe, 0x4b, 0xd9, 0x6, 0xa5, 0xb2, 0xe, 0x86 }}
> >>
> >> typedef UINT32 EFI_ACPI_TABLE_VERSION;
> >> -typedef VOID *EFI_ACPI_HANDLE;
> >> +struct EFI_ACPI_OBJECT;
> >> +typedef struct EFI_ACPI_OBJECT *EFI_ACPI_HANDLE;
> >>
> >> #define EFI_ACPI_TABLE_VERSION_NONE (1 << 0)
> >> #define EFI_ACPI_TABLE_VERSION_1_0B (1 << 1)
> >> diff --git a/MdePkg/Include/Protocol/Bis.h b/MdePkg/Include/Protocol/Bis.h
> >> index 2be6718f4bc2..8eca94512d03 100644
> >> --- a/MdePkg/Include/Protocol/Bis.h
> >> +++ b/MdePkg/Include/Protocol/Bis.h
> >> @@ -37,7 +37,8 @@ typedef struct _EFI_BIS_PROTOCOL EFI_BIS_PROTOCOL;
> >> //
> >> // Basic types
> >> //
> >> -typedef VOID *BIS_APPLICATION_HANDLE;
> >> +struct BIS_APPLICATION_OBJECT;
> >> +typedef struct BIS_APPLICATION_OBJECT *BIS_APPLICATION_HANDLE;
> >> typedef UINT16 BIS_ALG_ID;
> >> typedef UINT32 BIS_CERT_ID;
> >>
> >> diff --git a/MdePkg/Include/Protocol/Eap.h b/MdePkg/Include/Protocol/Eap.h
> >> index 203d0f40b0dd..06584ef409d0 100644
> >> --- a/MdePkg/Include/Protocol/Eap.h
> >> +++ b/MdePkg/Include/Protocol/Eap.h
> >> @@ -28,7 +28,8 @@ typedef struct _EFI_EAP_PROTOCOL EFI_EAP_PROTOCOL;
> >> /// Type for the identification number assigned to the Port by the
> >> /// System in which the Port resides.
> >> ///
> >> -typedef VOID * EFI_PORT_HANDLE;
> >> +struct EFI_PORT_OBJECT;
> >> +typedef struct EFI_PORT_OBJECT *EFI_PORT_HANDLE;
> >>
> >> ///
> >> /// EAP Authentication Method Type (RFC 3748)
> >> diff --git a/MdePkg/Include/Protocol/HiiFont.h b/MdePkg/Include/Protocol/HiiFont.h
> >> index 1f2e321ea4e2..450cad9ada70 100644
> >> --- a/MdePkg/Include/Protocol/HiiFont.h
> >> +++ b/MdePkg/Include/Protocol/HiiFont.h
> >> @@ -19,8 +19,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> >> { 0xe9ca4775, 0x8657, 0x47fc, { 0x97, 0xe7, 0x7e, 0xd6, 0x5a, 0x8, 0x43, 0x24 } }
> >>
> >> typedef struct _EFI_HII_FONT_PROTOCOL EFI_HII_FONT_PROTOCOL;
> >> -
> >> -typedef VOID *EFI_FONT_HANDLE;
> >> +typedef LIST_ENTRY *EFI_FONT_HANDLE;
> >>
> >> ///
> >> /// EFI_HII_OUT_FLAGS.
> >> diff --git a/MdePkg/Include/Protocol/MmMp.h b/MdePkg/Include/Protocol/MmMp.h
> >> index beace1386cbe..cd4e0db47e08 100644
> >> --- a/MdePkg/Include/Protocol/MmMp.h
> >> +++ b/MdePkg/Include/Protocol/MmMp.h
> >> @@ -36,7 +36,8 @@
> >> //
> >> // Completion token
> >> //
> >> -typedef VOID* MM_COMPLETION;
> >> +struct MM_COMPLETION_OBJECT;
> >> +typedef struct MM_COMPLETION_OBJECT* MM_COMPLETION;
> >>
> >> typedef struct {
> >> MM_COMPLETION Completion;
> >> diff --git a/MdePkg/Include/Protocol/S3SaveState.h b/MdePkg/Include/Protocol/S3SaveState.h
> >> index c1b8f8b9e08d..235c36be6737 100644
> >> --- a/MdePkg/Include/Protocol/S3SaveState.h
> >> +++ b/MdePkg/Include/Protocol/S3SaveState.h
> >> @@ -21,7 +21,7 @@
> >> { 0xe857caf6, 0xc046, 0x45dc, { 0xbe, 0x3f, 0xee, 0x7, 0x65, 0xfb, 0xa8, 0x87 }}
> >>
> >>
> >> -typedef VOID *EFI_S3_BOOT_SCRIPT_POSITION;
> >> +typedef UINT8 *EFI_S3_BOOT_SCRIPT_POSITION;
> >>
> >> typedef struct _EFI_S3_SAVE_STATE_PROTOCOL EFI_S3_SAVE_STATE_PROTOCOL;
> >>
> >> diff --git a/MdePkg/Include/Protocol/Shell.h b/MdePkg/Include/Protocol/Shell.h
> >> index cfb7878228c5..bf791792b4f2 100644
> >> --- a/MdePkg/Include/Protocol/Shell.h
> >> +++ b/MdePkg/Include/Protocol/Shell.h
> >> @@ -11,12 +11,13 @@
> >> #define __EFI_SHELL_PROTOCOL_H__
> >>
> >> #include <Guid/FileInfo.h>
> >> +#include <Protocol/SimpleFileSystem.h>
> >>
> >> #define EFI_SHELL_PROTOCOL_GUID \
> >> { \
> >> 0x6302d008, 0x7f9b, 0x4f30, { 0x87, 0xac, 0x60, 0xc9, 0xfe, 0xf5, 0xda, 0x4e } \
> >> }
> >> -typedef VOID *SHELL_FILE_HANDLE;
> >> +typedef EFI_FILE_PROTOCOL *SHELL_FILE_HANDLE;
> >>
> >> typedef enum {
> >> ///
> >> diff --git a/MdePkg/Include/Protocol/UserManager.h b/MdePkg/Include/Protocol/UserManager.h
> >> index 26ac4955f1ec..9abfcffbeebf 100644
> >> --- a/MdePkg/Include/Protocol/UserManager.h
> >> +++ b/MdePkg/Include/Protocol/UserManager.h
> >> @@ -24,8 +24,10 @@
> >> 0xbaf1e6de, 0x209e, 0x4adb, { 0x8d, 0x96, 0xfd, 0x8b, 0x71, 0xf3, 0xf6, 0x83 } \
> >> }
> >>
> >> -typedef VOID *EFI_USER_PROFILE_HANDLE;
> >> -typedef VOID *EFI_USER_INFO_HANDLE;
> >> +struct EFI_USER_PROFILE_OBJECT;
> >> +typedef struct EFI_USER_PROFILE_OBJECT *EFI_USER_PROFILE_HANDLE;
> >> +struct EFI_USER_INFO_OBJECT;
> >> +typedef struct EFI_USER_INFO_OBJECT *EFI_USER_INFO_HANDLE;
> >>
> >> ///
> >> /// The attributes of the user profile information.
> >> @@ -157,7 +159,8 @@ typedef CHAR16 *EFI_USER_INFO_CREDENTIAL_PROVIDER_NAME;
> >> /// Biometric Exchange Formats Framework) specification.
> >> ///
> >> #define EFI_USER_INFO_CBEFF_RECORD 0x0B
> >> -typedef VOID *EFI_USER_INFO_CBEFF;
> >> +struct EFI_USER_INFO_CBEFF_OBJECT;
> >> +typedef struct EFI_USER_INFO_CBEFF_OBJECT *EFI_USER_INFO_CBEFF;
> >> ///
> >> /// Indicates how close of a match the fingerprint must be in order to be considered a match.
> >> ///
> >> diff --git a/MdePkg/Include/Uefi/UefiBaseType.h b/MdePkg/Include/Uefi/UefiBaseType.h
> >> index a62f13dd064f..be5831991b52 100644
> >> --- a/MdePkg/Include/Uefi/UefiBaseType.h
> >> +++ b/MdePkg/Include/Uefi/UefiBaseType.h
> >> @@ -28,11 +28,13 @@ typedef RETURN_STATUS EFI_STATUS;
> >> ///
> >> /// A collection of related interfaces.
> >> ///
> >> -typedef VOID *EFI_HANDLE;
> >> +struct EFI_OBJECT;
> >> +typedef struct EFI_OBJECT *EFI_HANDLE;
> >> ///
> >> /// Handle to an event structure.
> >> ///
> >> -typedef VOID *EFI_EVENT;
> >> +struct EFI_EVENT_OBJECT;
> >> +typedef struct EFI_EVENT_OBJECT *EFI_EVENT;
> >> ///
> >> /// Task priority level.
> >> ///
> >> diff --git a/MdePkg/Include/Uefi/UefiInternalFormRepresentation.h
> >> b/MdePkg/Include/Uefi/UefiInternalFormRepresentation.h
> >> index 4a1346a599d0..93bf9e9e0f13 100644
> >> --- a/MdePkg/Include/Uefi/UefiInternalFormRepresentation.h
> >> +++ b/MdePkg/Include/Uefi/UefiInternalFormRepresentation.h
> >> @@ -20,7 +20,8 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> >> ///
> >> /// The following types are currently defined:
> >> ///
> >> -typedef VOID* EFI_HII_HANDLE;
> >> +struct EFI_HII_OBJECT;
> >> +typedef struct EFI_HII_OBJECT* EFI_HII_HANDLE;
> >> typedef CHAR16* EFI_STRING;
> >> typedef UINT16 EFI_IMAGE_ID;
> >> typedef UINT16 EFI_QUESTION_ID;
> >> diff --git a/MdeModulePkg/Core/Dxe/Event/Event.h b/MdeModulePkg/Core/Dxe/Event/Event.h
> >> index 8141c5003eec..42590cb1dd09 100644
> >> --- a/MdeModulePkg/Core/Dxe/Event/Event.h
> >> +++ b/MdeModulePkg/Core/Dxe/Event/Event.h
> >> @@ -37,7 +37,7 @@ typedef struct {
> >> } TIMER_EVENT_INFO;
> >>
> >> #define EVENT_SIGNATURE SIGNATURE_32('e','v','n','t')
> >> -typedef struct {
> >> +typedef struct EFI_EVENT_OBJECT {
> >> UINTN Signature;
> >> UINT32 Type;
> >> UINT32 SignalCount;
> >> diff --git a/MdeModulePkg/Core/Dxe/Hand/Handle.h b/MdeModulePkg/Core/Dxe/Hand/Handle.h
> >> index 83eb2b9f3afe..1f1ab3274e8a 100644
> >> --- a/MdeModulePkg/Core/Dxe/Hand/Handle.h
> >> +++ b/MdeModulePkg/Core/Dxe/Hand/Handle.h
> >> @@ -15,7 +15,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> >> ///
> >> /// IHANDLE - contains a list of protocol handles
> >> ///
> >> -typedef struct {
> >> +typedef struct EFI_OBJECT {
> >> UINTN Signature;
> >> /// All handles list of IHANDLE
> >> LIST_ENTRY AllHandles;
> >> diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
> >> index 0908e7f4e9e7..c55da58d465e 100644
> >> --- a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
> >> +++ b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
> >> @@ -145,7 +145,7 @@ typedef struct {
> >> ///
> >> /// IHANDLE - contains a list of protocol handles
> >> ///
> >> -typedef struct {
> >> +typedef struct EFI_OBJECT {
> >> UINTN Signature;
> >> /// All handles list of IHANDLE
> >> LIST_ENTRY AllHandles;
> >> diff --git a/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h
> >> b/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h
> >> index 50d4c96edb63..bfebbb1f8182 100644
> >> --- a/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h
> >> +++ b/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h
> >> @@ -88,7 +88,7 @@ struct _EFI_AML_NODE_LIST {
> >> // This buffer should not be freed.
> >> // Size is the total size of this ACPI node buffer.
> >> //
> >> -typedef struct {
> >> +typedef struct EFI_ACPI_OBJECT {
> >> UINT32 Signature;
> >> UINT8 *Buffer;
> >> UINTN Size;
> >> diff --git a/MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabase.h
> >> b/MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabase.h
> >> index 4a3feab94df5..48972d0fcad6 100644
> >> --- a/MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabase.h
> >> +++ b/MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabase.h
> >> @@ -274,7 +274,7 @@ typedef struct _HII_DATABASE_PACKAGE_LIST_INSTANCE {
> >>
> >> #define HII_HANDLE_SIGNATURE SIGNATURE_32 ('h','i','h','l')
> >>
> >> -typedef struct {
> >> +typedef struct EFI_HII_OBJECT {
> >> UINTN Signature;
> >> LIST_ENTRY Handle;
> >> UINTN Key;
> >> diff --git a/StandaloneMmPkg/Core/StandaloneMmCore.h b/StandaloneMmPkg/Core/StandaloneMmCore.h
> >> index 4d0eed273f50..dcf91bc5e916 100644
> >> --- a/StandaloneMmPkg/Core/StandaloneMmCore.h
> >> +++ b/StandaloneMmPkg/Core/StandaloneMmCore.h
> >> @@ -105,7 +105,7 @@ typedef struct {
> >> ///
> >> /// IHANDLE - contains a list of protocol handles
> >> ///
> >> -typedef struct {
> >> +typedef struct EFI_OBJECT {
> >> UINTN Signature;
> >> /// All handles list of IHANDLE
> >> LIST_ENTRY AllHandles;
> >> --
> >> 2.19.1.3.g30247aa5d201
> >>
> >>
> >>
> >> -=-=-=-=-=-=
> >> Groups.io Links: You receive all messages sent to this group.
> >>
> >> View/Reply Online (#47388): https://edk2.groups.io/g/devel/message/47388
> >> Mute This Topic: https://groups.io/mt/34180199/1712937
> >> Group Owner: devel+owner@edk2.groups.io
> >> Unsubscribe: https://edk2.groups.io/g/devel/unsub [ray.ni@intel.com]
> >> -=-=-=-=-=-=
> >
>
>
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 01/35] DO NOT APPLY: edk2: turn standard handle types into pointers to non-VOID
2019-09-17 20:28 ` Ni, Ray
@ 2019-09-17 21:07 ` Andrew Fish
2019-09-17 21:11 ` Michael D Kinney
0 siblings, 1 reply; 155+ messages in thread
From: Andrew Fish @ 2019-09-17 21:07 UTC (permalink / raw)
To: devel, ray.ni
Cc: lersek@redhat.com, Achin Gupta, Anthony Perard, Ard Biesheuvel,
You, Benjamin, Zhang, Chao B, Bi, Dandan, David Woodhouse,
Dong, Eric, Dong, Guo, Wu, Hao A, Carsey, Jaben, Wang, Jian J,
Wu, Jiaxin, Yao, Jiewen, Jordan Justen, Julien Grall,
Leif Lindholm, Gao, Liming, Ma, Maurice, Mike Kinney, Fu, Siyuan,
Supreeth Venkatesh, Gao, Zhichao
> On Sep 17, 2019, at 1:28 PM, Ni, Ray <ray.ni@intel.com> wrote:
>
> Andrew,
> I agree. Your solution is like "use strict;" in Perl language. (https://perldoc.perl.org/strict.html)
> Maybe "STRICT_UEFI_TYPES" without "ER". I don't see any strict in today's code. 😊
>
Ray,
I'm flexible on the name, I was just trying to give a good example of what I was suggesting.
Thanks,
Andrew Fish
> Thanks,
> Ray
>
>> -----Original Message-----
>> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Andrew Fish via Groups.Io
>> Sent: Tuesday, September 17, 2019 1:22 PM
>> To: Ni, Ray <ray.ni@intel.com>
>> Cc: devel@edk2.groups.io; lersek@redhat.com; Achin Gupta <achin.gupta@arm.com>; Anthony Perard
>> <anthony.perard@citrix.com>; Ard Biesheuvel <ard.biesheuvel@linaro.org>; You, Benjamin <benjamin.you@intel.com>;
>> Zhang, Chao B <chao.b.zhang@intel.com>; Bi, Dandan <dandan.bi@intel.com>; David Woodhouse
>> <dwmw2@infradead.org>; Dong, Eric <eric.dong@intel.com>; Dong, Guo <guo.dong@intel.com>; Wu, Hao A
>> <hao.a.wu@intel.com>; Carsey, Jaben <jaben.carsey@intel.com>; Wang, Jian J <jian.j.wang@intel.com>; Wu, Jiaxin
>> <jiaxin.wu@intel.com>; Yao, Jiewen <jiewen.yao@intel.com>; Justen, Jordan L <jordan.l.justen@intel.com>; Julien Grall
>> <julien.grall@arm.com>; Leif Lindholm <leif.lindholm@linaro.org>; Gao, Liming <liming.gao@intel.com>; Ma, Maurice
>> <maurice.ma@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>; Supreeth
>> Venkatesh <supreeth.venkatesh@arm.com>; Gao, Zhichao <zhichao.gao@intel.com>
>> Subject: Re: [edk2-devel] [PATCH 01/35] DO NOT APPLY: edk2: turn standard handle types into pointers to non-VOID
>>
>>
>>
>>> On Sep 17, 2019, at 1:06 PM, Ni, Ray <ray.ni@intel.com> wrote:
>>>
>>> Laszlo,
>>> Thank you very much for this work.
>>> They are quite helpful to detect potential issues.
>>>
>>> But without this specific patch being checked in, future break will still happen.
>>> I don't want it to be checked in ASAP because I know that there are quite a lot of close source code that may get build
>> break due to this change.
>>> Besides that, what prevent you make the decision to check in the changes?
>>>
>>
>> Ray,
>>
>> I was thinking the same thing. Could we make this an optional feature via a #define? We could always default to the Spec
>> Behavior, and new projects could opt into the stricter version.
>>
>> #ifndef STRICTER_UEFI_TYPES
>> typedef VOID *EFI_PEI_FV_HANDLE;
>> #else
>> struct EFI_PEI_FV_OBJECT;
>> typedef struct EFI_PEI_FV_OBJECT *EFI_PEI_FV_HANDLE;
>> #endif
>>
>> Thanks,
>>
>> Andrew Fish
>>
>>> Thanks,
>>> Ray
>>>
>>>
>>>> -----Original Message-----
>>>> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Laszlo Ersek
>>>> Sent: Tuesday, September 17, 2019 12:49 PM
>>>> To: edk2-devel-groups-io <devel@edk2.groups.io>
>>>> Cc: Achin Gupta <achin.gupta@arm.com>; Andrew Fish <afish@apple.com>; Anthony Perard
>> <anthony.perard@citrix.com>;
>>>> Ard Biesheuvel <ard.biesheuvel@linaro.org>; You, Benjamin <benjamin.you@intel.com>; Zhang, Chao B
>>>> <chao.b.zhang@intel.com>; Bi, Dandan <dandan.bi@intel.com>; David Woodhouse <dwmw2@infradead.org>; Dong,
>> Eric
>>>> <eric.dong@intel.com>; Dong, Guo <guo.dong@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Carsey, Jaben
>>>> <jaben.carsey@intel.com>; Wang, Jian J <jian.j.wang@intel.com>; Wu, Jiaxin <jiaxin.wu@intel.com>; Yao, Jiewen
>>>> <jiewen.yao@intel.com>; Justen, Jordan L <jordan.l.justen@intel.com>; Julien Grall <julien.grall@arm.com>; Leif
>> Lindholm
>>>> <leif.lindholm@linaro.org>; Gao, Liming <liming.gao@intel.com>; Ma, Maurice <maurice.ma@intel.com>; Kinney,
>> Michael
>>>> D <michael.d.kinney@intel.com>; Ni, Ray <ray.ni@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>; Supreeth Venkatesh
>>>> <supreeth.venkatesh@arm.com>; Gao, Zhichao <zhichao.gao@intel.com>
>>>> Subject: [edk2-devel] [PATCH 01/35] DO NOT APPLY: edk2: turn standard handle types into pointers to non-VOID
>>>>
>>>> Unfortunately, the UEFI / PI / Shell specs define a number of handle types
>>>> as pointers to VOID. This is a design mistake; those types should have
>>>> been pointers to incomplete union or structure types. Any
>>>> pointer-to-object type converts implicitly to, and from, pointer-to-void,
>>>> which prevents compilers from catching at least the following two types of
>>>> mistakes:
>>>>
>>>> - mixing up one handle type with another (for example, EFI_HANDLE with
>>>> EFI_EVENT),
>>>>
>>>> - getting the depth of indirection wrong (for example, mixing up
>>>> (EFI_HANDLE*) with EFI_HANDLE).
>>>>
>>>> In order to root out such mistakes in the edk2 codebase, introduce
>>>> incomplete structure types with unique tags, such as:
>>>>
>>>> struct EFI_FOOBAR_OBJECT;
>>>> typedef struct EFI_FOOBAR_OBJECT *EFI_FOOBAR_HANDLE;
>>>>
>>>> replacing the spec mandated
>>>>
>>>> typedef VOID *EFI_FOOBAR_HANDLE;
>>>>
>>>> (For some types, such as:
>>>>
>>>> - EFI_ACPI_HANDLE,
>>>> - EFI_EVENT,
>>>> - EFI_FONT_HANDLE,
>>>> - EFI_HANDLE,
>>>> - EFI_HII_HANDLE,
>>>> - EFI_S3_BOOT_SCRIPT_POSITION,
>>>> - SHELL_FILE_HANDLE,
>>>>
>>>> we connect the actual complete type (the internal, implementation-specific
>>>> type) to the typedef. Some of these also demonstrate how the code could
>>>> have looked in practice if the specs had used proper opaque (=incomplete)
>>>> types.)
>>>>
>>>> Then, unleash "build" on the package DSC files. This causes the compiler
>>>> to warn about incompatible pointer assignments, and to stop the build.
>>>>
>>>> The rest of the series addresses the resultant warnings. Each patch
>>>> belongs in one of two categories:
>>>>
>>>> - semantic cleanups (no functional / behavioral changes),
>>>> - actual bugfixes.
>>>>
>>>> As the subject line of this patch states, this specific patch is *not*
>>>> meant to be applied. It is just a "what if" patch that temporarily
>>>> isolates the standard types from each other, the way the specs should
>>>> have, so that the compiler have more information to work with.
>>>>
>>>> Cc: Achin Gupta <achin.gupta@arm.com>
>>>> Cc: Andrew Fish <afish@apple.com>
>>>> Cc: Anthony Perard <anthony.perard@citrix.com>
>>>> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>>>> Cc: Benjamin You <benjamin.you@intel.com>
>>>> Cc: Chao Zhang <chao.b.zhang@intel.com>
>>>> Cc: Dandan Bi <dandan.bi@intel.com>
>>>> Cc: David Woodhouse <dwmw2@infradead.org>
>>>> Cc: Eric Dong <eric.dong@intel.com>
>>>> Cc: Guo Dong <guo.dong@intel.com>
>>>> Cc: Hao A Wu <hao.a.wu@intel.com>
>>>> Cc: Jaben Carsey <jaben.carsey@intel.com>
>>>> Cc: Jian J Wang <jian.j.wang@intel.com>
>>>> Cc: Jian Wang <jian.j.wang@intel.com>
>>>> Cc: Jiaxin Wu <jiaxin.wu@intel.com>
>>>> Cc: Jiewen Yao <jiewen.yao@intel.com>
>>>> Cc: Jordan Justen <jordan.l.justen@intel.com>
>>>> Cc: Julien Grall <julien.grall@arm.com>
>>>> Cc: Leif Lindholm <leif.lindholm@linaro.org>
>>>> Cc: Liming Gao <liming.gao@intel.com>
>>>> Cc: Maurice Ma <maurice.ma@intel.com>
>>>> Cc: Michael D Kinney <michael.d.kinney@intel.com>
>>>> Cc: Ray Ni <ray.ni@intel.com>
>>>> Cc: Siyuan Fu <siyuan.fu@intel.com>
>>>> Cc: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
>>>> Cc: Zhichao Gao <zhichao.gao@intel.com>
>>>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>>>> ---
>>>> MdePkg/Include/Pi/PiPeiCis.h | 6 ++++--
>>>> MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h | 3 ++-
>>>> MdePkg/Include/Protocol/Bis.h | 3 ++-
>>>> MdePkg/Include/Protocol/Eap.h | 3 ++-
>>>> MdePkg/Include/Protocol/HiiFont.h | 3 +--
>>>> MdePkg/Include/Protocol/MmMp.h | 3 ++-
>>>> MdePkg/Include/Protocol/S3SaveState.h | 2 +-
>>>> MdePkg/Include/Protocol/Shell.h | 3 ++-
>>>> MdePkg/Include/Protocol/UserManager.h | 9 ++++++---
>>>> MdePkg/Include/Uefi/UefiBaseType.h | 6 ++++--
>>>> MdePkg/Include/Uefi/UefiInternalFormRepresentation.h | 3 ++-
>>>> MdeModulePkg/Core/Dxe/Event/Event.h | 2 +-
>>>> MdeModulePkg/Core/Dxe/Hand/Handle.h | 2 +-
>>>> MdeModulePkg/Core/PiSmmCore/PiSmmCore.h | 2 +-
>>>> MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h | 2 +-
>>>> MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabase.h | 2 +-
>>>> StandaloneMmPkg/Core/StandaloneMmCore.h | 2 +-
>>>> 17 files changed, 34 insertions(+), 22 deletions(-)
>>>>
>>>> diff --git a/MdePkg/Include/Pi/PiPeiCis.h b/MdePkg/Include/Pi/PiPeiCis.h
>>>> index d9d4ed7d413a..3e9e82b62ae9 100644
>>>> --- a/MdePkg/Include/Pi/PiPeiCis.h
>>>> +++ b/MdePkg/Include/Pi/PiPeiCis.h
>>>> @@ -18,12 +18,14 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>>>> ///
>>>> /// The handles of EFI FV.
>>>> ///
>>>> -typedef VOID *EFI_PEI_FV_HANDLE;
>>>> +struct EFI_PEI_FV_OBJECT;
>>>> +typedef struct EFI_PEI_FV_OBJECT *EFI_PEI_FV_HANDLE;
>>>>
>>>> ///
>>>> /// The handles of EFI FFS.
>>>> ///
>>>> -typedef VOID *EFI_PEI_FILE_HANDLE;
>>>> +struct EFI_PEI_FILE_OBJECT;
>>>> +typedef struct EFI_PEI_FILE_OBJECT *EFI_PEI_FILE_HANDLE;
>>>>
>>>> ///
>>>> /// Declare the forward reference data structure for EFI_PEI_SERVICE.
>>>> diff --git a/MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h
>>>> b/MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h
>>>> index a8e0b24c6c8d..8a1863f3e03d 100644
>>>> --- a/MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h
>>>> +++ b/MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h
>>>> @@ -16,7 +16,8 @@
>>>> { 0xeb97088e, 0xcfdf, 0x49c6, { 0xbe, 0x4b, 0xd9, 0x6, 0xa5, 0xb2, 0xe, 0x86 }}
>>>>
>>>> typedef UINT32 EFI_ACPI_TABLE_VERSION;
>>>> -typedef VOID *EFI_ACPI_HANDLE;
>>>> +struct EFI_ACPI_OBJECT;
>>>> +typedef struct EFI_ACPI_OBJECT *EFI_ACPI_HANDLE;
>>>>
>>>> #define EFI_ACPI_TABLE_VERSION_NONE (1 << 0)
>>>> #define EFI_ACPI_TABLE_VERSION_1_0B (1 << 1)
>>>> diff --git a/MdePkg/Include/Protocol/Bis.h b/MdePkg/Include/Protocol/Bis.h
>>>> index 2be6718f4bc2..8eca94512d03 100644
>>>> --- a/MdePkg/Include/Protocol/Bis.h
>>>> +++ b/MdePkg/Include/Protocol/Bis.h
>>>> @@ -37,7 +37,8 @@ typedef struct _EFI_BIS_PROTOCOL EFI_BIS_PROTOCOL;
>>>> //
>>>> // Basic types
>>>> //
>>>> -typedef VOID *BIS_APPLICATION_HANDLE;
>>>> +struct BIS_APPLICATION_OBJECT;
>>>> +typedef struct BIS_APPLICATION_OBJECT *BIS_APPLICATION_HANDLE;
>>>> typedef UINT16 BIS_ALG_ID;
>>>> typedef UINT32 BIS_CERT_ID;
>>>>
>>>> diff --git a/MdePkg/Include/Protocol/Eap.h b/MdePkg/Include/Protocol/Eap.h
>>>> index 203d0f40b0dd..06584ef409d0 100644
>>>> --- a/MdePkg/Include/Protocol/Eap.h
>>>> +++ b/MdePkg/Include/Protocol/Eap.h
>>>> @@ -28,7 +28,8 @@ typedef struct _EFI_EAP_PROTOCOL EFI_EAP_PROTOCOL;
>>>> /// Type for the identification number assigned to the Port by the
>>>> /// System in which the Port resides.
>>>> ///
>>>> -typedef VOID * EFI_PORT_HANDLE;
>>>> +struct EFI_PORT_OBJECT;
>>>> +typedef struct EFI_PORT_OBJECT *EFI_PORT_HANDLE;
>>>>
>>>> ///
>>>> /// EAP Authentication Method Type (RFC 3748)
>>>> diff --git a/MdePkg/Include/Protocol/HiiFont.h b/MdePkg/Include/Protocol/HiiFont.h
>>>> index 1f2e321ea4e2..450cad9ada70 100644
>>>> --- a/MdePkg/Include/Protocol/HiiFont.h
>>>> +++ b/MdePkg/Include/Protocol/HiiFont.h
>>>> @@ -19,8 +19,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>>>> { 0xe9ca4775, 0x8657, 0x47fc, { 0x97, 0xe7, 0x7e, 0xd6, 0x5a, 0x8, 0x43, 0x24 } }
>>>>
>>>> typedef struct _EFI_HII_FONT_PROTOCOL EFI_HII_FONT_PROTOCOL;
>>>> -
>>>> -typedef VOID *EFI_FONT_HANDLE;
>>>> +typedef LIST_ENTRY *EFI_FONT_HANDLE;
>>>>
>>>> ///
>>>> /// EFI_HII_OUT_FLAGS.
>>>> diff --git a/MdePkg/Include/Protocol/MmMp.h b/MdePkg/Include/Protocol/MmMp.h
>>>> index beace1386cbe..cd4e0db47e08 100644
>>>> --- a/MdePkg/Include/Protocol/MmMp.h
>>>> +++ b/MdePkg/Include/Protocol/MmMp.h
>>>> @@ -36,7 +36,8 @@
>>>> //
>>>> // Completion token
>>>> //
>>>> -typedef VOID* MM_COMPLETION;
>>>> +struct MM_COMPLETION_OBJECT;
>>>> +typedef struct MM_COMPLETION_OBJECT* MM_COMPLETION;
>>>>
>>>> typedef struct {
>>>> MM_COMPLETION Completion;
>>>> diff --git a/MdePkg/Include/Protocol/S3SaveState.h b/MdePkg/Include/Protocol/S3SaveState.h
>>>> index c1b8f8b9e08d..235c36be6737 100644
>>>> --- a/MdePkg/Include/Protocol/S3SaveState.h
>>>> +++ b/MdePkg/Include/Protocol/S3SaveState.h
>>>> @@ -21,7 +21,7 @@
>>>> { 0xe857caf6, 0xc046, 0x45dc, { 0xbe, 0x3f, 0xee, 0x7, 0x65, 0xfb, 0xa8, 0x87 }}
>>>>
>>>>
>>>> -typedef VOID *EFI_S3_BOOT_SCRIPT_POSITION;
>>>> +typedef UINT8 *EFI_S3_BOOT_SCRIPT_POSITION;
>>>>
>>>> typedef struct _EFI_S3_SAVE_STATE_PROTOCOL EFI_S3_SAVE_STATE_PROTOCOL;
>>>>
>>>> diff --git a/MdePkg/Include/Protocol/Shell.h b/MdePkg/Include/Protocol/Shell.h
>>>> index cfb7878228c5..bf791792b4f2 100644
>>>> --- a/MdePkg/Include/Protocol/Shell.h
>>>> +++ b/MdePkg/Include/Protocol/Shell.h
>>>> @@ -11,12 +11,13 @@
>>>> #define __EFI_SHELL_PROTOCOL_H__
>>>>
>>>> #include <Guid/FileInfo.h>
>>>> +#include <Protocol/SimpleFileSystem.h>
>>>>
>>>> #define EFI_SHELL_PROTOCOL_GUID \
>>>> { \
>>>> 0x6302d008, 0x7f9b, 0x4f30, { 0x87, 0xac, 0x60, 0xc9, 0xfe, 0xf5, 0xda, 0x4e } \
>>>> }
>>>> -typedef VOID *SHELL_FILE_HANDLE;
>>>> +typedef EFI_FILE_PROTOCOL *SHELL_FILE_HANDLE;
>>>>
>>>> typedef enum {
>>>> ///
>>>> diff --git a/MdePkg/Include/Protocol/UserManager.h b/MdePkg/Include/Protocol/UserManager.h
>>>> index 26ac4955f1ec..9abfcffbeebf 100644
>>>> --- a/MdePkg/Include/Protocol/UserManager.h
>>>> +++ b/MdePkg/Include/Protocol/UserManager.h
>>>> @@ -24,8 +24,10 @@
>>>> 0xbaf1e6de, 0x209e, 0x4adb, { 0x8d, 0x96, 0xfd, 0x8b, 0x71, 0xf3, 0xf6, 0x83 } \
>>>> }
>>>>
>>>> -typedef VOID *EFI_USER_PROFILE_HANDLE;
>>>> -typedef VOID *EFI_USER_INFO_HANDLE;
>>>> +struct EFI_USER_PROFILE_OBJECT;
>>>> +typedef struct EFI_USER_PROFILE_OBJECT *EFI_USER_PROFILE_HANDLE;
>>>> +struct EFI_USER_INFO_OBJECT;
>>>> +typedef struct EFI_USER_INFO_OBJECT *EFI_USER_INFO_HANDLE;
>>>>
>>>> ///
>>>> /// The attributes of the user profile information.
>>>> @@ -157,7 +159,8 @@ typedef CHAR16 *EFI_USER_INFO_CREDENTIAL_PROVIDER_NAME;
>>>> /// Biometric Exchange Formats Framework) specification.
>>>> ///
>>>> #define EFI_USER_INFO_CBEFF_RECORD 0x0B
>>>> -typedef VOID *EFI_USER_INFO_CBEFF;
>>>> +struct EFI_USER_INFO_CBEFF_OBJECT;
>>>> +typedef struct EFI_USER_INFO_CBEFF_OBJECT *EFI_USER_INFO_CBEFF;
>>>> ///
>>>> /// Indicates how close of a match the fingerprint must be in order to be considered a match.
>>>> ///
>>>> diff --git a/MdePkg/Include/Uefi/UefiBaseType.h b/MdePkg/Include/Uefi/UefiBaseType.h
>>>> index a62f13dd064f..be5831991b52 100644
>>>> --- a/MdePkg/Include/Uefi/UefiBaseType.h
>>>> +++ b/MdePkg/Include/Uefi/UefiBaseType.h
>>>> @@ -28,11 +28,13 @@ typedef RETURN_STATUS EFI_STATUS;
>>>> ///
>>>> /// A collection of related interfaces.
>>>> ///
>>>> -typedef VOID *EFI_HANDLE;
>>>> +struct EFI_OBJECT;
>>>> +typedef struct EFI_OBJECT *EFI_HANDLE;
>>>> ///
>>>> /// Handle to an event structure.
>>>> ///
>>>> -typedef VOID *EFI_EVENT;
>>>> +struct EFI_EVENT_OBJECT;
>>>> +typedef struct EFI_EVENT_OBJECT *EFI_EVENT;
>>>> ///
>>>> /// Task priority level.
>>>> ///
>>>> diff --git a/MdePkg/Include/Uefi/UefiInternalFormRepresentation.h
>>>> b/MdePkg/Include/Uefi/UefiInternalFormRepresentation.h
>>>> index 4a1346a599d0..93bf9e9e0f13 100644
>>>> --- a/MdePkg/Include/Uefi/UefiInternalFormRepresentation.h
>>>> +++ b/MdePkg/Include/Uefi/UefiInternalFormRepresentation.h
>>>> @@ -20,7 +20,8 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>>>> ///
>>>> /// The following types are currently defined:
>>>> ///
>>>> -typedef VOID* EFI_HII_HANDLE;
>>>> +struct EFI_HII_OBJECT;
>>>> +typedef struct EFI_HII_OBJECT* EFI_HII_HANDLE;
>>>> typedef CHAR16* EFI_STRING;
>>>> typedef UINT16 EFI_IMAGE_ID;
>>>> typedef UINT16 EFI_QUESTION_ID;
>>>> diff --git a/MdeModulePkg/Core/Dxe/Event/Event.h b/MdeModulePkg/Core/Dxe/Event/Event.h
>>>> index 8141c5003eec..42590cb1dd09 100644
>>>> --- a/MdeModulePkg/Core/Dxe/Event/Event.h
>>>> +++ b/MdeModulePkg/Core/Dxe/Event/Event.h
>>>> @@ -37,7 +37,7 @@ typedef struct {
>>>> } TIMER_EVENT_INFO;
>>>>
>>>> #define EVENT_SIGNATURE SIGNATURE_32('e','v','n','t')
>>>> -typedef struct {
>>>> +typedef struct EFI_EVENT_OBJECT {
>>>> UINTN Signature;
>>>> UINT32 Type;
>>>> UINT32 SignalCount;
>>>> diff --git a/MdeModulePkg/Core/Dxe/Hand/Handle.h b/MdeModulePkg/Core/Dxe/Hand/Handle.h
>>>> index 83eb2b9f3afe..1f1ab3274e8a 100644
>>>> --- a/MdeModulePkg/Core/Dxe/Hand/Handle.h
>>>> +++ b/MdeModulePkg/Core/Dxe/Hand/Handle.h
>>>> @@ -15,7 +15,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>>>> ///
>>>> /// IHANDLE - contains a list of protocol handles
>>>> ///
>>>> -typedef struct {
>>>> +typedef struct EFI_OBJECT {
>>>> UINTN Signature;
>>>> /// All handles list of IHANDLE
>>>> LIST_ENTRY AllHandles;
>>>> diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
>>>> index 0908e7f4e9e7..c55da58d465e 100644
>>>> --- a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
>>>> +++ b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
>>>> @@ -145,7 +145,7 @@ typedef struct {
>>>> ///
>>>> /// IHANDLE - contains a list of protocol handles
>>>> ///
>>>> -typedef struct {
>>>> +typedef struct EFI_OBJECT {
>>>> UINTN Signature;
>>>> /// All handles list of IHANDLE
>>>> LIST_ENTRY AllHandles;
>>>> diff --git a/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h
>>>> b/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h
>>>> index 50d4c96edb63..bfebbb1f8182 100644
>>>> --- a/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h
>>>> +++ b/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h
>>>> @@ -88,7 +88,7 @@ struct _EFI_AML_NODE_LIST {
>>>> // This buffer should not be freed.
>>>> // Size is the total size of this ACPI node buffer.
>>>> //
>>>> -typedef struct {
>>>> +typedef struct EFI_ACPI_OBJECT {
>>>> UINT32 Signature;
>>>> UINT8 *Buffer;
>>>> UINTN Size;
>>>> diff --git a/MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabase.h
>>>> b/MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabase.h
>>>> index 4a3feab94df5..48972d0fcad6 100644
>>>> --- a/MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabase.h
>>>> +++ b/MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabase.h
>>>> @@ -274,7 +274,7 @@ typedef struct _HII_DATABASE_PACKAGE_LIST_INSTANCE {
>>>>
>>>> #define HII_HANDLE_SIGNATURE SIGNATURE_32 ('h','i','h','l')
>>>>
>>>> -typedef struct {
>>>> +typedef struct EFI_HII_OBJECT {
>>>> UINTN Signature;
>>>> LIST_ENTRY Handle;
>>>> UINTN Key;
>>>> diff --git a/StandaloneMmPkg/Core/StandaloneMmCore.h b/StandaloneMmPkg/Core/StandaloneMmCore.h
>>>> index 4d0eed273f50..dcf91bc5e916 100644
>>>> --- a/StandaloneMmPkg/Core/StandaloneMmCore.h
>>>> +++ b/StandaloneMmPkg/Core/StandaloneMmCore.h
>>>> @@ -105,7 +105,7 @@ typedef struct {
>>>> ///
>>>> /// IHANDLE - contains a list of protocol handles
>>>> ///
>>>> -typedef struct {
>>>> +typedef struct EFI_OBJECT {
>>>> UINTN Signature;
>>>> /// All handles list of IHANDLE
>>>> LIST_ENTRY AllHandles;
>>>> --
>>>> 2.19.1.3.g30247aa5d201
>>>>
>>>>
>>>>
>>>> -=-=-=-=-=-=
>>>> Groups.io Links: You receive all messages sent to this group.
>>>>
>>>> View/Reply Online (#47388): https://edk2.groups.io/g/devel/message/47388
>>>> Mute This Topic: https://groups.io/mt/34180199/1712937
>>>> Group Owner: devel+owner@edk2.groups.io
>>>> Unsubscribe: https://edk2.groups.io/g/devel/unsub [ray.ni@intel.com]
>>>> -=-=-=-=-=-=
>>>
>>
>>
>>
>
>
>
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 01/35] DO NOT APPLY: edk2: turn standard handle types into pointers to non-VOID
2019-09-17 21:07 ` Andrew Fish
@ 2019-09-17 21:11 ` Michael D Kinney
0 siblings, 0 replies; 155+ messages in thread
From: Michael D Kinney @ 2019-09-17 21:11 UTC (permalink / raw)
To: devel@edk2.groups.io, afish@apple.com, Ni, Ray, Kinney, Michael D
Cc: lersek@redhat.com, Achin Gupta, Anthony Perard, Ard Biesheuvel,
You, Benjamin, Zhang, Chao B, Bi, Dandan, David Woodhouse,
Dong, Eric, Dong, Guo, Wu, Hao A, Carsey, Jaben, Wang, Jian J,
Wu, Jiaxin, Yao, Jiewen, Justen, Jordan L, Julien Grall,
Leif Lindholm, Gao, Liming, Ma, Maurice, Fu, Siyuan,
Supreeth Venkatesh, Gao, Zhichao
Andrew,
Perhaps we want strict type checking as default, and platforms
Or packages that can not build with strict type checking set
the define for the relaxed type checking in their DSC files.
Mike
> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On
> Behalf Of Andrew Fish via Groups.Io
> Sent: Tuesday, September 17, 2019 2:07 PM
> To: devel@edk2.groups.io; Ni, Ray <ray.ni@intel.com>
> Cc: lersek@redhat.com; Achin Gupta
> <achin.gupta@arm.com>; Anthony Perard
> <anthony.perard@citrix.com>; Ard Biesheuvel
> <ard.biesheuvel@linaro.org>; You, Benjamin
> <benjamin.you@intel.com>; Zhang, Chao B
> <chao.b.zhang@intel.com>; Bi, Dandan
> <dandan.bi@intel.com>; David Woodhouse
> <dwmw2@infradead.org>; Dong, Eric
> <eric.dong@intel.com>; Dong, Guo <guo.dong@intel.com>;
> Wu, Hao A <hao.a.wu@intel.com>; Carsey, Jaben
> <jaben.carsey@intel.com>; Wang, Jian J
> <jian.j.wang@intel.com>; Wu, Jiaxin
> <jiaxin.wu@intel.com>; Yao, Jiewen
> <jiewen.yao@intel.com>; Justen, Jordan L
> <jordan.l.justen@intel.com>; Julien Grall
> <julien.grall@arm.com>; Leif Lindholm
> <leif.lindholm@linaro.org>; Gao, Liming
> <liming.gao@intel.com>; Ma, Maurice
> <maurice.ma@intel.com>; Kinney, Michael D
> <michael.d.kinney@intel.com>; Fu, Siyuan
> <siyuan.fu@intel.com>; Supreeth Venkatesh
> <supreeth.venkatesh@arm.com>; Gao, Zhichao
> <zhichao.gao@intel.com>
> Subject: Re: [edk2-devel] [PATCH 01/35] DO NOT APPLY:
> edk2: turn standard handle types into pointers to non-
> VOID
>
>
>
> > On Sep 17, 2019, at 1:28 PM, Ni, Ray
> <ray.ni@intel.com> wrote:
> >
> > Andrew,
> > I agree. Your solution is like "use strict;" in Perl
> language.
> > (https://perldoc.perl.org/strict.html)
> > Maybe "STRICT_UEFI_TYPES" without "ER". I don't see
> any strict in
> > today's code. 😊
> >
>
> Ray,
>
> I'm flexible on the name, I was just trying to give a
> good example of what I was suggesting.
>
> Thanks,
>
> Andrew Fish
>
> > Thanks,
> > Ray
> >
> >> -----Original Message-----
> >> From: devel@edk2.groups.io <devel@edk2.groups.io> On
> Behalf Of Andrew
> >> Fish via Groups.Io
> >> Sent: Tuesday, September 17, 2019 1:22 PM
> >> To: Ni, Ray <ray.ni@intel.com>
> >> Cc: devel@edk2.groups.io; lersek@redhat.com; Achin
> Gupta
> >> <achin.gupta@arm.com>; Anthony Perard
> <anthony.perard@citrix.com>;
> >> Ard Biesheuvel <ard.biesheuvel@linaro.org>; You,
> Benjamin
> >> <benjamin.you@intel.com>; Zhang, Chao B
> <chao.b.zhang@intel.com>; Bi,
> >> Dandan <dandan.bi@intel.com>; David Woodhouse
> <dwmw2@infradead.org>;
> >> Dong, Eric <eric.dong@intel.com>; Dong, Guo
> <guo.dong@intel.com>; Wu,
> >> Hao A <hao.a.wu@intel.com>; Carsey, Jaben
> <jaben.carsey@intel.com>;
> >> Wang, Jian J <jian.j.wang@intel.com>; Wu, Jiaxin
> >> <jiaxin.wu@intel.com>; Yao, Jiewen
> <jiewen.yao@intel.com>; Justen,
> >> Jordan L <jordan.l.justen@intel.com>; Julien Grall
> >> <julien.grall@arm.com>; Leif Lindholm
> <leif.lindholm@linaro.org>;
> >> Gao, Liming <liming.gao@intel.com>; Ma, Maurice
> >> <maurice.ma@intel.com>; Kinney, Michael D
> >> <michael.d.kinney@intel.com>; Fu, Siyuan
> <siyuan.fu@intel.com>;
> >> Supreeth Venkatesh <supreeth.venkatesh@arm.com>;
> Gao, Zhichao
> >> <zhichao.gao@intel.com>
> >> Subject: Re: [edk2-devel] [PATCH 01/35] DO NOT
> APPLY: edk2: turn
> >> standard handle types into pointers to non-VOID
> >>
> >>
> >>
> >>> On Sep 17, 2019, at 1:06 PM, Ni, Ray
> <ray.ni@intel.com> wrote:
> >>>
> >>> Laszlo,
> >>> Thank you very much for this work.
> >>> They are quite helpful to detect potential issues.
> >>>
> >>> But without this specific patch being checked in,
> future break will still happen.
> >>> I don't want it to be checked in ASAP because I
> know that there are
> >>> quite a lot of close source code that may get build
> >> break due to this change.
> >>> Besides that, what prevent you make the decision to
> check in the changes?
> >>>
> >>
> >> Ray,
> >>
> >> I was thinking the same thing. Could we make this an
> optional feature
> >> via a #define? We could always default to the Spec
> Behavior, and new projects could opt into the stricter
> version.
> >>
> >> #ifndef STRICTER_UEFI_TYPES
> >> typedef VOID *EFI_PEI_FV_HANDLE;
> >> #else
> >> struct EFI_PEI_FV_OBJECT;
> >> typedef struct EFI_PEI_FV_OBJECT *EFI_PEI_FV_HANDLE;
> #endif
> >>
> >> Thanks,
> >>
> >> Andrew Fish
> >>
> >>> Thanks,
> >>> Ray
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: devel@edk2.groups.io <devel@edk2.groups.io>
> On Behalf Of
> >>>> Laszlo Ersek
> >>>> Sent: Tuesday, September 17, 2019 12:49 PM
> >>>> To: edk2-devel-groups-io <devel@edk2.groups.io>
> >>>> Cc: Achin Gupta <achin.gupta@arm.com>; Andrew Fish
> >>>> <afish@apple.com>; Anthony Perard
> >> <anthony.perard@citrix.com>;
> >>>> Ard Biesheuvel <ard.biesheuvel@linaro.org>; You,
> Benjamin
> >>>> <benjamin.you@intel.com>; Zhang, Chao B
> <chao.b.zhang@intel.com>;
> >>>> Bi, Dandan <dandan.bi@intel.com>; David Woodhouse
> >>>> <dwmw2@infradead.org>; Dong,
> >> Eric
> >>>> <eric.dong@intel.com>; Dong, Guo
> <guo.dong@intel.com>; Wu, Hao A
> >>>> <hao.a.wu@intel.com>; Carsey, Jaben
> <jaben.carsey@intel.com>; Wang,
> >>>> Jian J <jian.j.wang@intel.com>; Wu, Jiaxin
> <jiaxin.wu@intel.com>;
> >>>> Yao, Jiewen <jiewen.yao@intel.com>; Justen, Jordan
> L
> >>>> <jordan.l.justen@intel.com>; Julien Grall
> <julien.grall@arm.com>;
> >>>> Leif
> >> Lindholm
> >>>> <leif.lindholm@linaro.org>; Gao, Liming
> <liming.gao@intel.com>; Ma,
> >>>> Maurice <maurice.ma@intel.com>; Kinney,
> >> Michael
> >>>> D <michael.d.kinney@intel.com>; Ni, Ray
> <ray.ni@intel.com>; Fu,
> >>>> Siyuan <siyuan.fu@intel.com>; Supreeth Venkatesh
> >>>> <supreeth.venkatesh@arm.com>; Gao, Zhichao
> <zhichao.gao@intel.com>
> >>>> Subject: [edk2-devel] [PATCH 01/35] DO NOT APPLY:
> edk2: turn
> >>>> standard handle types into pointers to non-VOID
> >>>>
> >>>> Unfortunately, the UEFI / PI / Shell specs define
> a number of
> >>>> handle types as pointers to VOID. This is a design
> mistake; those
> >>>> types should have been pointers to incomplete
> union or structure
> >>>> types. Any pointer-to-object type converts
> implicitly to, and from,
> >>>> pointer-to-void, which prevents compilers from
> catching at least
> >>>> the following two types of
> >>>> mistakes:
> >>>>
> >>>> - mixing up one handle type with another (for
> example, EFI_HANDLE
> >>>> with EFI_EVENT),
> >>>>
> >>>> - getting the depth of indirection wrong (for
> example, mixing up
> >>>> (EFI_HANDLE*) with EFI_HANDLE).
> >>>>
> >>>> In order to root out such mistakes in the edk2
> codebase, introduce
> >>>> incomplete structure types with unique tags, such
> as:
> >>>>
> >>>> struct EFI_FOOBAR_OBJECT;
> >>>> typedef struct EFI_FOOBAR_OBJECT
> *EFI_FOOBAR_HANDLE;
> >>>>
> >>>> replacing the spec mandated
> >>>>
> >>>> typedef VOID *EFI_FOOBAR_HANDLE;
> >>>>
> >>>> (For some types, such as:
> >>>>
> >>>> - EFI_ACPI_HANDLE,
> >>>> - EFI_EVENT,
> >>>> - EFI_FONT_HANDLE,
> >>>> - EFI_HANDLE,
> >>>> - EFI_HII_HANDLE,
> >>>> - EFI_S3_BOOT_SCRIPT_POSITION,
> >>>> - SHELL_FILE_HANDLE,
> >>>>
> >>>> we connect the actual complete type (the internal,
> >>>> implementation-specific
> >>>> type) to the typedef. Some of these also
> demonstrate how the code
> >>>> could have looked in practice if the specs had
> used proper opaque
> >>>> (=incomplete)
> >>>> types.)
> >>>>
> >>>> Then, unleash "build" on the package DSC files.
> This causes the
> >>>> compiler to warn about incompatible pointer
> assignments, and to stop the build.
> >>>>
> >>>> The rest of the series addresses the resultant
> warnings. Each patch
> >>>> belongs in one of two categories:
> >>>>
> >>>> - semantic cleanups (no functional / behavioral
> changes),
> >>>> - actual bugfixes.
> >>>>
> >>>> As the subject line of this patch states, this
> specific patch is
> >>>> *not* meant to be applied. It is just a "what if"
> patch that
> >>>> temporarily isolates the standard types from each
> other, the way
> >>>> the specs should have, so that the compiler have
> more information to work with.
> >>>>
> >>>> Cc: Achin Gupta <achin.gupta@arm.com>
> >>>> Cc: Andrew Fish <afish@apple.com>
> >>>> Cc: Anthony Perard <anthony.perard@citrix.com>
> >>>> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> >>>> Cc: Benjamin You <benjamin.you@intel.com>
> >>>> Cc: Chao Zhang <chao.b.zhang@intel.com>
> >>>> Cc: Dandan Bi <dandan.bi@intel.com>
> >>>> Cc: David Woodhouse <dwmw2@infradead.org>
> >>>> Cc: Eric Dong <eric.dong@intel.com>
> >>>> Cc: Guo Dong <guo.dong@intel.com>
> >>>> Cc: Hao A Wu <hao.a.wu@intel.com>
> >>>> Cc: Jaben Carsey <jaben.carsey@intel.com>
> >>>> Cc: Jian J Wang <jian.j.wang@intel.com>
> >>>> Cc: Jian Wang <jian.j.wang@intel.com>
> >>>> Cc: Jiaxin Wu <jiaxin.wu@intel.com>
> >>>> Cc: Jiewen Yao <jiewen.yao@intel.com>
> >>>> Cc: Jordan Justen <jordan.l.justen@intel.com>
> >>>> Cc: Julien Grall <julien.grall@arm.com>
> >>>> Cc: Leif Lindholm <leif.lindholm@linaro.org>
> >>>> Cc: Liming Gao <liming.gao@intel.com>
> >>>> Cc: Maurice Ma <maurice.ma@intel.com>
> >>>> Cc: Michael D Kinney <michael.d.kinney@intel.com>
> >>>> Cc: Ray Ni <ray.ni@intel.com>
> >>>> Cc: Siyuan Fu <siyuan.fu@intel.com>
> >>>> Cc: Supreeth Venkatesh
> <supreeth.venkatesh@arm.com>
> >>>> Cc: Zhichao Gao <zhichao.gao@intel.com>
> >>>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> >>>> ---
> >>>> MdePkg/Include/Pi/PiPeiCis.h
> | 6 ++++--
> >>>>
> MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h |
> 3 ++-
> >>>> MdePkg/Include/Protocol/Bis.h
> | 3 ++-
> >>>> MdePkg/Include/Protocol/Eap.h
> | 3 ++-
> >>>> MdePkg/Include/Protocol/HiiFont.h
> | 3 +--
> >>>> MdePkg/Include/Protocol/MmMp.h
> | 3 ++-
> >>>> MdePkg/Include/Protocol/S3SaveState.h
> | 2 +-
> >>>> MdePkg/Include/Protocol/Shell.h
> | 3 ++-
> >>>> MdePkg/Include/Protocol/UserManager.h
> | 9 ++++++---
> >>>> MdePkg/Include/Uefi/UefiBaseType.h
> | 6 ++++--
> >>>>
> MdePkg/Include/Uefi/UefiInternalFormRepresentation.h |
> 3 ++-
> >>>> MdeModulePkg/Core/Dxe/Event/Event.h
> | 2 +-
> >>>> MdeModulePkg/Core/Dxe/Hand/Handle.h
> | 2 +-
> >>>> MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
> | 2 +-
> >>>> MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h
> | 2 +-
> >>>>
> MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabase.h |
> 2 +-
> >>>> StandaloneMmPkg/Core/StandaloneMmCore.h
> | 2 +-
> >>>> 17 files changed, 34 insertions(+), 22 deletions(-
> )
> >>>>
> >>>> diff --git a/MdePkg/Include/Pi/PiPeiCis.h
> >>>> b/MdePkg/Include/Pi/PiPeiCis.h index
> d9d4ed7d413a..3e9e82b62ae9
> >>>> 100644
> >>>> --- a/MdePkg/Include/Pi/PiPeiCis.h
> >>>> +++ b/MdePkg/Include/Pi/PiPeiCis.h
> >>>> @@ -18,12 +18,14 @@ SPDX-License-Identifier: BSD-
> 2-Clause-Patent
> >>>> /// /// The handles of EFI FV.
> >>>> ///
> >>>> -typedef VOID *EFI_PEI_FV_HANDLE;
> >>>> +struct EFI_PEI_FV_OBJECT;
> >>>> +typedef struct EFI_PEI_FV_OBJECT
> *EFI_PEI_FV_HANDLE;
> >>>>
> >>>> ///
> >>>> /// The handles of EFI FFS.
> >>>> ///
> >>>> -typedef VOID *EFI_PEI_FILE_HANDLE;
> >>>> +struct EFI_PEI_FILE_OBJECT;
> >>>> +typedef struct EFI_PEI_FILE_OBJECT
> *EFI_PEI_FILE_HANDLE;
> >>>>
> >>>> ///
> >>>> /// Declare the forward reference data structure
> for EFI_PEI_SERVICE.
> >>>> diff --git
> a/MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h
> >>>>
> b/MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h
> >>>> index a8e0b24c6c8d..8a1863f3e03d 100644
> >>>> ---
> a/MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h
> >>>> +++
> b/MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h
> >>>> @@ -16,7 +16,8 @@
> >>>> { 0xeb97088e, 0xcfdf, 0x49c6, { 0xbe, 0x4b, 0xd9,
> 0x6, 0xa5, 0xb2,
> >>>> 0xe, 0x86 }}
> >>>>
> >>>> typedef UINT32 EFI_ACPI_TABLE_VERSION;
> >>>> -typedef VOID *EFI_ACPI_HANDLE;
> >>>> +struct EFI_ACPI_OBJECT;
> >>>> +typedef struct EFI_ACPI_OBJECT *EFI_ACPI_HANDLE;
> >>>>
> >>>> #define EFI_ACPI_TABLE_VERSION_NONE (1 << 0)
> #define
> >>>> EFI_ACPI_TABLE_VERSION_1_0B (1 << 1) diff --git
> >>>> a/MdePkg/Include/Protocol/Bis.h
> b/MdePkg/Include/Protocol/Bis.h
> >>>> index 2be6718f4bc2..8eca94512d03 100644
> >>>> --- a/MdePkg/Include/Protocol/Bis.h
> >>>> +++ b/MdePkg/Include/Protocol/Bis.h
> >>>> @@ -37,7 +37,8 @@ typedef struct _EFI_BIS_PROTOCOL
> >>>> EFI_BIS_PROTOCOL; // // Basic types //
> >>>> -typedef VOID *BIS_APPLICATION_HANDLE;
> >>>> +struct BIS_APPLICATION_OBJECT;
> >>>> +typedef struct BIS_APPLICATION_OBJECT
> *BIS_APPLICATION_HANDLE;
> >>>> typedef UINT16 BIS_ALG_ID;
> >>>> typedef UINT32 BIS_CERT_ID;
> >>>>
> >>>> diff --git a/MdePkg/Include/Protocol/Eap.h
> >>>> b/MdePkg/Include/Protocol/Eap.h index
> 203d0f40b0dd..06584ef409d0
> >>>> 100644
> >>>> --- a/MdePkg/Include/Protocol/Eap.h
> >>>> +++ b/MdePkg/Include/Protocol/Eap.h
> >>>> @@ -28,7 +28,8 @@ typedef struct _EFI_EAP_PROTOCOL
> >>>> EFI_EAP_PROTOCOL; /// Type for the identification
> number assigned
> >>>> to the Port by the /// System in which the Port
> resides.
> >>>> ///
> >>>> -typedef VOID * EFI_PORT_HANDLE;
> >>>> +struct EFI_PORT_OBJECT;
> >>>> +typedef struct EFI_PORT_OBJECT *EFI_PORT_HANDLE;
> >>>>
> >>>> ///
> >>>> /// EAP Authentication Method Type (RFC 3748) diff
> --git
> >>>> a/MdePkg/Include/Protocol/HiiFont.h
> >>>> b/MdePkg/Include/Protocol/HiiFont.h
> >>>> index 1f2e321ea4e2..450cad9ada70 100644
> >>>> --- a/MdePkg/Include/Protocol/HiiFont.h
> >>>> +++ b/MdePkg/Include/Protocol/HiiFont.h
> >>>> @@ -19,8 +19,7 @@ SPDX-License-Identifier: BSD-2-
> Clause-Patent {
> >>>> 0xe9ca4775, 0x8657, 0x47fc, { 0x97, 0xe7, 0x7e,
> 0xd6, 0x5a, 0x8,
> >>>> 0x43, 0x24 } }
> >>>>
> >>>> typedef struct _EFI_HII_FONT_PROTOCOL
> EFI_HII_FONT_PROTOCOL;
> >>>> -
> >>>> -typedef VOID *EFI_FONT_HANDLE;
> >>>> +typedef LIST_ENTRY *EFI_FONT_HANDLE;
> >>>>
> >>>> ///
> >>>> /// EFI_HII_OUT_FLAGS.
> >>>> diff --git a/MdePkg/Include/Protocol/MmMp.h
> >>>> b/MdePkg/Include/Protocol/MmMp.h index
> beace1386cbe..cd4e0db47e08
> >>>> 100644
> >>>> --- a/MdePkg/Include/Protocol/MmMp.h
> >>>> +++ b/MdePkg/Include/Protocol/MmMp.h
> >>>> @@ -36,7 +36,8 @@
> >>>> //
> >>>> // Completion token
> >>>> //
> >>>> -typedef VOID* MM_COMPLETION;
> >>>> +struct MM_COMPLETION_OBJECT;
> >>>> +typedef struct MM_COMPLETION_OBJECT*
> MM_COMPLETION;
> >>>>
> >>>> typedef struct {
> >>>> MM_COMPLETION Completion;
> >>>> diff --git a/MdePkg/Include/Protocol/S3SaveState.h
> >>>> b/MdePkg/Include/Protocol/S3SaveState.h
> >>>> index c1b8f8b9e08d..235c36be6737 100644
> >>>> --- a/MdePkg/Include/Protocol/S3SaveState.h
> >>>> +++ b/MdePkg/Include/Protocol/S3SaveState.h
> >>>> @@ -21,7 +21,7 @@
> >>>> { 0xe857caf6, 0xc046, 0x45dc, { 0xbe, 0x3f,
> 0xee, 0x7, 0x65,
> >>>> 0xfb, 0xa8, 0x87 }}
> >>>>
> >>>>
> >>>> -typedef VOID *EFI_S3_BOOT_SCRIPT_POSITION;
> >>>> +typedef UINT8 *EFI_S3_BOOT_SCRIPT_POSITION;
> >>>>
> >>>> typedef struct _EFI_S3_SAVE_STATE_PROTOCOL
> >>>> EFI_S3_SAVE_STATE_PROTOCOL;
> >>>>
> >>>> diff --git a/MdePkg/Include/Protocol/Shell.h
> >>>> b/MdePkg/Include/Protocol/Shell.h index
> cfb7878228c5..bf791792b4f2
> >>>> 100644
> >>>> --- a/MdePkg/Include/Protocol/Shell.h
> >>>> +++ b/MdePkg/Include/Protocol/Shell.h
> >>>> @@ -11,12 +11,13 @@
> >>>> #define __EFI_SHELL_PROTOCOL_H__
> >>>>
> >>>> #include <Guid/FileInfo.h>
> >>>> +#include <Protocol/SimpleFileSystem.h>
> >>>>
> >>>> #define EFI_SHELL_PROTOCOL_GUID \
> >>>> { \
> >>>> 0x6302d008, 0x7f9b, 0x4f30, { 0x87, 0xac, 0x60,
> 0xc9, 0xfe, 0xf5,
> >>>> 0xda, 0x4e } \ } -typedef VOID
> *SHELL_FILE_HANDLE;
> >>>> +typedef EFI_FILE_PROTOCOL *SHELL_FILE_HANDLE;
> >>>>
> >>>> typedef enum {
> >>>> ///
> >>>> diff --git a/MdePkg/Include/Protocol/UserManager.h
> >>>> b/MdePkg/Include/Protocol/UserManager.h
> >>>> index 26ac4955f1ec..9abfcffbeebf 100644
> >>>> --- a/MdePkg/Include/Protocol/UserManager.h
> >>>> +++ b/MdePkg/Include/Protocol/UserManager.h
> >>>> @@ -24,8 +24,10 @@
> >>>> 0xbaf1e6de, 0x209e, 0x4adb, { 0x8d, 0x96, 0xfd,
> 0x8b, 0x71,
> >>>> 0xf3, 0xf6, 0x83 } \ }
> >>>>
> >>>> -typedef VOID *EFI_USER_PROFILE_HANDLE; -typedef
> VOID
> >>>> *EFI_USER_INFO_HANDLE;
> >>>> +struct EFI_USER_PROFILE_OBJECT;
> >>>> +typedef struct EFI_USER_PROFILE_OBJECT
> *EFI_USER_PROFILE_HANDLE;
> >>>> +struct EFI_USER_INFO_OBJECT; typedef struct
> EFI_USER_INFO_OBJECT
> >>>> +*EFI_USER_INFO_HANDLE;
> >>>>
> >>>> ///
> >>>> /// The attributes of the user profile
> information.
> >>>> @@ -157,7 +159,8 @@ typedef CHAR16
> >>>> *EFI_USER_INFO_CREDENTIAL_PROVIDER_NAME;
> >>>> /// Biometric Exchange Formats Framework)
> specification.
> >>>> ///
> >>>> #define EFI_USER_INFO_CBEFF_RECORD
> 0x0B
> >>>> -typedef VOID *EFI_USER_INFO_CBEFF;
> >>>> +struct EFI_USER_INFO_CBEFF_OBJECT; typedef struct
> >>>> +EFI_USER_INFO_CBEFF_OBJECT *EFI_USER_INFO_CBEFF;
> >>>> ///
> >>>> /// Indicates how close of a match the fingerprint
> must be in order to be considered a match.
> >>>> ///
> >>>> diff --git a/MdePkg/Include/Uefi/UefiBaseType.h
> >>>> b/MdePkg/Include/Uefi/UefiBaseType.h
> >>>> index a62f13dd064f..be5831991b52 100644
> >>>> --- a/MdePkg/Include/Uefi/UefiBaseType.h
> >>>> +++ b/MdePkg/Include/Uefi/UefiBaseType.h
> >>>> @@ -28,11 +28,13 @@ typedef RETURN_STATUS
> EFI_STATUS;
> >>>> ///
> >>>> /// A collection of related interfaces.
> >>>> ///
> >>>> -typedef VOID *EFI_HANDLE;
> >>>> +struct EFI_OBJECT;
> >>>> +typedef struct EFI_OBJECT *EFI_HANDLE;
> >>>> ///
> >>>> /// Handle to an event structure.
> >>>> ///
> >>>> -typedef VOID *EFI_EVENT;
> >>>> +struct EFI_EVENT_OBJECT;
> >>>> +typedef struct EFI_EVENT_OBJECT *EFI_EVENT;
> >>>> ///
> >>>> /// Task priority level.
> >>>> ///
> >>>> diff --git
> a/MdePkg/Include/Uefi/UefiInternalFormRepresentation.h
> >>>>
> b/MdePkg/Include/Uefi/UefiInternalFormRepresentation.h
> >>>> index 4a1346a599d0..93bf9e9e0f13 100644
> >>>> ---
> a/MdePkg/Include/Uefi/UefiInternalFormRepresentation.h
> >>>> +++
> b/MdePkg/Include/Uefi/UefiInternalFormRepresentation.h
> >>>> @@ -20,7 +20,8 @@ SPDX-License-Identifier: BSD-2-
> Clause-Patent ///
> >>>> /// The following types are currently defined:
> >>>> ///
> >>>> -typedef VOID* EFI_HII_HANDLE;
> >>>> +struct EFI_HII_OBJECT;
> >>>> +typedef struct EFI_HII_OBJECT* EFI_HII_HANDLE;
> >>>> typedef CHAR16* EFI_STRING;
> >>>> typedef UINT16 EFI_IMAGE_ID;
> >>>> typedef UINT16 EFI_QUESTION_ID;
> >>>> diff --git a/MdeModulePkg/Core/Dxe/Event/Event.h
> >>>> b/MdeModulePkg/Core/Dxe/Event/Event.h
> >>>> index 8141c5003eec..42590cb1dd09 100644
> >>>> --- a/MdeModulePkg/Core/Dxe/Event/Event.h
> >>>> +++ b/MdeModulePkg/Core/Dxe/Event/Event.h
> >>>> @@ -37,7 +37,7 @@ typedef struct {
> >>>> } TIMER_EVENT_INFO;
> >>>>
> >>>> #define EVENT_SIGNATURE
> SIGNATURE_32('e','v','n','t')
> >>>> -typedef struct {
> >>>> +typedef struct EFI_EVENT_OBJECT {
> >>>> UINTN Signature;
> >>>> UINT32 Type;
> >>>> UINT32 SignalCount;
> >>>> diff --git a/MdeModulePkg/Core/Dxe/Hand/Handle.h
> >>>> b/MdeModulePkg/Core/Dxe/Hand/Handle.h
> >>>> index 83eb2b9f3afe..1f1ab3274e8a 100644
> >>>> --- a/MdeModulePkg/Core/Dxe/Hand/Handle.h
> >>>> +++ b/MdeModulePkg/Core/Dxe/Hand/Handle.h
> >>>> @@ -15,7 +15,7 @@ SPDX-License-Identifier: BSD-2-
> Clause-Patent ///
> >>>> /// IHANDLE - contains a list of protocol handles
> /// -typedef
> >>>> struct {
> >>>> +typedef struct EFI_OBJECT {
> >>>> UINTN Signature;
> >>>> /// All handles list of IHANDLE
> >>>> LIST_ENTRY AllHandles;
> >>>> diff --git
> a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
> >>>> b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
> >>>> index 0908e7f4e9e7..c55da58d465e 100644
> >>>> --- a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
> >>>> +++ b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
> >>>> @@ -145,7 +145,7 @@ typedef struct { /// ///
> IHANDLE - contains a
> >>>> list of protocol handles /// -typedef struct {
> >>>> +typedef struct EFI_OBJECT {
> >>>> UINTN Signature;
> >>>> /// All handles list of IHANDLE
> >>>> LIST_ENTRY AllHandles;
> >>>> diff --git
> a/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h
> >>>>
> b/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h
> >>>> index 50d4c96edb63..bfebbb1f8182 100644
> >>>> ---
> a/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h
> >>>> +++
> b/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h
> >>>> @@ -88,7 +88,7 @@ struct _EFI_AML_NODE_LIST {
> >>>> // This buffer should not be freed.
> >>>> // Size is the total size of this ACPI node
> buffer.
> >>>> //
> >>>> -typedef struct {
> >>>> +typedef struct EFI_ACPI_OBJECT {
> >>>> UINT32 Signature;
> >>>> UINT8 *Buffer;
> >>>> UINTN Size;
> >>>> diff --git
> a/MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabase.h
> >>>>
> b/MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabase.h
> >>>> index 4a3feab94df5..48972d0fcad6 100644
> >>>> ---
> a/MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabase.h
> >>>> +++
> b/MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabase.h
> >>>> @@ -274,7 +274,7 @@ typedef struct
> >>>> _HII_DATABASE_PACKAGE_LIST_INSTANCE {
> >>>>
> >>>> #define HII_HANDLE_SIGNATURE
> SIGNATURE_32 ('h','i','h','l')
> >>>>
> >>>> -typedef struct {
> >>>> +typedef struct EFI_HII_OBJECT {
> >>>> UINTN Signature;
> >>>> LIST_ENTRY Handle;
> >>>> UINTN Key;
> >>>> diff --git
> a/StandaloneMmPkg/Core/StandaloneMmCore.h
> >>>> b/StandaloneMmPkg/Core/StandaloneMmCore.h
> >>>> index 4d0eed273f50..dcf91bc5e916 100644
> >>>> --- a/StandaloneMmPkg/Core/StandaloneMmCore.h
> >>>> +++ b/StandaloneMmPkg/Core/StandaloneMmCore.h
> >>>> @@ -105,7 +105,7 @@ typedef struct { /// ///
> IHANDLE - contains a
> >>>> list of protocol handles /// -typedef struct {
> >>>> +typedef struct EFI_OBJECT {
> >>>> UINTN Signature;
> >>>> /// All handles list of IHANDLE
> >>>> LIST_ENTRY AllHandles;
> >>>> --
> >>>> 2.19.1.3.g30247aa5d201
> >>>>
> >>>>
> >>>>
> >>>> -=-=-=-=-=-=
> >>>> Groups.io Links: You receive all messages sent to
> this group.
> >>>>
> >>>> View/Reply Online (#47388):
> >>>> https://edk2.groups.io/g/devel/message/47388
> >>>> Mute This Topic:
> https://groups.io/mt/34180199/1712937
> >>>> Group Owner: devel+owner@edk2.groups.io
> >>>> Unsubscribe: https://edk2.groups.io/g/devel/unsub
> >>>> [ray.ni@intel.com] -=-=-=-=-=-=
> >>>
> >>
> >>
> >>
> >
> >
> >
> >
>
>
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 15/35] MdeModulePkg/PiSmmCore: make type punning consistent
2019-09-17 19:49 ` [PATCH 15/35] MdeModulePkg/PiSmmCore: make type punning consistent Laszlo Ersek
@ 2019-09-18 2:38 ` Dong, Eric
0 siblings, 0 replies; 155+ messages in thread
From: Dong, Eric @ 2019-09-18 2:38 UTC (permalink / raw)
To: Laszlo Ersek, edk2-devel-groups-io; +Cc: Wu, Hao A, Wang, Jian J, Ni, Ray
Reviewed-by: Eric Dong <eric.dong@intel.com>
> -----Original Message-----
> From: Laszlo Ersek [mailto:lersek@redhat.com]
> Sent: Wednesday, September 18, 2019 3:49 AM
> To: edk2-devel-groups-io <devel@edk2.groups.io>
> Cc: Dong, Eric <eric.dong@intel.com>; Wu, Hao A <hao.a.wu@intel.com>;
> Wang, Jian J <jian.j.wang@intel.com>; Ni, Ray <ray.ni@intel.com>
> Subject: [PATCH 15/35] MdeModulePkg/PiSmmCore: make type punning
> consistent
>
> The SmiHandlerRegister() function explicitly casts "SmiHandler" (of type
> (SMI_HANDLER*)) to EFI_HANDLE, when outputting "DispatchHandle".
>
> Apply the same cast in the counterpart function SmiHandlerUnRegister(),
> which compares multiple "SmiHandler"s against the input "DispatchHandle".
>
> This is a semantic cleanup; there is no functional change.
>
> Cc: Eric Dong <eric.dong@intel.com>
> Cc: Hao A Wu <hao.a.wu@intel.com>
> Cc: Jian J Wang <jian.j.wang@intel.com>
> Cc: Ray Ni <ray.ni@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> build-tested only, most likely -- I'm unaware of any code paths in OVMF
> that would lead to SmiHandlerUnRegister()
>
> MdeModulePkg/Core/PiSmmCore/Smi.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/MdeModulePkg/Core/PiSmmCore/Smi.c
> b/MdeModulePkg/Core/PiSmmCore/Smi.c
> index f8bd9f49ee3c..488af6754faf 100644
> --- a/MdeModulePkg/Core/PiSmmCore/Smi.c
> +++ b/MdeModulePkg/Core/PiSmmCore/Smi.c
> @@ -282,7 +282,7 @@ SmiHandlerUnRegister (
> //
> SmiHandler = NULL;
> for ( HandlerLink = GetFirstNode (&mRootSmiEntry.SmiHandlers)
> - ; !IsNull (&mRootSmiEntry.SmiHandlers, HandlerLink) && (SmiHandler !=
> DispatchHandle)
> + ; !IsNull (&mRootSmiEntry.SmiHandlers, HandlerLink) &&
> + ((EFI_HANDLE) SmiHandler != DispatchHandle)
> ; HandlerLink = GetNextNode (&mRootSmiEntry.SmiHandlers, HandlerLink)
> ) {
> SmiHandler = CR (HandlerLink, SMI_HANDLER, Link,
> SMI_HANDLER_SIGNATURE); @@ -292,19 +292,19 @@
> SmiHandlerUnRegister (
> // Look for it in non-root SMI handlers
> //
> for ( EntryLink = GetFirstNode (&mSmiEntryList)
> - ; !IsNull (&mSmiEntryList, EntryLink) && (SmiHandler != DispatchHandle)
> + ; !IsNull (&mSmiEntryList, EntryLink) && ((EFI_HANDLE) SmiHandler
> + != DispatchHandle)
> ; EntryLink = GetNextNode (&mSmiEntryList, EntryLink)
> ) {
> SmiEntry = CR (EntryLink, SMI_ENTRY, AllEntries, SMI_ENTRY_SIGNATURE);
> for ( HandlerLink = GetFirstNode (&SmiEntry->SmiHandlers)
> - ; !IsNull (&SmiEntry->SmiHandlers, HandlerLink) && (SmiHandler !=
> DispatchHandle)
> + ; !IsNull (&SmiEntry->SmiHandlers, HandlerLink) &&
> + ((EFI_HANDLE) SmiHandler != DispatchHandle)
> ; HandlerLink = GetNextNode (&SmiEntry->SmiHandlers, HandlerLink)
> ) {
> SmiHandler = CR (HandlerLink, SMI_HANDLER, Link,
> SMI_HANDLER_SIGNATURE);
> }
> }
>
> - if (SmiHandler != DispatchHandle) {
> + if ((EFI_HANDLE) SmiHandler != DispatchHandle) {
> return EFI_INVALID_PARAMETER;
> }
>
> --
> 2.19.1.3.g30247aa5d201
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 17/35] MdePkg/DxeServicesLib: remove bogus cast
2019-09-17 19:49 ` [PATCH 17/35] MdePkg/DxeServicesLib: remove bogus cast Laszlo Ersek
@ 2019-09-18 4:47 ` Liming Gao
2019-09-24 15:38 ` Philippe Mathieu-Daudé
1 sibling, 0 replies; 155+ messages in thread
From: Liming Gao @ 2019-09-18 4:47 UTC (permalink / raw)
To: devel@edk2.groups.io, lersek@redhat.com; +Cc: Kinney, Michael D
Reviewed-by: Liming Gao <liming.gao@intel.com>
>-----Original Message-----
>From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
>Laszlo Ersek
>Sent: Wednesday, September 18, 2019 3:49 AM
>To: edk2-devel-groups-io <devel@edk2.groups.io>
>Cc: Gao, Liming <liming.gao@intel.com>; Kinney, Michael D
><michael.d.kinney@intel.com>
>Subject: [edk2-devel] [PATCH 17/35] MdePkg/DxeServicesLib: remove bogus
>cast
>
>The HandleProtocol() boot service takes an EFI_HANDLE, not an
>(EFI_HANDLE*). Remove the bogus cast in the
>InternalImageHandleToFvHandle() function.
>
>This is a semantic cleanup; there is no change in behavior.
>
>Cc: Liming Gao <liming.gao@intel.com>
>Cc: Michael D Kinney <michael.d.kinney@intel.com>
>Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>---
>
>Notes:
> lightly tested, most probably: it's practically impossible to build a
> platform without consuming DxeServicesLib
>
> MdePkg/Library/DxeServicesLib/DxeServicesLib.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/MdePkg/Library/DxeServicesLib/DxeServicesLib.c
>b/MdePkg/Library/DxeServicesLib/DxeServicesLib.c
>index c416b2dd8c65..0735b2f80400 100644
>--- a/MdePkg/Library/DxeServicesLib/DxeServicesLib.c
>+++ b/MdePkg/Library/DxeServicesLib/DxeServicesLib.c
>@@ -49,7 +49,7 @@ InternalImageHandleToFvHandle (
> ASSERT (ImageHandle != NULL);
>
> Status = gBS->HandleProtocol (
>- (EFI_HANDLE *) ImageHandle,
>+ ImageHandle,
> &gEfiLoadedImageProtocolGuid,
> (VOID **) &LoadedImage
> );
>--
>2.19.1.3.g30247aa5d201
>
>
>
>-=-=-=-=-=-=
>Groups.io Links: You receive all messages sent to this group.
>
>View/Reply Online (#47404): https://edk2.groups.io/g/devel/message/47404
>Mute This Topic: https://groups.io/mt/34180218/1759384
>Group Owner: devel+owner@edk2.groups.io
>Unsubscribe: https://edk2.groups.io/g/devel/unsub [liming.gao@intel.com]
>-=-=-=-=-=-=
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 01/35] DO NOT APPLY: edk2: turn standard handle types into pointers to non-VOID
2019-09-17 20:06 ` [edk2-devel] " Ni, Ray
2019-09-17 20:22 ` Andrew Fish
@ 2019-09-18 8:36 ` Laszlo Ersek
1 sibling, 0 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-18 8:36 UTC (permalink / raw)
To: Ni, Ray, devel@edk2.groups.io
Cc: Achin Gupta, Andrew Fish, Anthony Perard, Ard Biesheuvel,
You, Benjamin, Zhang, Chao B, Bi, Dandan, David Woodhouse,
Dong, Eric, Dong, Guo, Wu, Hao A, Carsey, Jaben, Wang, Jian J,
Wu, Jiaxin, Yao, Jiewen, Justen, Jordan L, Julien Grall,
Leif Lindholm, Gao, Liming, Ma, Maurice, Kinney, Michael D,
Fu, Siyuan, Supreeth Venkatesh, Gao, Zhichao
On 09/17/19 22:06, Ni, Ray wrote:
> Laszlo,
> Thank you very much for this work.
> They are quite helpful to detect potential issues.
>
> But without this specific patch being checked in, future break will still happen.
Yes, I agree; that's quite likely.
> I don't want it to be checked in ASAP because I know that there are quite a lot of close source code that may get build break due to this change.
> Besides that, what prevent you make the decision to check in the changes?
There are two concerns:
(1) Applying this patch would cause edk2 to diverge from the UEFI / PI /
Shell specifications.
For example, consider the following 3rd party code:
EFI_HANDLE Foobar;
UINT64 Val;
Foobar = &Val;
*Semantically*, this code is wrong. However, given the publicly
specified EFI_HANDLE typedef in the UEFI spec, the code is *technically*
correct.
If we changed the EFI_HANDLE typedef in edk2, as follows:
struct EFI_OBJECT;
typedef struct EFI_OBJECT *EFI_HANDLE;
Then the assignment to Foobar above, in the 3rd party code, would become
a C language constraint violation -- and for constraint violations, C
compilers are required to emit diagnostics.
In brief, it would build-break 3rd party code that currently conforms to
the UEFI spec.
(2) Some of the changes in the patch are not optimal with regard to
"data hiding".
An example for good data hiding is the example above: "struct
EFI_OBJECT" being an incomplete type, without any details shared in the
public header.
However, in the patch we have bad data hiding too:
- typedef LIST_ENTRY *EFI_FONT_HANDLE
- typedef UINT8 *EFI_S3_BOOT_SCRIPT_POSITION
- typedef EFI_FILE_PROTOCOL *SHELL_FILE_HANDLE;
These typedefs, while they serve the purposes of the present patch set,
expose too much information (= the actual implementation) about the types.
For solving this data hiding problem, we'd have to (a) introduce
intermittent structure types (similar to EFI_OBJECT), and then (b) we'd
have to rework the rest of the implementation for that. Using
EFI_FONT_HANDLE as example:
(a) introduce the intermittent (opaque) structure type:
struct EFI_FONT_OBJECT;
typedef struct EFI_FONT_OBJECT *EFI_FONT_HANDLE;
(b) rework the implementation:
struct EFI_FONT_OBJECT {
LIST_ENTRY Entry;
};
typedef struct _HII_GLOBAL_FONT_INFO {
UINTN Signature;
struct EFI_FONT_OBJECT FontObject;
HII_FONT_PACKAGE_INSTANCE *FontPackage;
UINTN FontInfoSize;
EFI_FONT_INFO *FontInfo;
} HII_GLOBAL_FONT_INFO;
and then every reference to "HII_GLOBAL_FONT_INFO.Entry" would have to
be updated to "HII_GLOBAL_FONT_INFO.FontObject.Entry".
It's likely doable, but it would take a lot of work.
If we wanted to continue using this patch for sanity-checking edk2, then
one option would be to bracket the changes with #ifdef's. That is, make
the "type separation" dependent on a new feature test macro.
Normally, the feature test macro would not be defined (as it breaks UEFI
spec conformance, see above). But in CI, one set of the builds would
define the macro, for sanity checking edk2 itself.
Thanks
Laszlo
>
> Thanks,
> Ray
>
>
>> -----Original Message-----
>> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Laszlo Ersek
>> Sent: Tuesday, September 17, 2019 12:49 PM
>> To: edk2-devel-groups-io <devel@edk2.groups.io>
>> Cc: Achin Gupta <achin.gupta@arm.com>; Andrew Fish <afish@apple.com>; Anthony Perard <anthony.perard@citrix.com>;
>> Ard Biesheuvel <ard.biesheuvel@linaro.org>; You, Benjamin <benjamin.you@intel.com>; Zhang, Chao B
>> <chao.b.zhang@intel.com>; Bi, Dandan <dandan.bi@intel.com>; David Woodhouse <dwmw2@infradead.org>; Dong, Eric
>> <eric.dong@intel.com>; Dong, Guo <guo.dong@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Carsey, Jaben
>> <jaben.carsey@intel.com>; Wang, Jian J <jian.j.wang@intel.com>; Wu, Jiaxin <jiaxin.wu@intel.com>; Yao, Jiewen
>> <jiewen.yao@intel.com>; Justen, Jordan L <jordan.l.justen@intel.com>; Julien Grall <julien.grall@arm.com>; Leif Lindholm
>> <leif.lindholm@linaro.org>; Gao, Liming <liming.gao@intel.com>; Ma, Maurice <maurice.ma@intel.com>; Kinney, Michael
>> D <michael.d.kinney@intel.com>; Ni, Ray <ray.ni@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>; Supreeth Venkatesh
>> <supreeth.venkatesh@arm.com>; Gao, Zhichao <zhichao.gao@intel.com>
>> Subject: [edk2-devel] [PATCH 01/35] DO NOT APPLY: edk2: turn standard handle types into pointers to non-VOID
>>
>> Unfortunately, the UEFI / PI / Shell specs define a number of handle types
>> as pointers to VOID. This is a design mistake; those types should have
>> been pointers to incomplete union or structure types. Any
>> pointer-to-object type converts implicitly to, and from, pointer-to-void,
>> which prevents compilers from catching at least the following two types of
>> mistakes:
>>
>> - mixing up one handle type with another (for example, EFI_HANDLE with
>> EFI_EVENT),
>>
>> - getting the depth of indirection wrong (for example, mixing up
>> (EFI_HANDLE*) with EFI_HANDLE).
>>
>> In order to root out such mistakes in the edk2 codebase, introduce
>> incomplete structure types with unique tags, such as:
>>
>> struct EFI_FOOBAR_OBJECT;
>> typedef struct EFI_FOOBAR_OBJECT *EFI_FOOBAR_HANDLE;
>>
>> replacing the spec mandated
>>
>> typedef VOID *EFI_FOOBAR_HANDLE;
>>
>> (For some types, such as:
>>
>> - EFI_ACPI_HANDLE,
>> - EFI_EVENT,
>> - EFI_FONT_HANDLE,
>> - EFI_HANDLE,
>> - EFI_HII_HANDLE,
>> - EFI_S3_BOOT_SCRIPT_POSITION,
>> - SHELL_FILE_HANDLE,
>>
>> we connect the actual complete type (the internal, implementation-specific
>> type) to the typedef. Some of these also demonstrate how the code could
>> have looked in practice if the specs had used proper opaque (=incomplete)
>> types.)
>>
>> Then, unleash "build" on the package DSC files. This causes the compiler
>> to warn about incompatible pointer assignments, and to stop the build.
>>
>> The rest of the series addresses the resultant warnings. Each patch
>> belongs in one of two categories:
>>
>> - semantic cleanups (no functional / behavioral changes),
>> - actual bugfixes.
>>
>> As the subject line of this patch states, this specific patch is *not*
>> meant to be applied. It is just a "what if" patch that temporarily
>> isolates the standard types from each other, the way the specs should
>> have, so that the compiler have more information to work with.
>>
>> Cc: Achin Gupta <achin.gupta@arm.com>
>> Cc: Andrew Fish <afish@apple.com>
>> Cc: Anthony Perard <anthony.perard@citrix.com>
>> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> Cc: Benjamin You <benjamin.you@intel.com>
>> Cc: Chao Zhang <chao.b.zhang@intel.com>
>> Cc: Dandan Bi <dandan.bi@intel.com>
>> Cc: David Woodhouse <dwmw2@infradead.org>
>> Cc: Eric Dong <eric.dong@intel.com>
>> Cc: Guo Dong <guo.dong@intel.com>
>> Cc: Hao A Wu <hao.a.wu@intel.com>
>> Cc: Jaben Carsey <jaben.carsey@intel.com>
>> Cc: Jian J Wang <jian.j.wang@intel.com>
>> Cc: Jian Wang <jian.j.wang@intel.com>
>> Cc: Jiaxin Wu <jiaxin.wu@intel.com>
>> Cc: Jiewen Yao <jiewen.yao@intel.com>
>> Cc: Jordan Justen <jordan.l.justen@intel.com>
>> Cc: Julien Grall <julien.grall@arm.com>
>> Cc: Leif Lindholm <leif.lindholm@linaro.org>
>> Cc: Liming Gao <liming.gao@intel.com>
>> Cc: Maurice Ma <maurice.ma@intel.com>
>> Cc: Michael D Kinney <michael.d.kinney@intel.com>
>> Cc: Ray Ni <ray.ni@intel.com>
>> Cc: Siyuan Fu <siyuan.fu@intel.com>
>> Cc: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
>> Cc: Zhichao Gao <zhichao.gao@intel.com>
>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>> ---
>> MdePkg/Include/Pi/PiPeiCis.h | 6 ++++--
>> MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h | 3 ++-
>> MdePkg/Include/Protocol/Bis.h | 3 ++-
>> MdePkg/Include/Protocol/Eap.h | 3 ++-
>> MdePkg/Include/Protocol/HiiFont.h | 3 +--
>> MdePkg/Include/Protocol/MmMp.h | 3 ++-
>> MdePkg/Include/Protocol/S3SaveState.h | 2 +-
>> MdePkg/Include/Protocol/Shell.h | 3 ++-
>> MdePkg/Include/Protocol/UserManager.h | 9 ++++++---
>> MdePkg/Include/Uefi/UefiBaseType.h | 6 ++++--
>> MdePkg/Include/Uefi/UefiInternalFormRepresentation.h | 3 ++-
>> MdeModulePkg/Core/Dxe/Event/Event.h | 2 +-
>> MdeModulePkg/Core/Dxe/Hand/Handle.h | 2 +-
>> MdeModulePkg/Core/PiSmmCore/PiSmmCore.h | 2 +-
>> MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h | 2 +-
>> MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabase.h | 2 +-
>> StandaloneMmPkg/Core/StandaloneMmCore.h | 2 +-
>> 17 files changed, 34 insertions(+), 22 deletions(-)
>>
>> diff --git a/MdePkg/Include/Pi/PiPeiCis.h b/MdePkg/Include/Pi/PiPeiCis.h
>> index d9d4ed7d413a..3e9e82b62ae9 100644
>> --- a/MdePkg/Include/Pi/PiPeiCis.h
>> +++ b/MdePkg/Include/Pi/PiPeiCis.h
>> @@ -18,12 +18,14 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>> ///
>> /// The handles of EFI FV.
>> ///
>> -typedef VOID *EFI_PEI_FV_HANDLE;
>> +struct EFI_PEI_FV_OBJECT;
>> +typedef struct EFI_PEI_FV_OBJECT *EFI_PEI_FV_HANDLE;
>>
>> ///
>> /// The handles of EFI FFS.
>> ///
>> -typedef VOID *EFI_PEI_FILE_HANDLE;
>> +struct EFI_PEI_FILE_OBJECT;
>> +typedef struct EFI_PEI_FILE_OBJECT *EFI_PEI_FILE_HANDLE;
>>
>> ///
>> /// Declare the forward reference data structure for EFI_PEI_SERVICE.
>> diff --git a/MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h
>> b/MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h
>> index a8e0b24c6c8d..8a1863f3e03d 100644
>> --- a/MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h
>> +++ b/MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h
>> @@ -16,7 +16,8 @@
>> { 0xeb97088e, 0xcfdf, 0x49c6, { 0xbe, 0x4b, 0xd9, 0x6, 0xa5, 0xb2, 0xe, 0x86 }}
>>
>> typedef UINT32 EFI_ACPI_TABLE_VERSION;
>> -typedef VOID *EFI_ACPI_HANDLE;
>> +struct EFI_ACPI_OBJECT;
>> +typedef struct EFI_ACPI_OBJECT *EFI_ACPI_HANDLE;
>>
>> #define EFI_ACPI_TABLE_VERSION_NONE (1 << 0)
>> #define EFI_ACPI_TABLE_VERSION_1_0B (1 << 1)
>> diff --git a/MdePkg/Include/Protocol/Bis.h b/MdePkg/Include/Protocol/Bis.h
>> index 2be6718f4bc2..8eca94512d03 100644
>> --- a/MdePkg/Include/Protocol/Bis.h
>> +++ b/MdePkg/Include/Protocol/Bis.h
>> @@ -37,7 +37,8 @@ typedef struct _EFI_BIS_PROTOCOL EFI_BIS_PROTOCOL;
>> //
>> // Basic types
>> //
>> -typedef VOID *BIS_APPLICATION_HANDLE;
>> +struct BIS_APPLICATION_OBJECT;
>> +typedef struct BIS_APPLICATION_OBJECT *BIS_APPLICATION_HANDLE;
>> typedef UINT16 BIS_ALG_ID;
>> typedef UINT32 BIS_CERT_ID;
>>
>> diff --git a/MdePkg/Include/Protocol/Eap.h b/MdePkg/Include/Protocol/Eap.h
>> index 203d0f40b0dd..06584ef409d0 100644
>> --- a/MdePkg/Include/Protocol/Eap.h
>> +++ b/MdePkg/Include/Protocol/Eap.h
>> @@ -28,7 +28,8 @@ typedef struct _EFI_EAP_PROTOCOL EFI_EAP_PROTOCOL;
>> /// Type for the identification number assigned to the Port by the
>> /// System in which the Port resides.
>> ///
>> -typedef VOID * EFI_PORT_HANDLE;
>> +struct EFI_PORT_OBJECT;
>> +typedef struct EFI_PORT_OBJECT *EFI_PORT_HANDLE;
>>
>> ///
>> /// EAP Authentication Method Type (RFC 3748)
>> diff --git a/MdePkg/Include/Protocol/HiiFont.h b/MdePkg/Include/Protocol/HiiFont.h
>> index 1f2e321ea4e2..450cad9ada70 100644
>> --- a/MdePkg/Include/Protocol/HiiFont.h
>> +++ b/MdePkg/Include/Protocol/HiiFont.h
>> @@ -19,8 +19,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>> { 0xe9ca4775, 0x8657, 0x47fc, { 0x97, 0xe7, 0x7e, 0xd6, 0x5a, 0x8, 0x43, 0x24 } }
>>
>> typedef struct _EFI_HII_FONT_PROTOCOL EFI_HII_FONT_PROTOCOL;
>> -
>> -typedef VOID *EFI_FONT_HANDLE;
>> +typedef LIST_ENTRY *EFI_FONT_HANDLE;
>>
>> ///
>> /// EFI_HII_OUT_FLAGS.
>> diff --git a/MdePkg/Include/Protocol/MmMp.h b/MdePkg/Include/Protocol/MmMp.h
>> index beace1386cbe..cd4e0db47e08 100644
>> --- a/MdePkg/Include/Protocol/MmMp.h
>> +++ b/MdePkg/Include/Protocol/MmMp.h
>> @@ -36,7 +36,8 @@
>> //
>> // Completion token
>> //
>> -typedef VOID* MM_COMPLETION;
>> +struct MM_COMPLETION_OBJECT;
>> +typedef struct MM_COMPLETION_OBJECT* MM_COMPLETION;
>>
>> typedef struct {
>> MM_COMPLETION Completion;
>> diff --git a/MdePkg/Include/Protocol/S3SaveState.h b/MdePkg/Include/Protocol/S3SaveState.h
>> index c1b8f8b9e08d..235c36be6737 100644
>> --- a/MdePkg/Include/Protocol/S3SaveState.h
>> +++ b/MdePkg/Include/Protocol/S3SaveState.h
>> @@ -21,7 +21,7 @@
>> { 0xe857caf6, 0xc046, 0x45dc, { 0xbe, 0x3f, 0xee, 0x7, 0x65, 0xfb, 0xa8, 0x87 }}
>>
>>
>> -typedef VOID *EFI_S3_BOOT_SCRIPT_POSITION;
>> +typedef UINT8 *EFI_S3_BOOT_SCRIPT_POSITION;
>>
>> typedef struct _EFI_S3_SAVE_STATE_PROTOCOL EFI_S3_SAVE_STATE_PROTOCOL;
>>
>> diff --git a/MdePkg/Include/Protocol/Shell.h b/MdePkg/Include/Protocol/Shell.h
>> index cfb7878228c5..bf791792b4f2 100644
>> --- a/MdePkg/Include/Protocol/Shell.h
>> +++ b/MdePkg/Include/Protocol/Shell.h
>> @@ -11,12 +11,13 @@
>> #define __EFI_SHELL_PROTOCOL_H__
>>
>> #include <Guid/FileInfo.h>
>> +#include <Protocol/SimpleFileSystem.h>
>>
>> #define EFI_SHELL_PROTOCOL_GUID \
>> { \
>> 0x6302d008, 0x7f9b, 0x4f30, { 0x87, 0xac, 0x60, 0xc9, 0xfe, 0xf5, 0xda, 0x4e } \
>> }
>> -typedef VOID *SHELL_FILE_HANDLE;
>> +typedef EFI_FILE_PROTOCOL *SHELL_FILE_HANDLE;
>>
>> typedef enum {
>> ///
>> diff --git a/MdePkg/Include/Protocol/UserManager.h b/MdePkg/Include/Protocol/UserManager.h
>> index 26ac4955f1ec..9abfcffbeebf 100644
>> --- a/MdePkg/Include/Protocol/UserManager.h
>> +++ b/MdePkg/Include/Protocol/UserManager.h
>> @@ -24,8 +24,10 @@
>> 0xbaf1e6de, 0x209e, 0x4adb, { 0x8d, 0x96, 0xfd, 0x8b, 0x71, 0xf3, 0xf6, 0x83 } \
>> }
>>
>> -typedef VOID *EFI_USER_PROFILE_HANDLE;
>> -typedef VOID *EFI_USER_INFO_HANDLE;
>> +struct EFI_USER_PROFILE_OBJECT;
>> +typedef struct EFI_USER_PROFILE_OBJECT *EFI_USER_PROFILE_HANDLE;
>> +struct EFI_USER_INFO_OBJECT;
>> +typedef struct EFI_USER_INFO_OBJECT *EFI_USER_INFO_HANDLE;
>>
>> ///
>> /// The attributes of the user profile information.
>> @@ -157,7 +159,8 @@ typedef CHAR16 *EFI_USER_INFO_CREDENTIAL_PROVIDER_NAME;
>> /// Biometric Exchange Formats Framework) specification.
>> ///
>> #define EFI_USER_INFO_CBEFF_RECORD 0x0B
>> -typedef VOID *EFI_USER_INFO_CBEFF;
>> +struct EFI_USER_INFO_CBEFF_OBJECT;
>> +typedef struct EFI_USER_INFO_CBEFF_OBJECT *EFI_USER_INFO_CBEFF;
>> ///
>> /// Indicates how close of a match the fingerprint must be in order to be considered a match.
>> ///
>> diff --git a/MdePkg/Include/Uefi/UefiBaseType.h b/MdePkg/Include/Uefi/UefiBaseType.h
>> index a62f13dd064f..be5831991b52 100644
>> --- a/MdePkg/Include/Uefi/UefiBaseType.h
>> +++ b/MdePkg/Include/Uefi/UefiBaseType.h
>> @@ -28,11 +28,13 @@ typedef RETURN_STATUS EFI_STATUS;
>> ///
>> /// A collection of related interfaces.
>> ///
>> -typedef VOID *EFI_HANDLE;
>> +struct EFI_OBJECT;
>> +typedef struct EFI_OBJECT *EFI_HANDLE;
>> ///
>> /// Handle to an event structure.
>> ///
>> -typedef VOID *EFI_EVENT;
>> +struct EFI_EVENT_OBJECT;
>> +typedef struct EFI_EVENT_OBJECT *EFI_EVENT;
>> ///
>> /// Task priority level.
>> ///
>> diff --git a/MdePkg/Include/Uefi/UefiInternalFormRepresentation.h
>> b/MdePkg/Include/Uefi/UefiInternalFormRepresentation.h
>> index 4a1346a599d0..93bf9e9e0f13 100644
>> --- a/MdePkg/Include/Uefi/UefiInternalFormRepresentation.h
>> +++ b/MdePkg/Include/Uefi/UefiInternalFormRepresentation.h
>> @@ -20,7 +20,8 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>> ///
>> /// The following types are currently defined:
>> ///
>> -typedef VOID* EFI_HII_HANDLE;
>> +struct EFI_HII_OBJECT;
>> +typedef struct EFI_HII_OBJECT* EFI_HII_HANDLE;
>> typedef CHAR16* EFI_STRING;
>> typedef UINT16 EFI_IMAGE_ID;
>> typedef UINT16 EFI_QUESTION_ID;
>> diff --git a/MdeModulePkg/Core/Dxe/Event/Event.h b/MdeModulePkg/Core/Dxe/Event/Event.h
>> index 8141c5003eec..42590cb1dd09 100644
>> --- a/MdeModulePkg/Core/Dxe/Event/Event.h
>> +++ b/MdeModulePkg/Core/Dxe/Event/Event.h
>> @@ -37,7 +37,7 @@ typedef struct {
>> } TIMER_EVENT_INFO;
>>
>> #define EVENT_SIGNATURE SIGNATURE_32('e','v','n','t')
>> -typedef struct {
>> +typedef struct EFI_EVENT_OBJECT {
>> UINTN Signature;
>> UINT32 Type;
>> UINT32 SignalCount;
>> diff --git a/MdeModulePkg/Core/Dxe/Hand/Handle.h b/MdeModulePkg/Core/Dxe/Hand/Handle.h
>> index 83eb2b9f3afe..1f1ab3274e8a 100644
>> --- a/MdeModulePkg/Core/Dxe/Hand/Handle.h
>> +++ b/MdeModulePkg/Core/Dxe/Hand/Handle.h
>> @@ -15,7 +15,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>> ///
>> /// IHANDLE - contains a list of protocol handles
>> ///
>> -typedef struct {
>> +typedef struct EFI_OBJECT {
>> UINTN Signature;
>> /// All handles list of IHANDLE
>> LIST_ENTRY AllHandles;
>> diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
>> index 0908e7f4e9e7..c55da58d465e 100644
>> --- a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
>> +++ b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
>> @@ -145,7 +145,7 @@ typedef struct {
>> ///
>> /// IHANDLE - contains a list of protocol handles
>> ///
>> -typedef struct {
>> +typedef struct EFI_OBJECT {
>> UINTN Signature;
>> /// All handles list of IHANDLE
>> LIST_ENTRY AllHandles;
>> diff --git a/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h
>> b/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h
>> index 50d4c96edb63..bfebbb1f8182 100644
>> --- a/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h
>> +++ b/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h
>> @@ -88,7 +88,7 @@ struct _EFI_AML_NODE_LIST {
>> // This buffer should not be freed.
>> // Size is the total size of this ACPI node buffer.
>> //
>> -typedef struct {
>> +typedef struct EFI_ACPI_OBJECT {
>> UINT32 Signature;
>> UINT8 *Buffer;
>> UINTN Size;
>> diff --git a/MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabase.h
>> b/MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabase.h
>> index 4a3feab94df5..48972d0fcad6 100644
>> --- a/MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabase.h
>> +++ b/MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabase.h
>> @@ -274,7 +274,7 @@ typedef struct _HII_DATABASE_PACKAGE_LIST_INSTANCE {
>>
>> #define HII_HANDLE_SIGNATURE SIGNATURE_32 ('h','i','h','l')
>>
>> -typedef struct {
>> +typedef struct EFI_HII_OBJECT {
>> UINTN Signature;
>> LIST_ENTRY Handle;
>> UINTN Key;
>> diff --git a/StandaloneMmPkg/Core/StandaloneMmCore.h b/StandaloneMmPkg/Core/StandaloneMmCore.h
>> index 4d0eed273f50..dcf91bc5e916 100644
>> --- a/StandaloneMmPkg/Core/StandaloneMmCore.h
>> +++ b/StandaloneMmPkg/Core/StandaloneMmCore.h
>> @@ -105,7 +105,7 @@ typedef struct {
>> ///
>> /// IHANDLE - contains a list of protocol handles
>> ///
>> -typedef struct {
>> +typedef struct EFI_OBJECT {
>> UINTN Signature;
>> /// All handles list of IHANDLE
>> LIST_ENTRY AllHandles;
>> --
>> 2.19.1.3.g30247aa5d201
>>
>>
>>
>> -=-=-=-=-=-=
>> Groups.io Links: You receive all messages sent to this group.
>>
>> View/Reply Online (#47388): https://edk2.groups.io/g/devel/message/47388
>> Mute This Topic: https://groups.io/mt/34180199/1712937
>> Group Owner: devel+owner@edk2.groups.io
>> Unsubscribe: https://edk2.groups.io/g/devel/unsub [ray.ni@intel.com]
>> -=-=-=-=-=-=
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 01/35] DO NOT APPLY: edk2: turn standard handle types into pointers to non-VOID
2019-09-17 20:22 ` Andrew Fish
2019-09-17 20:28 ` Ni, Ray
@ 2019-09-18 8:41 ` Laszlo Ersek
2019-09-18 15:16 ` Michael D Kinney
2019-09-18 15:55 ` Andrew Fish
1 sibling, 2 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-18 8:41 UTC (permalink / raw)
To: Andrew Fish, Ni, Ray
Cc: devel@edk2.groups.io, Achin Gupta, Anthony Perard, Ard Biesheuvel,
You, Benjamin, Zhang, Chao B, Bi, Dandan, David Woodhouse,
Dong, Eric, Dong, Guo, Wu, Hao A, Carsey, Jaben, Wang, Jian J,
Wu, Jiaxin, Yao, Jiewen, Jordan Justen, Julien Grall,
Leif Lindholm, Gao, Liming, Ma, Maurice, Mike Kinney, Fu, Siyuan,
Supreeth Venkatesh, Gao, Zhichao
On 09/17/19 22:22, Andrew Fish wrote:
>
>
>> On Sep 17, 2019, at 1:06 PM, Ni, Ray <ray.ni@intel.com> wrote:
>>
>> Laszlo,
>> Thank you very much for this work.
>> They are quite helpful to detect potential issues.
>>
>> But without this specific patch being checked in, future break will still happen.
>> I don't want it to be checked in ASAP because I know that there are quite a lot of close source code that may get build break due to this change.
>> Besides that, what prevent you make the decision to check in the changes?
>>
>
> Ray,
>
> I was thinking the same thing. Could we make this an optional feature via a #define? We could always default to the Spec Behavior, and new projects could opt into the stricter version.
>
> #ifndef STRICTER_UEFI_TYPES
> typedef VOID *EFI_PEI_FV_HANDLE;
> #else
> struct EFI_PEI_FV_OBJECT;
> typedef struct EFI_PEI_FV_OBJECT *EFI_PEI_FV_HANDLE;
> #endif
Technically, this would work well.
However, if we wanted to allow new projects to #define
STRICTER_UEFI_TYPES as their normal mode of operation (and not just for
a sanity check in CI), then we'd have to update the UEFI spec too.
Otherwise, code that is technically spec-conformant (albeit semantically
nonsensical), like I mentioned up-thread, would no longer compile:
EFI_HANDLE Foobar;
UINT64 Val;
Foobar = &Val;
Thanks
Laszlo
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 22/35] OvmfPkg/XenBusDxe: fix UninstallMultipleProtocolInterfaces() call
2019-09-17 19:49 ` [PATCH 22/35] OvmfPkg/XenBusDxe: fix UninstallMultipleProtocolInterfaces() call Laszlo Ersek
@ 2019-09-18 9:32 ` Anthony PERARD
2019-09-18 10:30 ` Julien Grall
2019-09-23 15:03 ` [edk2-devel] " Philippe Mathieu-Daudé
2 siblings, 0 replies; 155+ messages in thread
From: Anthony PERARD @ 2019-09-18 9:32 UTC (permalink / raw)
To: Laszlo Ersek
Cc: edk2-devel-groups-io, Ard Biesheuvel, Jordan Justen, Julien Grall
On Tue, Sep 17, 2019 at 09:49:22PM +0200, Laszlo Ersek wrote:
> Unlike the InstallMultipleProtocolInterfaces() boot service, which takes
> an (EFI_HANDLE*) as first parameter, the
> UninstallMultipleProtocolInterfaces() boot service takes an EFI_HANDLE as
> first parameter.
>
> This is an actual bug. It must have remained hidden until now because it's
> on an error path. Fix the UninstallMultipleProtocolInterfaces() call.
>
> Cc: Anthony Perard <anthony.perard@citrix.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Jordan Justen <jordan.l.justen@intel.com>
> Cc: Julien Grall <julien.grall@arm.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Thanks,
--
Anthony PERARD
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 22/35] OvmfPkg/XenBusDxe: fix UninstallMultipleProtocolInterfaces() call
2019-09-17 19:49 ` [PATCH 22/35] OvmfPkg/XenBusDxe: fix UninstallMultipleProtocolInterfaces() call Laszlo Ersek
2019-09-18 9:32 ` Anthony PERARD
@ 2019-09-18 10:30 ` Julien Grall
2019-09-23 15:03 ` [edk2-devel] " Philippe Mathieu-Daudé
2 siblings, 0 replies; 155+ messages in thread
From: Julien Grall @ 2019-09-18 10:30 UTC (permalink / raw)
To: Laszlo Ersek, edk2-devel-groups-io
Cc: Anthony Perard, Ard Biesheuvel, Jordan Justen
Hi,
On 17/09/2019 20:49, Laszlo Ersek wrote:
> Unlike the InstallMultipleProtocolInterfaces() boot service, which takes
> an (EFI_HANDLE*) as first parameter, the
> UninstallMultipleProtocolInterfaces() boot service takes an EFI_HANDLE as
> first parameter.
>
> This is an actual bug. It must have remained hidden until now because it's
> on an error path. Fix the UninstallMultipleProtocolInterfaces() call.
>
> Cc: Anthony Perard <anthony.perard@citrix.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Jordan Justen <jordan.l.justen@intel.com>
> Cc: Julien Grall <julien.grall@arm.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Julien Grall <julien.grall@arm.com>
Cheers,
--
Julien Grall
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 01/35] DO NOT APPLY: edk2: turn standard handle types into pointers to non-VOID
2019-09-18 8:41 ` Laszlo Ersek
@ 2019-09-18 15:16 ` Michael D Kinney
2019-09-18 17:41 ` Laszlo Ersek
2019-09-18 15:55 ` Andrew Fish
1 sibling, 1 reply; 155+ messages in thread
From: Michael D Kinney @ 2019-09-18 15:16 UTC (permalink / raw)
To: Laszlo Ersek, Andrew Fish, Ni, Ray, Kinney, Michael D
Cc: devel@edk2.groups.io, Achin Gupta, Anthony Perard, Ard Biesheuvel,
You, Benjamin, Zhang, Chao B, Bi, Dandan, David Woodhouse,
Dong, Eric, Dong, Guo, Wu, Hao A, Carsey, Jaben, Wang, Jian J,
Wu, Jiaxin, Yao, Jiewen, Justen, Jordan L, Julien Grall,
Leif Lindholm, Gao, Liming, Ma, Maurice, Fu, Siyuan,
Supreeth Venkatesh, Gao, Zhichao
> -----Original Message-----
> From: Laszlo Ersek <lersek@redhat.com>
> Sent: Wednesday, September 18, 2019 1:42 AM
> To: Andrew Fish <afish@apple.com>; Ni, Ray
> <ray.ni@intel.com>
> Cc: devel@edk2.groups.io; Achin Gupta
> <achin.gupta@arm.com>; Anthony Perard
> <anthony.perard@citrix.com>; Ard Biesheuvel
> <ard.biesheuvel@linaro.org>; You, Benjamin
> <benjamin.you@intel.com>; Zhang, Chao B
> <chao.b.zhang@intel.com>; Bi, Dandan
> <dandan.bi@intel.com>; David Woodhouse
> <dwmw2@infradead.org>; Dong, Eric
> <eric.dong@intel.com>; Dong, Guo <guo.dong@intel.com>;
> Wu, Hao A <hao.a.wu@intel.com>; Carsey, Jaben
> <jaben.carsey@intel.com>; Wang, Jian J
> <jian.j.wang@intel.com>; Wu, Jiaxin
> <jiaxin.wu@intel.com>; Yao, Jiewen
> <jiewen.yao@intel.com>; Justen, Jordan L
> <jordan.l.justen@intel.com>; Julien Grall
> <julien.grall@arm.com>; Leif Lindholm
> <leif.lindholm@linaro.org>; Gao, Liming
> <liming.gao@intel.com>; Ma, Maurice
> <maurice.ma@intel.com>; Kinney, Michael D
> <michael.d.kinney@intel.com>; Fu, Siyuan
> <siyuan.fu@intel.com>; Supreeth Venkatesh
> <supreeth.venkatesh@arm.com>; Gao, Zhichao
> <zhichao.gao@intel.com>
> Subject: Re: [edk2-devel] [PATCH 01/35] DO NOT APPLY:
> edk2: turn standard handle types into pointers to non-
> VOID
>
> On 09/17/19 22:22, Andrew Fish wrote:
> >
> >
> >> On Sep 17, 2019, at 1:06 PM, Ni, Ray
> <ray.ni@intel.com> wrote:
> >>
> >> Laszlo,
> >> Thank you very much for this work.
> >> They are quite helpful to detect potential issues.
> >>
> >> But without this specific patch being checked in,
> future break will still happen.
> >> I don't want it to be checked in ASAP because I know
> that there are quite a lot of close source code that
> may get build break due to this change.
> >> Besides that, what prevent you make the decision to
> check in the changes?
> >>
> >
> > Ray,
> >
> > I was thinking the same thing. Could we make this an
> optional feature via a #define? We could always default
> to the Spec Behavior, and new projects could opt into
> the stricter version.
> >
> > #ifndef STRICTER_UEFI_TYPES
> > typedef VOID *EFI_PEI_FV_HANDLE;
> > #else
> > struct EFI_PEI_FV_OBJECT;
> > typedef struct EFI_PEI_FV_OBJECT *EFI_PEI_FV_HANDLE;
> #endif
>
> Technically, this would work well.
>
> However, if we wanted to allow new projects to #define
> STRICTER_UEFI_TYPES as their normal mode of operation
> (and not just for a sanity check in CI), then we'd have
> to update the UEFI spec too.
>
> Otherwise, code that is technically spec-conformant
> (albeit semantically nonsensical), like I mentioned up-
> thread, would no longer compile:
>
> EFI_HANDLE Foobar;
> UINT64 Val;
>
> Foobar = &Val;
Does this example build without warnings on all compilers.
I thought we usually have to add some typecasts:
Foobar = (EFI_HANDLE)&Val;
Or
Foobar = (EFI_HANDLE)(UINTN)&Val;
For examples like this, adding an explicit typecast would be an
improvement. So finding and reviewing and fixing these would be
a good improvement.
>
> Thanks
> Laszlo
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 01/35] DO NOT APPLY: edk2: turn standard handle types into pointers to non-VOID
2019-09-18 8:41 ` Laszlo Ersek
2019-09-18 15:16 ` Michael D Kinney
@ 2019-09-18 15:55 ` Andrew Fish
2019-09-18 16:16 ` Leif Lindholm
2019-09-18 17:45 ` Laszlo Ersek
1 sibling, 2 replies; 155+ messages in thread
From: Andrew Fish @ 2019-09-18 15:55 UTC (permalink / raw)
To: devel, lersek
Cc: Ni, Ray, Achin Gupta, Anthony Perard, Ard Biesheuvel,
You, Benjamin, Zhang, Chao B, Bi, Dandan, David Woodhouse,
Dong, Eric, Dong, Guo, Wu, Hao A, Carsey, Jaben, Wang, Jian J,
Wu, Jiaxin, Yao, Jiewen, Jordan Justen, Julien Grall,
Leif Lindholm, Gao, Liming, Ma, Maurice, Mike Kinney, Fu, Siyuan,
Supreeth Venkatesh, Gao, Zhichao
[-- Attachment #1: Type: text/plain, Size: 2082 bytes --]
> On Sep 18, 2019, at 1:41 AM, Laszlo Ersek <lersek@redhat.com> wrote:
>
> On 09/17/19 22:22, Andrew Fish wrote:
>>
>>
>>> On Sep 17, 2019, at 1:06 PM, Ni, Ray <ray.ni@intel.com> wrote:
>>>
>>> Laszlo,
>>> Thank you very much for this work.
>>> They are quite helpful to detect potential issues.
>>>
>>> But without this specific patch being checked in, future break will still happen.
>>> I don't want it to be checked in ASAP because I know that there are quite a lot of close source code that may get build break due to this change.
>>> Besides that, what prevent you make the decision to check in the changes?
>>>
>>
>> Ray,
>>
>> I was thinking the same thing. Could we make this an optional feature via a #define? We could always default to the Spec Behavior, and new projects could opt into the stricter version.
>>
>> #ifndef STRICTER_UEFI_TYPES
>> typedef VOID *EFI_PEI_FV_HANDLE;
>> #else
>> struct EFI_PEI_FV_OBJECT;
>> typedef struct EFI_PEI_FV_OBJECT *EFI_PEI_FV_HANDLE;
>> #endif
>
> Technically, this would work well.
>
> However, if we wanted to allow new projects to #define
> STRICTER_UEFI_TYPES as their normal mode of operation (and not just for
> a sanity check in CI), then we'd have to update the UEFI spec too.
>
> Otherwise, code that is technically spec-conformant (albeit semantically
> nonsensical), like I mentioned up-thread, would no longer compile:
>
Laszlo,
I think helping people NOT write nonsensical code is good. It is very good idea and I'd like to add it to the spec but as you point out it would break a lot of existing code so I'm not sure it is possible. I guess we could try to add a strict mode to the spec but given the types are defined in tables that may be problematic.
We have coding standards that are more strict than what the C spec allows. So I would see the STRICT_UEFI_TYPES as more of a enforce the coding standard kind of thing?
Thanks,
Andrew Fish
> EFI_HANDLE Foobar;
> UINT64 Val;
>
> Foobar = &Val;
>
> Thanks
> Laszlo
>
>
[-- Attachment #2: Type: text/html, Size: 14813 bytes --]
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 01/35] DO NOT APPLY: edk2: turn standard handle types into pointers to non-VOID
2019-09-18 15:55 ` Andrew Fish
@ 2019-09-18 16:16 ` Leif Lindholm
2019-09-18 17:45 ` Laszlo Ersek
1 sibling, 0 replies; 155+ messages in thread
From: Leif Lindholm @ 2019-09-18 16:16 UTC (permalink / raw)
To: devel, afish
Cc: lersek, Ni, Ray, Achin Gupta, Anthony Perard, Ard Biesheuvel,
You, Benjamin, Zhang, Chao B, Bi, Dandan, David Woodhouse,
Dong, Eric, Dong, Guo, Wu, Hao A, Carsey, Jaben, Wang, Jian J,
Wu, Jiaxin, Yao, Jiewen, Jordan Justen, Julien Grall, Gao, Liming,
Ma, Maurice, Mike Kinney, Fu, Siyuan, Supreeth Venkatesh,
Gao, Zhichao
On Wed, Sep 18, 2019 at 08:55:42AM -0700, Andrew Fish via Groups.Io wrote:
> >> #ifndef STRICTER_UEFI_TYPES
> >> typedef VOID *EFI_PEI_FV_HANDLE;
> >> #else
> >> struct EFI_PEI_FV_OBJECT;
> >> typedef struct EFI_PEI_FV_OBJECT *EFI_PEI_FV_HANDLE;
> >> #endif
> >
> > Technically, this would work well.
> >
> > However, if we wanted to allow new projects to #define
> > STRICTER_UEFI_TYPES as their normal mode of operation (and not just for
> > a sanity check in CI), then we'd have to update the UEFI spec too.
> >
> > Otherwise, code that is technically spec-conformant (albeit semantically
> > nonsensical), like I mentioned up-thread, would no longer compile:
>
> I think helping people NOT write nonsensical code is good. It is
> very good idea and I'd like to add it to the spec but as you point
> out it would break a lot of existing code so I'm not sure it is
> possible. I guess we could try to add a strict mode to the spec but
> given the types are defined in tables that may be problematic.
I think adding a strict mode to the specification should be doable -
an important aspect is that this should[1] only break *builds* of
existing code, never the execution of existing applications/drivers on
firmware built to the strict mode. (Unless I'm missing something
obvious.)
[1] It is always possible *some* toolchain does something weird that
is already wrong but not visible, and this change would expose the
underlying fault. This is not necessarily bad.
The specification could then describe the problematic types within
#ifdef starements.
Best Regards,
Leif
> We have coding standards that are more strict than what the C spec
> allows. So I would see the STRICT_UEFI_TYPES as more of a enforce
> the coding standard kind of thing?
>
> Thanks,
>
> Andrew Fish
>
> > EFI_HANDLE Foobar;
> > UINT64 Val;
> >
> > Foobar = &Val;
> >
> > Thanks
> > Laszlo
> >
> >
>
>
>
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 01/35] DO NOT APPLY: edk2: turn standard handle types into pointers to non-VOID
2019-09-18 15:16 ` Michael D Kinney
@ 2019-09-18 17:41 ` Laszlo Ersek
0 siblings, 0 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-18 17:41 UTC (permalink / raw)
To: Kinney, Michael D, Andrew Fish, Ni, Ray
Cc: devel@edk2.groups.io, Achin Gupta, Anthony Perard, Ard Biesheuvel,
You, Benjamin, Zhang, Chao B, Bi, Dandan, David Woodhouse,
Dong, Eric, Dong, Guo, Wu, Hao A, Carsey, Jaben, Wang, Jian J,
Wu, Jiaxin, Yao, Jiewen, Justen, Jordan L, Julien Grall,
Leif Lindholm, Gao, Liming, Ma, Maurice, Fu, Siyuan,
Supreeth Venkatesh, Gao, Zhichao
On 09/18/19 17:16, Kinney, Michael D wrote:
>> -----Original Message-----
>> From: Laszlo Ersek <lersek@redhat.com>
>> However, if we wanted to allow new projects to #define
>> STRICTER_UEFI_TYPES as their normal mode of operation
>> (and not just for a sanity check in CI), then we'd have
>> to update the UEFI spec too.
>>
>> Otherwise, code that is technically spec-conformant
>> (albeit semantically nonsensical), like I mentioned up-
>> thread, would no longer compile:
>>
>> EFI_HANDLE Foobar;
>> UINT64 Val;
>>
>> Foobar = &Val;
>
> Does this example build without warnings on all compilers.
I can't test "all" compilers :), but yes, per the C standard, it has to.
"Foobar" is a pointer-to-void, and "&Val" is a
pointer-to-unsigned-long-long. Such an assignment satisfies the
following passages in C99:
6. Language
6.3 Conversions
6.3.2 Other operands
6.3.2.3 Pointers
1 A pointer to void may be converted to or from a pointer to any
incomplete or object type. A pointer to any incomplete or
object type may be converted to a pointer to void and back
again; the result shall compare equal to the original pointer.
6.5 Expressions
6.5.4 Cast operators
Constraints
3 Conversions that involve pointers, other than where permitted by
the constraints of 6.5.16.1, shall be specified by means of an
explicit cast.
6.5.16 Assignment operators
6.5.16.1 Simple assignment
Constraints
1 One of the following shall hold:
[...]
- one operand is a pointer to an object or incomplete type and
the other is a pointer to a qualified or unqualified version
of void, and the type pointed to by the left has all the
qualifiers of the type pointed to by the right;
[...]
> I thought we usually have to add some typecasts:
>
> Foobar = (EFI_HANDLE)&Val;
That's exactly the problem with EFI_HANDLE being a typedef to (void*) --
the explicit cast is not required.
Note the "other than" language in 6.5.4 paragraph 3.
> Or
>
> Foobar = (EFI_HANDLE)(UINTN)&Val;
>
> For examples like this, adding an explicit typecast would be an
> improvement. So finding and reviewing and fixing these would be
> a good improvement.
The problem is that the
Foobar = &Val;
assignment is technically valid, considering both the C standard and the
UEFI spec. Breaking it would be a semantic improvement, but still in
conflict with what UEFI-2.8 promises.
Thanks
Laszlo
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 02/35] EmbeddedPkg: add missing EFIAPI calling convention specifiers
2019-09-17 19:49 ` [PATCH 02/35] EmbeddedPkg: add missing EFIAPI calling convention specifiers Laszlo Ersek
@ 2019-09-18 17:41 ` Leif Lindholm
0 siblings, 0 replies; 155+ messages in thread
From: Leif Lindholm @ 2019-09-18 17:41 UTC (permalink / raw)
To: Laszlo Ersek; +Cc: edk2-devel-groups-io, Ard Biesheuvel
On Tue, Sep 17, 2019 at 09:49:02PM +0200, Laszlo Ersek wrote:
> This patch is unrelated to the rest of the series; it just makes sure that
> "EmbeddedPkg/EmbeddedPkg.dsc" builds for all platforms advertised in
> SUPPORTED_ARCHITECTURES (in particular, X64).
Hmm, I'm nearly 100% sure I have tested that in the past, but it
certainly doesn't work with my GCC8 compiler.
> No functional changes.
>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Leif Lindholm <leif.lindholm@linaro.org>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> build-tested only
Well, EFIAPI is either a no-op or required for proper functionality to
begin with, so...
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
> EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.h | 32 +++++++++++++++-----
> EmbeddedPkg/GdbStub/GdbStubInternal.h | 9 ++++++
> EmbeddedPkg/Drivers/ConsolePrefDxe/ConsolePrefDxe.c | 1 +
> EmbeddedPkg/Drivers/Lan9118Dxe/Lan9118Dxe.c | 1 +
> EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c | 8 +++++
> EmbeddedPkg/MetronomeDxe/Metronome.c | 1 +
> 6 files changed, 44 insertions(+), 8 deletions(-)
>
> diff --git a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.h b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.h
> index e3db0821c38f..20636574c271 100644
> --- a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.h
> +++ b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.h
> @@ -205,7 +205,9 @@ SataSiI3132DriverBindingStop (
> IN EFI_HANDLE *ChildHandleBuffer
> );
>
> -EFI_STATUS SiI3132AtaPassThruCommand (
> +EFI_STATUS
> +EFIAPI
> +SiI3132AtaPassThruCommand (
> IN SATA_SI3132_INSTANCE *pSataSiI3132Instance,
> IN SATA_SI3132_PORT *pSataPort,
> IN UINT16 PortMultiplierPort,
> @@ -216,7 +218,9 @@ EFI_STATUS SiI3132AtaPassThruCommand (
> /**
> * EFI ATA Pass Thru Protocol
> */
> -EFI_STATUS SiI3132AtaPassThru (
> +EFI_STATUS
> +EFIAPI
> +SiI3132AtaPassThru (
> IN EFI_ATA_PASS_THRU_PROTOCOL *This,
> IN UINT16 Port,
> IN UINT16 PortMultiplierPort,
> @@ -224,37 +228,49 @@ EFI_STATUS SiI3132AtaPassThru (
> IN EFI_EVENT Event OPTIONAL
> );
>
> -EFI_STATUS SiI3132GetNextPort (
> +EFI_STATUS
> +EFIAPI
> +SiI3132GetNextPort (
> IN EFI_ATA_PASS_THRU_PROTOCOL *This,
> IN OUT UINT16 *Port
> );
>
> -EFI_STATUS SiI3132GetNextDevice (
> +EFI_STATUS
> +EFIAPI
> +SiI3132GetNextDevice (
> IN EFI_ATA_PASS_THRU_PROTOCOL *This,
> IN UINT16 Port,
> IN OUT UINT16 *PortMultiplierPort
> );
>
> -EFI_STATUS SiI3132BuildDevicePath (
> +EFI_STATUS
> +EFIAPI
> +SiI3132BuildDevicePath (
> IN EFI_ATA_PASS_THRU_PROTOCOL *This,
> IN UINT16 Port,
> IN UINT16 PortMultiplierPort,
> IN OUT EFI_DEVICE_PATH_PROTOCOL **DevicePath
> );
>
> -EFI_STATUS SiI3132GetDevice (
> +EFI_STATUS
> +EFIAPI
> +SiI3132GetDevice (
> IN EFI_ATA_PASS_THRU_PROTOCOL *This,
> IN EFI_DEVICE_PATH_PROTOCOL *DevicePath,
> OUT UINT16 *Port,
> OUT UINT16 *PortMultiplierPort
> );
>
> -EFI_STATUS SiI3132ResetPort (
> +EFI_STATUS
> +EFIAPI
> +SiI3132ResetPort (
> IN EFI_ATA_PASS_THRU_PROTOCOL *This,
> IN UINT16 Port
> );
>
> -EFI_STATUS SiI3132ResetDevice (
> +EFI_STATUS
> +EFIAPI
> +SiI3132ResetDevice (
> IN EFI_ATA_PASS_THRU_PROTOCOL *This,
> IN UINT16 Port,
> IN UINT16 PortMultiplierPort
> diff --git a/EmbeddedPkg/GdbStub/GdbStubInternal.h b/EmbeddedPkg/GdbStub/GdbStubInternal.h
> index b8346d7a545f..b08159302cfa 100644
> --- a/EmbeddedPkg/GdbStub/GdbStubInternal.h
> +++ b/EmbeddedPkg/GdbStub/GdbStubInternal.h
> @@ -323,6 +323,7 @@ SendError (
> Send 'OK' when the function is done executing successfully.
> **/
> VOID
> +EFIAPI
> SendSuccess (
> VOID
> );
> @@ -332,6 +333,7 @@ SendSuccess (
> Send empty packet to specify that particular command/functionality is not supported.
> **/
> VOID
> +EFIAPI
> SendNotSupported (
> VOID
> );
> @@ -353,6 +355,7 @@ ReadNthRegister (
> @param SystemContext Register content at time of the exception
> **/
> VOID
> +EFIAPI
> ReadGeneralRegisters (
> IN EFI_SYSTEM_CONTEXT SystemContext
> );
> @@ -364,6 +367,7 @@ ReadGeneralRegisters (
> @param InBuffer This is the input buffer received from gdb server
> **/
> VOID
> +EFIAPI
> WriteNthRegister (
> IN EFI_SYSTEM_CONTEXT SystemContext,
> IN CHAR8 *InBuffer
> @@ -377,6 +381,7 @@ WriteNthRegister (
> **/
>
> VOID
> +EFIAPI
> WriteGeneralRegisters (
> IN EFI_SYSTEM_CONTEXT SystemContext,
> IN CHAR8 *InBuffer
> @@ -391,6 +396,7 @@ WriteGeneralRegisters (
> @param *PacketData Pointer to Payload data for the packet
> **/
> VOID
> +EFIAPI
> ReadFromMemory (
> IN CHAR8 *PacketData
> );
> @@ -404,6 +410,7 @@ ReadFromMemory (
> @param PacketData Pointer to Payload data for the packet
> **/
> VOID
> +EFIAPI
> WriteToMemory (
> IN CHAR8 *PacketData
> );
> @@ -418,6 +425,7 @@ WriteToMemory (
> **/
>
> VOID
> +EFIAPI
> ContinueAtAddress (
> IN EFI_SYSTEM_CONTEXT SystemContext,
> IN CHAR8 *PacketData
> @@ -432,6 +440,7 @@ ContinueAtAddress (
> @param PacketData Pointer to Payload data for the packet
> **/
> VOID
> +EFIAPI
> SingleStep (
> IN EFI_SYSTEM_CONTEXT SystemContext,
> IN CHAR8 *PacketData
> diff --git a/EmbeddedPkg/Drivers/ConsolePrefDxe/ConsolePrefDxe.c b/EmbeddedPkg/Drivers/ConsolePrefDxe/ConsolePrefDxe.c
> index c250844eda74..08bba1bbf111 100644
> --- a/EmbeddedPkg/Drivers/ConsolePrefDxe/ConsolePrefDxe.c
> +++ b/EmbeddedPkg/Drivers/ConsolePrefDxe/ConsolePrefDxe.c
> @@ -174,6 +174,7 @@ RemoveSpcrTable (
>
> STATIC
> VOID
> +EFIAPI
> OnReadyToBoot (
> IN EFI_EVENT Event,
> IN VOID *Context
> diff --git a/EmbeddedPkg/Drivers/Lan9118Dxe/Lan9118Dxe.c b/EmbeddedPkg/Drivers/Lan9118Dxe/Lan9118Dxe.c
> index a0fca4d6a335..2138f7576bec 100644
> --- a/EmbeddedPkg/Drivers/Lan9118Dxe/Lan9118Dxe.c
> +++ b/EmbeddedPkg/Drivers/Lan9118Dxe/Lan9118Dxe.c
> @@ -34,6 +34,7 @@ LAN9118_DEVICE_PATH Lan9118PathTemplate = {
> **
> */
> EFI_STATUS
> +EFIAPI
> Lan9118DxeEntry (
> IN EFI_HANDLE Handle,
> IN EFI_SYSTEM_TABLE *SystemTable
> diff --git a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c
> index f6a723adfb28..0e2905c1ebb0 100644
> --- a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c
> +++ b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c
> @@ -39,6 +39,7 @@ GetSataDevice (
> }
>
> EFI_STATUS
> +EFIAPI
> SiI3132AtaPassThruCommand (
> IN SATA_SI3132_INSTANCE *SataSiI3132Instance,
> IN SATA_SI3132_PORT *SataPort,
> @@ -310,6 +311,7 @@ SiI3132AtaPassThruCommand (
>
> **/
> EFI_STATUS
> +EFIAPI
> SiI3132AtaPassThru (
> IN EFI_ATA_PASS_THRU_PROTOCOL *This,
> IN UINT16 Port,
> @@ -371,6 +373,7 @@ SiI3132AtaPassThru (
>
> **/
> EFI_STATUS
> +EFIAPI
> SiI3132GetNextPort (
> IN EFI_ATA_PASS_THRU_PROTOCOL *This,
> IN OUT UINT16 *Port
> @@ -442,6 +445,7 @@ SiI3132GetNextPort (
>
> **/
> EFI_STATUS
> +EFIAPI
> SiI3132GetNextDevice (
> IN EFI_ATA_PASS_THRU_PROTOCOL *This,
> IN UINT16 Port,
> @@ -523,6 +527,7 @@ SiI3132GetNextDevice (
>
> **/
> EFI_STATUS
> +EFIAPI
> SiI3132BuildDevicePath (
> IN EFI_ATA_PASS_THRU_PROTOCOL *This,
> IN UINT16 Port,
> @@ -601,6 +606,7 @@ SiI3132BuildDevicePath (
> port number does not exist.
> **/
> EFI_STATUS
> +EFIAPI
> SiI3132GetDevice (
> IN EFI_ATA_PASS_THRU_PROTOCOL *This,
> IN EFI_DEVICE_PATH_PROTOCOL *DevicePath,
> @@ -717,6 +723,7 @@ SiI3132HwResetPort (
>
> **/
> EFI_STATUS
> +EFIAPI
> SiI3132ResetPort (
> IN EFI_ATA_PASS_THRU_PROTOCOL *This,
> IN UINT16 Port
> @@ -772,6 +779,7 @@ SiI3132ResetPort (
>
> **/
> EFI_STATUS
> +EFIAPI
> SiI3132ResetDevice (
> IN EFI_ATA_PASS_THRU_PROTOCOL *This,
> IN UINT16 Port,
> diff --git a/EmbeddedPkg/MetronomeDxe/Metronome.c b/EmbeddedPkg/MetronomeDxe/Metronome.c
> index 579332169507..13db25168fac 100644
> --- a/EmbeddedPkg/MetronomeDxe/Metronome.c
> +++ b/EmbeddedPkg/MetronomeDxe/Metronome.c
> @@ -110,6 +110,7 @@ EFI_HANDLE gMetronomeHandle = NULL;
>
> **/
> EFI_STATUS
> +EFIAPI
> MetronomeInitialize (
> IN EFI_HANDLE ImageHandle,
> IN EFI_SYSTEM_TABLE *SystemTable
> --
> 2.19.1.3.g30247aa5d201
>
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 01/35] DO NOT APPLY: edk2: turn standard handle types into pointers to non-VOID
2019-09-18 15:55 ` Andrew Fish
2019-09-18 16:16 ` Leif Lindholm
@ 2019-09-18 17:45 ` Laszlo Ersek
1 sibling, 0 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-18 17:45 UTC (permalink / raw)
To: Andrew Fish, devel
Cc: Ni, Ray, Achin Gupta, Anthony Perard, Ard Biesheuvel,
You, Benjamin, Zhang, Chao B, Bi, Dandan, David Woodhouse,
Dong, Eric, Dong, Guo, Wu, Hao A, Carsey, Jaben, Wang, Jian J,
Wu, Jiaxin, Yao, Jiewen, Jordan Justen, Julien Grall,
Leif Lindholm, Gao, Liming, Ma, Maurice, Mike Kinney, Fu, Siyuan,
Supreeth Venkatesh, Gao, Zhichao
On 09/18/19 17:55, Andrew Fish wrote:
>
>
>> On Sep 18, 2019, at 1:41 AM, Laszlo Ersek <lersek@redhat.com> wrote:
>>
>> On 09/17/19 22:22, Andrew Fish wrote:
>>>
>>>
>>>> On Sep 17, 2019, at 1:06 PM, Ni, Ray <ray.ni@intel.com> wrote:
>>>>
>>>> Laszlo,
>>>> Thank you very much for this work.
>>>> They are quite helpful to detect potential issues.
>>>>
>>>> But without this specific patch being checked in, future break will still happen.
>>>> I don't want it to be checked in ASAP because I know that there are quite a lot of close source code that may get build break due to this change.
>>>> Besides that, what prevent you make the decision to check in the changes?
>>>>
>>>
>>> Ray,
>>>
>>> I was thinking the same thing. Could we make this an optional feature via a #define? We could always default to the Spec Behavior, and new projects could opt into the stricter version.
>>>
>>> #ifndef STRICTER_UEFI_TYPES
>>> typedef VOID *EFI_PEI_FV_HANDLE;
>>> #else
>>> struct EFI_PEI_FV_OBJECT;
>>> typedef struct EFI_PEI_FV_OBJECT *EFI_PEI_FV_HANDLE;
>>> #endif
>>
>> Technically, this would work well.
>>
>> However, if we wanted to allow new projects to #define
>> STRICTER_UEFI_TYPES as their normal mode of operation (and not just for
>> a sanity check in CI), then we'd have to update the UEFI spec too.
>>
>> Otherwise, code that is technically spec-conformant (albeit semantically
>> nonsensical), like I mentioned up-thread, would no longer compile:
>>
>
> Laszlo,
>
> I think helping people NOT write nonsensical code is good. It is very good idea and I'd like to add it to the spec but as you point out it would break a lot of existing code so I'm not sure it is possible. I guess we could try to add a strict mode to the spec but given the types are defined in tables that may be problematic.
>
> We have coding standards that are more strict than what the C spec allows. So I would see the STRICT_UEFI_TYPES as more of a enforce the coding standard kind of thing?
Hmmm, okay. That makes sense. The macro could be advertised as, "this
will give your project / platform some extra safety, but it will place
coding style requirements on your project / platform that go beyond, and
sometimes conflict (in case of semantically bogus code), with the UEFI
spec".
Thanks
Laszlo
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs
2019-09-17 19:49 [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs Laszlo Ersek
` (34 preceding siblings ...)
2019-09-17 19:49 ` [PATCH 35/35] UefiPayloadPkg/BlSupportDxe: fix ReserveResourceInGcd() calls Laszlo Ersek
@ 2019-09-19 0:32 ` Wu, Hao A
2019-09-23 16:27 ` Marvin Häuser
2019-10-08 23:49 ` Laszlo Ersek
37 siblings, 0 replies; 155+ messages in thread
From: Wu, Hao A @ 2019-09-19 0:32 UTC (permalink / raw)
To: edk2-devel-groups-io, 'lersek@redhat.com'
Cc: Achin Gupta, Andrew Fish, Anthony Perard, Ard Biesheuvel,
You, Benjamin, Zhang, Chao B, Bi, Dandan, David Woodhouse,
Dong, Eric, Dong, Guo, Carsey, Jaben, Wang, Jian J, Wu, Jiaxin,
Yao, Jiewen, Justen, Jordan L, Julien Grall, Leif Lindholm,
Gao, Liming, Ma, Maurice, Kinney, Michael D, Ni, Ray, Fu, Siyuan,
Supreeth Venkatesh, Gao, Zhichao
> -----Original Message-----
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Laszlo Ersek
> Sent: Wednesday, September 18, 2019 3:49 AM
> To: edk2-devel-groups-io
> Cc: Achin Gupta; Andrew Fish; Anthony Perard; Ard Biesheuvel; You,
> Benjamin; Zhang, Chao B; Bi, Dandan; David Woodhouse; Dong, Eric; Dong,
> Guo; Wu, Hao A; Carsey, Jaben; Wang, Jian J; Wu, Jiaxin; Yao, Jiewen; Justen,
> Jordan L; Julien Grall; Leif Lindholm; Gao, Liming; Ma, Maurice; Kinney,
> Michael D; Ni, Ray; Fu, Siyuan; Supreeth Venkatesh; Gao, Zhichao
> Subject: [edk2-devel] [PATCH 00/35] edk2: clean up the usage of
> standardized (VOID*) typedefs
>
> Repository: https://github.com/lersek/edk2.git
> Branch: voidptr
>
> The UEFI / PI / Shell specifications define a number of standard types
> as pointers to VOID. This is arguably a design mistake; those types
> should have been pointers to distinct incomplete union or structure
> types. Here's why:
>
> Roughly paraphrasing the constraints from ISO C99 "6.5.16.1 Simple
> assignment" and "6.5.4 Cast operators", any pointer-to-object type
> converts implicitly to, and from, pointer-to-void, provided const /
> volatile qualifications are not relaxed. Such implicit conversions
> prevent compilers from catching at least the following two kinds of
> coding mistakes:
>
> - mixing up one type with another (for example, EFI_HANDLE with
> EFI_EVENT),
>
> - getting the depth of indirection wrong (for example, mixing up
> (EFI_HANDLE*) with EFI_HANDLE).
>
> This series first separates these standard types from each other, in the
> first patch, which is *not* being proposed for merging. This unmasks a
> number of warts (semantic issues, or actual bugs) in the source code, in
> the form of build breakages. The rest of the series works through those
> breakages, cleaning and fixing the code.
>
> Every DSC file in the edk2 tree was built for at least one of the NOOPT,
> DEBUG, RELEASE targets (NOOPT being preferred), with the GCC48 toolchain
> (for IA32 / X64) and the GCC5 toolchain (for ARM / AARCH64). Of course,
> the build arches were restricted to the SUPPORTED_ARCHITECTURES stated
> in the individual DSC files.
>
> There were two exceptions to the above rule: DynamicTablesPkg was only
> build-tested with AARCH64 (despite its SUPPORTED_ARCHITECTURES), given
> that 32-bit ARM has no ACPI bindings. StandaloneMmPkg too was only
> build-tested with AARCH64; it doesn't actually support IA32/X64 yet.
>
> Regarding boot & runtime tests, ArmVirtQemu on AARCH64 was tested with
> booting to the OS (RHEL7). Furthermore, I exercised OVMF with my usual
> boot and S3 tests, covering IA32, IA32X64, and X64. Finally, some other
> individual tests (noted per patch) were done with OVMF.
>
> Cc: Achin Gupta <achin.gupta@arm.com>
> Cc: Andrew Fish <afish@apple.com>
> Cc: Anthony Perard <anthony.perard@citrix.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Benjamin You <benjamin.you@intel.com>
> Cc: Chao Zhang <chao.b.zhang@intel.com>
> Cc: Dandan Bi <dandan.bi@intel.com>
> Cc: David Woodhouse <dwmw2@infradead.org>
> Cc: Eric Dong <eric.dong@intel.com>
> Cc: Guo Dong <guo.dong@intel.com>
> Cc: Hao A Wu <hao.a.wu@intel.com>
> Cc: Jaben Carsey <jaben.carsey@intel.com>
> Cc: Jian J Wang <jian.j.wang@intel.com>
> Cc: Jian Wang <jian.j.wang@intel.com>
> Cc: Jiaxin Wu <jiaxin.wu@intel.com>
> Cc: Jiewen Yao <jiewen.yao@intel.com>
> Cc: Jordan Justen <jordan.l.justen@intel.com>
> Cc: Julien Grall <julien.grall@arm.com>
> Cc: Leif Lindholm <leif.lindholm@linaro.org>
> Cc: Liming Gao <liming.gao@intel.com>
> Cc: Maurice Ma <maurice.ma@intel.com>
> Cc: Michael D Kinney <michael.d.kinney@intel.com>
> Cc: Ray Ni <ray.ni@intel.com>
> Cc: Siyuan Fu <siyuan.fu@intel.com>
> Cc: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
> Cc: Zhichao Gao <zhichao.gao@intel.com>
>
> Thanks
> Laszlo
>
> Laszlo Ersek (35):
> DO NOT APPLY: edk2: turn standard handle types into pointers to
> non-VOID
> EmbeddedPkg: add missing EFIAPI calling convention specifiers
> EmbeddedPkg/AndroidFastbootTransportTcpDxe: fix DestroyChild() call
> EmbeddedPkg/Universal/MmcDxe: "fix" CloseProtocol() call in
> BindingStop()
> EmulatorPkg/DxeTimerLib: drop superfluous cast
> EmulatorPkg: stop abusing EFI_HANDLE for keystroke notify registration
> MdeModulePkg: fix cast in GetModuleInfoFromHandle() calls
> MdeModulePkg/UefiHiiLib: stop using EFI_HANDLE in place of
> EFI_HII_HANDLE
> MdeModulePkg: stop abusing EFI_EVENT for protocol notify registration
> MdeModulePkg/PlatformVarCleanupLib: fix HiiConstructConfigHdr() call
> MdeModulePkg: document workaround for EFI_RUNTIME_EVENT_ENTRY PI
> spec
> bug
> MdeModulePkg: stop abusing EFI_HANDLE for keystroke notify
> registration
> MdeModulePkg: PEI Core: clean up "AprioriFile" handling in
> FindFileEx()
> MdeModulePkg: fix UninstallMultipleProtocolInterfaces() calls
> MdeModulePkg/PiSmmCore: make type punning consistent
> MdeModulePkg/S3SaveState: cast Position for S3BootScriptLib explicitly
For the patches made to MdeModulePkg (patch 7~16),
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Best Regards,
Hao Wu
> MdePkg/DxeServicesLib: remove bogus cast
> NetworkPkg/DxeNetLib: fix type typo in NetLibGetMacAddress()
> NetworkPkg: fix CloseProtocol & UninstallMultipleProtocolInterfaces
> calls
> NetworkPkg/Ip4Dxe: fix NetLibDestroyServiceChild() call
> NetworkPkg/TcpDxe: fix SockFreeFoo() parameter list
> OvmfPkg/XenBusDxe: fix UninstallMultipleProtocolInterfaces() call
> OvmfPkg/VirtioNetDxe: fix SignalEvent() call
> OvmfPkg/PlatformDxe: fix EFI_HII_HANDLE parameters of internal
> functions
> OvmfPkg/VideoDxe: document EFI_EDID_OVERRIDE_PROTOCOL.GetEdid()
> call
> SecurityPkg: fix UninstallMultipleProtocolInterfaces() calls
> SecurityPkg: stop abusing EFI_EVENT for protocol notify registration
> ShellPkg/UefiShellDriver1CommandsLib: fix parameter list typo
> ShellPkg: stop using EFI_HANDLE in place of EFI_HII_HANDLE
> ShellPkg: stop taking EFI_HANDLE in place of SHELL_FILE_HANDLE
> ShellPkg/UefiShellDebug1CommandsLib: fix ShellCloseFile() call
> ShellPkg/UefiShellLib: clarify workaround for unfixable EdkShell bug
> StandaloneMmPkg/Core: stop abusing EFI_HANDLE for FwVolHeader
> tracking
> UefiPayloadPkg/BlSupportPei: fix MMCONFIG assignment from XSDT
> UefiPayloadPkg/BlSupportDxe: fix ReserveResourceInGcd() calls
>
>
> EmbeddedPkg/Drivers/AndroidFastbootTransportTcpDxe/FastbootTranspor
> tTcp.c | 2 +-
> EmbeddedPkg/Drivers/ConsolePrefDxe/ConsolePrefDxe.c | 1
> +
> EmbeddedPkg/Drivers/Lan9118Dxe/Lan9118Dxe.c | 1 +
> EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.h | 32
> ++++++--
> EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c | 8
> ++
> EmbeddedPkg/GdbStub/GdbStubInternal.h | 9 +++
> EmbeddedPkg/MetronomeDxe/Metronome.c | 1 +
> EmbeddedPkg/Universal/MmcDxe/Mmc.c | 5 +-
> EmulatorPkg/EmuGopDxe/GopInput.c | 4 +-
> EmulatorPkg/Library/DxeTimerLib/DxeTimerLib.c | 2 +-
> MdeModulePkg/Bus/I2c/I2cDxe/I2cBus.c | 2 +-
> MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c | 2
> +-
> MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c | 6
> +-
> MdeModulePkg/Bus/Pci/PciSioSerialDxe/Serial.c | 2 +-
> MdeModulePkg/Bus/Sd/EmmcDxe/EmmcDxe.c | 2 +-
> MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c | 2 +-
> MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassImpl.c
> | 2 +-
> MdeModulePkg/Core/Dxe/Event/Event.c | 8 ++
> MdeModulePkg/Core/Dxe/Event/Event.h | 2 +-
> MdeModulePkg/Core/Dxe/Hand/Handle.h | 2 +-
> MdeModulePkg/Core/Pei/FwVol/FwVol.c | 2 +-
> MdeModulePkg/Core/Pei/FwVol/FwVol.h | 2 +-
> MdeModulePkg/Core/PiSmmCore/PiSmmCore.h | 2 +-
> MdeModulePkg/Core/PiSmmCore/Smi.c | 8 +-
> MdeModulePkg/Core/RuntimeDxe/Runtime.c | 10 ++-
>
> MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c
> | 12 +--
> MdeModulePkg/Library/PlatformVarCleanupLib/PlatVarCleanupLib.c
> | 6 +-
>
> MdeModulePkg/Library/SmmCorePerformanceLib/SmmCorePerformanceLi
> b.c | 8 +-
> MdeModulePkg/Library/UefiHiiLib/HiiString.c | 4 +-
> MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h | 2
> +-
> MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c |
> 4 +-
> MdeModulePkg/Universal/Acpi/SmmS3SaveState/SmmS3SaveState.c
> | 4 +-
> MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c
> | 2 +-
> MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c |
> 4 +-
>
> MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c
> | 2 +-
>
> MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.
> c | 2 +-
> MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabase.h | 2
> +-
> MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.c | 2
> +-
> MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
> | 2 +-
> MdePkg/Include/Pi/PiPeiCis.h | 6 +-
> MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h | 3
> +-
> MdePkg/Include/Protocol/Bis.h | 3 +-
> MdePkg/Include/Protocol/Eap.h | 3 +-
> MdePkg/Include/Protocol/HiiFont.h | 3 +-
> MdePkg/Include/Protocol/MmMp.h | 3 +-
> MdePkg/Include/Protocol/S3SaveState.h | 2 +-
> MdePkg/Include/Protocol/Shell.h | 3 +-
> MdePkg/Include/Protocol/UserManager.h | 9 ++-
> MdePkg/Include/Uefi/UefiBaseType.h | 6 +-
> MdePkg/Include/Uefi/UefiInternalFormRepresentation.h | 3
> +-
> MdePkg/Library/DxeServicesLib/DxeServicesLib.c | 2 +-
> NetworkPkg/DnsDxe/DnsDriver.c | 4 +-
> NetworkPkg/IScsiDxe/IScsiConfig.c | 2 +-
> NetworkPkg/Ip4Dxe/Ip4Driver.c | 2 +-
> NetworkPkg/Ip4Dxe/Ip4If.c | 4 +-
> NetworkPkg/Ip6Dxe/Ip6Driver.c | 2 +-
> NetworkPkg/Library/DxeNetLib/DxeNetLib.c | 2 +-
> NetworkPkg/Mtftp4Dxe/Mtftp4Driver.c | 2 +-
> NetworkPkg/TcpDxe/SockImpl.c | 4 +-
> NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.c | 2 +-
> OvmfPkg/Csm/BiosThunk/VideoDxe/BiosVideo.c | 6 +-
> OvmfPkg/PlatformDxe/Platform.c | 4 +-
> OvmfPkg/VirtioNetDxe/Events.c | 2 +-
> OvmfPkg/XenBusDxe/XenBus.c | 2 +-
> SecurityPkg/HddPassword/HddPasswordDxe.c | 2 +-
> SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c | 2 +-
> SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c | 2 +-
>
> SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfi
> gDriver.c | 2 +-
> ShellPkg/DynamicCommand/DpDynamicCommand/Dp.c |
> 6 +-
> ShellPkg/DynamicCommand/DpDynamicCommand/Dp.h |
> 4 +-
> ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c |
> 6 +-
> ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.h |
> 4 +-
> ShellPkg/Include/Library/ShellCommandLib.h | 2 +-
> ShellPkg/Include/Library/ShellLib.h | 4 +-
> ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c | 2
> +-
> ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
> | 2 +-
> ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c
> | 2 +-
> ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.h
> | 2 +-
> ShellPkg/Library/UefiShellDebug1CommandsLib/Edit/FileBuffer.c |
> 2 +-
>
> ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1Comman
> dsLib.c | 2 +-
>
> ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1Comman
> dsLib.h | 2 +-
> ShellPkg/Library/UefiShellDriver1CommandsLib/Connect.c | 4
> +-
>
> ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1Command
> sLib.c | 2 +-
>
> ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1Command
> sLib.h | 2 +-
>
> ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsL
> ib.c | 2 +-
>
> ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsL
> ib.h | 2 +-
> ShellPkg/Library/UefiShellLevel2CommandsLib/Rm.c | 2 +-
>
> ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsL
> ib.c | 2 +-
>
> ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsL
> ib.h | 2 +-
> ShellPkg/Library/UefiShellLevel3CommandsLib/Touch.c | 2 +-
>
> ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsL
> ib.c | 2 +-
>
> ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsL
> ib.h | 2 +-
> ShellPkg/Library/UefiShellLib/UefiShellLib.c | 26 ++++++-
>
> ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1Com
> mandsLib.c | 2 +-
>
> ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1Com
> mandsLib.h | 2 +-
>
> ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2Com
> mandsLib.c | 2 +-
>
> ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2Com
> mandsLib.h | 2 +-
> StandaloneMmPkg/Core/Dispatcher.c | 80
> +++++++++++---------
> StandaloneMmPkg/Core/FwVol.c | 16 ++--
> StandaloneMmPkg/Core/StandaloneMmCore.h | 4 +-
> UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c | 4 +-
> UefiPayloadPkg/BlSupportPei/BlSupportPei.c | 19 +++--
> 102 files changed, 294 insertions(+), 194 deletions(-)
>
> --
> 2.19.1.3.g30247aa5d201
>
>
> -=-=-=-=-=-=
> Groups.io Links: You receive all messages sent to this group.
>
> View/Reply Online (#47387):
> https://edk2.groups.io/g/devel/message/47387
> Mute This Topic: https://groups.io/mt/34180197/1768737
> Group Owner: devel+owner@edk2.groups.io
> Unsubscribe: https://edk2.groups.io/g/devel/unsub [hao.a.wu@intel.com]
> -=-=-=-=-=-=
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 08/35] MdeModulePkg/UefiHiiLib: stop using EFI_HANDLE in place of EFI_HII_HANDLE
2019-09-17 19:49 ` [PATCH 08/35] MdeModulePkg/UefiHiiLib: stop using EFI_HANDLE in place of EFI_HII_HANDLE Laszlo Ersek
@ 2019-09-19 1:46 ` Dandan Bi
2019-09-24 10:49 ` [edk2-devel] " Philippe Mathieu-Daudé
1 sibling, 0 replies; 155+ messages in thread
From: Dandan Bi @ 2019-09-19 1:46 UTC (permalink / raw)
To: Laszlo Ersek, edk2-devel-groups-io; +Cc: Dong, Eric, Wu, Hao A, Wang, Jian J
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Thanks,
Dandan
> -----Original Message-----
> From: Laszlo Ersek [mailto:lersek@redhat.com]
> Sent: Wednesday, September 18, 2019 3:49 AM
> To: edk2-devel-groups-io <devel@edk2.groups.io>
> Cc: Bi, Dandan <dandan.bi@intel.com>; Dong, Eric <eric.dong@intel.com>;
> Wu, Hao A <hao.a.wu@intel.com>; Wang, Jian J <jian.j.wang@intel.com>
> Subject: [PATCH 08/35] MdeModulePkg/UefiHiiLib: stop using EFI_HANDLE in
> place of EFI_HII_HANDLE
>
> HiiGetHiiHandles() returns an array of EFI_HII_HANDLEs, not EFI_HANDLEs.
> HiiGetString() takes an EFI_HII_HANDLE, not an EFI_HANDLE.
>
> This change is a no-op in practice; it's a semantic improvement.
>
> Cc: Dandan Bi <dandan.bi@intel.com>
> Cc: Eric Dong <eric.dong@intel.com>
> Cc: Hao A Wu <hao.a.wu@intel.com>
> Cc: Jian J Wang <jian.j.wang@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> lightly tested, as UefiHiiLib is used by both ArmVirt and OVMF
>
> MdeModulePkg/Library/UefiHiiLib/HiiString.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/MdeModulePkg/Library/UefiHiiLib/HiiString.c
> b/MdeModulePkg/Library/UefiHiiLib/HiiString.c
> index 498f245dce1f..95229f8a8c9f 100644
> --- a/MdeModulePkg/Library/UefiHiiLib/HiiString.c
> +++ b/MdeModulePkg/Library/UefiHiiLib/HiiString.c
> @@ -173,8 +173,8 @@ HiiGetPackageString (
> IN CONST CHAR8 *Language OPTIONAL
> )
> {
> - EFI_HANDLE *HiiHandleBuffer;
> - EFI_HANDLE HiiHandle;
> + EFI_HII_HANDLE *HiiHandleBuffer;
> + EFI_HII_HANDLE HiiHandle;
>
> ASSERT (PackageListGuid != NULL);
>
> --
> 2.19.1.3.g30247aa5d201
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 13/35] MdeModulePkg: PEI Core: clean up "AprioriFile" handling in FindFileEx()
2019-09-17 19:49 ` [PATCH 13/35] MdeModulePkg: PEI Core: clean up "AprioriFile" handling in FindFileEx() Laszlo Ersek
@ 2019-09-19 1:46 ` Dandan Bi
2019-09-24 15:40 ` [edk2-devel] " Philippe Mathieu-Daudé
1 sibling, 0 replies; 155+ messages in thread
From: Dandan Bi @ 2019-09-19 1:46 UTC (permalink / raw)
To: Laszlo Ersek, edk2-devel-groups-io; +Cc: Wu, Hao A, Wang, Jian J, Gao, Liming
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Thanks,
Dandan
> -----Original Message-----
> From: Laszlo Ersek [mailto:lersek@redhat.com]
> Sent: Wednesday, September 18, 2019 3:49 AM
> To: edk2-devel-groups-io <devel@edk2.groups.io>
> Cc: Bi, Dandan <dandan.bi@intel.com>; Wu, Hao A <hao.a.wu@intel.com>;
> Wang, Jian J <jian.j.wang@intel.com>; Gao, Liming <liming.gao@intel.com>
> Subject: [PATCH 13/35] MdeModulePkg: PEI Core: clean up "AprioriFile"
> handling in FindFileEx()
>
> Clean up two issues around FindFileEx():
>
> - The "AprioriFile" parameter's type differs between the function
> declaration and the function definition. The correct type is
> (EFI_PEI_FILE_HANDLE*).
>
> - "FfsFileHeader" has type (EFI_FFS_FILE_HEADER*); for clarity, we should
> cast it explicitly to EFI_PEI_FILE_HANDLE when assigning it to
> (*AprioriFile).
>
> This is a semantic cleanup, there is no functional change.
>
> Cc: Dandan Bi <dandan.bi@intel.com>
> Cc: Hao A Wu <hao.a.wu@intel.com>
> Cc: Jian J Wang <jian.j.wang@intel.com>
> Cc: Liming Gao <liming.gao@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> lightly tested: OVMF uses APRIORI PEI in the FDF files
>
> MdeModulePkg/Core/Pei/FwVol/FwVol.h | 2 +-
> MdeModulePkg/Core/Pei/FwVol/FwVol.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/MdeModulePkg/Core/Pei/FwVol/FwVol.h
> b/MdeModulePkg/Core/Pei/FwVol/FwVol.h
> index 4082cfbec1f8..ca80e84e0fcb 100644
> --- a/MdeModulePkg/Core/Pei/FwVol/FwVol.h
> +++ b/MdeModulePkg/Core/Pei/FwVol/FwVol.h
> @@ -299,7 +299,7 @@ FindFileEx (
> IN CONST EFI_GUID *FileName, OPTIONAL
> IN EFI_FV_FILETYPE SearchType,
> IN OUT EFI_PEI_FILE_HANDLE *FileHandle,
> - IN OUT EFI_PEI_FV_HANDLE *AprioriFile OPTIONAL
> + IN OUT EFI_PEI_FILE_HANDLE *AprioriFile OPTIONAL
> );
>
> /**
> diff --git a/MdeModulePkg/Core/Pei/FwVol/FwVol.c
> b/MdeModulePkg/Core/Pei/FwVol/FwVol.c
> index 709db00694c2..f4642c47c13a 100644
> --- a/MdeModulePkg/Core/Pei/FwVol/FwVol.c
> +++ b/MdeModulePkg/Core/Pei/FwVol/FwVol.c
> @@ -407,7 +407,7 @@ FindFileEx (
> } else if (AprioriFile != NULL) {
> if (FfsFileHeader->Type == EFI_FV_FILETYPE_FREEFORM) {
> if (CompareGuid (&FfsFileHeader->Name, &gPeiAprioriFileNameGuid))
> {
> - *AprioriFile = FfsFileHeader;
> + *AprioriFile = (EFI_PEI_FILE_HANDLE)FfsFileHeader;
> }
> }
> }
> --
> 2.19.1.3.g30247aa5d201
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 07/35] MdeModulePkg: fix cast in GetModuleInfoFromHandle() calls
2019-09-17 19:49 ` [PATCH 07/35] MdeModulePkg: fix cast in GetModuleInfoFromHandle() calls Laszlo Ersek
@ 2019-09-19 1:46 ` Dandan Bi
2019-09-24 10:43 ` [edk2-devel] " Philippe Mathieu-Daudé
1 sibling, 0 replies; 155+ messages in thread
From: Dandan Bi @ 2019-09-19 1:46 UTC (permalink / raw)
To: Laszlo Ersek, edk2-devel-groups-io
Cc: Dong, Eric, Wu, Hao A, Wang, Jian J, Gao, Liming, Ni, Ray
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Thanks,
Dandan
> -----Original Message-----
> From: Laszlo Ersek [mailto:lersek@redhat.com]
> Sent: Wednesday, September 18, 2019 3:49 AM
> To: edk2-devel-groups-io <devel@edk2.groups.io>
> Cc: Bi, Dandan <dandan.bi@intel.com>; Dong, Eric <eric.dong@intel.com>;
> Wu, Hao A <hao.a.wu@intel.com>; Wang, Jian J <jian.j.wang@intel.com>;
> Gao, Liming <liming.gao@intel.com>; Ni, Ray <ray.ni@intel.com>
> Subject: [PATCH 07/35] MdeModulePkg: fix cast in
> GetModuleInfoFromHandle() calls
>
> GetModuleInfoFromHandle() takes an EFI_HANDLE -- (VOID*) -- as first
> parameter, but InsertFpdtRecord() passes (EFI_HANDLE*) -- (VOID**).
> (VOID**) converts silently to (VOID*), which is why the wrong cast is masked.
>
> Note that the *value* that is passed is alright -- therefore this patch does not
> change behavior --, it's just semantically wrong to pass an
> (EFI_HANDLE*) where an EFI_HANDLE is expected.
>
> Cc: Dandan Bi <dandan.bi@intel.com>
> Cc: Eric Dong <eric.dong@intel.com>
> Cc: Hao A Wu <hao.a.wu@intel.com>
> Cc: Jian J Wang <jian.j.wang@intel.com>
> Cc: Liming Gao <liming.gao@intel.com>
> Cc: Ray Ni <ray.ni@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> lightly tested, as DxeCorePerformanceLib is linked into ArmVirtQemu's
> DxeCore
>
>
> MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c
> | 12 ++++++------
> MdeModulePkg/Library/SmmCorePerformanceLib/SmmCorePerformanceLi
> b.c | 8 ++++----
> 2 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git
> a/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLi
> b.c
> b/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLi
> b.c
> index 0d507c445210..f500e20b320b 100644
> ---
> a/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLi
> b.c
> +++
> b/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLi
> b.c
> @@ -998,7 +998,7 @@ InsertFpdtRecord (
> switch (PerfId) {
> case MODULE_START_ID:
> case MODULE_END_ID:
> - GetModuleInfoFromHandle ((EFI_HANDLE *)CallerIdentifier,
> ModuleName, sizeof (ModuleName), &ModuleGuid);
> + GetModuleInfoFromHandle ((EFI_HANDLE)CallerIdentifier, ModuleName,
> + sizeof (ModuleName), &ModuleGuid);
> StringPtr = ModuleName;
> //
> // Cache the offset of start image start record and use to update the start
> image end record if needed.
> @@ -1031,7 +1031,7 @@ InsertFpdtRecord (
>
> case MODULE_LOADIMAGE_START_ID:
> case MODULE_LOADIMAGE_END_ID:
> - GetModuleInfoFromHandle ((EFI_HANDLE *)CallerIdentifier,
> ModuleName, sizeof (ModuleName), &ModuleGuid);
> + GetModuleInfoFromHandle ((EFI_HANDLE)CallerIdentifier, ModuleName,
> + sizeof (ModuleName), &ModuleGuid);
> StringPtr = ModuleName;
> if (PerfId == MODULE_LOADIMAGE_START_ID) {
> mLoadImageCount ++;
> @@ -1071,7 +1071,7 @@ InsertFpdtRecord (
> case MODULE_DB_SUPPORT_END_ID:
> case MODULE_DB_STOP_START_ID:
> case MODULE_DB_STOP_END_ID:
> - GetModuleInfoFromHandle ((EFI_HANDLE *)CallerIdentifier,
> ModuleName, sizeof (ModuleName), &ModuleGuid);
> + GetModuleInfoFromHandle ((EFI_HANDLE)CallerIdentifier, ModuleName,
> + sizeof (ModuleName), &ModuleGuid);
> StringPtr = ModuleName;
> if (!PcdGetBool (PcdEdkiiFpdtStringRecordEnableOnly)) {
> FpdtRecordPtr.GuidQwordEvent->Header.Type =
> FPDT_GUID_QWORD_EVENT_TYPE;
> @@ -1085,7 +1085,7 @@ InsertFpdtRecord (
> break;
>
> case MODULE_DB_END_ID:
> - GetModuleInfoFromHandle ((EFI_HANDLE *)CallerIdentifier,
> ModuleName, sizeof (ModuleName), &ModuleGuid);
> + GetModuleInfoFromHandle ((EFI_HANDLE)CallerIdentifier, ModuleName,
> + sizeof (ModuleName), &ModuleGuid);
> StringPtr = ModuleName;
> if (!PcdGetBool (PcdEdkiiFpdtStringRecordEnableOnly)) {
> FpdtRecordPtr.GuidQwordStringEvent->Header.Type =
> FPDT_GUID_QWORD_STRING_EVENT_TYPE;
> @@ -1131,7 +1131,7 @@ InsertFpdtRecord (
> case PERF_INMODULE_END_ID:
> case PERF_CROSSMODULE_START_ID:
> case PERF_CROSSMODULE_END_ID:
> - GetModuleInfoFromHandle ((EFI_HANDLE *)CallerIdentifier,
> ModuleName, sizeof (ModuleName), &ModuleGuid);
> + GetModuleInfoFromHandle ((EFI_HANDLE)CallerIdentifier, ModuleName,
> + sizeof (ModuleName), &ModuleGuid);
> if (String != NULL) {
> StringPtr = String;
> } else {
> @@ -1153,7 +1153,7 @@ InsertFpdtRecord (
>
> default:
> if (Attribute != PerfEntry) {
> - GetModuleInfoFromHandle ((EFI_HANDLE *)CallerIdentifier,
> ModuleName, sizeof (ModuleName), &ModuleGuid);
> + GetModuleInfoFromHandle ((EFI_HANDLE)CallerIdentifier,
> + ModuleName, sizeof (ModuleName), &ModuleGuid);
> if (String != NULL) {
> StringPtr = String;
> } else {
> diff --git
> a/MdeModulePkg/Library/SmmCorePerformanceLib/SmmCorePerformance
> Lib.c
> b/MdeModulePkg/Library/SmmCorePerformanceLib/SmmCorePerformance
> Lib.c
> index 5f07464c4ec7..b4f22c14ae73 100644
> ---
> a/MdeModulePkg/Library/SmmCorePerformanceLib/SmmCorePerformance
> Lib.c
> +++
> b/MdeModulePkg/Library/SmmCorePerformanceLib/SmmCorePerformance
> Lib.c
> @@ -587,7 +587,7 @@ InsertFpdtRecord (
> switch (PerfId) {
> case MODULE_START_ID:
> case MODULE_END_ID:
> - GetModuleInfoFromHandle ((EFI_HANDLE *)CallerIdentifier,
> ModuleName, sizeof (ModuleName), &ModuleGuid);
> + GetModuleInfoFromHandle ((EFI_HANDLE)CallerIdentifier, ModuleName,
> + sizeof (ModuleName), &ModuleGuid);
> StringPtr = ModuleName;
> //
> // Cache the offset of start image start record and use to update the start
> image end record if needed.
> @@ -612,7 +612,7 @@ InsertFpdtRecord (
>
> case MODULE_LOADIMAGE_START_ID:
> case MODULE_LOADIMAGE_END_ID:
> - GetModuleInfoFromHandle ((EFI_HANDLE *)CallerIdentifier,
> ModuleName, sizeof (ModuleName), &ModuleGuid);
> + GetModuleInfoFromHandle ((EFI_HANDLE)CallerIdentifier, ModuleName,
> + sizeof (ModuleName), &ModuleGuid);
> StringPtr = ModuleName;
> if (PerfId == MODULE_LOADIMAGE_START_ID) {
> mLoadImageCount++;
> @@ -669,7 +669,7 @@ InsertFpdtRecord (
> case PERF_INMODULE_END_ID:
> case PERF_CROSSMODULE_START_ID:
> case PERF_CROSSMODULE_END_ID:
> - GetModuleInfoFromHandle ((EFI_HANDLE *)CallerIdentifier,
> ModuleName, sizeof (ModuleName), &ModuleGuid);
> + GetModuleInfoFromHandle ((EFI_HANDLE)CallerIdentifier, ModuleName,
> + sizeof (ModuleName), &ModuleGuid);
> if (String != NULL) {
> StringPtr = String;
> } else {
> @@ -691,7 +691,7 @@ InsertFpdtRecord (
>
> default:
> if (Attribute != PerfEntry) {
> - GetModuleInfoFromHandle ((EFI_HANDLE *)CallerIdentifier,
> ModuleName, sizeof (ModuleName), &ModuleGuid);
> + GetModuleInfoFromHandle ((EFI_HANDLE)CallerIdentifier,
> + ModuleName, sizeof (ModuleName), &ModuleGuid);
> if (String != NULL) {
> StringPtr = String;
> } else {
> --
> 2.19.1.3.g30247aa5d201
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 12/35] MdeModulePkg: stop abusing EFI_HANDLE for keystroke notify registration
2019-09-17 19:49 ` [PATCH 12/35] MdeModulePkg: stop abusing EFI_HANDLE for keystroke notify registration Laszlo Ersek
2019-09-17 20:16 ` [edk2-devel] " Ni, Ray
@ 2019-09-19 1:47 ` Dandan Bi
2019-09-24 10:54 ` [edk2-devel] " Philippe Mathieu-Daudé
2 siblings, 0 replies; 155+ messages in thread
From: Dandan Bi @ 2019-09-19 1:47 UTC (permalink / raw)
To: Laszlo Ersek, edk2-devel-groups-io
Cc: Dong, Eric, Wu, Hao A, Wang, Jian J, Ni, Ray, Gao, Zhichao
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Thanks,
Dandan
> -----Original Message-----
> From: Laszlo Ersek [mailto:lersek@redhat.com]
> Sent: Wednesday, September 18, 2019 3:49 AM
> To: edk2-devel-groups-io <devel@edk2.groups.io>
> Cc: Bi, Dandan <dandan.bi@intel.com>; Dong, Eric <eric.dong@intel.com>;
> Wu, Hao A <hao.a.wu@intel.com>; Wang, Jian J <jian.j.wang@intel.com>; Ni,
> Ray <ray.ni@intel.com>; Gao, Zhichao <zhichao.gao@intel.com>
> Subject: [PATCH 12/35] MdeModulePkg: stop abusing EFI_HANDLE for
> keystroke notify registration
>
> EFI_REGISTER_KEYSTROKE_NOTIFY and
> EFI_UNREGISTER_KEYSTROKE_NOTIFY require the notification handle to
> have type (VOID*). The notification handle has nothing to do with the
> EFI_HANDLE type.
>
> This change is a semantic fix; functionally, it's a no-op.
>
> Cc: Dandan Bi <dandan.bi@intel.com>
> Cc: Eric Dong <eric.dong@intel.com>
> Cc: Hao A Wu <hao.a.wu@intel.com>
> Cc: Jian J Wang <jian.j.wang@intel.com>
> Cc: Ray Ni <ray.ni@intel.com>
> Cc: Zhichao Gao <zhichao.gao@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> lightly tested: ConSplitterDxe is part of the ArmVirt and OVMF platforms
>
> MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c | 2 +-
> MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c
> b/MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c
> index 63c814ae1816..9c38271b65f9 100644
> --- a/MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c
> +++ b/MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c
> @@ -4026,7 +4026,7 @@ ConSplitterTextInRegisterKeyNotify (
> if (NewNotify == NULL) {
> return EFI_OUT_OF_RESOURCES;
> }
> - NewNotify->NotifyHandleList = (EFI_HANDLE *) AllocateZeroPool (sizeof
> (EFI_HANDLE) * Private->TextInExListCount);
> + NewNotify->NotifyHandleList = (VOID **) AllocateZeroPool (sizeof
> + (VOID *) * Private->TextInExListCount);
> if (NewNotify->NotifyHandleList == NULL) {
> gBS->FreePool (NewNotify);
> return EFI_OUT_OF_RESOURCES;
> diff --git a/MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c
> b/MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c
> index 7cfd5c178861..f98797225b63 100644
> --- a/MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c
> +++ b/MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c
> @@ -143,7 +143,7 @@ InternalStartMonitor(
> EFI_HANDLE *Handles;
> UINTN HandleCount;
> UINTN HandleIndex;
> - EFI_HANDLE NotifyHandle;
> + VOID *NotifyHandle;
>
> Status = gBS->LocateHandleBuffer (
> ByProtocol,
> @@ -202,7 +202,7 @@ InternalStopMonitor(
> EFI_KEY_DATA KeyData;
> UINTN HandleCount;
> UINTN HandleIndex;
> - EFI_HANDLE NotifyHandle;
> + VOID *NotifyHandle;
>
> Status = gBS->LocateHandleBuffer (
> ByProtocol,
> --
> 2.19.1.3.g30247aa5d201
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 16/35] MdeModulePkg/S3SaveState: cast Position for S3BootScriptLib explicitly
2019-09-17 19:49 ` [PATCH 16/35] MdeModulePkg/S3SaveState: cast Position for S3BootScriptLib explicitly Laszlo Ersek
@ 2019-09-19 1:47 ` Dandan Bi
0 siblings, 0 replies; 155+ messages in thread
From: Dandan Bi @ 2019-09-19 1:47 UTC (permalink / raw)
To: devel@edk2.groups.io, lersek@redhat.com
Cc: Dong, Eric, Wu, Hao A, Wang, Jian J, Gao, Liming, Ni, Ray
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Thanks,
Dandan
> -----Original Message-----
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Laszlo Ersek
> Sent: Wednesday, September 18, 2019 3:49 AM
> To: edk2-devel-groups-io <devel@edk2.groups.io>
> Cc: Bi, Dandan <dandan.bi@intel.com>; Dong, Eric <eric.dong@intel.com>;
> Wu, Hao A <hao.a.wu@intel.com>; Wang, Jian J <jian.j.wang@intel.com>;
> Gao, Liming <liming.gao@intel.com>; Ni, Ray <ray.ni@intel.com>
> Subject: [edk2-devel] [PATCH 16/35] MdeModulePkg/S3SaveState: cast
> Position for S3BootScriptLib explicitly
>
> The BootScriptInsert() and BootScriptLabel() functions take the in/out
> parameter "Position" as (EFI_S3_BOOT_SCRIPT_POSITION*), and pass it to
> S3BootScriptMoveLastOpcode() and S3BootScriptLabel(), respectively.
>
> The callees take the in/out parameter "Position" as (VOID**). Add explicit
> casts for clarity.
>
> There is no change in functionality.
>
> Cc: Dandan Bi <dandan.bi@intel.com>
> Cc: Eric Dong <eric.dong@intel.com>
> Cc: Hao A Wu <hao.a.wu@intel.com>
> Cc: Jian J Wang <jian.j.wang@intel.com>
> Cc: Liming Gao <liming.gao@intel.com>
> Cc: Ray Ni <ray.ni@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> lightly tested: multiple drivers in OVMF write S3 boot script fragments
>
> MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c | 4 ++--
> MdeModulePkg/Universal/Acpi/SmmS3SaveState/SmmS3SaveState.c | 4
> ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c
> b/MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c
> index e94d15772d78..cfa8ebbd2f5d 100644
> --- a/MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c
> +++ b/MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c
> @@ -810,7 +810,7 @@ BootScriptInsert (
> }
>
> if (!EFI_ERROR (Status)) {
> - Status = S3BootScriptMoveLastOpcode (BeforeOrAfter, Position);
> + Status = S3BootScriptMoveLastOpcode (BeforeOrAfter, (VOID
> + **)Position);
> }
> return Status;
> }
> @@ -851,7 +851,7 @@ BootScriptLabel (
> IN CONST CHAR8 *Label
> )
> {
> - return S3BootScriptLabel (BeforeOrAfter, CreateIfNotFound, Position,
> Label);
> + return S3BootScriptLabel (BeforeOrAfter, CreateIfNotFound, (VOID
> + **)Position, Label);
> }
> /**
> Compare two positions in the boot script table and return their relative
> position.
> diff --git
> a/MdeModulePkg/Universal/Acpi/SmmS3SaveState/SmmS3SaveState.c
> b/MdeModulePkg/Universal/Acpi/SmmS3SaveState/SmmS3SaveState.c
> index 9637df4fb82a..fc6d29e48ba9 100644
> --- a/MdeModulePkg/Universal/Acpi/SmmS3SaveState/SmmS3SaveState.c
> +++ b/MdeModulePkg/Universal/Acpi/SmmS3SaveState/SmmS3SaveState.c
> @@ -808,7 +808,7 @@ BootScriptInsert (
> }
>
> if (!EFI_ERROR (Status)) {
> - Status = S3BootScriptMoveLastOpcode (BeforeOrAfter, Position);
> + Status = S3BootScriptMoveLastOpcode (BeforeOrAfter, (VOID
> + **)Position);
> }
> return Status;
> }
> @@ -849,7 +849,7 @@ BootScriptLabel (
> IN CONST CHAR8 *Label
> )
> {
> - return S3BootScriptLabel (BeforeOrAfter, CreateIfNotFound, Position,
> Label);
> + return S3BootScriptLabel (BeforeOrAfter, CreateIfNotFound, (VOID
> + **)Position, Label);
> }
> /**
> Compare two positions in the boot script table and return their relative
> position.
> --
> 2.19.1.3.g30247aa5d201
>
>
>
> -=-=-=-=-=-=
> Groups.io Links: You receive all messages sent to this group.
>
> View/Reply Online (#47403): https://edk2.groups.io/g/devel/message/47403
> Mute This Topic: https://groups.io/mt/34180217/1768738
> Group Owner: devel+owner@edk2.groups.io
> Unsubscribe: https://edk2.groups.io/g/devel/unsub [dandan.bi@intel.com]
> -=-=-=-=-=-=
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 11/35] MdeModulePkg: document workaround for EFI_RUNTIME_EVENT_ENTRY PI spec bug
2019-09-17 19:49 ` [PATCH 11/35] MdeModulePkg: document workaround for EFI_RUNTIME_EVENT_ENTRY PI spec bug Laszlo Ersek
@ 2019-09-19 1:47 ` Dandan Bi
0 siblings, 0 replies; 155+ messages in thread
From: Dandan Bi @ 2019-09-19 1:47 UTC (permalink / raw)
To: Laszlo Ersek, edk2-devel-groups-io; +Cc: Wu, Hao A, Wang, Jian J, Gao, Liming
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Thanks,
Dandan
> -----Original Message-----
> From: Laszlo Ersek [mailto:lersek@redhat.com]
> Sent: Wednesday, September 18, 2019 3:49 AM
> To: edk2-devel-groups-io <devel@edk2.groups.io>
> Cc: Bi, Dandan <dandan.bi@intel.com>; Wu, Hao A <hao.a.wu@intel.com>;
> Wang, Jian J <jian.j.wang@intel.com>; Gao, Liming <liming.gao@intel.com>
> Subject: [PATCH 11/35] MdeModulePkg: document workaround for
> EFI_RUNTIME_EVENT_ENTRY PI spec bug
>
> The PI spec (v1.7) correctly specifies "EFI_RUNTIME_EVENT_ENTRY.Event" in
> natural language, but the field type in the structure definition itself is wrong -
> - it should be EFI_EVENT, not (EFI_EVENT*).
>
> This spec bug is likely unfixable for compatibility reasons, and so edk2 works
> it around already. We should clearly document the workaround.
>
> Functionally, this patch is a no-op.
>
> (I've also requested a non-normative (informative) clarification for the PI
> spec: <https://mantis.uefi.org/mantis/view.php?id=2017>.)
>
> Cc: Dandan Bi <dandan.bi@intel.com>
> Cc: Hao A Wu <hao.a.wu@intel.com>
> Cc: Jian J Wang <jian.j.wang@intel.com>
> Cc: Liming Gao <liming.gao@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> lightly tested, as these modules are part of the ArmVirt and/or OVMF
> platforms
>
> MdeModulePkg/Core/Dxe/Event/Event.c | 8 ++++++++
> MdeModulePkg/Core/RuntimeDxe/Runtime.c | 10 +++++++++-
> 2 files changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/MdeModulePkg/Core/Dxe/Event/Event.c
> b/MdeModulePkg/Core/Dxe/Event/Event.c
> index 21db38aaf037..c83c572c8f84 100644
> --- a/MdeModulePkg/Core/Dxe/Event/Event.c
> +++ b/MdeModulePkg/Core/Dxe/Event/Event.c
> @@ -485,6 +485,14 @@ CoreCreateEventInternal (
> IEvent->RuntimeData.NotifyTpl = NotifyTpl;
> IEvent->RuntimeData.NotifyFunction = NotifyFunction;
> IEvent->RuntimeData.NotifyContext = (VOID *) NotifyContext;
> + //
> + // Work around the bug in the Platform Init specification (v1.7), reported
> + // as Mantis#2017: "EFI_RUNTIME_EVENT_ENTRY.Event" should have
> type
> + // EFI_EVENT, not (EFI_EVENT*). The PI spec documents the field
> correctly
> + // as "The EFI_EVENT returned by CreateEvent()", but the type of the
> field
> + // doesn't match the natural language description. Therefore we need an
> + // explicit cast here.
> + //
> IEvent->RuntimeData.Event = (EFI_EVENT *) IEvent;
> InsertTailList (&gRuntime->EventHead, &IEvent->RuntimeData.Link);
> }
> diff --git a/MdeModulePkg/Core/RuntimeDxe/Runtime.c
> b/MdeModulePkg/Core/RuntimeDxe/Runtime.c
> index c52b2b7ecf68..f7220a205d1e 100644
> --- a/MdeModulePkg/Core/RuntimeDxe/Runtime.c
> +++ b/MdeModulePkg/Core/RuntimeDxe/Runtime.c
> @@ -285,8 +285,16 @@ RuntimeDriverSetVirtualAddressMap (
> for (Link = mRuntime.EventHead.ForwardLink; Link !=
> &mRuntime.EventHead; Link = Link->ForwardLink) {
> RuntimeEvent = BASE_CR (Link, EFI_RUNTIME_EVENT_ENTRY, Link);
> if ((RuntimeEvent->Type & EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE) ==
> EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE) {
> + //
> + // Work around the bug in the Platform Init specification (v1.7),
> + // reported as Mantis#2017: "EFI_RUNTIME_EVENT_ENTRY.Event"
> should have
> + // type EFI_EVENT, not (EFI_EVENT*). The PI spec documents the field
> + // correctly as "The EFI_EVENT returned by CreateEvent()", but the type
> + // of the field doesn't match the natural language description. Therefore
> + // we need an explicit cast here.
> + //
> RuntimeEvent->NotifyFunction (
> - RuntimeEvent->Event,
> + (EFI_EVENT) RuntimeEvent->Event,
> RuntimeEvent->NotifyContext
> );
> }
> --
> 2.19.1.3.g30247aa5d201
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 24/35] OvmfPkg/PlatformDxe: fix EFI_HII_HANDLE parameters of internal functions
2019-09-17 19:49 ` [PATCH 24/35] OvmfPkg/PlatformDxe: fix EFI_HII_HANDLE parameters of internal functions Laszlo Ersek
@ 2019-09-20 14:56 ` Philippe Mathieu-Daudé
2019-09-25 15:57 ` Ard Biesheuvel
1 sibling, 0 replies; 155+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-09-20 14:56 UTC (permalink / raw)
To: devel, lersek; +Cc: Ard Biesheuvel, Jordan Justen
On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> In the following call tree:
>
> PlatformInit ()
> mInstalledPackages = HiiAddPackages ()
> GopInstalled ()
> PopulateForm (PackageList = mInstalledPackages)
> CreateResolutionOptions (PackageList)
> HiiSetString (PackageList
> HiiUpdateForm (PackageList)
>
> PlatformDxe passes around an EFI_HII_HANDLE that (a) originates from
> HiiAddPackages() and (b) is ultimately passed to HiiSetString() and
> HiiUpdateForm(). The intermediate functions PopulateForm() and
> CreateResolutionOptions() however take that parameter as an
> (EFI_HII_HANDLE*).
>
> There is no bug in practice (because the affected functions never try to
> de-reference the "PackageList" parameter, they just pass it on), but the
> function prototypes are semantically wrong. Fix that.
>
> This could remain hidden so long because pointer-to-VOID silently converts
> to/from any pointer-to-object type, and the UEFI spec mandates that
> EFI_HII_HANDLE be a typedef to (VOID*).
>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Jordan Justen <jordan.l.justen@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
> ---
>
> Notes:
> tested in UiApp
>
> OvmfPkg/PlatformDxe/Platform.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/OvmfPkg/PlatformDxe/Platform.c b/OvmfPkg/PlatformDxe/Platform.c
> index 09181769babf..23ad43901f66 100644
> --- a/OvmfPkg/PlatformDxe/Platform.c
> +++ b/OvmfPkg/PlatformDxe/Platform.c
> @@ -486,7 +486,7 @@ STATIC
> EFI_STATUS
> EFIAPI
> CreateResolutionOptions (
> - IN EFI_HII_HANDLE *PackageList,
> + IN EFI_HII_HANDLE PackageList,
> OUT VOID **OpCodeBuffer,
> IN UINTN NumGopModes,
> IN GOP_MODE *GopModes
> @@ -547,7 +547,7 @@ STATIC
> EFI_STATUS
> EFIAPI
> PopulateForm (
> - IN EFI_HII_HANDLE *PackageList,
> + IN EFI_HII_HANDLE PackageList,
> IN EFI_GUID *FormSetGuid,
> IN EFI_FORM_ID FormId,
> IN UINTN NumGopModes,
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 23/35] OvmfPkg/VirtioNetDxe: fix SignalEvent() call
2019-09-17 19:49 ` [PATCH 23/35] OvmfPkg/VirtioNetDxe: fix SignalEvent() call Laszlo Ersek
@ 2019-09-20 14:59 ` Philippe Mathieu-Daudé
2019-09-26 12:16 ` Laszlo Ersek
2019-09-26 12:17 ` Ard Biesheuvel
2 siblings, 0 replies; 155+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-09-20 14:59 UTC (permalink / raw)
To: devel, lersek; +Cc: Ard Biesheuvel, Jordan Justen
On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> The SignalEvent() boot service takes an EFI_EVENT, not an (EFI_EVENT*).
> Fix the call in the notification function of
> "EFI_SIMPLE_NETWORK_PROTOCOL.WaitForPacket".
>
> This is an actual bug. The reason it's never been triggered is likely that
> the "SNP.WaitForPacket" event is rarely waited for by applications -- edk2
> itself has zero instances of that, for example.
>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Jordan Justen <jordan.l.justen@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> build-tested only
>
> OvmfPkg/VirtioNetDxe/Events.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/OvmfPkg/VirtioNetDxe/Events.c b/OvmfPkg/VirtioNetDxe/Events.c
> index 620910774bc5..83e96e5e5d91 100644
> --- a/OvmfPkg/VirtioNetDxe/Events.c
> +++ b/OvmfPkg/VirtioNetDxe/Events.c
> @@ -58,7 +58,7 @@ VirtioNetIsPacketAvailable (
> MemoryFence ();
>
> if (Dev->RxLastUsed != RxCurUsed) {
> - gBS->SignalEvent (&Dev->Snp.WaitForPacket);
> + gBS->SignalEvent (Dev->Snp.WaitForPacket);
> }
> }
>
>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 05/35] EmulatorPkg/DxeTimerLib: drop superfluous cast
2019-09-17 19:49 ` [PATCH 05/35] EmulatorPkg/DxeTimerLib: drop superfluous cast Laszlo Ersek
2019-09-17 20:02 ` Ni, Ray
@ 2019-09-20 15:00 ` Philippe Mathieu-Daudé
1 sibling, 0 replies; 155+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-09-20 15:00 UTC (permalink / raw)
To: devel, lersek; +Cc: Andrew Fish, Jordan Justen, Ray Ni
On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> "gTimerEvent" has type EFI_EVENT already, drop the superfluous cast.
>
> Cc: Andrew Fish <afish@apple.com>
> Cc: Jordan Justen <jordan.l.justen@intel.com>
> Cc: Ray Ni <ray.ni@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> build-tested only
>
> EmulatorPkg/Library/DxeTimerLib/DxeTimerLib.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/EmulatorPkg/Library/DxeTimerLib/DxeTimerLib.c b/EmulatorPkg/Library/DxeTimerLib/DxeTimerLib.c
> index 14cae4214c66..6fb5d8f3aaea 100644
> --- a/EmulatorPkg/Library/DxeTimerLib/DxeTimerLib.c
> +++ b/EmulatorPkg/Library/DxeTimerLib/DxeTimerLib.c
> @@ -40,7 +40,7 @@ RegisterTimerArchProtocol (
> gTimerPeriod = MultU64x32 (gTimerPeriod, 100);
>
> if (gTimerEvent == NULL) {
> - Status = gBS->CreateEvent (EVT_TIMER, 0, NULL, NULL, (VOID **)&gTimerEvent);
> + Status = gBS->CreateEvent (EVT_TIMER, 0, NULL, NULL, &gTimerEvent);
> ASSERT_EFI_ERROR (Status);
> }
> }
>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 35/35] UefiPayloadPkg/BlSupportDxe: fix ReserveResourceInGcd() calls
2019-09-17 19:49 ` [PATCH 35/35] UefiPayloadPkg/BlSupportDxe: fix ReserveResourceInGcd() calls Laszlo Ersek
@ 2019-09-23 2:28 ` Guo Dong
2019-09-23 15:08 ` Philippe Mathieu-Daudé
1 sibling, 0 replies; 155+ messages in thread
From: Guo Dong @ 2019-09-23 2:28 UTC (permalink / raw)
To: devel@edk2.groups.io, lersek@redhat.com; +Cc: You, Benjamin, Ma, Maurice
Thanks for the fix.
Reviewed-by: Guo Dong <guo.dong@intel.com>
> -----Original Message-----
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Laszlo Ersek
> Sent: Tuesday, September 17, 2019 12:50 PM
> To: edk2-devel-groups-io <devel@edk2.groups.io>
> Cc: You, Benjamin <benjamin.you@intel.com>; Dong, Guo
> <guo.dong@intel.com>; Ma, Maurice <maurice.ma@intel.com>
> Subject: [edk2-devel] [PATCH 35/35] UefiPayloadPkg/BlSupportDxe: fix
> ReserveResourceInGcd() calls
>
> The last parameter of ReserveResourceInGcd() is "ImageHandle", forwarded
> in turn to gDS->AllocateMemorySpace() or gDS->AllocateIoSpace() as
> "owner"
> image handle.
>
> But BlDxeEntryPoint() passes "SystemTable" as "ImageHandle".
>
> Compilers have not flagged it because EFI_HANDLE (the type of
> "ImageHandle") is unfortunately specified as (VOID*), and
> (EFI_SYSTEM_TABLE*) converts to (VOID*) silently.
>
> Hand the entry point function's "ImageHandle" parameter to
> ReserveResourceInGcd(). This fixes an actual bug.
>
> Cc: Benjamin You <benjamin.you@intel.com>
> Cc: Guo Dong <guo.dong@intel.com>
> Cc: Maurice Ma <maurice.ma@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> build-tested only
>
> UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c
> b/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c
> index bcee4cd9bc41..28dfc8fc5545 100644
> --- a/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c
> +++ b/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c
> @@ -106,10 +106,10 @@ BlDxeEntryPoint (
> //
> // Report MMIO/IO Resources
> //
> - Status = ReserveResourceInGcd (TRUE,
> EfiGcdMemoryTypeMemoryMappedIo, 0xFEC00000, SIZE_4KB, 0,
> SystemTable); // IOAPIC
> + Status = ReserveResourceInGcd (TRUE,
> EfiGcdMemoryTypeMemoryMappedIo,
> + 0xFEC00000, SIZE_4KB, 0, ImageHandle); // IOAPIC
> ASSERT_EFI_ERROR (Status);
>
> - Status = ReserveResourceInGcd (TRUE,
> EfiGcdMemoryTypeMemoryMappedIo, 0xFED00000, SIZE_1KB, 0,
> SystemTable); // HPET
> + Status = ReserveResourceInGcd (TRUE,
> EfiGcdMemoryTypeMemoryMappedIo,
> + 0xFED00000, SIZE_1KB, 0, ImageHandle); // HPET
> ASSERT_EFI_ERROR (Status);
>
> //
> --
> 2.19.1.3.g30247aa5d201
>
>
> -=-=-=-=-=-=
> Groups.io Links: You receive all messages sent to this group.
>
> View/Reply Online (#47422): https://edk2.groups.io/g/devel/message/47422
> Mute This Topic: https://groups.io/mt/34180240/1781375
> Group Owner: devel+owner@edk2.groups.io
> Unsubscribe: https://edk2.groups.io/g/devel/unsub [guo.dong@intel.com]
> -=-=-=-=-=-=
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 34/35] UefiPayloadPkg/BlSupportPei: fix MMCONFIG assignment from XSDT
2019-09-17 19:49 ` [PATCH 34/35] UefiPayloadPkg/BlSupportPei: fix MMCONFIG assignment from XSDT Laszlo Ersek
@ 2019-09-23 2:30 ` Guo Dong
2019-09-26 13:17 ` [edk2-devel] " Philippe Mathieu-Daudé
1 sibling, 0 replies; 155+ messages in thread
From: Guo Dong @ 2019-09-23 2:30 UTC (permalink / raw)
To: Laszlo Ersek, edk2-devel-groups-io; +Cc: You, Benjamin, Ma, Maurice
It looks good to me.
Reviewed-by: Guo Dong <guo.dong@intel.com>
> -----Original Message-----
> From: Laszlo Ersek [mailto:lersek@redhat.com]
> Sent: Tuesday, September 17, 2019 12:50 PM
> To: edk2-devel-groups-io <devel@edk2.groups.io>
> Cc: You, Benjamin <benjamin.you@intel.com>; Dong, Guo
> <guo.dong@intel.com>; Ma, Maurice <maurice.ma@intel.com>
> Subject: [PATCH 34/35] UefiPayloadPkg/BlSupportPei: fix MMCONFIG
> assignment from XSDT
>
> (This patch is unrelated to the rest of this series; its purpose is to enable
> building the UefiPayloadPkg DSC files with GCC.)
>
> When building "UefiPayloadPkg/UefiPayloadPkgIa32.dsc" with GCC48 for the
> DEBUG target, the compiler reports that "Entry32" may be used uninitialized
> in ParseAcpiInfo(), in the XSDT branch.
>
> Code inspection proves the compiler right. In the XSDT branch, the code from
> the RSDT branch must have been duplicated, and "Entry32" references were
> replaced with "Entry64" -- except where "MmCfgHdr" is assigned.
>
> Fix this bug by introducing a helper variable called "Signature", so that we
> have to refer to "Entry32" or "Entry64" only once per loop body.
>
> Cc: Benjamin You <benjamin.you@intel.com>
> Cc: Guo Dong <guo.dong@intel.com>
> Cc: Maurice Ma <maurice.ma@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> build-tested only
>
> UefiPayloadPkg/BlSupportPei/BlSupportPei.c | 19 +++++++++++--------
> 1 file changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/UefiPayloadPkg/BlSupportPei/BlSupportPei.c
> b/UefiPayloadPkg/BlSupportPei/BlSupportPei.c
> index 90433b609f22..22972453117a 100644
> --- a/UefiPayloadPkg/BlSupportPei/BlSupportPei.c
> +++ b/UefiPayloadPkg/BlSupportPei/BlSupportPei.c
> @@ -164,6 +164,7 @@ ParseAcpiInfo (
> UINT64 *Entry64;
> UINTN Entry64Num;
> UINTN Idx;
> + UINT32 *Signature;
>
> EFI_ACPI_MEMORY_MAPPED_CONFIGURATION_BASE_ADDRESS_TABLE_HE
> ADER *MmCfgHdr;
>
> EFI_ACPI_MEMORY_MAPPED_ENHANCED_CONFIGURATION_SPACE_BASE_
> ADDRESS_ALLOCATION_STRUCTURE *MmCfgBase;
>
> @@ -181,13 +182,14 @@ ParseAcpiInfo (
> Entry32 = (UINT32 *)(Rsdt + 1);
> Entry32Num = (Rsdt->Length - sizeof(EFI_ACPI_DESCRIPTION_HEADER))
> >> 2;
> for (Idx = 0; Idx < Entry32Num; Idx++) {
> - if (*(UINT32 *)(UINTN)(Entry32[Idx]) ==
> EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE_SIGNATURE) {
> - Fadt = (EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE
> *)(UINTN)(Entry32[Idx]);
> + Signature = (UINT32 *)(UINTN)Entry32[Idx];
> + if (*Signature ==
> EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE_SIGNATURE) {
> + Fadt = (EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE *)Signature;
> DEBUG ((DEBUG_INFO, "Found Fadt in Rsdt\n"));
> }
>
> - if (*(UINT32 *)(UINTN)(Entry32[Idx]) ==
> EFI_ACPI_5_0_PCI_EXPRESS_MEMORY_MAPPED_CONFIGURATION_SPACE
> _BASE_ADDRESS_DESCRIPTION_TABLE_SIGNATURE) {
> - MmCfgHdr =
> (EFI_ACPI_MEMORY_MAPPED_CONFIGURATION_BASE_ADDRESS_TABLE_H
> EADER *)(UINTN)(Entry32[Idx]);
> + if (*Signature ==
> EFI_ACPI_5_0_PCI_EXPRESS_MEMORY_MAPPED_CONFIGURATION_SPACE
> _BASE_ADDRESS_DESCRIPTION_TABLE_SIGNATURE) {
> + MmCfgHdr =
> +
> (EFI_ACPI_MEMORY_MAPPED_CONFIGURATION_BASE_ADDRESS_TABLE_H
> EADER
> + *)Signature;
> DEBUG ((DEBUG_INFO, "Found MM config address in Rsdt\n"));
> }
>
> @@ -205,13 +207,14 @@ ParseAcpiInfo (
> Entry64 = (UINT64 *)(Xsdt + 1);
> Entry64Num = (Xsdt->Length - sizeof(EFI_ACPI_DESCRIPTION_HEADER))
> >> 3;
> for (Idx = 0; Idx < Entry64Num; Idx++) {
> - if (*(UINT32 *)(UINTN)(Entry64[Idx]) ==
> EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE_SIGNATURE) {
> - Fadt = (EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE
> *)(UINTN)(Entry64[Idx]);
> + Signature = (UINT32 *)(UINTN)Entry64[Idx];
> + if (*Signature ==
> EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE_SIGNATURE) {
> + Fadt = (EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE *)Signature;
> DEBUG ((DEBUG_INFO, "Found Fadt in Xsdt\n"));
> }
>
> - if (*(UINT32 *)(UINTN)(Entry64[Idx]) ==
> EFI_ACPI_5_0_PCI_EXPRESS_MEMORY_MAPPED_CONFIGURATION_SPACE
> _BASE_ADDRESS_DESCRIPTION_TABLE_SIGNATURE) {
> - MmCfgHdr =
> (EFI_ACPI_MEMORY_MAPPED_CONFIGURATION_BASE_ADDRESS_TABLE_H
> EADER *)(UINTN)(Entry32[Idx]);
> + if (*Signature ==
> EFI_ACPI_5_0_PCI_EXPRESS_MEMORY_MAPPED_CONFIGURATION_SPACE
> _BASE_ADDRESS_DESCRIPTION_TABLE_SIGNATURE) {
> + MmCfgHdr =
> +
> (EFI_ACPI_MEMORY_MAPPED_CONFIGURATION_BASE_ADDRESS_TABLE_H
> EADER
> + *)Signature;
> DEBUG ((DEBUG_INFO, "Found MM config address in Xsdt\n"));
> }
>
> --
> 2.19.1.3.g30247aa5d201
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 26/35] SecurityPkg: fix UninstallMultipleProtocolInterfaces() calls
2019-09-17 19:49 ` [PATCH 26/35] SecurityPkg: fix UninstallMultipleProtocolInterfaces() calls Laszlo Ersek
@ 2019-09-23 9:55 ` Philippe Mathieu-Daudé
2019-09-26 12:45 ` Laszlo Ersek
1 sibling, 0 replies; 155+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-09-23 9:55 UTC (permalink / raw)
To: devel, lersek; +Cc: Chao Zhang, Jian Wang, Jiewen Yao
On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> Unlike the InstallMultipleProtocolInterfaces() boot service, which takes
> an (EFI_HANDLE*) as first parameter, the
> UninstallMultipleProtocolInterfaces() boot service takes an EFI_HANDLE as
> first parameter.
>
> These are actual bugs. They must have remained hidden until now because
> they are all in Unload() functions, which are probably exercised
> infrequently. Fix the UninstallMultipleProtocolInterfaces() calls.
>
> Cc: Chao Zhang <chao.b.zhang@intel.com>
> Cc: Jian Wang <jian.j.wang@intel.com>
> Cc: Jiewen Yao <jiewen.yao@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> build-tested only
>
> SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c | 2 +-
> SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c | 2 +-
> SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDriver.c | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c b/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c
> index 54155a338100..9052eced757d 100644
> --- a/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c
> +++ b/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c
> @@ -443,7 +443,7 @@ Tcg2ConfigDriverUnload (
> ASSERT (PrivateData->Signature == TCG2_CONFIG_PRIVATE_DATA_SIGNATURE);
>
> gBS->UninstallMultipleProtocolInterfaces (
> - &ImageHandle,
> + ImageHandle,
> &gEfiCallerIdGuid,
> PrivateData,
> NULL
> diff --git a/SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c b/SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c
> index 341879e4c4ba..fb06624fdb8f 100644
> --- a/SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c
> +++ b/SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c
> @@ -138,7 +138,7 @@ TcgConfigDriverUnload (
> ASSERT (PrivateData->Signature == TCG_CONFIG_PRIVATE_DATA_SIGNATURE);
>
> gBS->UninstallMultipleProtocolInterfaces (
> - &ImageHandle,
> + ImageHandle,
> &gEfiCallerIdGuid,
> PrivateData,
> NULL
> diff --git a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDriver.c b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDriver.c
> index 798ef9cfbc01..6c0294151e6c 100644
> --- a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDriver.c
> +++ b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDriver.c
> @@ -115,7 +115,7 @@ SecureBootConfigDriverUnload (
> ASSERT (PrivateData->Signature == SECUREBOOT_CONFIG_PRIVATE_DATA_SIGNATURE);
>
> gBS->UninstallMultipleProtocolInterfaces (
> - &ImageHandle,
> + ImageHandle,
> &gEfiCallerIdGuid,
> PrivateData,
> NULL
>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 27/35] SecurityPkg: stop abusing EFI_EVENT for protocol notify registration
2019-09-17 19:49 ` [PATCH 27/35] SecurityPkg: stop abusing EFI_EVENT for protocol notify registration Laszlo Ersek
@ 2019-09-23 9:56 ` Philippe Mathieu-Daudé
2019-09-26 12:46 ` Laszlo Ersek
1 sibling, 0 replies; 155+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-09-23 9:56 UTC (permalink / raw)
To: devel, lersek; +Cc: Chao Zhang, Jian Wang, Jiewen Yao
On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> EfiCreateProtocolNotifyEvent() takes a (VOID**) for "Registration",
> similarly to gBS->RegisterProtocolNotify(). We should pass the address of
> an actual pointer-to-VOID, and not the address of an EFI_EVENT. EFI_EVENT
> just happens to be specified as (VOID*), and has nothing to do with the
> registration.
>
> This change is a no-op in practice; it's a semantic improvement.
>
> Cc: Chao Zhang <chao.b.zhang@intel.com>
> Cc: Jian Wang <jian.j.wang@intel.com>
> Cc: Jiewen Yao <jiewen.yao@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> build-tested only
>
> SecurityPkg/HddPassword/HddPasswordDxe.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/SecurityPkg/HddPassword/HddPasswordDxe.c b/SecurityPkg/HddPassword/HddPasswordDxe.c
> index b0d795b6597f..051e64091d7f 100644
> --- a/SecurityPkg/HddPassword/HddPasswordDxe.c
> +++ b/SecurityPkg/HddPassword/HddPasswordDxe.c
> @@ -2770,7 +2770,7 @@ HddPasswordDxeInit (
> {
> EFI_STATUS Status;
> HDD_PASSWORD_DXE_PRIVATE_DATA *Private;
> - EFI_EVENT Registration;
> + VOID *Registration;
> EFI_EVENT EndOfDxeEvent;
> EDKII_VARIABLE_LOCK_PROTOCOL *VariableLock;
>
>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 30/35] ShellPkg: stop taking EFI_HANDLE in place of SHELL_FILE_HANDLE
2019-09-17 19:49 ` [PATCH 30/35] ShellPkg: stop taking EFI_HANDLE in place of SHELL_FILE_HANDLE Laszlo Ersek
@ 2019-09-23 9:58 ` Philippe Mathieu-Daudé
2019-09-26 2:53 ` Gao, Zhichao
1 sibling, 0 replies; 155+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-09-23 9:58 UTC (permalink / raw)
To: devel, lersek; +Cc: Jaben Carsey, Ray Ni, Zhichao Gao
On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> The TouchFileByHandle() and IsDirectoryEmpty() functions are passed
> SHELL_FILE_HANDLE parameters, and they use those parameters correctly.
> However, their parameter lists say EFI_HANDLE.
>
> Spell out the right type in the parameter lists.
>
> In practice, this change is a no-op (because, quite regrettably, both
> EFI_HANDLE and SHELL_FILE_HANDLE are specified to be typedefs of (VOID*)).
>
> Cc: Jaben Carsey <jaben.carsey@intel.com>
> Cc: Ray Ni <ray.ni@intel.com>
> Cc: Zhichao Gao <zhichao.gao@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> tested: rm, touch
>
> ShellPkg/Library/UefiShellLevel2CommandsLib/Rm.c | 2 +-
> ShellPkg/Library/UefiShellLevel3CommandsLib/Touch.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/ShellPkg/Library/UefiShellLevel2CommandsLib/Rm.c b/ShellPkg/Library/UefiShellLevel2CommandsLib/Rm.c
> index 3a1196f1529e..59f7eec376f2 100644
> --- a/ShellPkg/Library/UefiShellLevel2CommandsLib/Rm.c
> +++ b/ShellPkg/Library/UefiShellLevel2CommandsLib/Rm.c
> @@ -24,7 +24,7 @@ STATIC CONST SHELL_PARAM_ITEM ParamList[] = {
> **/
> BOOLEAN
> IsDirectoryEmpty (
> - IN EFI_HANDLE FileHandle
> + IN SHELL_FILE_HANDLE FileHandle
> )
> {
> EFI_STATUS Status;
> diff --git a/ShellPkg/Library/UefiShellLevel3CommandsLib/Touch.c b/ShellPkg/Library/UefiShellLevel3CommandsLib/Touch.c
> index 0f00344c815e..a215f5774c69 100644
> --- a/ShellPkg/Library/UefiShellLevel3CommandsLib/Touch.c
> +++ b/ShellPkg/Library/UefiShellLevel3CommandsLib/Touch.c
> @@ -21,7 +21,7 @@
> **/
> EFI_STATUS
> TouchFileByHandle (
> - IN EFI_HANDLE Handle
> + IN SHELL_FILE_HANDLE Handle
> )
> {
> EFI_STATUS Status;
>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 31/35] ShellPkg/UefiShellDebug1CommandsLib: fix ShellCloseFile() call
2019-09-17 19:49 ` [PATCH 31/35] ShellPkg/UefiShellDebug1CommandsLib: fix ShellCloseFile() call Laszlo Ersek
@ 2019-09-23 10:01 ` Philippe Mathieu-Daudé
2019-09-23 14:28 ` Carsey, Jaben
0 siblings, 1 reply; 155+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-09-23 10:01 UTC (permalink / raw)
To: devel, lersek; +Cc: Jaben Carsey, Ray Ni, Zhichao Gao
On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> In the FileBufferSave() function, we invoke ShellCloseFile() if "Directory
> Can Not Be Saved".
>
> The ShellCloseFile() function takes a (SHELL_FILE_HANDLE*) parameter
> called "FileHandle", and correctly passes the de-referenced (*FileHandle)
> to EFI_SHELL_CLOSE_FILE, which takes a SHELL_FILE_HANDLE.
>
> However, FileBufferSave() passes SHELL_FILE_HANDLE to ShellCloseFile(),
> not the expected (SHELL_FILE_HANDLE*). Correct it.
>
> This fixes an actual bug that has remained hidden for two reasons:
>
> - pointer-to-VOID converts from/to any pointer-to-object type silently,
> - the bug is on an error path which has likely never fired in practice.
>
> Cc: Jaben Carsey <jaben.carsey@intel.com>
> Cc: Ray Ni <ray.ni@intel.com>
> Cc: Zhichao Gao <zhichao.gao@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> tested: edit (saving a file)
>
> ShellPkg/Library/UefiShellDebug1CommandsLib/Edit/FileBuffer.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/Edit/FileBuffer.c b/ShellPkg/Library/UefiShellDebug1CommandsLib/Edit/FileBuffer.c
> index 464f9de38e52..fd324cc4a861 100644
> --- a/ShellPkg/Library/UefiShellDebug1CommandsLib/Edit/FileBuffer.c
> +++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/Edit/FileBuffer.c
> @@ -1462,7 +1462,7 @@ FileBufferSave (
>
> if (Info != NULL && Info->Attribute & EFI_FILE_DIRECTORY) {
> StatusBarSetStatusString (L"Directory Can Not Be Saved");
> - ShellCloseFile(FileHandle);
> + ShellCloseFile (&FileHandle);
> FreePool(Info);
> return EFI_LOAD_ERROR;
> }
>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 10/35] MdeModulePkg/PlatformVarCleanupLib: fix HiiConstructConfigHdr() call
2019-09-17 19:49 ` [PATCH 10/35] MdeModulePkg/PlatformVarCleanupLib: fix HiiConstructConfigHdr() call Laszlo Ersek
@ 2019-09-23 11:45 ` Philippe Mathieu-Daudé
2019-09-24 17:28 ` Laszlo Ersek
0 siblings, 1 reply; 155+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-09-23 11:45 UTC (permalink / raw)
To: devel, lersek; +Cc: Hao A Wu, Jian J Wang, Liming Gao
On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> The HiiConstructConfigHdr() function takes the "DriverHandle" parameter in
> order to fetch the device path from it, and then turn the device path into
> PATH routing information.
>
> The HiiConstructConfigHdr() function is called from
> VariableCleanupHiiExtractConfig(), which is only installed when "Type" is
> "VarCleanupManually" in PlatformVarCleanup().
>
> In that case, we create "Private->DriverHandle" as a new handle, and
> install "mVarCleanupHiiVendorDevicePath" on it. Then we pass
> "Private->DriverHandle" to HiiAddPackages(), which consumes the device
> path for routing purposes.
>
> It follows that the "DriverHandle" argument pased to
"passed"
> HiiConstructConfigHdr() should be the same driver handle, for matching
> routing.
>
> Currently we pass "Private->HiiHandle", which is clearly a typo, because
> it is the return value of HiiAddPackages(), and stands for the published
> HII package list.
Phew...
> Therefore this patch addresses an actual bug.
>
> The typo has not been flagged by compilers because the UEFI spec
> regrettably defines both EFI_HANDLE and EFI_HII_HANDLE as (VOID*).
>
> Cc: Hao A Wu <hao.a.wu@intel.com>
> Cc: Jian J Wang <jian.j.wang@intel.com>
> Cc: Liming Gao <liming.gao@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> build-tested only
>
> MdeModulePkg/Library/PlatformVarCleanupLib/PlatVarCleanupLib.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/MdeModulePkg/Library/PlatformVarCleanupLib/PlatVarCleanupLib.c b/MdeModulePkg/Library/PlatformVarCleanupLib/PlatVarCleanupLib.c
> index 968c044a316a..3875d614bb41 100644
> --- a/MdeModulePkg/Library/PlatformVarCleanupLib/PlatVarCleanupLib.c
> +++ b/MdeModulePkg/Library/PlatformVarCleanupLib/PlatVarCleanupLib.c
> @@ -609,7 +609,11 @@ VariableCleanupHiiExtractConfig (
> // Allocate and fill a buffer large enough to hold the <ConfigHdr> template
> // followed by "&OFFSET=0&WIDTH=WWWWWWWWWWWWWWWW" followed by a Null-terminator.
> //
> - ConfigRequestHdr = HiiConstructConfigHdr (&mVariableCleanupHiiGuid, mVarStoreName, Private->HiiHandle);
> + ConfigRequestHdr = HiiConstructConfigHdr (
> + &mVariableCleanupHiiGuid,
> + mVarStoreName,
> + Private->DriverHandle
> + );
> Size = (StrLen (ConfigRequestHdr) + 32 + 1) * sizeof (CHAR16);
> ConfigRequest = AllocateZeroPool (Size);
> ASSERT (ConfigRequest != NULL);
>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 31/35] ShellPkg/UefiShellDebug1CommandsLib: fix ShellCloseFile() call
2019-09-23 10:01 ` [edk2-devel] " Philippe Mathieu-Daudé
@ 2019-09-23 14:28 ` Carsey, Jaben
2019-09-24 1:18 ` Gao, Zhichao
0 siblings, 1 reply; 155+ messages in thread
From: Carsey, Jaben @ 2019-09-23 14:28 UTC (permalink / raw)
To: Philippe Mathieu-Daudé, devel@edk2.groups.io,
lersek@redhat.com
Cc: Ni, Ray, Gao, Zhichao
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Thanks
-Jaben
> -----Original Message-----
> From: Philippe Mathieu-Daudé [mailto:philmd@redhat.com]
> Sent: Monday, September 23, 2019 3:01 AM
> To: devel@edk2.groups.io; lersek@redhat.com
> Cc: Carsey, Jaben <jaben.carsey@intel.com>; Ni, Ray <ray.ni@intel.com>;
> Gao, Zhichao <zhichao.gao@intel.com>
> Subject: Re: [edk2-devel] [PATCH 31/35]
> ShellPkg/UefiShellDebug1CommandsLib: fix ShellCloseFile() call
>
> On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> > In the FileBufferSave() function, we invoke ShellCloseFile() if "Directory
> > Can Not Be Saved".
> >
> > The ShellCloseFile() function takes a (SHELL_FILE_HANDLE*) parameter
> > called "FileHandle", and correctly passes the de-referenced (*FileHandle)
> > to EFI_SHELL_CLOSE_FILE, which takes a SHELL_FILE_HANDLE.
> >
> > However, FileBufferSave() passes SHELL_FILE_HANDLE to ShellCloseFile(),
> > not the expected (SHELL_FILE_HANDLE*). Correct it.
> >
> > This fixes an actual bug that has remained hidden for two reasons:
> >
> > - pointer-to-VOID converts from/to any pointer-to-object type silently,
> > - the bug is on an error path which has likely never fired in practice.
> >
> > Cc: Jaben Carsey <jaben.carsey@intel.com>
> > Cc: Ray Ni <ray.ni@intel.com>
> > Cc: Zhichao Gao <zhichao.gao@intel.com>
> > Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> > ---
> >
> > Notes:
> > tested: edit (saving a file)
> >
> > ShellPkg/Library/UefiShellDebug1CommandsLib/Edit/FileBuffer.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git
> a/ShellPkg/Library/UefiShellDebug1CommandsLib/Edit/FileBuffer.c
> b/ShellPkg/Library/UefiShellDebug1CommandsLib/Edit/FileBuffer.c
> > index 464f9de38e52..fd324cc4a861 100644
> > --- a/ShellPkg/Library/UefiShellDebug1CommandsLib/Edit/FileBuffer.c
> > +++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/Edit/FileBuffer.c
> > @@ -1462,7 +1462,7 @@ FileBufferSave (
> >
> > if (Info != NULL && Info->Attribute & EFI_FILE_DIRECTORY) {
> > StatusBarSetStatusString (L"Directory Can Not Be Saved");
> > - ShellCloseFile(FileHandle);
> > + ShellCloseFile (&FileHandle);
> > FreePool(Info);
> > return EFI_LOAD_ERROR;
> > }
> >
>
> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 22/35] OvmfPkg/XenBusDxe: fix UninstallMultipleProtocolInterfaces() call
2019-09-17 19:49 ` [PATCH 22/35] OvmfPkg/XenBusDxe: fix UninstallMultipleProtocolInterfaces() call Laszlo Ersek
2019-09-18 9:32 ` Anthony PERARD
2019-09-18 10:30 ` Julien Grall
@ 2019-09-23 15:03 ` Philippe Mathieu-Daudé
2 siblings, 0 replies; 155+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-09-23 15:03 UTC (permalink / raw)
To: devel, lersek; +Cc: Anthony Perard, Ard Biesheuvel, Jordan Justen, Julien Grall
On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> Unlike the InstallMultipleProtocolInterfaces() boot service, which takes
> an (EFI_HANDLE*) as first parameter, the
> UninstallMultipleProtocolInterfaces() boot service takes an EFI_HANDLE as
> first parameter.
>
> This is an actual bug. It must have remained hidden until now because it's
> on an error path. Fix the UninstallMultipleProtocolInterfaces() call.
>
> Cc: Anthony Perard <anthony.perard@citrix.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Jordan Justen <jordan.l.justen@intel.com>
> Cc: Julien Grall <julien.grall@arm.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> build-tested only
>
> OvmfPkg/XenBusDxe/XenBus.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/OvmfPkg/XenBusDxe/XenBus.c b/OvmfPkg/XenBusDxe/XenBus.c
> index bb8ddbc4d44d..2451e58a5961 100644
> --- a/OvmfPkg/XenBusDxe/XenBus.c
> +++ b/OvmfPkg/XenBusDxe/XenBus.c
> @@ -210,7 +210,7 @@ XenBusAddDevice (
>
> ErrorOpenProtocolByChild:
> gBS->UninstallMultipleProtocolInterfaces (
> - &Private->Handle,
> + Private->Handle,
> &gEfiDevicePathProtocolGuid, Private->DevicePath,
> &gXenBusProtocolGuid, &Private->XenBusIo,
> NULL);
>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 35/35] UefiPayloadPkg/BlSupportDxe: fix ReserveResourceInGcd() calls
2019-09-17 19:49 ` [PATCH 35/35] UefiPayloadPkg/BlSupportDxe: fix ReserveResourceInGcd() calls Laszlo Ersek
2019-09-23 2:28 ` [edk2-devel] " Guo Dong
@ 2019-09-23 15:08 ` Philippe Mathieu-Daudé
2019-09-23 16:02 ` Guo Dong
2019-09-24 17:29 ` Laszlo Ersek
1 sibling, 2 replies; 155+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-09-23 15:08 UTC (permalink / raw)
To: devel, lersek; +Cc: Benjamin You, Guo Dong, Maurice Ma
On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> The last parameter of ReserveResourceInGcd() is "ImageHandle", forwarded
> in turn to gDS->AllocateMemorySpace() or gDS->AllocateIoSpace() as "owner"
> image handle.
>
> But BlDxeEntryPoint() passes "SystemTable" as "ImageHandle".
>
> Compilers have not flagged it because EFI_HANDLE (the type of
> "ImageHandle") is unfortunately specified as (VOID*), and
> (EFI_SYSTEM_TABLE*) converts to (VOID*) silently.
>
> Hand the entry point function's "ImageHandle" parameter to
> ReserveResourceInGcd(). This fixes an actual bug.
Wow very buggy, so I assume this is mostly dead code, right?
> Cc: Benjamin You <benjamin.you@intel.com>
> Cc: Guo Dong <guo.dong@intel.com>
> Cc: Maurice Ma <maurice.ma@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> build-tested only
>
> UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c b/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c
> index bcee4cd9bc41..28dfc8fc5545 100644
> --- a/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c
> +++ b/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c
> @@ -106,10 +106,10 @@ BlDxeEntryPoint (
> //
> // Report MMIO/IO Resources
> //
> - Status = ReserveResourceInGcd (TRUE, EfiGcdMemoryTypeMemoryMappedIo, 0xFEC00000, SIZE_4KB, 0, SystemTable); // IOAPIC
> + Status = ReserveResourceInGcd (TRUE, EfiGcdMemoryTypeMemoryMappedIo, 0xFEC00000, SIZE_4KB, 0, ImageHandle); // IOAPIC
> ASSERT_EFI_ERROR (Status);
>
> - Status = ReserveResourceInGcd (TRUE, EfiGcdMemoryTypeMemoryMappedIo, 0xFED00000, SIZE_1KB, 0, SystemTable); // HPET
> + Status = ReserveResourceInGcd (TRUE, EfiGcdMemoryTypeMemoryMappedIo, 0xFED00000, SIZE_1KB, 0, ImageHandle); // HPET
> ASSERT_EFI_ERROR (Status);
>
> //
>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 21/35] NetworkPkg/TcpDxe: fix SockFreeFoo() parameter list
2019-09-17 19:49 ` [PATCH 21/35] NetworkPkg/TcpDxe: fix SockFreeFoo() parameter list Laszlo Ersek
@ 2019-09-23 15:09 ` Philippe Mathieu-Daudé
2019-09-26 12:14 ` Laszlo Ersek
2019-09-27 0:06 ` Siyuan, Fu
2 siblings, 0 replies; 155+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-09-23 15:09 UTC (permalink / raw)
To: devel, lersek; +Cc: Jiaxin Wu, Siyuan Fu
On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> The SockFreeFoo() callback function for NetbufFromExt() has to match the
> NET_VECTOR_EXT_FREE prototype, which takes a (VOID*) as callback argument
> (Arg). EFI_EVENT has nothing to do with NET_VECTOR_EXT_FREE. Fix the
> SockFreeFoo() parameter list.
>
> This change is a no-op in practice.
>
> Cc: Jiaxin Wu <jiaxin.wu@intel.com>
> Cc: Siyuan Fu <siyuan.fu@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> build-tested only
>
> NetworkPkg/TcpDxe/SockImpl.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/NetworkPkg/TcpDxe/SockImpl.c b/NetworkPkg/TcpDxe/SockImpl.c
> index f5e01771e2a8..fb28e2ed40d3 100644
> --- a/NetworkPkg/TcpDxe/SockImpl.c
> +++ b/NetworkPkg/TcpDxe/SockImpl.c
> @@ -67,13 +67,13 @@ SockBufNext (
> /**
> User provided callback function for NetbufFromExt.
>
> - @param[in] Event The Event this notify function registered to, ignored.
> + @param[in] Arg The Arg parameter forwarded by NetbufFromExt(). Ignored.
>
> **/
> VOID
> EFIAPI
> SockFreeFoo (
> - IN EFI_EVENT Event
> + IN VOID *Arg
> )
> {
> return;
>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 25/35] OvmfPkg/VideoDxe: document EFI_EDID_OVERRIDE_PROTOCOL.GetEdid() call
2019-09-17 19:49 ` [PATCH 25/35] OvmfPkg/VideoDxe: document EFI_EDID_OVERRIDE_PROTOCOL.GetEdid() call Laszlo Ersek
@ 2019-09-23 15:59 ` Philippe Mathieu-Daudé
2019-09-26 12:43 ` Laszlo Ersek
0 siblings, 1 reply; 155+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-09-23 15:59 UTC (permalink / raw)
To: devel, lersek; +Cc: Ard Biesheuvel, David Woodhouse, Jordan Justen
Hi Laszlo,
On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> According to the UEFI spec -- and to the edk2 header
> "MdePkg/Include/Protocol/EdidOverride.h" too --,
> EFI_EDID_OVERRIDE_PROTOCOL_GET_EDID takes an (EFI_HANDLE*), and not an
> EFI_HANDLE, as second parameter ("ChildHandle").
>
> This is probably [*] a bug in the UEFI spec. Given that this CSM module
> (VideoDxe) had been used for a long time on physical platforms before it
> was moved to OvmfPkg, keep the current "ChildHandle" argument, just cast
> it explicitly.
>
> [*] The edk2 tree contains no other GetEdid() call, and also no GetEdid()
> implementation.
>
> The edk2-platforms tree contains two GetEdid() calls, at commit
> 022c212167e0, in files
> - "Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/Edid.c",
> - "Drivers/OptionRomPkg/CirrusLogic5430Dxe/Edid.c".
>
> From these, the first passes an (EFI_HANDLE*) as "ChildHandle", the
> second passes an EFI_HANDLE. It's difficult to draw a conclusion. :/
>
> No functional changes.
>
> (I've also requested a non-normative (informative) clarification for the
> UEFI spec: <https://mantis.uefi.org/mantis/view.php?id=2018>, in the
> direction that matches this patch.)
(EFI_HANDLE*) makes sense to me, but I'd rather wait for the spec
clarification before Acking this patch, I don't want we silent a bug
with this cast.
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: David Woodhouse <dwmw2@infradead.org>
> Cc: Jordan Justen <jordan.l.justen@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> build-tested only
>
> OvmfPkg/Csm/BiosThunk/VideoDxe/BiosVideo.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/OvmfPkg/Csm/BiosThunk/VideoDxe/BiosVideo.c b/OvmfPkg/Csm/BiosThunk/VideoDxe/BiosVideo.c
> index 0640656dba14..995136adee27 100644
> --- a/OvmfPkg/Csm/BiosThunk/VideoDxe/BiosVideo.c
> +++ b/OvmfPkg/Csm/BiosThunk/VideoDxe/BiosVideo.c
> @@ -1402,9 +1402,13 @@ BiosVideoCheckForVbe (
> goto Done;
> }
>
> + //
> + // Cast "ChildHandle" to (EFI_HANDLE*) in order to work around the spec bug
> + // in UEFI v2.8, reported as Mantis#2018.
> + //
> Status = EdidOverride->GetEdid (
> EdidOverride,
> - BiosVideoPrivate->Handle,
> + (EFI_HANDLE *) BiosVideoPrivate->Handle,
> &EdidAttributes,
> &EdidOverrideDataSize,
> (UINT8 **) &EdidOverrideDataBlock
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 35/35] UefiPayloadPkg/BlSupportDxe: fix ReserveResourceInGcd() calls
2019-09-23 15:08 ` Philippe Mathieu-Daudé
@ 2019-09-23 16:02 ` Guo Dong
2019-09-23 16:04 ` Philippe Mathieu-Daudé
2019-09-24 17:29 ` Laszlo Ersek
1 sibling, 1 reply; 155+ messages in thread
From: Guo Dong @ 2019-09-23 16:02 UTC (permalink / raw)
To: Philippe Mathieu-Daudé, devel@edk2.groups.io,
lersek@redhat.com
Cc: You, Benjamin, Ma, Maurice
This is not dead code.
This actual bug didn't cause issues since BlSupportDxe just allocate resources reported from bootloaders.
Anyway, this is a great enhancement from spec to capture such bugs.
Thanks,
Guo
> -----Original Message-----
> From: Philippe Mathieu-Daudé [mailto:philmd@redhat.com]
> Sent: Monday, September 23, 2019 8:08 AM
> To: devel@edk2.groups.io; lersek@redhat.com
> Cc: You, Benjamin <benjamin.you@intel.com>; Dong, Guo
> <guo.dong@intel.com>; Ma, Maurice <maurice.ma@intel.com>
> Subject: Re: [edk2-devel] [PATCH 35/35] UefiPayloadPkg/BlSupportDxe: fix
> ReserveResourceInGcd() calls
>
> On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> > The last parameter of ReserveResourceInGcd() is "ImageHandle",
> > forwarded in turn to gDS->AllocateMemorySpace() or gDS-
> >AllocateIoSpace() as "owner"
> > image handle.
> >
> > But BlDxeEntryPoint() passes "SystemTable" as "ImageHandle".
> >
> > Compilers have not flagged it because EFI_HANDLE (the type of
> > "ImageHandle") is unfortunately specified as (VOID*), and
> > (EFI_SYSTEM_TABLE*) converts to (VOID*) silently.
> >
> > Hand the entry point function's "ImageHandle" parameter to
> > ReserveResourceInGcd(). This fixes an actual bug.
>
> Wow very buggy, so I assume this is mostly dead code, right?
>
> > Cc: Benjamin You <benjamin.you@intel.com>
> > Cc: Guo Dong <guo.dong@intel.com>
> > Cc: Maurice Ma <maurice.ma@intel.com>
> > Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> > ---
> >
> > Notes:
> > build-tested only
> >
> > UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c
> > b/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c
> > index bcee4cd9bc41..28dfc8fc5545 100644
> > --- a/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c
> > +++ b/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c
> > @@ -106,10 +106,10 @@ BlDxeEntryPoint (
> > //
> > // Report MMIO/IO Resources
> > //
> > - Status = ReserveResourceInGcd (TRUE,
> > EfiGcdMemoryTypeMemoryMappedIo, 0xFEC00000, SIZE_4KB, 0,
> SystemTable);
> > // IOAPIC
> > + Status = ReserveResourceInGcd (TRUE,
> > + EfiGcdMemoryTypeMemoryMappedIo, 0xFEC00000, SIZE_4KB, 0,
> > + ImageHandle); // IOAPIC
> > ASSERT_EFI_ERROR (Status);
> >
> > - Status = ReserveResourceInGcd (TRUE,
> > EfiGcdMemoryTypeMemoryMappedIo, 0xFED00000, SIZE_1KB, 0,
> SystemTable);
> > // HPET
> > + Status = ReserveResourceInGcd (TRUE,
> > + EfiGcdMemoryTypeMemoryMappedIo, 0xFED00000, SIZE_1KB, 0,
> > + ImageHandle); // HPET
> > ASSERT_EFI_ERROR (Status);
> >
> > //
> >
>
> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 20/35] NetworkPkg/Ip4Dxe: fix NetLibDestroyServiceChild() call
2019-09-17 19:49 ` [PATCH 20/35] NetworkPkg/Ip4Dxe: fix NetLibDestroyServiceChild() call Laszlo Ersek
@ 2019-09-23 16:03 ` Philippe Mathieu-Daudé
2019-09-27 0:04 ` Siyuan, Fu
2019-09-26 12:14 ` Laszlo Ersek
1 sibling, 1 reply; 155+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-09-23 16:03 UTC (permalink / raw)
To: devel, lersek; +Cc: Jiaxin Wu, Siyuan Fu
On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> Both NetLibDestroyServiceChild() and EFI_SERVICE_BINDING_DESTROY_CHILD
> take an EFI_HANDLE for the "ChildHandle" parameter, not an (EFI_HANDLE*).
>
> This patch fixes a real bug.
>
> Cc: Jiaxin Wu <jiaxin.wu@intel.com>
> Cc: Siyuan Fu <siyuan.fu@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> possibly only build-tested
>
> NetworkPkg/Ip4Dxe/Ip4If.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/NetworkPkg/Ip4Dxe/Ip4If.c b/NetworkPkg/Ip4Dxe/Ip4If.c
> index 44b8d9fc8faf..53a333037f94 100644
> --- a/NetworkPkg/Ip4Dxe/Ip4If.c
> +++ b/NetworkPkg/Ip4Dxe/Ip4If.c
> @@ -592,7 +592,7 @@ Ip4SetAddress (
> Interface->Controller,
> Interface->Image,
> &gEfiArpServiceBindingProtocolGuid,
> - &Interface->ArpHandle
> + Interface->ArpHandle
> );
>
> Interface->ArpHandle = NULL;
> @@ -657,7 +657,7 @@ ON_ERROR:
> Interface->Controller,
> Interface->Image,
> &gEfiArpServiceBindingProtocolGuid,
> - &Interface->ArpHandle
> + Interface->ArpHandle
I'm surprise this one never triggered unexpected behaviors, it
looks easy to reach.
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
> );
>
> return Status;
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 35/35] UefiPayloadPkg/BlSupportDxe: fix ReserveResourceInGcd() calls
2019-09-23 16:02 ` Guo Dong
@ 2019-09-23 16:04 ` Philippe Mathieu-Daudé
0 siblings, 0 replies; 155+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-09-23 16:04 UTC (permalink / raw)
To: Dong, Guo, devel@edk2.groups.io, lersek@redhat.com
Cc: You, Benjamin, Ma, Maurice
On 9/23/19 6:02 PM, Dong, Guo wrote:
>
> This is not dead code.
> This actual bug didn't cause issues since BlSupportDxe just allocate resources reported from bootloaders.
Ah OK, thanks Guo.
> Anyway, this is a great enhancement from spec to capture such bugs.
>
> Thanks,
> Guo
>
>> -----Original Message-----
>> From: Philippe Mathieu-Daudé [mailto:philmd@redhat.com]
>> Sent: Monday, September 23, 2019 8:08 AM
>> To: devel@edk2.groups.io; lersek@redhat.com
>> Cc: You, Benjamin <benjamin.you@intel.com>; Dong, Guo
>> <guo.dong@intel.com>; Ma, Maurice <maurice.ma@intel.com>
>> Subject: Re: [edk2-devel] [PATCH 35/35] UefiPayloadPkg/BlSupportDxe: fix
>> ReserveResourceInGcd() calls
>>
>> On 9/17/19 9:49 PM, Laszlo Ersek wrote:
>>> The last parameter of ReserveResourceInGcd() is "ImageHandle",
>>> forwarded in turn to gDS->AllocateMemorySpace() or gDS-
>>> AllocateIoSpace() as "owner"
>>> image handle.
>>>
>>> But BlDxeEntryPoint() passes "SystemTable" as "ImageHandle".
>>>
>>> Compilers have not flagged it because EFI_HANDLE (the type of
>>> "ImageHandle") is unfortunately specified as (VOID*), and
>>> (EFI_SYSTEM_TABLE*) converts to (VOID*) silently.
>>>
>>> Hand the entry point function's "ImageHandle" parameter to
>>> ReserveResourceInGcd(). This fixes an actual bug.
>>
>> Wow very buggy, so I assume this is mostly dead code, right?
>>
>>> Cc: Benjamin You <benjamin.you@intel.com>
>>> Cc: Guo Dong <guo.dong@intel.com>
>>> Cc: Maurice Ma <maurice.ma@intel.com>
>>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>>> ---
>>>
>>> Notes:
>>> build-tested only
>>>
>>> UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c
>>> b/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c
>>> index bcee4cd9bc41..28dfc8fc5545 100644
>>> --- a/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c
>>> +++ b/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c
>>> @@ -106,10 +106,10 @@ BlDxeEntryPoint (
>>> //
>>> // Report MMIO/IO Resources
>>> //
>>> - Status = ReserveResourceInGcd (TRUE,
>>> EfiGcdMemoryTypeMemoryMappedIo, 0xFEC00000, SIZE_4KB, 0,
>> SystemTable);
>>> // IOAPIC
>>> + Status = ReserveResourceInGcd (TRUE,
>>> + EfiGcdMemoryTypeMemoryMappedIo, 0xFEC00000, SIZE_4KB, 0,
>>> + ImageHandle); // IOAPIC
>>> ASSERT_EFI_ERROR (Status);
>>>
>>> - Status = ReserveResourceInGcd (TRUE,
>>> EfiGcdMemoryTypeMemoryMappedIo, 0xFED00000, SIZE_1KB, 0,
>> SystemTable);
>>> // HPET
>>> + Status = ReserveResourceInGcd (TRUE,
>>> + EfiGcdMemoryTypeMemoryMappedIo, 0xFED00000, SIZE_1KB, 0,
>>> + ImageHandle); // HPET
>>> ASSERT_EFI_ERROR (Status);
>>>
>>> //
>>>
>>
>> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs
2019-09-17 19:49 [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs Laszlo Ersek
` (35 preceding siblings ...)
2019-09-19 0:32 ` [edk2-devel] [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs Wu, Hao A
@ 2019-09-23 16:27 ` Marvin Häuser
2019-09-24 20:26 ` Laszlo Ersek
2019-10-08 23:49 ` Laszlo Ersek
37 siblings, 1 reply; 155+ messages in thread
From: Marvin Häuser @ 2019-09-23 16:27 UTC (permalink / raw)
To: devel@edk2.groups.io, lersek@redhat.com
Cc: Andrew Fish, Anthony Perard, Ard Biesheuvel, Benjamin You,
Chao Zhang, Dandan Bi, David Woodhouse, Eric Dong, Guo Dong,
Hao A Wu, Jaben Carsey, Jian J Wang, Jiaxin Wu, Jiewen Yao,
Jordan Justen, Julien Grall, Leif Lindholm, Liming Gao,
Maurice Ma, Michael D Kinney, Ray Ni, Siyuan Fu,
Supreeth Venkatesh, Zhichao Gao
Good day,
Thank you, Laszlo, for your ambition to introduce stricter code style
enforcements. Sorry to "hijack" the actual topic (I did not CC anyone on
purpose, as this is mostly a separate topic and I'd like a quick comment
first), but this seems like a good occasion to mention another few bad
practices edk2 has been following. Mainly, I'd like to call *some*
attention to quality problems in the code base while this has some
traction, and cause a discussion on whether and how those are to be
approached.
Thank you for your time.
Regards,
Marvin
"inadequate type punning":
e.g.
https://github.com/tianocore/edk2/blob/fcdedafd97c8f18c33a63d26b954e5dbaee81a2b/MdeModulePkg/Bus/Usb/UsbBusPei/HubPeim.c#L446
This is mostly about the infamous "Strict Aliasing" rule, which is
basically:
"An object shall have its stored value accessed only by an lvalue
expression that has one of the
following types:
— a type compatible with the effective type of the object,
— a qualifed version of a type compatible with the effective type of the
object,
— a type that is the signed or unsigned type corresponding to the
effective type of the object,
— a type that is the signed or unsigned type corresponding to a qualifed
version of the effective
type of the object,
— an aggregate or union type that includes one of the aforementioned
types among its members
(including, recursively, a member of a subaggregate or contained union), or
— a character type."
C18 (ISO/IEC 9899:2018), 6.5.7 (exists, though has been updated, since C90)
Currently optimisations based on this are disabled. This is a bit nasty
to work around if *seriously* needed when sticking to C90, I can only
think of memcpy right now. However, even though there are compilers that
do not fully support C99 (ahem, Microsoft :) ), type-punning by unions
should be supported by them all, and has been legal as of C99, where the
following part has been dropped from the standard:
"With one exception, if a member of a union object is accessed after a
value has been stored in a different member of the object, the behavior
is implementation-defined."
C90 (ISO/IEC 9899:1990), 6.3.2.3
"pointer unions":
e.g.
https://github.com/tianocore/edk2/blob/fcdedafd97c8f18c33a63d26b954e5dbaee81a2b/MdePkg/Include/IndustryStandard/SmBios.h#L2592
While the idea behind them is certainly style preference, using a union
of pointers prevents two important things over a union of structs.
1) CONST declaration: When defining a variable of a union type
containing pointers as CONST, speaking of its members, they are all
going to be CONST pointers to arbitrary memory and not arbitrary
pointers to CONST memory. With a union of structs, you can have either
as required (e.g. CONST UNION_TYPE *union, or UNION_TYPE *COST union).
2) Well-defined header inspection:
"if a union contains several structures that share a common initial
sequence [...], it is permitted to inspect the common initial part of
any of them anywhere that a declaration of the completed type of the
union is visible"
C18 (ISO/IEC 9899:2018), 6.5.2.3.6 (exists since at least C90)
This guarantee can be used to inspect the type defined in a common
header (e.g. SMBIOS_STRUCTURE) and the process the type-specific data by
accessing the appropiate member (e.g. SMBIOS_TABLE_TYPE0) legally. Plain
casts and "pointer union" accesses are illegal as per the "inadequate
type punning" point above.
"casting away CONST":
e.g.
https://github.com/tianocore/edk2/blob/fcdedafd97c8f18c33a63d26b954e5dbaee81a2b/MdePkg/Library/BaseIoLibIntrinsic/IoLibMmioBuffer.c#L236
This should be obvious as Undefined Behaviour because memory previously
guaranteed to be read-only is returned as a pointer to memory that
allows writing, but for easier lookup, here's the related rule:
"the left operand has atomic, qualifed, or unqualifed pointer type, and
[...] the type pointed to by the left has all the qualifers of the type
pointed to by the right"
C18 (ISO/IEC 9899:2018), 6.5.16.1 (exists since at least C90)
"structs with trailing 1-length array"
e.g.
https://github.com/tianocore/edk2/blob/fcdedafd97c8f18c33a63d26b954e5dbaee81a2b/MdePkg/Include/Guid/FileInfo.h#L51
This is undefined as per:
"The behavior is undefned in the following circumstances:
[...]
— Addition or subtraction of a pointer into, or just beyond, an array
object and an integer type produces a result that does not point into,
or just beyond, the same array object (6.5.6).
— Addition or subtraction of a pointer into, or just beyond, an array
object and an integer type produces a result that points just beyond the
array object and is used as the operand of a unary * operator that is
evaluated (6.5.6).
— Pointers that do not point into, or just beyond, the same array object
are subtracted (6.5.6)."
C18 (ISO/IEC 9899:2018), J.2 (exists since at least C90)
Same as above, while not all compilers fully support C99, flexible
arrays should be support by all reasonably new compilers and allow a
legal declaration and usage where this hack is in place. At worst, a
macro could be provided to declare a [1] vs a [] array on demand and a
requirement be introduced to have a "SIZE_OF_" macro for each such
struct, but my personal preference would be to just enforce flexible arrays.
"Missing security checks for external data":
e.g.
https://github.com/tianocore/edk2/blob/fcdedafd97c8f18c33a63d26b954e5dbaee81a2b/MdePkg/Library/BasePeCoffLib/BasePeCoff.c#L943
The given example misses an alignment verification of the resulting
pointer (which technically has to be verified *before* casting), as
documented here:
"The behavior is undefined in the following circumstances:
[...]
— Conversion between two pointer types produces a result that is
incorrectly aligned (6.3.2.3)."
C18 (ISO/IEC 9899:2018), J.2 (exists since at least C90)
There are more such issues throughout the codebase, including missing
overflow and (or flawed, see before) bounds checks, however I cannot
find such quickly.
"signed int BIT definitions":
e.g.
https://github.com/tianocore/edk2/blob/fcdedafd97c8f18c33a63d26b954e5dbaee81a2b/MdePkg/Include/Base.h#L348
Fixing this would be prone to regressions, but I'd like to add it for
tracking purposes. Related discussion can be found down the chain here:
https://lists.01.org/pipermail/edk2-devel/2018-February/021919.html
Am 17.09.2019 um 21:49 schrieb Laszlo Ersek:
> Repository: https://github.com/lersek/edk2.git
> Branch: voidptr
>
> The UEFI / PI / Shell specifications define a number of standard types
> as pointers to VOID. This is arguably a design mistake; those types
> should have been pointers to distinct incomplete union or structure
> types. Here's why:
>
> Roughly paraphrasing the constraints from ISO C99 "6.5.16.1 Simple
> assignment" and "6.5.4 Cast operators", any pointer-to-object type
> converts implicitly to, and from, pointer-to-void, provided const /
> volatile qualifications are not relaxed. Such implicit conversions
> prevent compilers from catching at least the following two kinds of
> coding mistakes:
>
> - mixing up one type with another (for example, EFI_HANDLE with
> EFI_EVENT),
>
> - getting the depth of indirection wrong (for example, mixing up
> (EFI_HANDLE*) with EFI_HANDLE).
>
> This series first separates these standard types from each other, in the
> first patch, which is *not* being proposed for merging. This unmasks a
> number of warts (semantic issues, or actual bugs) in the source code, in
> the form of build breakages. The rest of the series works through those
> breakages, cleaning and fixing the code.
>
> Every DSC file in the edk2 tree was built for at least one of the NOOPT,
> DEBUG, RELEASE targets (NOOPT being preferred), with the GCC48 toolchain
> (for IA32 / X64) and the GCC5 toolchain (for ARM / AARCH64). Of course,
> the build arches were restricted to the SUPPORTED_ARCHITECTURES stated
> in the individual DSC files.
>
> There were two exceptions to the above rule: DynamicTablesPkg was only
> build-tested with AARCH64 (despite its SUPPORTED_ARCHITECTURES), given
> that 32-bit ARM has no ACPI bindings. StandaloneMmPkg too was only
> build-tested with AARCH64; it doesn't actually support IA32/X64 yet.
>
> Regarding boot & runtime tests, ArmVirtQemu on AARCH64 was tested with
> booting to the OS (RHEL7). Furthermore, I exercised OVMF with my usual
> boot and S3 tests, covering IA32, IA32X64, and X64. Finally, some other
> individual tests (noted per patch) were done with OVMF.
>
> Cc: Achin Gupta <achin.gupta@arm.com>
> Cc: Andrew Fish <afish@apple.com>
> Cc: Anthony Perard <anthony.perard@citrix.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Benjamin You <benjamin.you@intel.com>
> Cc: Chao Zhang <chao.b.zhang@intel.com>
> Cc: Dandan Bi <dandan.bi@intel.com>
> Cc: David Woodhouse <dwmw2@infradead.org>
> Cc: Eric Dong <eric.dong@intel.com>
> Cc: Guo Dong <guo.dong@intel.com>
> Cc: Hao A Wu <hao.a.wu@intel.com>
> Cc: Jaben Carsey <jaben.carsey@intel.com>
> Cc: Jian J Wang <jian.j.wang@intel.com>
> Cc: Jian Wang <jian.j.wang@intel.com>
> Cc: Jiaxin Wu <jiaxin.wu@intel.com>
> Cc: Jiewen Yao <jiewen.yao@intel.com>
> Cc: Jordan Justen <jordan.l.justen@intel.com>
> Cc: Julien Grall <julien.grall@arm.com>
> Cc: Leif Lindholm <leif.lindholm@linaro.org>
> Cc: Liming Gao <liming.gao@intel.com>
> Cc: Maurice Ma <maurice.ma@intel.com>
> Cc: Michael D Kinney <michael.d.kinney@intel.com>
> Cc: Ray Ni <ray.ni@intel.com>
> Cc: Siyuan Fu <siyuan.fu@intel.com>
> Cc: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
> Cc: Zhichao Gao <zhichao.gao@intel.com>
>
> Thanks
> Laszlo
>
> Laszlo Ersek (35):
> DO NOT APPLY: edk2: turn standard handle types into pointers to
> non-VOID
> EmbeddedPkg: add missing EFIAPI calling convention specifiers
> EmbeddedPkg/AndroidFastbootTransportTcpDxe: fix DestroyChild() call
> EmbeddedPkg/Universal/MmcDxe: "fix" CloseProtocol() call in
> BindingStop()
> EmulatorPkg/DxeTimerLib: drop superfluous cast
> EmulatorPkg: stop abusing EFI_HANDLE for keystroke notify registration
> MdeModulePkg: fix cast in GetModuleInfoFromHandle() calls
> MdeModulePkg/UefiHiiLib: stop using EFI_HANDLE in place of
> EFI_HII_HANDLE
> MdeModulePkg: stop abusing EFI_EVENT for protocol notify registration
> MdeModulePkg/PlatformVarCleanupLib: fix HiiConstructConfigHdr() call
> MdeModulePkg: document workaround for EFI_RUNTIME_EVENT_ENTRY PI spec
> bug
> MdeModulePkg: stop abusing EFI_HANDLE for keystroke notify
> registration
> MdeModulePkg: PEI Core: clean up "AprioriFile" handling in
> FindFileEx()
> MdeModulePkg: fix UninstallMultipleProtocolInterfaces() calls
> MdeModulePkg/PiSmmCore: make type punning consistent
> MdeModulePkg/S3SaveState: cast Position for S3BootScriptLib explicitly
> MdePkg/DxeServicesLib: remove bogus cast
> NetworkPkg/DxeNetLib: fix type typo in NetLibGetMacAddress()
> NetworkPkg: fix CloseProtocol & UninstallMultipleProtocolInterfaces
> calls
> NetworkPkg/Ip4Dxe: fix NetLibDestroyServiceChild() call
> NetworkPkg/TcpDxe: fix SockFreeFoo() parameter list
> OvmfPkg/XenBusDxe: fix UninstallMultipleProtocolInterfaces() call
> OvmfPkg/VirtioNetDxe: fix SignalEvent() call
> OvmfPkg/PlatformDxe: fix EFI_HII_HANDLE parameters of internal
> functions
> OvmfPkg/VideoDxe: document EFI_EDID_OVERRIDE_PROTOCOL.GetEdid() call
> SecurityPkg: fix UninstallMultipleProtocolInterfaces() calls
> SecurityPkg: stop abusing EFI_EVENT for protocol notify registration
> ShellPkg/UefiShellDriver1CommandsLib: fix parameter list typo
> ShellPkg: stop using EFI_HANDLE in place of EFI_HII_HANDLE
> ShellPkg: stop taking EFI_HANDLE in place of SHELL_FILE_HANDLE
> ShellPkg/UefiShellDebug1CommandsLib: fix ShellCloseFile() call
> ShellPkg/UefiShellLib: clarify workaround for unfixable EdkShell bug
> StandaloneMmPkg/Core: stop abusing EFI_HANDLE for FwVolHeader tracking
> UefiPayloadPkg/BlSupportPei: fix MMCONFIG assignment from XSDT
> UefiPayloadPkg/BlSupportDxe: fix ReserveResourceInGcd() calls
>
> EmbeddedPkg/Drivers/AndroidFastbootTransportTcpDxe/FastbootTransportTcp.c | 2 +-
> EmbeddedPkg/Drivers/ConsolePrefDxe/ConsolePrefDxe.c | 1 +
> EmbeddedPkg/Drivers/Lan9118Dxe/Lan9118Dxe.c | 1 +
> EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.h | 32 ++++++--
> EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c | 8 ++
> EmbeddedPkg/GdbStub/GdbStubInternal.h | 9 +++
> EmbeddedPkg/MetronomeDxe/Metronome.c | 1 +
> EmbeddedPkg/Universal/MmcDxe/Mmc.c | 5 +-
> EmulatorPkg/EmuGopDxe/GopInput.c | 4 +-
> EmulatorPkg/Library/DxeTimerLib/DxeTimerLib.c | 2 +-
> MdeModulePkg/Bus/I2c/I2cDxe/I2cBus.c | 2 +-
> MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c | 2 +-
> MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c | 6 +-
> MdeModulePkg/Bus/Pci/PciSioSerialDxe/Serial.c | 2 +-
> MdeModulePkg/Bus/Sd/EmmcDxe/EmmcDxe.c | 2 +-
> MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c | 2 +-
> MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassImpl.c | 2 +-
> MdeModulePkg/Core/Dxe/Event/Event.c | 8 ++
> MdeModulePkg/Core/Dxe/Event/Event.h | 2 +-
> MdeModulePkg/Core/Dxe/Hand/Handle.h | 2 +-
> MdeModulePkg/Core/Pei/FwVol/FwVol.c | 2 +-
> MdeModulePkg/Core/Pei/FwVol/FwVol.h | 2 +-
> MdeModulePkg/Core/PiSmmCore/PiSmmCore.h | 2 +-
> MdeModulePkg/Core/PiSmmCore/Smi.c | 8 +-
> MdeModulePkg/Core/RuntimeDxe/Runtime.c | 10 ++-
> MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c | 12 +--
> MdeModulePkg/Library/PlatformVarCleanupLib/PlatVarCleanupLib.c | 6 +-
> MdeModulePkg/Library/SmmCorePerformanceLib/SmmCorePerformanceLib.c | 8 +-
> MdeModulePkg/Library/UefiHiiLib/HiiString.c | 4 +-
> MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h | 2 +-
> MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c | 4 +-
> MdeModulePkg/Universal/Acpi/SmmS3SaveState/SmmS3SaveState.c | 4 +-
> MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c | 2 +-
> MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c | 4 +-
> MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c | 2 +-
> MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c | 2 +-
> MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabase.h | 2 +-
> MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.c | 2 +-
> MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c | 2 +-
> MdePkg/Include/Pi/PiPeiCis.h | 6 +-
> MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h | 3 +-
> MdePkg/Include/Protocol/Bis.h | 3 +-
> MdePkg/Include/Protocol/Eap.h | 3 +-
> MdePkg/Include/Protocol/HiiFont.h | 3 +-
> MdePkg/Include/Protocol/MmMp.h | 3 +-
> MdePkg/Include/Protocol/S3SaveState.h | 2 +-
> MdePkg/Include/Protocol/Shell.h | 3 +-
> MdePkg/Include/Protocol/UserManager.h | 9 ++-
> MdePkg/Include/Uefi/UefiBaseType.h | 6 +-
> MdePkg/Include/Uefi/UefiInternalFormRepresentation.h | 3 +-
> MdePkg/Library/DxeServicesLib/DxeServicesLib.c | 2 +-
> NetworkPkg/DnsDxe/DnsDriver.c | 4 +-
> NetworkPkg/IScsiDxe/IScsiConfig.c | 2 +-
> NetworkPkg/Ip4Dxe/Ip4Driver.c | 2 +-
> NetworkPkg/Ip4Dxe/Ip4If.c | 4 +-
> NetworkPkg/Ip6Dxe/Ip6Driver.c | 2 +-
> NetworkPkg/Library/DxeNetLib/DxeNetLib.c | 2 +-
> NetworkPkg/Mtftp4Dxe/Mtftp4Driver.c | 2 +-
> NetworkPkg/TcpDxe/SockImpl.c | 4 +-
> NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.c | 2 +-
> OvmfPkg/Csm/BiosThunk/VideoDxe/BiosVideo.c | 6 +-
> OvmfPkg/PlatformDxe/Platform.c | 4 +-
> OvmfPkg/VirtioNetDxe/Events.c | 2 +-
> OvmfPkg/XenBusDxe/XenBus.c | 2 +-
> SecurityPkg/HddPassword/HddPasswordDxe.c | 2 +-
> SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c | 2 +-
> SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c | 2 +-
> SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDriver.c | 2 +-
> ShellPkg/DynamicCommand/DpDynamicCommand/Dp.c | 6 +-
> ShellPkg/DynamicCommand/DpDynamicCommand/Dp.h | 4 +-
> ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c | 6 +-
> ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.h | 4 +-
> ShellPkg/Include/Library/ShellCommandLib.h | 2 +-
> ShellPkg/Include/Library/ShellLib.h | 4 +-
> ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c | 2 +-
> ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c | 2 +-
> ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c | 2 +-
> ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.h | 2 +-
> ShellPkg/Library/UefiShellDebug1CommandsLib/Edit/FileBuffer.c | 2 +-
> ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.c | 2 +-
> ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.h | 2 +-
> ShellPkg/Library/UefiShellDriver1CommandsLib/Connect.c | 4 +-
> ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.c | 2 +-
> ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.h | 2 +-
> ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.c | 2 +-
> ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.h | 2 +-
> ShellPkg/Library/UefiShellLevel2CommandsLib/Rm.c | 2 +-
> ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.c | 2 +-
> ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.h | 2 +-
> ShellPkg/Library/UefiShellLevel3CommandsLib/Touch.c | 2 +-
> ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.c | 2 +-
> ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.h | 2 +-
> ShellPkg/Library/UefiShellLib/UefiShellLib.c | 26 ++++++-
> ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.c | 2 +-
> ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.h | 2 +-
> ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.c | 2 +-
> ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.h | 2 +-
> StandaloneMmPkg/Core/Dispatcher.c | 80 +++++++++++---------
> StandaloneMmPkg/Core/FwVol.c | 16 ++--
> StandaloneMmPkg/Core/StandaloneMmCore.h | 4 +-
> UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c | 4 +-
> UefiPayloadPkg/BlSupportPei/BlSupportPei.c | 19 +++--
> 102 files changed, 294 insertions(+), 194 deletions(-)
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 31/35] ShellPkg/UefiShellDebug1CommandsLib: fix ShellCloseFile() call
2019-09-23 14:28 ` Carsey, Jaben
@ 2019-09-24 1:18 ` Gao, Zhichao
0 siblings, 0 replies; 155+ messages in thread
From: Gao, Zhichao @ 2019-09-24 1:18 UTC (permalink / raw)
To: Carsey, Jaben, Philippe Mathieu-Daudé, devel@edk2.groups.io,
lersek@redhat.com
Cc: Ni, Ray
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
> -----Original Message-----
> From: Carsey, Jaben
> Sent: Monday, September 23, 2019 10:29 PM
> To: Philippe Mathieu-Daudé <philmd@redhat.com>; devel@edk2.groups.io;
> lersek@redhat.com
> Cc: Ni, Ray <ray.ni@intel.com>; Gao, Zhichao <zhichao.gao@intel.com>
> Subject: RE: [edk2-devel] [PATCH 31/35]
> ShellPkg/UefiShellDebug1CommandsLib: fix ShellCloseFile() call
>
> Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
>
> Thanks
> -Jaben
>
> > -----Original Message-----
> > From: Philippe Mathieu-Daudé [mailto:philmd@redhat.com]
> > Sent: Monday, September 23, 2019 3:01 AM
> > To: devel@edk2.groups.io; lersek@redhat.com
> > Cc: Carsey, Jaben <jaben.carsey@intel.com>; Ni, Ray
> > <ray.ni@intel.com>; Gao, Zhichao <zhichao.gao@intel.com>
> > Subject: Re: [edk2-devel] [PATCH 31/35]
> > ShellPkg/UefiShellDebug1CommandsLib: fix ShellCloseFile() call
> >
> > On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> > > In the FileBufferSave() function, we invoke ShellCloseFile() if
> > > "Directory Can Not Be Saved".
> > >
> > > The ShellCloseFile() function takes a (SHELL_FILE_HANDLE*) parameter
> > > called "FileHandle", and correctly passes the de-referenced
> > > (*FileHandle) to EFI_SHELL_CLOSE_FILE, which takes a
> SHELL_FILE_HANDLE.
> > >
> > > However, FileBufferSave() passes SHELL_FILE_HANDLE to
> > > ShellCloseFile(), not the expected (SHELL_FILE_HANDLE*). Correct it.
> > >
> > > This fixes an actual bug that has remained hidden for two reasons:
> > >
> > > - pointer-to-VOID converts from/to any pointer-to-object type
> > > silently,
> > > - the bug is on an error path which has likely never fired in practice.
> > >
> > > Cc: Jaben Carsey <jaben.carsey@intel.com>
> > > Cc: Ray Ni <ray.ni@intel.com>
> > > Cc: Zhichao Gao <zhichao.gao@intel.com>
> > > Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> > > ---
> > >
> > > Notes:
> > > tested: edit (saving a file)
> > >
> > > ShellPkg/Library/UefiShellDebug1CommandsLib/Edit/FileBuffer.c | 2
> > > +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git
> > a/ShellPkg/Library/UefiShellDebug1CommandsLib/Edit/FileBuffer.c
> > b/ShellPkg/Library/UefiShellDebug1CommandsLib/Edit/FileBuffer.c
> > > index 464f9de38e52..fd324cc4a861 100644
> > > --- a/ShellPkg/Library/UefiShellDebug1CommandsLib/Edit/FileBuffer.c
> > > +++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/Edit/FileBuffer.c
> > > @@ -1462,7 +1462,7 @@ FileBufferSave (
> > >
> > > if (Info != NULL && Info->Attribute & EFI_FILE_DIRECTORY) {
> > > StatusBarSetStatusString (L"Directory Can Not Be Saved");
> > > - ShellCloseFile(FileHandle);
> > > + ShellCloseFile (&FileHandle);
> > > FreePool(Info);
> > > return EFI_LOAD_ERROR;
> > > }
> > >
> >
> > Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 07/35] MdeModulePkg: fix cast in GetModuleInfoFromHandle() calls
2019-09-17 19:49 ` [PATCH 07/35] MdeModulePkg: fix cast in GetModuleInfoFromHandle() calls Laszlo Ersek
2019-09-19 1:46 ` Dandan Bi
@ 2019-09-24 10:43 ` Philippe Mathieu-Daudé
1 sibling, 0 replies; 155+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-09-24 10:43 UTC (permalink / raw)
To: devel, lersek
Cc: Dandan Bi, Eric Dong, Hao A Wu, Jian J Wang, Liming Gao, Ray Ni
On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> GetModuleInfoFromHandle() takes an EFI_HANDLE -- (VOID*) -- as first
> parameter, but InsertFpdtRecord() passes (EFI_HANDLE*) -- (VOID**).
> (VOID**) converts silently to (VOID*), which is why the wrong cast is
> masked.
>
> Note that the *value* that is passed is alright -- therefore this patch
> does not change behavior --, it's just semantically wrong to pass an
> (EFI_HANDLE*) where an EFI_HANDLE is expected.
>
> Cc: Dandan Bi <dandan.bi@intel.com>
> Cc: Eric Dong <eric.dong@intel.com>
> Cc: Hao A Wu <hao.a.wu@intel.com>
> Cc: Jian J Wang <jian.j.wang@intel.com>
> Cc: Liming Gao <liming.gao@intel.com>
> Cc: Ray Ni <ray.ni@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> lightly tested, as DxeCorePerformanceLib is linked into ArmVirtQemu's
> DxeCore
>
> MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c | 12 ++++++------
> MdeModulePkg/Library/SmmCorePerformanceLib/SmmCorePerformanceLib.c | 8 ++++----
> 2 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c b/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c
> index 0d507c445210..f500e20b320b 100644
> --- a/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c
> +++ b/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c
> @@ -998,7 +998,7 @@ InsertFpdtRecord (
> switch (PerfId) {
> case MODULE_START_ID:
> case MODULE_END_ID:
> - GetModuleInfoFromHandle ((EFI_HANDLE *)CallerIdentifier, ModuleName, sizeof (ModuleName), &ModuleGuid);
> + GetModuleInfoFromHandle ((EFI_HANDLE)CallerIdentifier, ModuleName, sizeof (ModuleName), &ModuleGuid);
> StringPtr = ModuleName;
> //
> // Cache the offset of start image start record and use to update the start image end record if needed.
> @@ -1031,7 +1031,7 @@ InsertFpdtRecord (
>
> case MODULE_LOADIMAGE_START_ID:
> case MODULE_LOADIMAGE_END_ID:
> - GetModuleInfoFromHandle ((EFI_HANDLE *)CallerIdentifier, ModuleName, sizeof (ModuleName), &ModuleGuid);
> + GetModuleInfoFromHandle ((EFI_HANDLE)CallerIdentifier, ModuleName, sizeof (ModuleName), &ModuleGuid);
> StringPtr = ModuleName;
> if (PerfId == MODULE_LOADIMAGE_START_ID) {
> mLoadImageCount ++;
> @@ -1071,7 +1071,7 @@ InsertFpdtRecord (
> case MODULE_DB_SUPPORT_END_ID:
> case MODULE_DB_STOP_START_ID:
> case MODULE_DB_STOP_END_ID:
> - GetModuleInfoFromHandle ((EFI_HANDLE *)CallerIdentifier, ModuleName, sizeof (ModuleName), &ModuleGuid);
> + GetModuleInfoFromHandle ((EFI_HANDLE)CallerIdentifier, ModuleName, sizeof (ModuleName), &ModuleGuid);
> StringPtr = ModuleName;
> if (!PcdGetBool (PcdEdkiiFpdtStringRecordEnableOnly)) {
> FpdtRecordPtr.GuidQwordEvent->Header.Type = FPDT_GUID_QWORD_EVENT_TYPE;
> @@ -1085,7 +1085,7 @@ InsertFpdtRecord (
> break;
>
> case MODULE_DB_END_ID:
> - GetModuleInfoFromHandle ((EFI_HANDLE *)CallerIdentifier, ModuleName, sizeof (ModuleName), &ModuleGuid);
> + GetModuleInfoFromHandle ((EFI_HANDLE)CallerIdentifier, ModuleName, sizeof (ModuleName), &ModuleGuid);
> StringPtr = ModuleName;
> if (!PcdGetBool (PcdEdkiiFpdtStringRecordEnableOnly)) {
> FpdtRecordPtr.GuidQwordStringEvent->Header.Type = FPDT_GUID_QWORD_STRING_EVENT_TYPE;
> @@ -1131,7 +1131,7 @@ InsertFpdtRecord (
> case PERF_INMODULE_END_ID:
> case PERF_CROSSMODULE_START_ID:
> case PERF_CROSSMODULE_END_ID:
> - GetModuleInfoFromHandle ((EFI_HANDLE *)CallerIdentifier, ModuleName, sizeof (ModuleName), &ModuleGuid);
> + GetModuleInfoFromHandle ((EFI_HANDLE)CallerIdentifier, ModuleName, sizeof (ModuleName), &ModuleGuid);
> if (String != NULL) {
> StringPtr = String;
> } else {
> @@ -1153,7 +1153,7 @@ InsertFpdtRecord (
>
> default:
> if (Attribute != PerfEntry) {
> - GetModuleInfoFromHandle ((EFI_HANDLE *)CallerIdentifier, ModuleName, sizeof (ModuleName), &ModuleGuid);
> + GetModuleInfoFromHandle ((EFI_HANDLE)CallerIdentifier, ModuleName, sizeof (ModuleName), &ModuleGuid);
> if (String != NULL) {
> StringPtr = String;
> } else {
> diff --git a/MdeModulePkg/Library/SmmCorePerformanceLib/SmmCorePerformanceLib.c b/MdeModulePkg/Library/SmmCorePerformanceLib/SmmCorePerformanceLib.c
> index 5f07464c4ec7..b4f22c14ae73 100644
> --- a/MdeModulePkg/Library/SmmCorePerformanceLib/SmmCorePerformanceLib.c
> +++ b/MdeModulePkg/Library/SmmCorePerformanceLib/SmmCorePerformanceLib.c
> @@ -587,7 +587,7 @@ InsertFpdtRecord (
> switch (PerfId) {
> case MODULE_START_ID:
> case MODULE_END_ID:
> - GetModuleInfoFromHandle ((EFI_HANDLE *)CallerIdentifier, ModuleName, sizeof (ModuleName), &ModuleGuid);
> + GetModuleInfoFromHandle ((EFI_HANDLE)CallerIdentifier, ModuleName, sizeof (ModuleName), &ModuleGuid);
> StringPtr = ModuleName;
> //
> // Cache the offset of start image start record and use to update the start image end record if needed.
> @@ -612,7 +612,7 @@ InsertFpdtRecord (
>
> case MODULE_LOADIMAGE_START_ID:
> case MODULE_LOADIMAGE_END_ID:
> - GetModuleInfoFromHandle ((EFI_HANDLE *)CallerIdentifier, ModuleName, sizeof (ModuleName), &ModuleGuid);
> + GetModuleInfoFromHandle ((EFI_HANDLE)CallerIdentifier, ModuleName, sizeof (ModuleName), &ModuleGuid);
> StringPtr = ModuleName;
> if (PerfId == MODULE_LOADIMAGE_START_ID) {
> mLoadImageCount++;
> @@ -669,7 +669,7 @@ InsertFpdtRecord (
> case PERF_INMODULE_END_ID:
> case PERF_CROSSMODULE_START_ID:
> case PERF_CROSSMODULE_END_ID:
> - GetModuleInfoFromHandle ((EFI_HANDLE *)CallerIdentifier, ModuleName, sizeof (ModuleName), &ModuleGuid);
> + GetModuleInfoFromHandle ((EFI_HANDLE)CallerIdentifier, ModuleName, sizeof (ModuleName), &ModuleGuid);
> if (String != NULL) {
> StringPtr = String;
> } else {
> @@ -691,7 +691,7 @@ InsertFpdtRecord (
>
> default:
> if (Attribute != PerfEntry) {
> - GetModuleInfoFromHandle ((EFI_HANDLE *)CallerIdentifier, ModuleName, sizeof (ModuleName), &ModuleGuid);
> + GetModuleInfoFromHandle ((EFI_HANDLE)CallerIdentifier, ModuleName, sizeof (ModuleName), &ModuleGuid);
> if (String != NULL) {
> StringPtr = String;
> } else {
>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 06/35] EmulatorPkg: stop abusing EFI_HANDLE for keystroke notify registration
2019-09-17 19:49 ` [PATCH 06/35] EmulatorPkg: stop abusing EFI_HANDLE for keystroke notify registration Laszlo Ersek
2019-09-17 20:01 ` Ni, Ray
@ 2019-09-24 10:44 ` Philippe Mathieu-Daudé
1 sibling, 0 replies; 155+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-09-24 10:44 UTC (permalink / raw)
To: devel, lersek; +Cc: Andrew Fish, Jordan Justen, Ray Ni
On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> EFI_REGISTER_KEYSTROKE_NOTIFY and EFI_UNREGISTER_KEYSTROKE_NOTIFY require
> the notification handle to have type (VOID*). The notification handle has
> nothing to do with the EFI_HANDLE type.
>
> This change is a semantic fix; functionally, it's a no-op.
>
> Cc: Andrew Fish <afish@apple.com>
> Cc: Jordan Justen <jordan.l.justen@intel.com>
> Cc: Ray Ni <ray.ni@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> build-tested only
>
> EmulatorPkg/EmuGopDxe/GopInput.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/EmulatorPkg/EmuGopDxe/GopInput.c b/EmulatorPkg/EmuGopDxe/GopInput.c
> index fdd0b4911555..2a23564a2173 100644
> --- a/EmulatorPkg/EmuGopDxe/GopInput.c
> +++ b/EmulatorPkg/EmuGopDxe/GopInput.c
> @@ -517,7 +517,7 @@ EmuGopSimpleTextInExRegisterKeyNotify (
> IN EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL *This,
> IN EFI_KEY_DATA *KeyData,
> IN EFI_KEY_NOTIFY_FUNCTION KeyNotificationFunction,
> - OUT EFI_HANDLE *NotifyHandle
> + OUT VOID **NotifyHandle
> )
> {
> EFI_STATUS Status;
> @@ -600,7 +600,7 @@ EFI_STATUS
> EFIAPI
> EmuGopSimpleTextInExUnregisterKeyNotify (
> IN EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL *This,
> - IN EFI_HANDLE NotificationHandle
> + IN VOID *NotificationHandle
> )
> /*++
>
>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 03/35] EmbeddedPkg/AndroidFastbootTransportTcpDxe: fix DestroyChild() call
2019-09-17 19:49 ` [PATCH 03/35] EmbeddedPkg/AndroidFastbootTransportTcpDxe: fix DestroyChild() call Laszlo Ersek
@ 2019-09-24 10:47 ` Philippe Mathieu-Daudé
2019-09-26 12:12 ` Laszlo Ersek
2019-09-26 12:16 ` Ard Biesheuvel
2 siblings, 0 replies; 155+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-09-24 10:47 UTC (permalink / raw)
To: devel, lersek; +Cc: Ard Biesheuvel, Leif Lindholm
On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> - The 2nd parameter of EFI_SERVICE_BINDING_CREATE_CHILD is:
>
> IN OUT EFI_HANDLE *ChildHandle
>
> - The 2nd parameter of EFI_SERVICE_BINDING_DESTROY_CHILD is:
>
> IN EFI_HANDLE ChildHandle
>
> Fix the DestroyChild() call in TcpFastbootTransportStop().
>
> This is an actual bugfix; I don't know why the current code doesn't crash.
> Perhaps the function is never reached in practice? (It could be tied to an
> error path.)
>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Leif Lindholm <leif.lindholm@linaro.org>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> build-tested only
>
> EmbeddedPkg/Drivers/AndroidFastbootTransportTcpDxe/FastbootTransportTcp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/EmbeddedPkg/Drivers/AndroidFastbootTransportTcpDxe/FastbootTransportTcp.c b/EmbeddedPkg/Drivers/AndroidFastbootTransportTcpDxe/FastbootTransportTcp.c
> index 29f23a82c75f..34f9ba74e4db 100644
> --- a/EmbeddedPkg/Drivers/AndroidFastbootTransportTcpDxe/FastbootTransportTcp.c
> +++ b/EmbeddedPkg/Drivers/AndroidFastbootTransportTcpDxe/FastbootTransportTcp.c
> @@ -503,7 +503,7 @@ TcpFastbootTransportStop (
> Status = mTcpListener->Configure (mTcpListener, NULL);
> ASSERT_EFI_ERROR (Status);
>
> - Status = mTcpServiceBinding->DestroyChild (mTcpServiceBinding, &mTcpHandle);
> + Status = mTcpServiceBinding->DestroyChild (mTcpServiceBinding, mTcpHandle);
>
> // Free any data the user didn't pick up
> Entry = (FASTBOOT_TCP_PACKET_LIST *) GetFirstNode (&mPacketListHead);
>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 08/35] MdeModulePkg/UefiHiiLib: stop using EFI_HANDLE in place of EFI_HII_HANDLE
2019-09-17 19:49 ` [PATCH 08/35] MdeModulePkg/UefiHiiLib: stop using EFI_HANDLE in place of EFI_HII_HANDLE Laszlo Ersek
2019-09-19 1:46 ` Dandan Bi
@ 2019-09-24 10:49 ` Philippe Mathieu-Daudé
1 sibling, 0 replies; 155+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-09-24 10:49 UTC (permalink / raw)
To: devel, lersek; +Cc: Dandan Bi, Eric Dong, Hao A Wu, Jian J Wang
On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> HiiGetHiiHandles() returns an array of EFI_HII_HANDLEs, not EFI_HANDLEs.
> HiiGetString() takes an EFI_HII_HANDLE, not an EFI_HANDLE.
>
> This change is a no-op in practice; it's a semantic improvement.
>
> Cc: Dandan Bi <dandan.bi@intel.com>
> Cc: Eric Dong <eric.dong@intel.com>
> Cc: Hao A Wu <hao.a.wu@intel.com>
> Cc: Jian J Wang <jian.j.wang@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> lightly tested, as UefiHiiLib is used by both ArmVirt and OVMF
>
> MdeModulePkg/Library/UefiHiiLib/HiiString.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/MdeModulePkg/Library/UefiHiiLib/HiiString.c b/MdeModulePkg/Library/UefiHiiLib/HiiString.c
> index 498f245dce1f..95229f8a8c9f 100644
> --- a/MdeModulePkg/Library/UefiHiiLib/HiiString.c
> +++ b/MdeModulePkg/Library/UefiHiiLib/HiiString.c
> @@ -173,8 +173,8 @@ HiiGetPackageString (
> IN CONST CHAR8 *Language OPTIONAL
> )
> {
> - EFI_HANDLE *HiiHandleBuffer;
> - EFI_HANDLE HiiHandle;
> + EFI_HII_HANDLE *HiiHandleBuffer;
> + EFI_HII_HANDLE HiiHandle;
>
> ASSERT (PackageListGuid != NULL);
>
>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 12/35] MdeModulePkg: stop abusing EFI_HANDLE for keystroke notify registration
2019-09-17 19:49 ` [PATCH 12/35] MdeModulePkg: stop abusing EFI_HANDLE for keystroke notify registration Laszlo Ersek
2019-09-17 20:16 ` [edk2-devel] " Ni, Ray
2019-09-19 1:47 ` Dandan Bi
@ 2019-09-24 10:54 ` Philippe Mathieu-Daudé
2 siblings, 0 replies; 155+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-09-24 10:54 UTC (permalink / raw)
To: devel, lersek
Cc: Dandan Bi, Eric Dong, Hao A Wu, Jian J Wang, Ray Ni, Zhichao Gao
On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> EFI_REGISTER_KEYSTROKE_NOTIFY and EFI_UNREGISTER_KEYSTROKE_NOTIFY require
> the notification handle to have type (VOID*). The notification handle has
> nothing to do with the EFI_HANDLE type.
>
> This change is a semantic fix; functionally, it's a no-op.
>
> Cc: Dandan Bi <dandan.bi@intel.com>
> Cc: Eric Dong <eric.dong@intel.com>
> Cc: Hao A Wu <hao.a.wu@intel.com>
> Cc: Jian J Wang <jian.j.wang@intel.com>
> Cc: Ray Ni <ray.ni@intel.com>
> Cc: Zhichao Gao <zhichao.gao@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> lightly tested: ConSplitterDxe is part of the ArmVirt and OVMF platforms
>
> MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c | 2 +-
> MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c b/MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c
> index 63c814ae1816..9c38271b65f9 100644
> --- a/MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c
> +++ b/MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c
> @@ -4026,7 +4026,7 @@ ConSplitterTextInRegisterKeyNotify (
> if (NewNotify == NULL) {
> return EFI_OUT_OF_RESOURCES;
> }
> - NewNotify->NotifyHandleList = (EFI_HANDLE *) AllocateZeroPool (sizeof (EFI_HANDLE) * Private->TextInExListCount);
> + NewNotify->NotifyHandleList = (VOID **) AllocateZeroPool (sizeof (VOID *) * Private->TextInExListCount);
TEXT_IN_EX_SPLITTER_NOTIFY->NotifyHandleList is of type (VOID **), OK.
> if (NewNotify->NotifyHandleList == NULL) {
> gBS->FreePool (NewNotify);
> return EFI_OUT_OF_RESOURCES;
> diff --git a/MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c b/MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c
> index 7cfd5c178861..f98797225b63 100644
> --- a/MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c
> +++ b/MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c
> @@ -143,7 +143,7 @@ InternalStartMonitor(
> EFI_HANDLE *Handles;
> UINTN HandleCount;
> UINTN HandleIndex;
> - EFI_HANDLE NotifyHandle;
> + VOID *NotifyHandle;
>
> Status = gBS->LocateHandleBuffer (
> ByProtocol,
> @@ -202,7 +202,7 @@ InternalStopMonitor(
> EFI_KEY_DATA KeyData;
> UINTN HandleCount;
> UINTN HandleIndex;
> - EFI_HANDLE NotifyHandle;
> + VOID *NotifyHandle;
>
> Status = gBS->LocateHandleBuffer (
> ByProtocol,
>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 18/35] NetworkPkg/DxeNetLib: fix type typo in NetLibGetMacAddress()
2019-09-17 19:49 ` [PATCH 18/35] NetworkPkg/DxeNetLib: fix type typo in NetLibGetMacAddress() Laszlo Ersek
@ 2019-09-24 11:00 ` Philippe Mathieu-Daudé
2019-10-08 0:32 ` Siyuan, Fu
2019-09-26 12:14 ` Laszlo Ersek
2019-10-07 18:15 ` Michael D Kinney
2 siblings, 1 reply; 155+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-09-24 11:00 UTC (permalink / raw)
To: devel, lersek; +Cc: Jiaxin Wu, Siyuan Fu
On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> NetLibGetSnpHandle() returns an EFI_HANDLE, not an (EFI_HANDLE*).
> NetLibGetMacAddress() only uses the return value ("SnpHandle") for a
> NULL-check. Fix the type of "SnpHandle".
>
> This patch is a no-op.
>
> Cc: Jiaxin Wu <jiaxin.wu@intel.com>
> Cc: Siyuan Fu <siyuan.fu@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> lightly tested: MAC strings are displayed in UiApp
>
> NetworkPkg/Library/DxeNetLib/DxeNetLib.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/NetworkPkg/Library/DxeNetLib/DxeNetLib.c b/NetworkPkg/Library/DxeNetLib/DxeNetLib.c
> index 8e2f720666ea..a39c20be3d34 100644
> --- a/NetworkPkg/Library/DxeNetLib/DxeNetLib.c
> +++ b/NetworkPkg/Library/DxeNetLib/DxeNetLib.c
> @@ -2182,7 +2182,7 @@ NetLibGetMacAddress (
> EFI_SIMPLE_NETWORK_MODE SnpModeData;
> EFI_MANAGED_NETWORK_PROTOCOL *Mnp;
> EFI_SERVICE_BINDING_PROTOCOL *MnpSb;
> - EFI_HANDLE *SnpHandle;
> + EFI_HANDLE SnpHandle;
> EFI_HANDLE MnpChildHandle;
>
> ASSERT (MacAddress != NULL);
>
Since SnpHandle is only checked for being non-null, this change is
indeed a no-op, else it would probably fixed some bug.
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 17/35] MdePkg/DxeServicesLib: remove bogus cast
2019-09-17 19:49 ` [PATCH 17/35] MdePkg/DxeServicesLib: remove bogus cast Laszlo Ersek
2019-09-18 4:47 ` [edk2-devel] " Liming Gao
@ 2019-09-24 15:38 ` Philippe Mathieu-Daudé
1 sibling, 0 replies; 155+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-09-24 15:38 UTC (permalink / raw)
To: devel, lersek; +Cc: Liming Gao, Michael D Kinney
On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> The HandleProtocol() boot service takes an EFI_HANDLE, not an
> (EFI_HANDLE*). Remove the bogus cast in the
> InternalImageHandleToFvHandle() function.
>
> This is a semantic cleanup; there is no change in behavior.
>
> Cc: Liming Gao <liming.gao@intel.com>
> Cc: Michael D Kinney <michael.d.kinney@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> lightly tested, most probably: it's practically impossible to build a
> platform without consuming DxeServicesLib
>
> MdePkg/Library/DxeServicesLib/DxeServicesLib.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MdePkg/Library/DxeServicesLib/DxeServicesLib.c b/MdePkg/Library/DxeServicesLib/DxeServicesLib.c
> index c416b2dd8c65..0735b2f80400 100644
> --- a/MdePkg/Library/DxeServicesLib/DxeServicesLib.c
> +++ b/MdePkg/Library/DxeServicesLib/DxeServicesLib.c
> @@ -49,7 +49,7 @@ InternalImageHandleToFvHandle (
> ASSERT (ImageHandle != NULL);
>
> Status = gBS->HandleProtocol (
> - (EFI_HANDLE *) ImageHandle,
> + ImageHandle,
> &gEfiLoadedImageProtocolGuid,
> (VOID **) &LoadedImage
> );
>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 13/35] MdeModulePkg: PEI Core: clean up "AprioriFile" handling in FindFileEx()
2019-09-17 19:49 ` [PATCH 13/35] MdeModulePkg: PEI Core: clean up "AprioriFile" handling in FindFileEx() Laszlo Ersek
2019-09-19 1:46 ` Dandan Bi
@ 2019-09-24 15:40 ` Philippe Mathieu-Daudé
1 sibling, 0 replies; 155+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-09-24 15:40 UTC (permalink / raw)
To: devel, lersek; +Cc: Dandan Bi, Hao A Wu, Jian J Wang, Liming Gao
On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> Clean up two issues around FindFileEx():
>
> - The "AprioriFile" parameter's type differs between the function
> declaration and the function definition. The correct type is
> (EFI_PEI_FILE_HANDLE*).
>
> - "FfsFileHeader" has type (EFI_FFS_FILE_HEADER*); for clarity, we should
> cast it explicitly to EFI_PEI_FILE_HANDLE when assigning it to
> (*AprioriFile).
>
> This is a semantic cleanup, there is no functional change.
>
> Cc: Dandan Bi <dandan.bi@intel.com>
> Cc: Hao A Wu <hao.a.wu@intel.com>
> Cc: Jian J Wang <jian.j.wang@intel.com>
> Cc: Liming Gao <liming.gao@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> lightly tested: OVMF uses APRIORI PEI in the FDF files
>
> MdeModulePkg/Core/Pei/FwVol/FwVol.h | 2 +-
> MdeModulePkg/Core/Pei/FwVol/FwVol.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/MdeModulePkg/Core/Pei/FwVol/FwVol.h b/MdeModulePkg/Core/Pei/FwVol/FwVol.h
> index 4082cfbec1f8..ca80e84e0fcb 100644
> --- a/MdeModulePkg/Core/Pei/FwVol/FwVol.h
> +++ b/MdeModulePkg/Core/Pei/FwVol/FwVol.h
> @@ -299,7 +299,7 @@ FindFileEx (
> IN CONST EFI_GUID *FileName, OPTIONAL
> IN EFI_FV_FILETYPE SearchType,
> IN OUT EFI_PEI_FILE_HANDLE *FileHandle,
> - IN OUT EFI_PEI_FV_HANDLE *AprioriFile OPTIONAL
> + IN OUT EFI_PEI_FILE_HANDLE *AprioriFile OPTIONAL
> );
>
> /**
> diff --git a/MdeModulePkg/Core/Pei/FwVol/FwVol.c b/MdeModulePkg/Core/Pei/FwVol/FwVol.c
> index 709db00694c2..f4642c47c13a 100644
> --- a/MdeModulePkg/Core/Pei/FwVol/FwVol.c
> +++ b/MdeModulePkg/Core/Pei/FwVol/FwVol.c
> @@ -407,7 +407,7 @@ FindFileEx (
> } else if (AprioriFile != NULL) {
> if (FfsFileHeader->Type == EFI_FV_FILETYPE_FREEFORM) {
> if (CompareGuid (&FfsFileHeader->Name, &gPeiAprioriFileNameGuid)) {
> - *AprioriFile = FfsFileHeader;
> + *AprioriFile = (EFI_PEI_FILE_HANDLE)FfsFileHeader;
> }
> }
> }
>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 28/35] ShellPkg/UefiShellDriver1CommandsLib: fix parameter list typo
2019-09-17 19:49 ` [PATCH 28/35] ShellPkg/UefiShellDriver1CommandsLib: fix parameter list typo Laszlo Ersek
@ 2019-09-24 15:44 ` Philippe Mathieu-Daudé
2019-09-26 2:46 ` Gao, Zhichao
1 sibling, 0 replies; 155+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-09-24 15:44 UTC (permalink / raw)
To: devel, lersek; +Cc: Jaben Carsey, Ray Ni, Zhichao Gao
On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> The ShellCommandRunConnect() function passes EFI_HANDLE -- (VOID*) --
> objects to ConvertAndConnectControllers(), and
> ConvertAndConnectControllers() passes those to gBS->OpenProtocol().
>
> Accordingly, ConvertAndConnectControllers() should specify EFI_HANDLE
> parameter types, not (EFI_HANDLE*) -- (VOID**) -- types.
>
> This typo is masked because (VOID*) converts to and from any
> pointer-to-object type silently.
>
> Note that functionally speaking there is no problem, so this patch does
> not change beavior, only cleans up the code.
>
> Cc: Jaben Carsey <jaben.carsey@intel.com>
> Cc: Ray Ni <ray.ni@intel.com>
> Cc: Zhichao Gao <zhichao.gao@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> tested with "connect -r"
>
> ShellPkg/Library/UefiShellDriver1CommandsLib/Connect.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/ShellPkg/Library/UefiShellDriver1CommandsLib/Connect.c b/ShellPkg/Library/UefiShellDriver1CommandsLib/Connect.c
> index 359394dfd291..3f4e132674ea 100644
> --- a/ShellPkg/Library/UefiShellDriver1CommandsLib/Connect.c
> +++ b/ShellPkg/Library/UefiShellDriver1CommandsLib/Connect.c
> @@ -346,8 +346,8 @@ ShellConnectFromDevPaths (
> **/
> EFI_STATUS
> ConvertAndConnectControllers (
> - IN EFI_HANDLE *Handle1 OPTIONAL,
> - IN EFI_HANDLE *Handle2 OPTIONAL,
> + IN EFI_HANDLE Handle1 OPTIONAL,
> + IN EFI_HANDLE Handle2 OPTIONAL,
> IN CONST BOOLEAN Recursive,
> IN CONST BOOLEAN Output
> )
>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 10/35] MdeModulePkg/PlatformVarCleanupLib: fix HiiConstructConfigHdr() call
2019-09-23 11:45 ` [edk2-devel] " Philippe Mathieu-Daudé
@ 2019-09-24 17:28 ` Laszlo Ersek
0 siblings, 0 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-24 17:28 UTC (permalink / raw)
To: Philippe Mathieu-Daudé, devel; +Cc: Hao A Wu, Jian J Wang, Liming Gao
On 09/23/19 13:45, Philippe Mathieu-Daudé wrote:
> On 9/17/19 9:49 PM, Laszlo Ersek wrote:
>> The HiiConstructConfigHdr() function takes the "DriverHandle" parameter in
>> order to fetch the device path from it, and then turn the device path into
>> PATH routing information.
>>
>> The HiiConstructConfigHdr() function is called from
>> VariableCleanupHiiExtractConfig(), which is only installed when "Type" is
>> "VarCleanupManually" in PlatformVarCleanup().
>>
>> In that case, we create "Private->DriverHandle" as a new handle, and
>> install "mVarCleanupHiiVendorDevicePath" on it. Then we pass
>> "Private->DriverHandle" to HiiAddPackages(), which consumes the device
>> path for routing purposes.
>>
>> It follows that the "DriverHandle" argument pased to
>
> "passed"
Good catch, thanks! (For the other reviews as well, of course!)
Laszlo
>
>> HiiConstructConfigHdr() should be the same driver handle, for matching
>> routing.
>>
>> Currently we pass "Private->HiiHandle", which is clearly a typo, because
>> it is the return value of HiiAddPackages(), and stands for the published
>> HII package list.
>
> Phew...
>
>> Therefore this patch addresses an actual bug.
>>
>> The typo has not been flagged by compilers because the UEFI spec
>> regrettably defines both EFI_HANDLE and EFI_HII_HANDLE as (VOID*).
>>
>> Cc: Hao A Wu <hao.a.wu@intel.com>
>> Cc: Jian J Wang <jian.j.wang@intel.com>
>> Cc: Liming Gao <liming.gao@intel.com>
>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>> ---
>>
>> Notes:
>> build-tested only
>>
>> MdeModulePkg/Library/PlatformVarCleanupLib/PlatVarCleanupLib.c | 6 +++++-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/MdeModulePkg/Library/PlatformVarCleanupLib/PlatVarCleanupLib.c b/MdeModulePkg/Library/PlatformVarCleanupLib/PlatVarCleanupLib.c
>> index 968c044a316a..3875d614bb41 100644
>> --- a/MdeModulePkg/Library/PlatformVarCleanupLib/PlatVarCleanupLib.c
>> +++ b/MdeModulePkg/Library/PlatformVarCleanupLib/PlatVarCleanupLib.c
>> @@ -609,7 +609,11 @@ VariableCleanupHiiExtractConfig (
>> // Allocate and fill a buffer large enough to hold the <ConfigHdr> template
>> // followed by "&OFFSET=0&WIDTH=WWWWWWWWWWWWWWWW" followed by a Null-terminator.
>> //
>> - ConfigRequestHdr = HiiConstructConfigHdr (&mVariableCleanupHiiGuid, mVarStoreName, Private->HiiHandle);
>> + ConfigRequestHdr = HiiConstructConfigHdr (
>> + &mVariableCleanupHiiGuid,
>> + mVarStoreName,
>> + Private->DriverHandle
>> + );
>> Size = (StrLen (ConfigRequestHdr) + 32 + 1) * sizeof (CHAR16);
>> ConfigRequest = AllocateZeroPool (Size);
>> ASSERT (ConfigRequest != NULL);
>>
>
> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 35/35] UefiPayloadPkg/BlSupportDxe: fix ReserveResourceInGcd() calls
2019-09-23 15:08 ` Philippe Mathieu-Daudé
2019-09-23 16:02 ` Guo Dong
@ 2019-09-24 17:29 ` Laszlo Ersek
1 sibling, 0 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-24 17:29 UTC (permalink / raw)
To: Philippe Mathieu-Daudé, devel; +Cc: Benjamin You, Guo Dong, Maurice Ma
On 09/23/19 17:08, Philippe Mathieu-Daudé wrote:
> On 9/17/19 9:49 PM, Laszlo Ersek wrote:
>> The last parameter of ReserveResourceInGcd() is "ImageHandle", forwarded
>> in turn to gDS->AllocateMemorySpace() or gDS->AllocateIoSpace() as "owner"
>> image handle.
>>
>> But BlDxeEntryPoint() passes "SystemTable" as "ImageHandle".
>>
>> Compilers have not flagged it because EFI_HANDLE (the type of
>> "ImageHandle") is unfortunately specified as (VOID*), and
>> (EFI_SYSTEM_TABLE*) converts to (VOID*) silently.
>>
>> Hand the entry point function's "ImageHandle" parameter to
>> ReserveResourceInGcd(). This fixes an actual bug.
>
> Wow very buggy, so I assume this is mostly dead code, right?
Not necessarily; as long as noone tries to use the "owner" image handle
in practice, the issue may remain dormant.
Thanks
Laszlo
>> Cc: Benjamin You <benjamin.you@intel.com>
>> Cc: Guo Dong <guo.dong@intel.com>
>> Cc: Maurice Ma <maurice.ma@intel.com>
>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>> ---
>>
>> Notes:
>> build-tested only
>>
>> UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c b/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c
>> index bcee4cd9bc41..28dfc8fc5545 100644
>> --- a/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c
>> +++ b/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c
>> @@ -106,10 +106,10 @@ BlDxeEntryPoint (
>> //
>> // Report MMIO/IO Resources
>> //
>> - Status = ReserveResourceInGcd (TRUE, EfiGcdMemoryTypeMemoryMappedIo, 0xFEC00000, SIZE_4KB, 0, SystemTable); // IOAPIC
>> + Status = ReserveResourceInGcd (TRUE, EfiGcdMemoryTypeMemoryMappedIo, 0xFEC00000, SIZE_4KB, 0, ImageHandle); // IOAPIC
>> ASSERT_EFI_ERROR (Status);
>>
>> - Status = ReserveResourceInGcd (TRUE, EfiGcdMemoryTypeMemoryMappedIo, 0xFED00000, SIZE_1KB, 0, SystemTable); // HPET
>> + Status = ReserveResourceInGcd (TRUE, EfiGcdMemoryTypeMemoryMappedIo, 0xFED00000, SIZE_1KB, 0, ImageHandle); // HPET
>> ASSERT_EFI_ERROR (Status);
>>
>> //
>>
>
> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs
2019-09-23 16:27 ` Marvin Häuser
@ 2019-09-24 20:26 ` Laszlo Ersek
2019-09-25 8:13 ` Marvin Häuser
0 siblings, 1 reply; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-24 20:26 UTC (permalink / raw)
To: Marvin Häuser, devel@edk2.groups.io
Cc: Andrew Fish, Anthony Perard, Ard Biesheuvel, Benjamin You,
Chao Zhang, Dandan Bi, David Woodhouse, Eric Dong, Guo Dong,
Hao A Wu, Jaben Carsey, Jian J Wang, Jiaxin Wu, Jiewen Yao,
Jordan Justen, Julien Grall, Leif Lindholm, Liming Gao,
Maurice Ma, Michael D Kinney, Ray Ni, Siyuan Fu,
Supreeth Venkatesh, Zhichao Gao
On 09/23/19 18:27, Marvin Häuser wrote:
> Good day,
>
> Thank you, Laszlo, for your ambition to introduce stricter code style
> enforcements. Sorry to "hijack" the actual topic (I did not CC anyone on
> purpose, as this is mostly a separate topic and I'd like a quick comment
> first), but this seems like a good occasion to mention another few bad
> practices edk2 has been following. Mainly, I'd like to call *some*
> attention to quality problems in the code base while this has some
> traction, and cause a discussion on whether and how those are to be
> approached.
>
> Thank you for your time.
Sure, I can offer my personal opinion on these.
> "inadequate type punning":
> e.g.
> https://github.com/tianocore/edk2/blob/fcdedafd97c8f18c33a63d26b954e5dbaee81a2b/MdeModulePkg/Bus/Usb/UsbBusPei/HubPeim.c#L446
>
> This is mostly about the infamous "Strict Aliasing" rule, which is
> basically:
> "An object shall have its stored value accessed only by an lvalue
> expression that has one of the
> following types:
> — a type compatible with the effective type of the object,
> — a qualifed version of a type compatible with the effective type of the
> object,
> — a type that is the signed or unsigned type corresponding to the
> effective type of the object,
> — a type that is the signed or unsigned type corresponding to a qualifed
> version of the effective
> type of the object,
> — an aggregate or union type that includes one of the aforementioned
> types among its members
> (including, recursively, a member of a subaggregate or contained union), or
> — a character type."
> C18 (ISO/IEC 9899:2018), 6.5.7 (exists, though has been updated, since C90)
>
> Currently optimisations based on this are disabled. This is a bit nasty
> to work around if *seriously* needed when sticking to C90, I can only
> think of memcpy right now. However, even though there are compilers that
> do not fully support C99 (ahem, Microsoft :) ), type-punning by unions
> should be supported by them all, and has been legal as of C99, where the
> following part has been dropped from the standard:
> "With one exception, if a member of a union object is accessed after a
> value has been stored in a different member of the object, the behavior
> is implementation-defined."
> C90 (ISO/IEC 9899:1990), 6.3.2.3
I'm opposed to enforcing the strict aliasing rules, even though in all
code that I write, I either try to conform to them, or at least I seek
to be fully conscious of breaking them.
Here's the thing: IMO, the strict aliasing rules sacrifice flexibility
for performance (optimization possibilities). Not to mention the amount
of code in edk2 that would have to be identified and updated.
BaseTools uses "-fno-strict-aliasing" everywhere, and I think that's a
good choice.
https://blog.regehr.org/archives/1180
This proposal for a "friendly dialect of C" intended to eliminate the
strict aliasing rules altogether. (Item#10; possibly also item#13.)
Also, as it points out, the Linux kernel is built with
"-fno-strict-aliasing". I've checked now, with a *long* series of "git
blame" commands, even digging into the "history" repository (which is at
<git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git>). I can
say that the current flag has been in place since *at least* Linux
v2.5.0 (2002-02-04).
QEMU has been built with "-fno-strict-aliasing" ever since commit
b932caba32c6 ("new disk image layer", 2004-08-01), known originally as
SVN rev 1030.
Consider the following example. You have a dynamically allocated buffer.
You read some data into it, from the network or the disk, using PCI DMA.
Let's assume that, from the block read via PCI DMA, the library
function(s) or protocol member(s) that you call, directly or indirectly,
there is at least one that:
- copies data from a source buffer to a target buffer, using UINT32 or
UINT64 assignments (for speed),
- and is implemented in C.
Now, according to the effective type rules, your dynamic buffer's
effective type is "array of UINT32" or "array of UINT64". That's because
of C99 6.5 Expressions, p6:
"If a value is stored into an object having no declared type through an
lvalue having a type that is not a character type, then the type of the
lvalue becomes the effective type of the object for that access and for
subsequent accesses that do not modify the stored value."
Then if you try to parse this buffer as a UEFI device path (= a packed
sequence of device path node structures), *IN PLACE*, you will break the
effective type rules no matter what. Because, you will necessarily look
at the next node in the blob as an EFI_DEVICE_PATH_PROTOCOL (because
you'll want to learn the Type and the SubType fields, and the Length
array too). Note that EFI_DEVICE_PATH_PROTOCOL is a structure with no
UINT32 or UINT64 members. Boom.
So you have to resort to one of the following things:
1. Define a union type, assign the *full union* first
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90167#c3>, and then check
the union helper variable. (First you must make sure there was enough
room in the buffer being parsed for a full union.)
2. Or, use memcpy() -- or something that the compiler is similarly
enlightened about --, to the same helper variable.
3. Or, write a manual copy loop with character access, to the helper
variable.
4. Or, use character access to read the fields.
#1 through #3 add a separate copying step, while #4 is extremely
uncomfortable to program.
In a nutshell, the effective type rules require separate
de-serialization routines for all data, and that's incredibly annoying.
It kills the utility of packed C structures.
I prefer packed C structures, size checks (!!!) against the buffers to
parse, and then type punning of pointers.
> "pointer unions":
> e.g.
> https://github.com/tianocore/edk2/blob/fcdedafd97c8f18c33a63d26b954e5dbaee81a2b/MdePkg/Include/IndustryStandard/SmBios.h#L2592
>
> While the idea behind them is certainly style preference, using a union
> of pointers prevents two important things over a union of structs.
>
> 1) CONST declaration: When defining a variable of a union type
> containing pointers as CONST, speaking of its members, they are all
> going to be CONST pointers to arbitrary memory and not arbitrary
> pointers to CONST memory. With a union of structs, you can have either
> as required (e.g. CONST UNION_TYPE *union, or UNION_TYPE *COST union).
Formally, you are right, but I'm doubtful of the utility of
"pointer-to-union-of-structs". We cannot de-reference a pointer to the
union unless the buffer has enough data for the complete union. This
leaves the parsing of small structs unsolved.
A union of pointers is just syntactic sugar, of course, but it's
convenient. The member that is "pointer-to-smallest-header-substructure"
can be used for determining the actual structure type. Then we can
determine if there's enough data for that structure in the buffer. Then
we can use the matching pointer member, for accessing that structure.
Furthermore, CONST gets too complex really soon, and we have to start
adding explicit casts. My favorite link is:
http://c-faq.com/ansi/constmismatch.html
I had never met "pointer unions" before edk2, but I've found them quite
convenient.
> 2) Well-defined header inspection:
> "if a union contains several structures that share a common initial
> sequence [...], it is permitted to inspect the common initial part of
> any of them anywhere that a declaration of the completed type of the
> union is visible"
> C18 (ISO/IEC 9899:2018), 6.5.2.3.6 (exists since at least C90)
>
> This guarantee can be used to inspect the type defined in a common
> header (e.g. SMBIOS_STRUCTURE) and the process the type-specific data by
> accessing the appropiate member (e.g. SMBIOS_TABLE_TYPE0) legally.
This only applies *after* you have populated the union for inspection.
(Or at least enough bytes for the common header that you're going to
inspect.)
If you have a union collecting three structures: 5 bytes, 19 bytes, and
32 bytes, and you have a buffer with 24 bytes left (suggesting a 5 byte
structure and a 19 byte structure in it, or vice versa), you cannot
populate the full union -- you don't have 32 bytes left.
So let's then assume that the common header is 2 bytes long (with 3 vs.
17 vs. 30 additional bytes required in the specific structures). Fine,
then you read 2 bytes into the stand-alone union helper variable, for
inspecting the common header. Based on the header inspection, you then
decide to (attempt to) read 3 more bytes, or 17 bytes, continuing into
the union, and then parse the specific (now completed) structure through
the matching union member. Great?
Not really. Notice that, in this process, you didn't need the union *at
all*. You can simply use standalone structures, and you may not even
need more stack space.
Compare:
(i) with a union:
enum Type {
type_1,
type_2
}
struct H {
enum Type t;
...
};
struct S1 {
struct H h;
int S1_i1;
};
struct S2 {
struct H h;
char S2_c;
double S2_d;
};
union U {
S1 s1;
S2 s2;
};
Code:
union U u;
char unsigned *src = buffer;
char unsigned *dst = (void*)&u;
size_t specific;
if (room_left < sizeof(struct H)) {
return BAD;
}
memcpy(dst, src, sizeof(struct H));
dst += sizeof(struct H);
src += sizeof(struct H);
room_left -= sizeof(struct H);
switch (u.s1.h.t) {
case type_1:
specific = sizeof(struct S1) - sizeof(struct H);
if (room_left < specific) {
return BAD;
}
memcpy(dst, src, specific);
dst += specific;
src += specific;
room_left -= specific;
/* now access u.s1.S1_i1 */
return GOOD;
case type_2:
specific = sizeof(struct S2) - sizeof(struct H);
if (room_left < specific) {
return BAD;
}
memcpy(dst, src, specific);
dst += specific;
src += specific;
room_left -= specific;
/* now access u.s2.{S2_c,S2_d} */
return GOOD;
default:
return BAD;
}
(ii) without a union:
enum Type {
type_1,
type_2
}
struct H {
enum Type t;
...
};
/* note: header no longer embedded */
struct S1 {
int S1_i1;
};
/* note: header no longer embedded */
struct S2 {
char S2_c;
double S2_d;
};
Code:
struct H h; /* note: no union, just the common header */
char unsigned *src = buffer;
/* note: no dst pointer into union */
size_t specific;
if (room_left < sizeof h) {
return BAD;
}
memcpy(&h, src, sizeof h);
src += sizeof h;
room_left -= sizeof h;
switch (h.t) { /* note: no awkward reference to "u.s1" */
case type_1:
{
struct S1 s1; /* note: never co-exists with "s2" on the stack */
specific = sizeof s1; /* note: no awkward subtraction */
if (room_left < specific) {
return BAD;
}
memcpy(&s1, src, specific);
src += specific;
room_left -= specific;
/* now access s1.S1_i1 */
}
return GOOD;
case type_2:
{
struct S2 s2; /* note: never co-exists with "s1" on the stack */
specific = sizeof s2; /* note: no awkward subtraction */
if (room_left < specific) {
return BAD;
}
memcpy(&s2, src, specific);
src += specific;
room_left -= specific;
/* now access s2.S2_c, s2.S2_d */
}
return GOOD;
default:
return BAD;
}
To me, (ii) is much cleaner than (i); the union is not needed.
Of course, I find the type punning approach even better than (ii) :) See
below:
(iii) no union, yes type punning:
struct H *h;
char unsigned *src = buffer;
if (room_left < sizeof *h) {
return BAD;
}
h = (struct H *)src; /* note: no copying */
src += sizeof *h;
room_left -= sizeof *h;
switch (h->t) {
case type_1:
{
struct S1 *s1;
specific = sizeof *s1;
if (room_left < specific) {
return BAD;
}
s1 = (struct S1 *)src; /* note: no copying */
src += specific;
room_left -= specific;
/* now access s1->S1_i1 */
}
return GOOD;
and so on.
> Plain
> casts and "pointer union" accesses are illegal as per the "inadequate
> type punning" point above.
>
>
>
> "casting away CONST":
> e.g.
> https://github.com/tianocore/edk2/blob/fcdedafd97c8f18c33a63d26b954e5dbaee81a2b/MdePkg/Library/BaseIoLibIntrinsic/IoLibMmioBuffer.c#L236
In this case, the real problem is with the function prototype /
specification, not the implementation. The implementation follows from
the problematic function semantics -- if you take Buffer as (CONST UINT8
*), then why return the exact same buffer as (UINT8 *)?
> This should be obvious as Undefined Behaviour because memory previously
> guaranteed to be read-only is returned as a pointer to memory that
> allows writing,
Note: this is *per se* not undefined behavior. Casting away CONST
(explicitly) in itself is OK. Writing through the pointer is also OK
*if* the pointed-to object was never defined as CONST. Otherwise, the
behavior is undefined. See C99 6.7.3 Type qualifiers, p5:
"If an attempt is made to modify an object defined with a
const-qualified type through use of an lvalue with non-const-qualified
type, the behavior is undefined. If an attempt is made to refer to an
object defined with a volatile-qualified type through use of an lvalue
with non-volatile-qualified type, the behavior is undefined."
I've cited the part about "volatile" to highlight the difference between
"modify" and "refer to". When casting away const, the behavior is only
undefined if you actually try to modify an object that is actually const.
int i = 2;
int const ci = 3;
int *pi;
int const *pci;
pci = &i;
pi = (int *)pci; /* fine in itself, but now you're on your own */
*pi = 3; /* fine, as "i" is not defined const */
pci = &ci;
pi = (int *)pci; /* fine in itself, but now you're on your own */
i = *pi; /* fine, not modifying "ci" */
*pi = 3; /* undefined, as "ci" is defined const */
But, yes, the pattern seen under the link is risky practice.
> but for easier lookup, here's the related rule:
> "the left operand has atomic, qualifed, or unqualifed pointer type, and
> [...] the type pointed to by the left has all the qualifers of the type
> pointed to by the right"
> C18 (ISO/IEC 9899:2018), 6.5.16.1 (exists since at least C90)
What you quote is from the Constraints of "Simple assignment". Look at
"6.5.4 Cast operators" as well, paragraph 3:
"Conversions that involve pointers, other than where permitted by the
constraints of 6.5.16.1, shall be specified by means of an explicit cast."
In brief, casting away const is not invalid in itself; it just throws
away protections (diagnostics) that the compiler would otherwise be
required to emit. Sometimes it's unavoidable. In most cases we should
avoid it. That might require fixing a few function prototypes.
> "structs with trailing 1-length array"
> e.g.
> https://github.com/tianocore/edk2/blob/fcdedafd97c8f18c33a63d26b954e5dbaee81a2b/MdePkg/Include/Guid/FileInfo.h#L51
>
> This is undefined as per:
> "The behavior is undefned in the following circumstances:
> [...]
> — Addition or subtraction of a pointer into, or just beyond, an array
> object and an integer type produces a result that does not point into,
> or just beyond, the same array object (6.5.6).
> — Addition or subtraction of a pointer into, or just beyond, an array
> object and an integer type produces a result that points just beyond the
> array object and is used as the operand of a unary * operator that is
> evaluated (6.5.6).
> — Pointers that do not point into, or just beyond, the same array object
> are subtracted (6.5.6)."
> C18 (ISO/IEC 9899:2018), J.2 (exists since at least C90)
>
> Same as above, while not all compilers fully support C99, flexible
> arrays should be support by all reasonably new compilers and allow a
> legal declaration and usage where this hack is in place. At worst, a
> macro could be provided to declare a [1] vs a [] array on demand and a
> requirement be introduced to have a "SIZE_OF_" macro for each such
> struct, but my personal preference would be to just enforce flexible arrays.
Yes, in C99, the flexible array member was introduced to replace the
"struct hack", which had always been undefined.
It would be nice to remove all toolchains that don't support the
flexible array member, and then to replace all struct hacks with the
flexible array member. I agree.
Unfortunately, there's one extra difficulty (beyond the "expected"
regressions in adjusting code for the fixed element at offset 0): the
struct hack is used in several places in the UEFI 2.8 spec. So that
would have to be updated too.
> "Missing security checks for external data":
> e.g.
> https://github.com/tianocore/edk2/blob/fcdedafd97c8f18c33a63d26b954e5dbaee81a2b/MdePkg/Library/BasePeCoffLib/BasePeCoff.c#L943
>
> The given example misses an alignment verification of the resulting
> pointer (which technically has to be verified *before* casting), as
> documented here:
> "The behavior is undefined in the following circumstances:
> [...]
> — Conversion between two pointer types produces a result that is
> incorrectly aligned (6.3.2.3)."
> C18 (ISO/IEC 9899:2018), J.2 (exists since at least C90)
In C99 anyway, "6.3.2.3 Pointers", paragraph 7 writes,
"A pointer to an object or incomplete type may be converted to a pointer
to a different object or incomplete type. If the resulting pointer is
not correctly aligned [...] for the pointed-to type, the behavior is
undefined. [...]"
I find this very impractical and limiting, when accessing RAM (not
MMIO). I prefer if unaligned pointers (into RAM) just work, albeit slow,
perhaps. I believe AARCH64 can be configured to trip a fault vs. work
(but more slowly). On Intel, it just works.
I think we should be given the freedom to "define" the behavior that's
left undefined in this case by the standard.
> There are more such issues throughout the codebase, including missing
> overflow and (or flawed, see before) bounds checks, however I cannot
> find such quickly.
>
>
>
> "signed int BIT definitions":
> e.g.
> https://github.com/tianocore/edk2/blob/fcdedafd97c8f18c33a63d26b954e5dbaee81a2b/MdePkg/Include/Base.h#L348
>
> Fixing this would be prone to regressions, but I'd like to add it for
> tracking purposes. Related discussion can be found down the chain here:
> https://lists.01.org/pipermail/edk2-devel/2018-February/021919.html
I agree about this, in theory. I'm afraid it's impossible to fix in
practice, given the huge amounts of dependent code (esp. out of tree code).
More or less, I'd summarize my opinion as follows:
- we should try to write such new code that conforms to the standard,
- *except* when the standard doesn't give us enough guarantees (i.e.
leaves the behavior undefined) that we need for convenient *in-place*
parsing (from RAM). Integer range checks and buffer boundary checks are
extremely important and we should implement those meticulously, but once
we've made sure our accesses are in range, the compiler should just
follow our pointers wherever they point. We should drag our toolchains
kicking and screaming into a state where they build the source the way
we need, for *in-place* parsing of RAM buffers, through packed
structures. As long as the architectures that we target don't prevent us
from in-place parsing, the toolchains should neither.
Thanks
Laszlo
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs
2019-09-24 20:26 ` Laszlo Ersek
@ 2019-09-25 8:13 ` Marvin Häuser
2019-09-25 15:54 ` Laszlo Ersek
0 siblings, 1 reply; 155+ messages in thread
From: Marvin Häuser @ 2019-09-25 8:13 UTC (permalink / raw)
To: devel@edk2.groups.io, lersek@redhat.com
Thanks for your input.
Due to a misconception of union casts (or accesses, really), multiple
points were rendered infeasible. I suppose the main point left I'd like
some attention towards is alignment, and of course the misdesigned
prototypes (CONST).
Comments inline.
Thanks and regards,
Marvin
Am 24.09.2019 um 22:26 schrieb Laszlo Ersek:
> On 09/23/19 18:27, Marvin Häuser wrote:
>> Good day,
>>
>> Thank you, Laszlo, for your ambition to introduce stricter code style
>> enforcements. Sorry to "hijack" the actual topic (I did not CC anyone on
>> purpose, as this is mostly a separate topic and I'd like a quick comment
>> first), but this seems like a good occasion to mention another few bad
>> practices edk2 has been following. Mainly, I'd like to call *some*
>> attention to quality problems in the code base while this has some
>> traction, and cause a discussion on whether and how those are to be
>> approached.
>>
>> Thank you for your time.
>
> Sure, I can offer my personal opinion on these.
>
>
>> "inadequate type punning":
>> e.g.
>> https://github.com/tianocore/edk2/blob/fcdedafd97c8f18c33a63d26b954e5dbaee81a2b/MdeModulePkg/Bus/Usb/UsbBusPei/HubPeim.c#L446
>>
>> This is mostly about the infamous "Strict Aliasing" rule, which is
>> basically:
>> "An object shall have its stored value accessed only by an lvalue
>> expression that has one of the
>> following types:
>> — a type compatible with the effective type of the object,
>> — a qualifed version of a type compatible with the effective type of the
>> object,
>> — a type that is the signed or unsigned type corresponding to the
>> effective type of the object,
>> — a type that is the signed or unsigned type corresponding to a qualifed
>> version of the effective
>> type of the object,
>> — an aggregate or union type that includes one of the aforementioned
>> types among its members
>> (including, recursively, a member of a subaggregate or contained union), or
>> — a character type."
>> C18 (ISO/IEC 9899:2018), 6.5.7 (exists, though has been updated, since C90)
>>
>> Currently optimisations based on this are disabled. This is a bit nasty
>> to work around if *seriously* needed when sticking to C90, I can only
>> think of memcpy right now. However, even though there are compilers that
>> do not fully support C99 (ahem, Microsoft :) ), type-punning by unions
>> should be supported by them all, and has been legal as of C99, where the
>> following part has been dropped from the standard:
>> "With one exception, if a member of a union object is accessed after a
>> value has been stored in a different member of the object, the behavior
>> is implementation-defined."
>> C90 (ISO/IEC 9899:1990), 6.3.2.3
>
> I'm opposed to enforcing the strict aliasing rules, even though in all
> code that I write, I either try to conform to them, or at least I seek
> to be fully conscious of breaking them.
I agree with that, but I often see completely needless violations of
them. In my opinion, all intentional violations should be documented to
signal the conscious breakage of the standard, as should be any "abuse"
of known implementation-defined behaviour. I suppose for the amount of
in-place parsing done, the Strict Aliasing rule should be an exception
for these cases, as per the assumptions below.
>
> Here's the thing: IMO, the strict aliasing rules sacrifice flexibility
> for performance (optimization possibilities). Not to mention the amount
> of code in edk2 that would have to be identified and updated.
>
> BaseTools uses "-fno-strict-aliasing" everywhere, and I think that's a
> good choice.
>
> https://blog.regehr.org/archives/1180
>
> This proposal for a "friendly dialect of C" intended to eliminate the
> strict aliasing rules altogether. (Item#10; possibly also item#13.)
>
> Also, as it points out, the Linux kernel is built with
> "-fno-strict-aliasing". I've checked now, with a *long* series of "git
> blame" commands, even digging into the "history" repository (which is at
> <git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git>). I can
> say that the current flag has been in place since *at least* Linux
> v2.5.0 (2002-02-04).
>
> QEMU has been built with "-fno-strict-aliasing" ever since commit
> b932caba32c6 ("new disk image layer", 2004-08-01), known originally as
> SVN rev 1030.
My point here is invalidated two comments below.
>
>
> Consider the following example. You have a dynamically allocated buffer.
> You read some data into it, from the network or the disk, using PCI DMA.
> Let's assume that, from the block read via PCI DMA, the library
> function(s) or protocol member(s) that you call, directly or indirectly,
> there is at least one that:
> - copies data from a source buffer to a target buffer, using UINT32 or
> UINT64 assignments (for speed),
Honestly, I did not consider this and only had memcpy/memmove in mind.
However, if we "virtually" treat CopyMem as memmove, the compiler
compatibility verification would be reduced from all callers to just it,
i.e. CopyMem must be implemented in a way that, for all supported
compilers, we can assume the original effective type is "carried over",
such with at worst (which should not be required with any sane compiler)
char-copying.
I'm not looking to have absolute C compliance enforced, but to reduce
pointless violations and possibly "concentrate" violations for easier
compatibility verification.
> - and is implemented in C.
>
> Now, according to the effective type rules, your dynamic buffer's
> effective type is "array of UINT32" or "array of UINT64". That's because
> of C99 6.5 Expressions, p6:
>
> "If a value is stored into an object having no declared type through an
> lvalue having a type that is not a character type, then the type of the
> lvalue becomes the effective type of the object for that access and for
> subsequent accesses that do not modify the stored value."
>
> Then if you try to parse this buffer as a UEFI device path (= a packed
> sequence of device path node structures), *IN PLACE*, you will break the
> effective type rules no matter what. Because, you will necessarily look
> at the next node in the blob as an EFI_DEVICE_PATH_PROTOCOL (because
> you'll want to learn the Type and the SubType fields, and the Length
> array too). Note that EFI_DEVICE_PATH_PROTOCOL is a structure with no
> UINT32 or UINT64 members. Boom.
>
> So you have to resort to one of the following things:
>
> 1. Define a union type, assign the *full union* first
> <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90167#c3>, and then check
> the union helper variable. (First you must make sure there was enough
> room in the buffer being parsed for a full union.)
I was going to argue the exact same way you did in that bug, I was not
aware of GCC treating this rule, in my opinion, inappropriately (the
reasoning there makes sense, but I'd hope the committee was actually
seeking to allow this). As long as no writes are performed through the
union (because that yields unspecified values for all bytes between the
end of the written-to member and the end of the full union size), I
would not have thought there'd be problems with such a cast, for the
exact part you quoted. This makes the situation ridiculous to handle, I
agree.
I hope there will be some sort of adaption that will allow exactly this
in the future, then this should be enforced (it cannot break more than
the current solution, and for future standards and complying compilers,
would avoid Undefined Behaviour).
>
> 2. Or, use memcpy() -- or something that the compiler is similarly
> enlightened about --, to the same helper variable.
>
> 3. Or, write a manual copy loop with character access, to the helper
> variable.
>
> 4. Or, use character access to read the fields.
>
> #1 through #3 add a separate copying step, while #4 is extremely
> uncomfortable to program.
>
> In a nutshell, the effective type rules require separate
> de-serialization routines for all data, and that's incredibly annoying.
> It kills the utility of packed C structures.
>
> I prefer packed C structures, size checks (!!!) against the buffers to
> parse, and then type punning of pointers.
>
>
>> "pointer unions":
>> e.g.
>> https://github.com/tianocore/edk2/blob/fcdedafd97c8f18c33a63d26b954e5dbaee81a2b/MdePkg/Include/IndustryStandard/SmBios.h#L2592
>>
>> While the idea behind them is certainly style preference, using a union
>> of pointers prevents two important things over a union of structs.
>>
>> 1) CONST declaration: When defining a variable of a union type
>> containing pointers as CONST, speaking of its members, they are all
>> going to be CONST pointers to arbitrary memory and not arbitrary
>> pointers to CONST memory. With a union of structs, you can have either
>> as required (e.g. CONST UNION_TYPE *union, or UNION_TYPE *COST union).
>
> Formally, you are right, but I'm doubtful of the utility of
> "pointer-to-union-of-structs". We cannot de-reference a pointer to the
> union unless the buffer has enough data for the complete union. This
> leaves the parsing of small structs unsolved.
>
> A union of pointers is just syntactic sugar, of course, but it's
> convenient. The member that is "pointer-to-smallest-header-substructure"
> can be used for determining the actual structure type. Then we can
> determine if there's enough data for that structure in the buffer. Then
> we can use the matching pointer member, for accessing that structure.
>
> Furthermore, CONST gets too complex really soon, and we have to start
> adding explicit casts. My favorite link is:
>
> http://c-faq.com/ansi/constmismatch.html
>
> I had never met "pointer unions" before edk2, but I've found them quite
> convenient.
>
>
>> 2) Well-defined header inspection:
>> "if a union contains several structures that share a common initial
>> sequence [...], it is permitted to inspect the common initial part of
>> any of them anywhere that a declaration of the completed type of the
>> union is visible"
>> C18 (ISO/IEC 9899:2018), 6.5.2.3.6 (exists since at least C90)
>>
>> This guarantee can be used to inspect the type defined in a common
>> header (e.g. SMBIOS_STRUCTURE) and the process the type-specific data by
>> accessing the appropiate member (e.g. SMBIOS_TABLE_TYPE0) legally.
>
> This only applies *after* you have populated the union for inspection.
> (Or at least enough bytes for the common header that you're going to
> inspect.)
>
> If you have a union collecting three structures: 5 bytes, 19 bytes, and
> 32 bytes, and you have a buffer with 24 bytes left (suggesting a 5 byte
> structure and a 19 byte structure in it, or vice versa), you cannot
> populate the full union -- you don't have 32 bytes left.
>
> So let's then assume that the common header is 2 bytes long (with 3 vs.
> 17 vs. 30 additional bytes required in the specific structures). Fine,
> then you read 2 bytes into the stand-alone union helper variable, for
> inspecting the common header. Based on the header inspection, you then
> decide to (attempt to) read 3 more bytes, or 17 bytes, continuing into
> the union, and then parse the specific (now completed) structure through
> the matching union member. Great?
>
> Not really. Notice that, in this process, you didn't need the union *at
> all*. You can simply use standalone structures, and you may not even
> need more stack space.
>
> Compare:
>
> (i) with a union:
>
> enum Type {
> type_1,
> type_2
> }
>
> struct H {
> enum Type t;
> ...
> };
>
> struct S1 {
> struct H h;
> int S1_i1;
> };
>
> struct S2 {
> struct H h;
> char S2_c;
> double S2_d;
> };
>
> union U {
> S1 s1;
> S2 s2;
> };
>
> Code:
>
> union U u;
> char unsigned *src = buffer;
> char unsigned *dst = (void*)&u;
> size_t specific;
>
> if (room_left < sizeof(struct H)) {
> return BAD;
> }
>
> memcpy(dst, src, sizeof(struct H));
> dst += sizeof(struct H);
> src += sizeof(struct H);
> room_left -= sizeof(struct H);
>
> switch (u.s1.h.t) {
> case type_1:
> specific = sizeof(struct S1) - sizeof(struct H);
> if (room_left < specific) {
> return BAD;
> }
> memcpy(dst, src, specific);
> dst += specific;
> src += specific;
> room_left -= specific;
> /* now access u.s1.S1_i1 */
> return GOOD;
>
> case type_2:
> specific = sizeof(struct S2) - sizeof(struct H);
> if (room_left < specific) {
> return BAD;
> }
> memcpy(dst, src, specific);
> dst += specific;
> src += specific;
> room_left -= specific;
> /* now access u.s2.{S2_c,S2_d} */
> return GOOD;
>
> default:
> return BAD;
> }
>
>
> (ii) without a union:
>
> enum Type {
> type_1,
> type_2
> }
>
> struct H {
> enum Type t;
> ...
> };
>
> /* note: header no longer embedded */
> struct S1 {
> int S1_i1;
> };
>
> /* note: header no longer embedded */
> struct S2 {
> char S2_c;
> double S2_d;
> };
>
> Code:
>
> struct H h; /* note: no union, just the common header */
> char unsigned *src = buffer;
> /* note: no dst pointer into union */
> size_t specific;
>
> if (room_left < sizeof h) {
> return BAD;
> }
>
> memcpy(&h, src, sizeof h);
> src += sizeof h;
> room_left -= sizeof h;
>
> switch (h.t) { /* note: no awkward reference to "u.s1" */
> case type_1:
> {
> struct S1 s1; /* note: never co-exists with "s2" on the stack */
>
> specific = sizeof s1; /* note: no awkward subtraction */
> if (room_left < specific) {
> return BAD;
> }
> memcpy(&s1, src, specific);
> src += specific;
> room_left -= specific;
> /* now access s1.S1_i1 */
> }
> return GOOD;
>
> case type_2:
> {
> struct S2 s2; /* note: never co-exists with "s1" on the stack */
>
> specific = sizeof s2; /* note: no awkward subtraction */
> if (room_left < specific) {
> return BAD;
> }
> memcpy(&s2, src, specific);
> src += specific;
> room_left -= specific;
> /* now access s2.S2_c, s2.S2_d */
> }
> return GOOD;
>
> default:
> return BAD;
> }
>
>
> To me, (ii) is much cleaner than (i); the union is not needed.
>
> Of course, I find the type punning approach even better than (ii) :) See
> below:
>
> (iii) no union, yes type punning:
>
> struct H *h;
> char unsigned *src = buffer;
>
> if (room_left < sizeof *h) {
> return BAD;
> }
> h = (struct H *)src; /* note: no copying */
> src += sizeof *h;
> room_left -= sizeof *h;
>
> switch (h->t) {
> case type_1:
> {
> struct S1 *s1;
>
> specific = sizeof *s1;
> if (room_left < specific) {
> return BAD;
> }
> s1 = (struct S1 *)src; /* note: no copying */
> src += specific;
> room_left -= specific;
> /* now access s1->S1_i1 */
> }
> return GOOD;
>
> and so on.
>
Thanks for your comprehensive examples, but that part was written with
the idea of casting to a union pointer as you mentioned in the previous
point in mind. Without such casts and subsequent accesses being legal,
this is not of a lot of use for us, I agree.
>
>> Plain
>> casts and "pointer union" accesses are illegal as per the "inadequate
>> type punning" point above.
>>
>>
>>
>> "casting away CONST":
>> e.g.
>> https://github.com/tianocore/edk2/blob/fcdedafd97c8f18c33a63d26b954e5dbaee81a2b/MdePkg/Library/BaseIoLibIntrinsic/IoLibMmioBuffer.c#L236
>
> In this case, the real problem is with the function prototype /
> specification, not the implementation. The implementation follows from
> the problematic function semantics -- if you take Buffer as (CONST UINT8
> *), then why return the exact same buffer as (UINT8 *)?
I agree, the prototype has been misdesigned. I was just referring to
such "patterns" being a problem, not from where they actually originate.
>
>
>> This should be obvious as Undefined Behaviour because memory previously
>> guaranteed to be read-only is returned as a pointer to memory that
>> allows writing,
>
> Note: this is *per se* not undefined behavior. Casting away CONST
> (explicitly) in itself is OK. Writing through the pointer is also OK
> *if* the pointed-to object was never defined as CONST. Otherwise, the
> behavior is undefined. See C99 6.7.3 Type qualifiers, p5:
>
> "If an attempt is made to modify an object defined with a
> const-qualified type through use of an lvalue with non-const-qualified
> type, the behavior is undefined. If an attempt is made to refer to an
> object defined with a volatile-qualified type through use of an lvalue
> with non-volatile-qualified type, the behavior is undefined."
>
> I've cited the part about "volatile" to highlight the difference between
> "modify" and "refer to". When casting away const, the behavior is only
> undefined if you actually try to modify an object that is actually const.
>
> int i = 2;
> int const ci = 3;
> int *pi;
> int const *pci;
>
> pci = &i;
> pi = (int *)pci; /* fine in itself, but now you're on your own */
> *pi = 3; /* fine, as "i" is not defined const */
>
> pci = &ci;
> pi = (int *)pci; /* fine in itself, but now you're on your own */
> i = *pi; /* fine, not modifying "ci" */
> *pi = 3; /* undefined, as "ci" is defined const */
>
>
> But, yes, the pattern seen under the link is risky practice.
>
>
>> but for easier lookup, here's the related rule:
>> "the left operand has atomic, qualifed, or unqualifed pointer type, and
>> [...] the type pointed to by the left has all the qualifers of the type
>> pointed to by the right"
>> C18 (ISO/IEC 9899:2018), 6.5.16.1 (exists since at least C90)
>
> What you quote is from the Constraints of "Simple assignment". Look at
> "6.5.4 Cast operators" as well, paragraph 3:
>
> "Conversions that involve pointers, other than where permitted by the
> constraints of 6.5.16.1, shall be specified by means of an explicit cast."
>
> In brief, casting away const is not invalid in itself; it just throws
> away protections (diagnostics) that the compiler would otherwise be
> required to emit. Sometimes it's unavoidable. In most cases we should
> avoid it. That might require fixing a few function prototypes.
Sorry, that was a bit rushed, but the actual problem persists. If
nothing else, casting away CONST drastically increases the likeliness of
misuse happening, as the only indicator for const-ness has been dropped.
>
>
>> "structs with trailing 1-length array"
>> e.g.
>> https://github.com/tianocore/edk2/blob/fcdedafd97c8f18c33a63d26b954e5dbaee81a2b/MdePkg/Include/Guid/FileInfo.h#L51
>>
>> This is undefined as per:
>> "The behavior is undefned in the following circumstances:
>> [...]
>> — Addition or subtraction of a pointer into, or just beyond, an array
>> object and an integer type produces a result that does not point into,
>> or just beyond, the same array object (6.5.6).
>> — Addition or subtraction of a pointer into, or just beyond, an array
>> object and an integer type produces a result that points just beyond the
>> array object and is used as the operand of a unary * operator that is
>> evaluated (6.5.6).
>> — Pointers that do not point into, or just beyond, the same array object
>> are subtracted (6.5.6)."
>> C18 (ISO/IEC 9899:2018), J.2 (exists since at least C90)
>>
>> Same as above, while not all compilers fully support C99, flexible
>> arrays should be support by all reasonably new compilers and allow a
>> legal declaration and usage where this hack is in place. At worst, a
>> macro could be provided to declare a [1] vs a [] array on demand and a
>> requirement be introduced to have a "SIZE_OF_" macro for each such
>> struct, but my personal preference would be to just enforce flexible arrays.
>
> Yes, in C99, the flexible array member was introduced to replace the
> "struct hack", which had always been undefined.
>
> It would be nice to remove all toolchains that don't support the
> flexible array member, and then to replace all struct hacks with the
> flexible array member. I agree.
>
> Unfortunately, there's one extra difficulty (beyond the "expected"
> regressions in adjusting code for the fixed element at offset 0): the
> struct hack is used in several places in the UEFI 2.8 spec. So that
> would have to be updated too.
Agreed. However, I see value in updating the UEFI specification, as it
should mandate the abstract-ish concept (trailing array of a length not
known at compile time), not the implementation (struct hack), which in
this case even is a language standard violation.
>
>
>> "Missing security checks for external data":
>> e.g.
>> https://github.com/tianocore/edk2/blob/fcdedafd97c8f18c33a63d26b954e5dbaee81a2b/MdePkg/Library/BasePeCoffLib/BasePeCoff.c#L943
>>
>> The given example misses an alignment verification of the resulting
>> pointer (which technically has to be verified *before* casting), as
>> documented here:
>> "The behavior is undefined in the following circumstances:
>> [...]
>> — Conversion between two pointer types produces a result that is
>> incorrectly aligned (6.3.2.3)."
>> C18 (ISO/IEC 9899:2018), J.2 (exists since at least C90)
>
> In C99 anyway, "6.3.2.3 Pointers", paragraph 7 writes,
>
> "A pointer to an object or incomplete type may be converted to a pointer
> to a different object or incomplete type. If the resulting pointer is
> not correctly aligned [...] for the pointed-to type, the behavior is
> undefined. [...]"
>
> I find this very impractical and limiting, when accessing RAM (not
> MMIO). I prefer if unaligned pointers (into RAM) just work, albeit slow,
> perhaps. I believe AARCH64 can be configured to trip a fault vs. work
> (but more slowly). On Intel, it just works.
On Intel it depends actually, e.g. SSE often (always?) mandates aligned
pointers. If, in C code, you ignore the alignment requirements, the
compiler is technically allowed to perform optimizations with
instructions that do require aligned addresses. I think for Intel,
SSE-based optimizations are disabled (for this reason? I'm not sure),
but this only makes life tougher when adding support for new compilers
and architectures honestly.
Also, in case of file parsing, if the file format mandates alignment for
certain offsets (segments, sections, sub-headers) and the offset is
unalgined, an alignment verification aids as an additional layer of
input sanity verification. As I see it, you either have an aligned
struct and make sure the pointer is aligned, or you have an unaligned
struct and the compiler takes care of accessing the data unaligned.
>
> I think we should be given the freedom to "define" the behavior that's
> left undefined in this case by the standard.
What when dealing with an architecture that just does not support
unaligned accesses? I suppose that's going to be unlikely.
>
>
>> There are more such issues throughout the codebase, including missing
>> overflow and (or flawed, see before) bounds checks, however I cannot
>> find such quickly.
>>
>>
>>
>> "signed int BIT definitions":
>> e.g.
>> https://github.com/tianocore/edk2/blob/fcdedafd97c8f18c33a63d26b954e5dbaee81a2b/MdePkg/Include/Base.h#L348
>>
>> Fixing this would be prone to regressions, but I'd like to add it for
>> tracking purposes. Related discussion can be found down the chain here:
>> https://lists.01.org/pipermail/edk2-devel/2018-February/021919.html
>
> I agree about this, in theory. I'm afraid it's impossible to fix in
> practice, given the huge amounts of dependent code (esp. out of tree code).
Definitely.
>
>
> More or less, I'd summarize my opinion as follows:
>
> - we should try to write such new code that conforms to the standard,
>
> - *except* when the standard doesn't give us enough guarantees (i.e.
> leaves the behavior undefined) that we need for convenient *in-place*
> parsing (from RAM). Integer range checks and buffer boundary checks are
> extremely important and we should implement those meticulously, but once
> we've made sure our accesses are in range, the compiler should just
> follow our pointers wherever they point. We should drag our toolchains
> kicking and screaming into a state where they build the source the way
> we need, for *in-place* parsing of RAM buffers, through packed
> structures. As long as the architectures that we target don't prevent us
> from in-place parsing, the toolchains should neither.
Agreed.
>
> Thanks
> Laszlo
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 04/35] EmbeddedPkg/Universal/MmcDxe: "fix" CloseProtocol() call in BindingStop()
2019-09-17 19:49 ` [PATCH 04/35] EmbeddedPkg/Universal/MmcDxe: "fix" CloseProtocol() call in BindingStop() Laszlo Ersek
@ 2019-09-25 15:52 ` Ard Biesheuvel
0 siblings, 0 replies; 155+ messages in thread
From: Ard Biesheuvel @ 2019-09-25 15:52 UTC (permalink / raw)
To: Laszlo Ersek; +Cc: edk2-devel-groups-io, Leif Lindholm
On Tue, 17 Sep 2019 at 21:49, Laszlo Ersek <lersek@redhat.com> wrote:
>
> The 3rd and 4th parameters of the CloseProtocol() call are wrong.
>
> Given that we're not dissociating a child controller from a parent
> controller (= closing a BY_CHILD_CONTROLLER open), but closing a BY_DRIVER
> open, the 4th parameter (ControllerHandle) should equal the 1st parameter
> (Handle).
>
> It's unclear why this code hasn't crashed before.
>
> Note that the patch doesn't fix the underlying driver model bug. I don't
> understand what the loop in MmcDriverBindingStop() attempts to do. Is this
> driver supposed to be a bus driver? It seems to create new handles, and to
> append device path nodes. But it doesn't set up proper parent/child
> protocol opens, and it doesn't close them.
>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Leif Lindholm <leif.lindholm@linaro.org>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
This code predates my involvement in Tianocore, so I cannot answer
your questions.
For the change itself,
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
>
> Notes:
> build-tested only
>
> EmbeddedPkg/Universal/MmcDxe/Mmc.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/EmbeddedPkg/Universal/MmcDxe/Mmc.c b/EmbeddedPkg/Universal/MmcDxe/Mmc.c
> index 2f9ec9c7e7c1..c6170880debd 100644
> --- a/EmbeddedPkg/Universal/MmcDxe/Mmc.c
> +++ b/EmbeddedPkg/Universal/MmcDxe/Mmc.c
> @@ -329,8 +329,9 @@ MmcDriverBindingStop (
> // Close gEfiMmcHostProtocolGuid
> Status = gBS->CloseProtocol (
> Controller,
> - &gEfiMmcHostProtocolGuid,(VOID **) &MmcHostInstance->MmcHost,
> - This->DriverBindingHandle
> + &gEfiMmcHostProtocolGuid,
> + This->DriverBindingHandle,
> + Controller
> );
>
> // Remove MMC Host Instance from the pool
> --
> 2.19.1.3.g30247aa5d201
>
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs
2019-09-25 8:13 ` Marvin Häuser
@ 2019-09-25 15:54 ` Laszlo Ersek
0 siblings, 0 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-25 15:54 UTC (permalink / raw)
To: Marvin Häuser, devel@edk2.groups.io
(snipping liberally)
On 09/25/19 10:13, Marvin Häuser wrote:
> Am 24.09.2019 um 22:26 schrieb Laszlo Ersek:
>> I'm opposed to enforcing the strict aliasing rules, even though in
>> all code that I write, I either try to conform to them, or at least I
>> seek to be fully conscious of breaking them.
>
> I agree with that, but I often see completely needless violations of
> them. In my opinion, all intentional violations should be documented
> to signal the conscious breakage of the standard, as should be any
> "abuse" of known implementation-defined behaviour.
Agreed!
> I suppose for the amount of in-place parsing done, the Strict Aliasing
> rule should be an exception for these cases, as per the assumptions
> below.
Probably so; from personal experience, I'm basically only drawn to type
punning when there's some binary data to parse into (or via)
structure(s); and in firmware, there are *surprisingly* many sequences /
tables to parse.
>> Consider the following example. You have a dynamically allocated
>> buffer. You read some data into it, from the network or the disk,
>> using PCI DMA. Let's assume that, from the block read via PCI DMA,
>> the library function(s) or protocol member(s) that you call, directly
>> or indirectly, there is at least one that:
>> - copies data from a source buffer to a target buffer, using UINT32
>> or UINT64 assignments (for speed),
>
> Honestly, I did not consider this and only had memcpy/memmove in mind.
It may not be an intuitive example.
There are other (similarly practical) instances of this pattern. See
commit 6e2543b01d0c ("ArmVirtualizationPkg: introduce QemuFwCfgLib
instance for DXE drivers", 2015-01-02), for example:
> [...]
>
> Because MMIO accesses are costly on KVM/ARM, InternalQemuFwCfgReadBytes()
> accesses the fw_cfg data register in full words. This speeds up transfers
> almost linearly.
>
> [...]
>
> +/**
> + Reads firmware configuration bytes into a buffer
> +
> + @param[in] Size Size in bytes to read
> + @param[in] Buffer Buffer to store data into (OPTIONAL if Size is 0)
> +
> +**/
> +STATIC
> +VOID
> +EFIAPI
> +InternalQemuFwCfgReadBytes (
> + IN UINTN Size,
> + IN VOID *Buffer OPTIONAL
> + )
> +{
> + UINTN Left;
> + UINT8 *Ptr;
> + UINT8 *End;
> +
> +#ifdef MDE_CPU_AARCH64
> + Left = Size & 7;
> +#else
> + Left = Size & 3;
> +#endif
> +
> + Size -= Left;
> + Ptr = Buffer;
> + End = Ptr + Size;
> +
> +#ifdef MDE_CPU_AARCH64
> + while (Ptr < End) {
> + *(UINT64 *)Ptr = MmioRead64 (mFwCfgDataAddress);
> + Ptr += 8;
> + }
> + if (Left & 4) {
> + *(UINT32 *)Ptr = MmioRead32 (mFwCfgDataAddress);
> + Ptr += 4;
> + }
> +#else
> + while (Ptr < End) {
> + *(UINT32 *)Ptr = MmioRead32 (mFwCfgDataAddress);
> + Ptr += 4;
> + }
> +#endif
> +
> + if (Left & 2) {
> + *(UINT16 *)Ptr = MmioRead16 (mFwCfgDataAddress);
> + Ptr += 2;
> + }
> + if (Left & 1) {
> + *Ptr = MmioRead8 (mFwCfgDataAddress);
> + }
> +}
And then the data read like this from the hypervisor may contain
arbitrary structures for the firmware to parse.
Back to the discussion:
On 09/25/19 10:13, Marvin Häuser wrote:
> However, if we "virtually" treat CopyMem as memmove, the compiler
> compatibility verification would be reduced from all callers to just
> it, i.e. CopyMem must be implemented in a way that, for all supported
> compilers, we can assume the original effective type is "carried
> over", such with at worst (which should not be required with any sane
> compiler) char-copying.
As far as I understand, you're saying that, if we ensure that compilers
recognize CopyMem() as similar to memmove(), then we can apply the C
standard (~ the effective type rules) to edk2 too, only replacing
memcpy() / memmove() references in the std language with CopyMem()
references.
Then we could call edk2 conformant once all such data manipulation
boiled down to correct use of CopyMem().
If that's your point, then I agree with it.
> I'm not looking to have absolute C compliance enforced, but to reduce
> pointless violations and possibly "concentrate" violations for easier
> compatibility verification.
These are very good goals.
(As a digression, consider the following -- very frequent -- pattern:
EFI_PCI_IO_PROTOCOL *PciIo;
Status = gBS->OpenProtocol (
DeviceHandle,
&gEfiPciIoProtocolGuid,
(VOID **)&PciIo,
This->DriverBindingHandle,
DeviceHandle,
EFI_OPEN_PROTOCOL_BY_DRIVER
);
Technically, the third argument
(VOID **)&PciIo
is wrong, as pointer-to-structure types (which have identical
representation to each other) need not have the same representation as
pointer-to-void. See C99 "6.2.5 Types", p27:
> A pointer to void shall have the same representation and alignment
> requirements as a pointer to a character type. [...] Similarly,
> pointers to qualified or unqualified versions of compatible types
> shall have the same representation and alignment requirements. All
> pointers to structure types shall have the same representation and
> alignment requirements as each other. All pointers to union types
> shall have the same representation and alignment requirements as each
> other. Pointers to other types need not have the same representation
> or alignment requirements.
The proper way to do it would be:
VOID *Interface;
EFI_PCI_IO_PROTOCOL *PciIo;
Status = gBS->OpenProtocol (
DeviceHandle,
&gEfiPciIoProtocolGuid,
&Interface,
This->DriverBindingHandle,
DeviceHandle,
EFI_OPEN_PROTOCOL_BY_DRIVER
);
if (!EFI_ERROR (Status)) {
PciIo = Interface;
}
Because, in the assignment, the pointer-to-void is *converted* to
pointer-to-structure (not just re-interpreted as), with any necessary
updates to the internal representation.
IIRC, POSIX ultimately added a requirement (beyond the C standard) for
implementations, for said pointer representations to be identical.
So, this is a very frequent violation of the standard; I think it's even
visible in the UEFI spec, in various example code.
Is this violation pointless? It wouldn't be difficult to write all new
code following the second (proper) pattern. Updating all existent sites
would be a nightmare though.
)
Continuing:
On 09/25/19 10:13, Marvin Häuser wrote:
> If nothing else, casting away CONST drastically increases the
> likeliness of misuse happening, as the only indicator for const-ness
> has been dropped.
I agree; before casting away an existing const-qualification, we should
think thrice.
(OTOH, trying to design all function prototypes as tightly as possible,
const-qualifying as many as possible pointed-to objects under the
pointer-typed parameters, tends to become unwieldy really quick. In my
experience anyway.)
>> It would be nice to remove all toolchains that don't support the
>> flexible array member, and then to replace all struct hacks with the
>> flexible array member. I agree.
>>
>> Unfortunately, there's one extra difficulty (beyond the "expected"
>> regressions in adjusting code for the fixed element at offset 0): the
>> struct hack is used in several places in the UEFI 2.8 spec. So that
>> would have to be updated too.
>
> Agreed. However, I see value in updating the UEFI specification, as it
> should mandate the abstract-ish concept (trailing array of a length not
> known at compile time), not the implementation (struct hack), which in
> this case even is a language standard violation.
It's not that I don't see value in updating the spec -- I generally
don't have time for working on the spec (or for reviewing ECRs)! :)
Thanks!
Laszlo
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 24/35] OvmfPkg/PlatformDxe: fix EFI_HII_HANDLE parameters of internal functions
2019-09-17 19:49 ` [PATCH 24/35] OvmfPkg/PlatformDxe: fix EFI_HII_HANDLE parameters of internal functions Laszlo Ersek
2019-09-20 14:56 ` [edk2-devel] " Philippe Mathieu-Daudé
@ 2019-09-25 15:57 ` Ard Biesheuvel
1 sibling, 0 replies; 155+ messages in thread
From: Ard Biesheuvel @ 2019-09-25 15:57 UTC (permalink / raw)
To: Laszlo Ersek; +Cc: edk2-devel-groups-io, Jordan Justen
On Tue, 17 Sep 2019 at 21:50, Laszlo Ersek <lersek@redhat.com> wrote:
>
> In the following call tree:
>
> PlatformInit ()
> mInstalledPackages = HiiAddPackages ()
> GopInstalled ()
> PopulateForm (PackageList = mInstalledPackages)
> CreateResolutionOptions (PackageList)
> HiiSetString (PackageList
> HiiUpdateForm (PackageList)
>
> PlatformDxe passes around an EFI_HII_HANDLE that (a) originates from
> HiiAddPackages() and (b) is ultimately passed to HiiSetString() and
> HiiUpdateForm(). The intermediate functions PopulateForm() and
> CreateResolutionOptions() however take that parameter as an
> (EFI_HII_HANDLE*).
>
> There is no bug in practice (because the affected functions never try to
> de-reference the "PackageList" parameter, they just pass it on), but the
> function prototypes are semantically wrong. Fix that.
>
> This could remain hidden so long because pointer-to-VOID silently converts
> to/from any pointer-to-object type, and the UEFI spec mandates that
> EFI_HII_HANDLE be a typedef to (VOID*).
>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Jordan Justen <jordan.l.justen@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
>
> Notes:
> tested in UiApp
>
> OvmfPkg/PlatformDxe/Platform.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/OvmfPkg/PlatformDxe/Platform.c b/OvmfPkg/PlatformDxe/Platform.c
> index 09181769babf..23ad43901f66 100644
> --- a/OvmfPkg/PlatformDxe/Platform.c
> +++ b/OvmfPkg/PlatformDxe/Platform.c
> @@ -486,7 +486,7 @@ STATIC
> EFI_STATUS
> EFIAPI
> CreateResolutionOptions (
> - IN EFI_HII_HANDLE *PackageList,
> + IN EFI_HII_HANDLE PackageList,
> OUT VOID **OpCodeBuffer,
> IN UINTN NumGopModes,
> IN GOP_MODE *GopModes
> @@ -547,7 +547,7 @@ STATIC
> EFI_STATUS
> EFIAPI
> PopulateForm (
> - IN EFI_HII_HANDLE *PackageList,
> + IN EFI_HII_HANDLE PackageList,
> IN EFI_GUID *FormSetGuid,
> IN EFI_FORM_ID FormId,
> IN UINTN NumGopModes,
> --
> 2.19.1.3.g30247aa5d201
>
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 09/35] MdeModulePkg: stop abusing EFI_EVENT for protocol notify registration
2019-09-17 19:49 ` [PATCH 09/35] MdeModulePkg: stop abusing EFI_EVENT for protocol notify registration Laszlo Ersek
2019-09-17 20:17 ` Ni, Ray
@ 2019-09-25 16:02 ` Philippe Mathieu-Daudé
2019-09-26 12:10 ` Laszlo Ersek
1 sibling, 1 reply; 155+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-09-25 16:02 UTC (permalink / raw)
To: devel, lersek; +Cc: Hao A Wu, Jian J Wang, Liming Gao, Ray Ni, Zhichao Gao
On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> EfiCreateProtocolNotifyEvent() takes a (VOID**) for "Registration",
> similarly to gBS->RegisterProtocolNotify(). We should pass the address of
> an actual pointer-to-VOID, and not the address of an EFI_EVENT. EFI_EVENT
> just happens to be specified as (VOID*), and has nothing to do with the
> registration.
>
> The same applies to gMmst->MmRegisterProtocolNotify().
>
> "mFtwRegistration", "mFvRegistration", and "mFvbRegistration" are used for
> nothing else.
>
> This change is a no-op in practice; it's a semantic improvement.
>
> Cc: Hao A Wu <hao.a.wu@intel.com>
> Cc: Jian J Wang <jian.j.wang@intel.com>
> Cc: Liming Gao <liming.gao@intel.com>
> Cc: Ray Ni <ray.ni@intel.com>
> Cc: Zhichao Gao <zhichao.gao@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> lightly tested, as these modules (except LoadFileOnFv2) are part of the
> ArmVirt and/or OVMF platforms
>
> MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c | 2 +-
> MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c | 2 +-
> MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.c | 2 +-
> MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c | 2 +-
> 4 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c
> index ae8f117905cd..de38ea028af1 100644
> --- a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c
> +++ b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c
> @@ -47,7 +47,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>
> #include <Library/UefiBootServicesTableLib.h>
> #include "FaultTolerantWrite.h"
> -EFI_EVENT mFvbRegistration = NULL;
> +VOID *mFvbRegistration = NULL;
>
>
> /**
> diff --git a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c
> index e8e935a85b5b..9612b394865b 100644
> --- a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c
> +++ b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c
> @@ -56,7 +56,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> #include "FaultTolerantWriteSmmCommon.h"
> #include <Protocol/MmEndOfDxe.h>
>
> -EFI_EVENT mFvbRegistration = NULL;
> +VOID *mFvbRegistration = NULL;
> EFI_FTW_DEVICE *mFtwDevice = NULL;
>
> ///
> diff --git a/MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.c b/MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.c
> index 4af2da05e145..43fa6ce12875 100644
> --- a/MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.c
> +++ b/MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.c
> @@ -36,7 +36,7 @@ typedef struct {
> #define LOAD_FILE_ON_FV2_PRIVATE_DATA_FROM_THIS(a) CR (a, LOAD_FILE_ON_FV2_PRIVATE_DATA, LoadFile, LOAD_FILE_ON_FV2_PRIVATE_DATA_SIGNATURE)
> #define LOAD_FILE_ON_FV2_PRIVATE_DATA_FROM_LINK(a) CR (a, LOAD_FILE_ON_FV2_PRIVATE_DATA, Link, LOAD_FILE_ON_FV2_PRIVATE_DATA_SIGNATURE)
>
> -EFI_EVENT mFvRegistration;
> +VOID *mFvRegistration;
> LIST_ENTRY mPrivateDataList;
>
> /**
> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
> index 3d232bb36cb4..7d2b6c8e1fad 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
> @@ -13,7 +13,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>
> EFI_HANDLE mHandle = NULL;
> EFI_EVENT mVirtualAddressChangeEvent = NULL;
> -EFI_EVENT mFtwRegistration = NULL;
> +VOID *mFtwRegistration = NULL;
> VOID ***mVarCheckAddressPointer = NULL;
> UINTN mVarCheckAddressPointerCount = 0;
> EDKII_VARIABLE_LOCK_PROTOCOL mVariableLock = { VariableLockRequestToLock };
Surprisingly the one declared in
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c is correct :)
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 29/35] ShellPkg: stop using EFI_HANDLE in place of EFI_HII_HANDLE
2019-09-17 19:49 ` [PATCH 29/35] ShellPkg: stop using EFI_HANDLE in place of EFI_HII_HANDLE Laszlo Ersek
@ 2019-09-25 18:04 ` Philippe Mathieu-Daudé
2019-09-26 11:48 ` Laszlo Ersek
2019-09-26 2:43 ` Gao, Zhichao
1 sibling, 1 reply; 155+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-09-25 18:04 UTC (permalink / raw)
To: devel, lersek; +Cc: Jaben Carsey, Ray Ni, Zhichao Gao
On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> The UefiShell*CommandsLib instances have constructor functions that do
> something like:
>
> gHiiHandle = HiiAddPackages (...);
> ...
> ShellCommandRegisterCommandName (..., gHiiHandle, ...);
>
> and destructor functions that implement the following pattern:
>
> HiiRemovePackages (gHiiHandle);
>
> The -- semantic, not functional -- problem is that "gHiiHandle" is
> declared with type EFI_HANDLE, and not EFI_HII_HANDLE, in all of these
> library instances, even though HiiAddPackages() correctly returns
> EFI_HII_HANDLE, and HiiRemovePackages() takes EFI_HII_HANDLE.
>
> Once we fix the type of "gHiiHandle", it causes sort of a butterfly
> effect, because it is passed around widely. Track down and update all of
> those locations.
>
> The DynamicCommand lib instances use a similar pattern, so they are
> affected too.
>
> NOTE: in practice, this patch is a no-op, as both EFI_HII_HANDLE and
> EFI_HANDLE are typedefs to (VOID*). However, we shouldn't use EFI_HANDLE
> where semantically EFI_HII_HANDLE is passed around.
>
> Cc: Jaben Carsey <jaben.carsey@intel.com>
> Cc: Ray Ni <ray.ni@intel.com>
> Cc: Zhichao Gao <zhichao.gao@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> tested with:
> - level 1: stall, exit
> - level 2: ls
> - level 3: pause
> - dynamic command: tftp
> - handle parsing: drivers, devices, dh
>
> ShellPkg/Include/Library/ShellCommandLib.h | 2 +-
> ShellPkg/Include/Library/ShellLib.h | 4 ++--
> ShellPkg/DynamicCommand/DpDynamicCommand/Dp.h | 4 ++--
> ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.h | 4 ++--
> ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.h | 2 +-
> ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.h | 2 +-
> ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.h | 2 +-
> ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.h | 2 +-
> ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.h | 2 +-
> ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.h | 2 +-
> ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.h | 2 +-
> ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.h | 2 +-
> ShellPkg/DynamicCommand/DpDynamicCommand/Dp.c | 6 +++---
> ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c | 6 +++---
> ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c | 2 +-
> ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c | 2 +-
> ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c | 2 +-
> ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.c | 2 +-
> ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.c | 2 +-
> ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.c | 2 +-
> ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.c | 2 +-
> ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.c | 2 +-
> ShellPkg/Library/UefiShellLib/UefiShellLib.c | 4 ++--
> ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.c | 2 +-
> ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.c | 2 +-
> 25 files changed, 33 insertions(+), 33 deletions(-)
>
> diff --git a/ShellPkg/Include/Library/ShellCommandLib.h b/ShellPkg/Include/Library/ShellCommandLib.h
> index 287bc0eba7f9..63fcac82a2de 100644
> --- a/ShellPkg/Include/Library/ShellCommandLib.h
> +++ b/ShellPkg/Include/Library/ShellCommandLib.h
> @@ -136,7 +136,7 @@ ShellCommandRegisterCommandName (
> IN UINT32 ShellMinSupportLevel,
> IN CONST CHAR16 *ProfileName,
> IN CONST BOOLEAN CanAffectLE,
> - IN CONST EFI_HANDLE HiiHandle,
> + IN CONST EFI_HII_HANDLE HiiHandle,
Updated in UefiShellCommandLib/UefiShellCommandLib.h, OK.
> IN CONST EFI_STRING_ID ManFormatHelp
> );
>
> diff --git a/ShellPkg/Include/Library/ShellLib.h b/ShellPkg/Include/Library/ShellLib.h
> index 31594796cd21..1dc41f2cc11b 100644
> --- a/ShellPkg/Include/Library/ShellLib.h
> +++ b/ShellPkg/Include/Library/ShellLib.h
> @@ -965,7 +965,7 @@ ShellPrintHiiEx(
> IN INT32 Row OPTIONAL,
> IN CONST CHAR8 *Language OPTIONAL,
> IN CONST EFI_STRING_ID HiiFormatStringId,
> - IN CONST EFI_HANDLE HiiFormatHandle,
> + IN CONST EFI_HII_HANDLE HiiFormatHandle,
OK
> ...
> );
>
> @@ -1260,7 +1260,7 @@ EFIAPI
> ShellPromptForResponseHii (
> IN SHELL_PROMPT_REQUEST_TYPE Type,
> IN CONST EFI_STRING_ID HiiFormatStringId,
> - IN CONST EFI_HANDLE HiiFormatHandle,
> + IN CONST EFI_HII_HANDLE HiiFormatHandle,
OK
> IN OUT VOID **Response
> );
>
> diff --git a/ShellPkg/DynamicCommand/DpDynamicCommand/Dp.h b/ShellPkg/DynamicCommand/DpDynamicCommand/Dp.h
> index 43aa4505ee37..e446cccde923 100644
> --- a/ShellPkg/DynamicCommand/DpDynamicCommand/Dp.h
> +++ b/ShellPkg/DynamicCommand/DpDynamicCommand/Dp.h
> @@ -36,7 +36,7 @@
> #include <Library/UefiHiiServicesLib.h>
> #include <Library/PerformanceLib.h>
>
> -extern EFI_HANDLE mDpHiiHandle;
> +extern EFI_HII_HANDLE mDpHiiHandle;
>
> #define DP_MAJOR_VERSION 2
> #define DP_MINOR_VERSION 5
> @@ -133,7 +133,7 @@ RunDp (
>
> @return HII handle.
> **/
> -EFI_HANDLE
> +EFI_HII_HANDLE
OK
> InitializeHiiPackage (
> EFI_HANDLE ImageHandle
> );
> diff --git a/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.h b/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.h
> index 7a9ed4724e1f..4cd778436813 100644
> --- a/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.h
> +++ b/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.h
> @@ -30,7 +30,7 @@
> #include <Library/PrintLib.h>
> #include <Library/UefiHiiServicesLib.h>
>
> -extern EFI_HANDLE mTftpHiiHandle;
> +extern EFI_HII_HANDLE mTftpHiiHandle;
OK
>
> typedef struct {
> UINTN FileSize;
> @@ -62,7 +62,7 @@ RunTftp (
>
> @return HII handle.
> **/
> -EFI_HANDLE
> +EFI_HII_HANDLE
OK
> InitializeHiiPackage (
> EFI_HANDLE ImageHandle
> );
> diff --git a/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.h b/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.h
> index 36fe628a8c68..8ecc2f6bf5a2 100644
> --- a/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.h
> +++ b/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.h
> @@ -46,7 +46,7 @@ typedef struct{
> SHELL_GET_MAN_FILENAME GetManFileName;
> SHELL_RUN_COMMAND CommandHandler;
> BOOLEAN LastError;
> - EFI_HANDLE HiiHandle;
> + EFI_HII_HANDLE HiiHandle;
OK
> EFI_STRING_ID ManFormatHelp;
> } SHELL_COMMAND_INTERNAL_LIST_ENTRY;
>
> diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.h b/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.h
> index 32a933b9f062..082d488cb283 100644
> --- a/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.h
> +++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.h
> @@ -52,7 +52,7 @@
> #include <Library/HandleParsingLib.h>
>
>
> -extern EFI_HANDLE gShellDebug1HiiHandle;
> +extern EFI_HII_HANDLE gShellDebug1HiiHandle;
OK
>
> /**
> Function returns a system configuration table that is stored in the
> diff --git a/ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.h b/ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.h
> index 7e0b8b094057..ee795c4ce024 100644
> --- a/ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.h
> +++ b/ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.h
> @@ -58,7 +58,7 @@
> #include <Library/HandleParsingLib.h>
>
>
> -extern EFI_HANDLE gShellDriver1HiiHandle;
> +extern EFI_HII_HANDLE gShellDriver1HiiHandle;
> extern BOOLEAN gInReconnect;
>
> /**
> diff --git a/ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.h b/ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.h
> index 55acdd2b1f95..f2f9cc5dcf3b 100644
> --- a/ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.h
> +++ b/ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.h
> @@ -33,7 +33,7 @@
> #include <Library/HiiLib.h>
> #include <Library/FileHandleLib.h>
>
> -extern EFI_HANDLE gShellLevel1HiiHandle;
> +extern EFI_HII_HANDLE gShellLevel1HiiHandle;
>
> /**
> Function for 'stall' command.
> diff --git a/ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.h b/ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.h
> index 6d522d4bb4a1..77be6f1a12c7 100644
> --- a/ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.h
> +++ b/ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.h
> @@ -43,7 +43,7 @@
> #include <Library/FileHandleLib.h>
>
> extern CONST CHAR16 mFileName[];
> -extern EFI_HANDLE gShellLevel2HiiHandle;
> +extern EFI_HII_HANDLE gShellLevel2HiiHandle;
OK
>
> /**
> Function for 'attrib' command.
> diff --git a/ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.h b/ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.h
> index 2d97ae4d3c91..c095b9275ed0 100644
> --- a/ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.h
> +++ b/ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.h
> @@ -32,7 +32,7 @@
> #include <Library/HiiLib.h>
> #include <Library/FileHandleLib.h>
>
> -extern EFI_HANDLE gShellLevel3HiiHandle;
> +extern EFI_HII_HANDLE gShellLevel3HiiHandle;
>
> /**
> Function for 'type' command.
> diff --git a/ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.h b/ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.h
> index d4ed8c04652d..fddada2efa48 100644
> --- a/ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.h
> +++ b/ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.h
> @@ -38,7 +38,7 @@
> #include <Library/DevicePathLib.h>
> #include <Library/PrintLib.h>
>
> -extern EFI_HANDLE gShellNetwork1HiiHandle;
> +extern EFI_HII_HANDLE gShellNetwork1HiiHandle;
>
> /**
> Function for 'ping' command.
> diff --git a/ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.h b/ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.h
> index 9a5db32f2b76..9ea42cf26d53 100644
> --- a/ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.h
> +++ b/ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.h
> @@ -27,7 +27,7 @@
> #include <Library/HiiLib.h>
> #include <Library/NetLib.h>
>
> -extern EFI_HANDLE gShellNetwork2HiiHandle;
> +extern EFI_HII_HANDLE gShellNetwork2HiiHandle;
OK
>
> /**
> Function for 'ping6' command.
> diff --git a/ShellPkg/DynamicCommand/DpDynamicCommand/Dp.c b/ShellPkg/DynamicCommand/DpDynamicCommand/Dp.c
> index 735cdcbcc018..4ec4c18348bd 100644
> --- a/ShellPkg/DynamicCommand/DpDynamicCommand/Dp.c
> +++ b/ShellPkg/DynamicCommand/DpDynamicCommand/Dp.c
> @@ -36,7 +36,7 @@ typedef struct {
>
> #pragma pack()
>
> -EFI_HANDLE mDpHiiHandle;
> +EFI_HII_HANDLE mDpHiiHandle;
OK
>
> typedef struct {
> EFI_HANDLE Handle;
> @@ -924,14 +924,14 @@ Done:
>
> @return HII handle.
> **/
> -EFI_HANDLE
> +EFI_HII_HANDLE
OK
> InitializeHiiPackage (
> EFI_HANDLE ImageHandle
> )
> {
> EFI_STATUS Status;
> EFI_HII_PACKAGE_LIST_HEADER *PackageList;
> - EFI_HANDLE HiiHandle;
> + EFI_HII_HANDLE HiiHandle;
OK
>
> //
> // Retrieve HII package list from ImageHandle
> diff --git a/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c b/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c
> index 607899032e9d..f28da9af723c 100644
> --- a/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c
> +++ b/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c
> @@ -11,7 +11,7 @@
> #include "Tftp.h"
>
> #define IP4_CONFIG2_INTERFACE_INFO_NAME_LENGTH 32
> -EFI_HANDLE mTftpHiiHandle;
> +EFI_HII_HANDLE mTftpHiiHandle;
OK
>
> /*
> Constant strings and definitions related to the message indicating the amount of
> @@ -1087,14 +1087,14 @@ CheckPacket (
>
> @return HII handle.
> **/
> -EFI_HANDLE
> +EFI_HII_HANDLE
OK
> InitializeHiiPackage (
> EFI_HANDLE ImageHandle
> )
> {
> EFI_STATUS Status;
> EFI_HII_PACKAGE_LIST_HEADER *PackageList;
> - EFI_HANDLE HiiHandle;
> + EFI_HII_HANDLE HiiHandle;
OK
>
> //
> // Retrieve HII package list from ImageHandle
> diff --git a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
> index f179c4109223..f62d30ef677a 100644
> --- a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
> +++ b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
> @@ -14,7 +14,7 @@
> #include <PiDxe.h>
> #include <Protocol/FirmwareVolume2.h>
>
> -EFI_HANDLE mHandleParsingHiiHandle = NULL;
> +EFI_HII_HANDLE mHandleParsingHiiHandle = NULL;
OK
> HANDLE_INDEX_LIST mHandleList = {{{NULL,NULL},0,0},0};
> GUID_INFO_BLOCK *mGuidList;
> UINTN mGuidListCount;
> diff --git a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
> index e8b48b4990dd..f8bcaebe46c8 100644
> --- a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
> +++ b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
> @@ -38,7 +38,7 @@
> #include <Library/UefiBootManagerLib.h>
>
> STATIC CONST CHAR16 mFileName[] = L"ShellCommands";
> -STATIC EFI_HANDLE gShellBcfgHiiHandle = NULL;
> +STATIC EFI_HII_HANDLE gShellBcfgHiiHandle = NULL;
OK
>
> typedef enum {
> BcfgTargetBootOrder = 0,
> diff --git a/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c b/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c
> index 826ced30a8c8..4c48b65fbc1d 100644
> --- a/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c
> +++ b/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c
> @@ -554,7 +554,7 @@ ShellCommandRegisterCommandName (
> IN UINT32 ShellMinSupportLevel,
> IN CONST CHAR16 *ProfileName,
> IN CONST BOOLEAN CanAffectLE,
> - IN CONST EFI_HANDLE HiiHandle,
> + IN CONST EFI_HII_HANDLE HiiHandle,
OK
> IN CONST EFI_STRING_ID ManFormatHelp
> )
> {
> diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.c b/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.c
> index ddce3bef5a30..f918867f47af 100644
> --- a/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.c
> +++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.c
> @@ -10,7 +10,7 @@
> #include <Library/BcfgCommandLib.h>
>
> STATIC CONST CHAR16 mFileName[] = L"Debug1Commands";
> -EFI_HANDLE gShellDebug1HiiHandle = NULL;
> +EFI_HII_HANDLE gShellDebug1HiiHandle = NULL;
OK
>
> /**
> Gets the debug file name. This will be used if HII is not working.
> diff --git a/ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.c b/ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.c
> index 4a05fa9942c4..e2219c62ec25 100644
> --- a/ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.c
> +++ b/ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.c
> @@ -9,7 +9,7 @@
> #include "UefiShellDriver1CommandsLib.h"
>
> STATIC CONST CHAR16 mFileName[] = L"Driver1Commands";
> -EFI_HANDLE gShellDriver1HiiHandle = NULL;
> +EFI_HII_HANDLE gShellDriver1HiiHandle = NULL;
OK
> BOOLEAN gInReconnect = FALSE;
>
> /**
> diff --git a/ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.c b/ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.c
> index ecbee99e3b3d..88cddd88ddc4 100644
> --- a/ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.c
> +++ b/ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.c
> @@ -10,7 +10,7 @@
> #include "UefiShellLevel1CommandsLib.h"
>
> STATIC CONST CHAR16 mFileName[] = L"ShellCommands";
> -EFI_HANDLE gShellLevel1HiiHandle = NULL;
> +EFI_HII_HANDLE gShellLevel1HiiHandle = NULL;
OK
>
> /**
> Return the help text filename. Only used if no HII information found.
> diff --git a/ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.c b/ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.c
> index c2a0bb492fbb..69427637bb87 100644
> --- a/ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.c
> +++ b/ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.c
> @@ -29,7 +29,7 @@
> #include "UefiShellLevel2CommandsLib.h"
>
> CONST CHAR16 mFileName[] = L"ShellCommands";
> -EFI_HANDLE gShellLevel2HiiHandle = NULL;
> +EFI_HII_HANDLE gShellLevel2HiiHandle = NULL;
OK
>
> /**
> Get the filename to get help text from if not using HII.
> diff --git a/ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.c b/ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.c
> index 7d2cc4a48371..ce4afd117aa1 100644
> --- a/ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.c
> +++ b/ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.c
> @@ -9,7 +9,7 @@
> #include "UefiShellLevel3CommandsLib.h"
>
> CONST CHAR16 gShellLevel3FileName[] = L"ShellCommands";
> -EFI_HANDLE gShellLevel3HiiHandle = NULL;
> +EFI_HII_HANDLE gShellLevel3HiiHandle = NULL;
OK
>
> /**
> return the filename to get help from is not using HII.
> diff --git a/ShellPkg/Library/UefiShellLib/UefiShellLib.c b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> index 5be530092e1b..835d0f88ca74 100644
> --- a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> +++ b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> @@ -2997,7 +2997,7 @@ ShellPrintHiiEx(
> IN INT32 Row OPTIONAL,
> IN CONST CHAR8 *Language OPTIONAL,
> IN CONST EFI_STRING_ID HiiFormatStringId,
> - IN CONST EFI_HANDLE HiiFormatHandle,
> + IN CONST EFI_HII_HANDLE HiiFormatHandle,
OK
> ...
> )
> {
> @@ -3609,7 +3609,7 @@ EFIAPI
> ShellPromptForResponseHii (
> IN SHELL_PROMPT_REQUEST_TYPE Type,
> IN CONST EFI_STRING_ID HiiFormatStringId,
> - IN CONST EFI_HANDLE HiiFormatHandle,
> + IN CONST EFI_HII_HANDLE HiiFormatHandle,
OK
> IN OUT VOID **Response
> )
> {
> diff --git a/ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.c b/ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.c
> index 7e823cabd2fe..9a2b23fdc5ba 100644
> --- a/ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.c
> +++ b/ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.c
> @@ -8,7 +8,7 @@
> #include "UefiShellNetwork1CommandsLib.h"
>
> CONST CHAR16 gShellNetwork1FileName[] = L"ShellCommands";
> -EFI_HANDLE gShellNetwork1HiiHandle = NULL;
> +EFI_HII_HANDLE gShellNetwork1HiiHandle = NULL;
OK
>
> /**
> return the file name of the help text file if not using HII.
> diff --git a/ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.c b/ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.c
> index 5a7ffbfa19eb..4aab4295c1ba 100644
> --- a/ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.c
> +++ b/ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.c
> @@ -8,7 +8,7 @@
> #include "UefiShellNetwork2CommandsLib.h"
>
> CONST CHAR16 gShellNetwork2FileName[] = L"ShellCommands";
> -EFI_HANDLE gShellNetwork2HiiHandle = NULL;
> +EFI_HII_HANDLE gShellNetwork2HiiHandle = NULL;
OK
>
> /**
> return the file name of the help text file if not using HII.
>
I checked every case, entertaining.
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 29/35] ShellPkg: stop using EFI_HANDLE in place of EFI_HII_HANDLE
2019-09-17 19:49 ` [PATCH 29/35] ShellPkg: stop using EFI_HANDLE in place of EFI_HII_HANDLE Laszlo Ersek
2019-09-25 18:04 ` [edk2-devel] " Philippe Mathieu-Daudé
@ 2019-09-26 2:43 ` Gao, Zhichao
1 sibling, 0 replies; 155+ messages in thread
From: Gao, Zhichao @ 2019-09-26 2:43 UTC (permalink / raw)
To: Laszlo Ersek, edk2-devel-groups-io; +Cc: Carsey, Jaben, Ni, Ray
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
> -----Original Message-----
> From: Laszlo Ersek [mailto:lersek@redhat.com]
> Sent: Wednesday, September 18, 2019 3:49 AM
> To: edk2-devel-groups-io <devel@edk2.groups.io>
> Cc: Carsey, Jaben <jaben.carsey@intel.com>; Ni, Ray <ray.ni@intel.com>;
> Gao, Zhichao <zhichao.gao@intel.com>
> Subject: [PATCH 29/35] ShellPkg: stop using EFI_HANDLE in place of
> EFI_HII_HANDLE
>
> The UefiShell*CommandsLib instances have constructor functions that do
> something like:
>
> gHiiHandle = HiiAddPackages (...);
> ...
> ShellCommandRegisterCommandName (..., gHiiHandle, ...);
>
> and destructor functions that implement the following pattern:
>
> HiiRemovePackages (gHiiHandle);
>
> The -- semantic, not functional -- problem is that "gHiiHandle" is declared
> with type EFI_HANDLE, and not EFI_HII_HANDLE, in all of these library
> instances, even though HiiAddPackages() correctly returns EFI_HII_HANDLE,
> and HiiRemovePackages() takes EFI_HII_HANDLE.
>
> Once we fix the type of "gHiiHandle", it causes sort of a butterfly effect,
> because it is passed around widely. Track down and update all of those
> locations.
>
> The DynamicCommand lib instances use a similar pattern, so they are
> affected too.
>
> NOTE: in practice, this patch is a no-op, as both EFI_HII_HANDLE and
> EFI_HANDLE are typedefs to (VOID*). However, we shouldn't use
> EFI_HANDLE where semantically EFI_HII_HANDLE is passed around.
>
> Cc: Jaben Carsey <jaben.carsey@intel.com>
> Cc: Ray Ni <ray.ni@intel.com>
> Cc: Zhichao Gao <zhichao.gao@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> tested with:
> - level 1: stall, exit
> - level 2: ls
> - level 3: pause
> - dynamic command: tftp
> - handle parsing: drivers, devices, dh
>
> ShellPkg/Include/Library/ShellCommandLib.h | 2 +-
> ShellPkg/Include/Library/ShellLib.h | 4 ++--
> ShellPkg/DynamicCommand/DpDynamicCommand/Dp.h | 4
> ++--
> ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.h | 4
> ++--
> ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.h | 2
> +-
>
> ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1Commands
> Lib.h | 2 +-
>
> ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsL
> ib.h | 2 +-
>
> ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib
> .h | 2 +-
>
> ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib
> .h | 2 +-
>
> ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib
> .h | 2 +-
>
> ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1Comm
> andsLib.h | 2 +-
> ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2Comm
> andsLib.h | 2 +-
> ShellPkg/DynamicCommand/DpDynamicCommand/Dp.c | 6
> +++---
> ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c | 6
> +++---
> ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c | 2 +-
> ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
> | 2 +-
> ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c | 2
> +-
>
> ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1Commands
> Lib.c | 2 +-
>
> ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsL
> ib.c | 2 +-
>
> ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib
> .c | 2 +-
>
> ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib
> .c | 2 +-
>
> ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib
> .c | 2 +-
> ShellPkg/Library/UefiShellLib/UefiShellLib.c | 4 ++--
>
> ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1Comm
> andsLib.c | 2 +-
> ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2Comm
> andsLib.c | 2 +-
> 25 files changed, 33 insertions(+), 33 deletions(-)
>
> diff --git a/ShellPkg/Include/Library/ShellCommandLib.h
> b/ShellPkg/Include/Library/ShellCommandLib.h
> index 287bc0eba7f9..63fcac82a2de 100644
> --- a/ShellPkg/Include/Library/ShellCommandLib.h
> +++ b/ShellPkg/Include/Library/ShellCommandLib.h
> @@ -136,7 +136,7 @@ ShellCommandRegisterCommandName (
> IN UINT32 ShellMinSupportLevel,
> IN CONST CHAR16 *ProfileName,
> IN CONST BOOLEAN CanAffectLE,
> - IN CONST EFI_HANDLE HiiHandle,
> + IN CONST EFI_HII_HANDLE HiiHandle,
> IN CONST EFI_STRING_ID ManFormatHelp
> );
>
> diff --git a/ShellPkg/Include/Library/ShellLib.h
> b/ShellPkg/Include/Library/ShellLib.h
> index 31594796cd21..1dc41f2cc11b 100644
> --- a/ShellPkg/Include/Library/ShellLib.h
> +++ b/ShellPkg/Include/Library/ShellLib.h
> @@ -965,7 +965,7 @@ ShellPrintHiiEx(
> IN INT32 Row OPTIONAL,
> IN CONST CHAR8 *Language OPTIONAL,
> IN CONST EFI_STRING_ID HiiFormatStringId,
> - IN CONST EFI_HANDLE HiiFormatHandle,
> + IN CONST EFI_HII_HANDLE HiiFormatHandle,
> ...
> );
>
> @@ -1260,7 +1260,7 @@ EFIAPI
> ShellPromptForResponseHii (
> IN SHELL_PROMPT_REQUEST_TYPE Type,
> IN CONST EFI_STRING_ID HiiFormatStringId,
> - IN CONST EFI_HANDLE HiiFormatHandle,
> + IN CONST EFI_HII_HANDLE HiiFormatHandle,
> IN OUT VOID **Response
> );
>
> diff --git a/ShellPkg/DynamicCommand/DpDynamicCommand/Dp.h
> b/ShellPkg/DynamicCommand/DpDynamicCommand/Dp.h
> index 43aa4505ee37..e446cccde923 100644
> --- a/ShellPkg/DynamicCommand/DpDynamicCommand/Dp.h
> +++ b/ShellPkg/DynamicCommand/DpDynamicCommand/Dp.h
> @@ -36,7 +36,7 @@
> #include <Library/UefiHiiServicesLib.h> #include <Library/PerformanceLib.h>
>
> -extern EFI_HANDLE mDpHiiHandle;
> +extern EFI_HII_HANDLE mDpHiiHandle;
>
> #define DP_MAJOR_VERSION 2
> #define DP_MINOR_VERSION 5
> @@ -133,7 +133,7 @@ RunDp (
>
> @return HII handle.
> **/
> -EFI_HANDLE
> +EFI_HII_HANDLE
> InitializeHiiPackage (
> EFI_HANDLE ImageHandle
> );
> diff --git a/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.h
> b/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.h
> index 7a9ed4724e1f..4cd778436813 100644
> --- a/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.h
> +++ b/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.h
> @@ -30,7 +30,7 @@
> #include <Library/PrintLib.h>
> #include <Library/UefiHiiServicesLib.h>
>
> -extern EFI_HANDLE mTftpHiiHandle;
> +extern EFI_HII_HANDLE mTftpHiiHandle;
>
> typedef struct {
> UINTN FileSize;
> @@ -62,7 +62,7 @@ RunTftp (
>
> @return HII handle.
> **/
> -EFI_HANDLE
> +EFI_HII_HANDLE
> InitializeHiiPackage (
> EFI_HANDLE ImageHandle
> );
> diff --git a/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.h
> b/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.h
> index 36fe628a8c68..8ecc2f6bf5a2 100644
> --- a/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.h
> +++ b/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.h
> @@ -46,7 +46,7 @@ typedef struct{
> SHELL_GET_MAN_FILENAME GetManFileName;
> SHELL_RUN_COMMAND CommandHandler;
> BOOLEAN LastError;
> - EFI_HANDLE HiiHandle;
> + EFI_HII_HANDLE HiiHandle;
> EFI_STRING_ID ManFormatHelp;
> } SHELL_COMMAND_INTERNAL_LIST_ENTRY;
>
> diff --git
> a/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1Comman
> dsLib.h
> b/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1Comman
> dsLib.h
> index 32a933b9f062..082d488cb283 100644
> ---
> a/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1Comman
> dsLib.h
> +++
> b/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1Comman
> d
> +++ sLib.h
> @@ -52,7 +52,7 @@
> #include <Library/HandleParsingLib.h>
>
>
> -extern EFI_HANDLE gShellDebug1HiiHandle;
> +extern EFI_HII_HANDLE gShellDebug1HiiHandle;
>
> /**
> Function returns a system configuration table that is stored in the diff --git
> a/ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1Command
> sLib.h
> b/ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1Comman
> dsLib.h
> index 7e0b8b094057..ee795c4ce024 100644
> ---
> a/ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1Command
> sLib.h
> +++
> b/ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1Comma
> +++ ndsLib.h
> @@ -58,7 +58,7 @@
> #include <Library/HandleParsingLib.h>
>
>
> -extern EFI_HANDLE gShellDriver1HiiHandle;
> +extern EFI_HII_HANDLE gShellDriver1HiiHandle;
> extern BOOLEAN gInReconnect;
>
> /**
> diff --git
> a/ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1Commands
> Lib.h
> b/ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1Commands
> Lib.h
> index 55acdd2b1f95..f2f9cc5dcf3b 100644
> ---
> a/ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1Commands
> Lib.h
> +++
> b/ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1Command
> +++ sLib.h
> @@ -33,7 +33,7 @@
> #include <Library/HiiLib.h>
> #include <Library/FileHandleLib.h>
>
> -extern EFI_HANDLE gShellLevel1HiiHandle;
> +extern EFI_HII_HANDLE gShellLevel1HiiHandle;
>
> /**
> Function for 'stall' command.
> diff --git
> a/ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2Commands
> Lib.h
> b/ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2Commands
> Lib.h
> index 6d522d4bb4a1..77be6f1a12c7 100644
> ---
> a/ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2Commands
> Lib.h
> +++
> b/ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2Command
> +++ sLib.h
> @@ -43,7 +43,7 @@
> #include <Library/FileHandleLib.h>
>
> extern CONST CHAR16 mFileName[];
> -extern EFI_HANDLE gShellLevel2HiiHandle;
> +extern EFI_HII_HANDLE gShellLevel2HiiHandle;
>
> /**
> Function for 'attrib' command.
> diff --git
> a/ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3Commands
> Lib.h
> b/ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3Commands
> Lib.h
> index 2d97ae4d3c91..c095b9275ed0 100644
> ---
> a/ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3Commands
> Lib.h
> +++
> b/ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3Command
> +++ sLib.h
> @@ -32,7 +32,7 @@
> #include <Library/HiiLib.h>
> #include <Library/FileHandleLib.h>
>
> -extern EFI_HANDLE gShellLevel3HiiHandle;
> +extern EFI_HII_HANDLE gShellLevel3HiiHandle;
>
> /**
> Function for 'type' command.
> diff --git
> a/ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1Com
> mandsLib.h
> b/ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1Com
> mandsLib.h
> index d4ed8c04652d..fddada2efa48 100644
> ---
> a/ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1Com
> mandsLib.h
> +++
> b/ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1Com
> +++ mandsLib.h
> @@ -38,7 +38,7 @@
> #include <Library/DevicePathLib.h>
> #include <Library/PrintLib.h>
>
> -extern EFI_HANDLE gShellNetwork1HiiHandle;
> +extern EFI_HII_HANDLE gShellNetwork1HiiHandle;
>
> /**
> Function for 'ping' command.
> diff --git
> a/ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2Com
> mandsLib.h
> b/ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2Com
> mandsLib.h
> index 9a5db32f2b76..9ea42cf26d53 100644
> ---
> a/ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2Com
> mandsLib.h
> +++
> b/ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2Com
> +++ mandsLib.h
> @@ -27,7 +27,7 @@
> #include <Library/HiiLib.h>
> #include <Library/NetLib.h>
>
> -extern EFI_HANDLE gShellNetwork2HiiHandle;
> +extern EFI_HII_HANDLE gShellNetwork2HiiHandle;
>
> /**
> Function for 'ping6' command.
> diff --git a/ShellPkg/DynamicCommand/DpDynamicCommand/Dp.c
> b/ShellPkg/DynamicCommand/DpDynamicCommand/Dp.c
> index 735cdcbcc018..4ec4c18348bd 100644
> --- a/ShellPkg/DynamicCommand/DpDynamicCommand/Dp.c
> +++ b/ShellPkg/DynamicCommand/DpDynamicCommand/Dp.c
> @@ -36,7 +36,7 @@ typedef struct {
>
> #pragma pack()
>
> -EFI_HANDLE mDpHiiHandle;
> +EFI_HII_HANDLE mDpHiiHandle;
>
> typedef struct {
> EFI_HANDLE Handle;
> @@ -924,14 +924,14 @@ Done:
>
> @return HII handle.
> **/
> -EFI_HANDLE
> +EFI_HII_HANDLE
> InitializeHiiPackage (
> EFI_HANDLE ImageHandle
> )
> {
> EFI_STATUS Status;
> EFI_HII_PACKAGE_LIST_HEADER *PackageList;
> - EFI_HANDLE HiiHandle;
> + EFI_HII_HANDLE HiiHandle;
>
> //
> // Retrieve HII package list from ImageHandle diff --git
> a/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c
> b/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c
> index 607899032e9d..f28da9af723c 100644
> --- a/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c
> +++ b/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c
> @@ -11,7 +11,7 @@
> #include "Tftp.h"
>
> #define IP4_CONFIG2_INTERFACE_INFO_NAME_LENGTH 32
> -EFI_HANDLE mTftpHiiHandle;
> +EFI_HII_HANDLE mTftpHiiHandle;
>
> /*
> Constant strings and definitions related to the message indicating the
> amount of @@ -1087,14 +1087,14 @@ CheckPacket (
>
> @return HII handle.
> **/
> -EFI_HANDLE
> +EFI_HII_HANDLE
> InitializeHiiPackage (
> EFI_HANDLE ImageHandle
> )
> {
> EFI_STATUS Status;
> EFI_HII_PACKAGE_LIST_HEADER *PackageList;
> - EFI_HANDLE HiiHandle;
> + EFI_HII_HANDLE HiiHandle;
>
> //
> // Retrieve HII package list from ImageHandle diff --git
> a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
> b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
> index f179c4109223..f62d30ef677a 100644
> --- a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
> +++ b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
> @@ -14,7 +14,7 @@
> #include <PiDxe.h>
> #include <Protocol/FirmwareVolume2.h>
>
> -EFI_HANDLE mHandleParsingHiiHandle = NULL;
> +EFI_HII_HANDLE mHandleParsingHiiHandle = NULL;
> HANDLE_INDEX_LIST mHandleList = {{{NULL,NULL},0,0},0};
> GUID_INFO_BLOCK *mGuidList;
> UINTN mGuidListCount;
> diff --git
> a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
> b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
> index e8b48b4990dd..f8bcaebe46c8 100644
> ---
> a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
> +++
> b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
> @@ -38,7 +38,7 @@
> #include <Library/UefiBootManagerLib.h>
>
> STATIC CONST CHAR16 mFileName[] = L"ShellCommands"; -STATIC
> EFI_HANDLE gShellBcfgHiiHandle = NULL;
> +STATIC EFI_HII_HANDLE gShellBcfgHiiHandle = NULL;
>
> typedef enum {
> BcfgTargetBootOrder = 0,
> diff --git a/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c
> b/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c
> index 826ced30a8c8..4c48b65fbc1d 100644
> --- a/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c
> +++ b/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c
> @@ -554,7 +554,7 @@ ShellCommandRegisterCommandName (
> IN UINT32 ShellMinSupportLevel,
> IN CONST CHAR16 *ProfileName,
> IN CONST BOOLEAN CanAffectLE,
> - IN CONST EFI_HANDLE HiiHandle,
> + IN CONST EFI_HII_HANDLE HiiHandle,
> IN CONST EFI_STRING_ID ManFormatHelp
> )
> {
> diff --git
> a/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1Comman
> dsLib.c
> b/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1Comman
> dsLib.c
> index ddce3bef5a30..f918867f47af 100644
> ---
> a/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1Comman
> dsLib.c
> +++
> b/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1Comman
> d
> +++ sLib.c
> @@ -10,7 +10,7 @@
> #include <Library/BcfgCommandLib.h>
>
> STATIC CONST CHAR16 mFileName[] = L"Debug1Commands"; -EFI_HANDLE
> gShellDebug1HiiHandle = NULL;
> +EFI_HII_HANDLE gShellDebug1HiiHandle = NULL;
>
> /**
> Gets the debug file name. This will be used if HII is not working.
> diff --git
> a/ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1Command
> sLib.c
> b/ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1Comman
> dsLib.c
> index 4a05fa9942c4..e2219c62ec25 100644
> ---
> a/ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1Command
> sLib.c
> +++
> b/ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1Comma
> +++ ndsLib.c
> @@ -9,7 +9,7 @@
> #include "UefiShellDriver1CommandsLib.h"
>
> STATIC CONST CHAR16 mFileName[] = L"Driver1Commands"; -EFI_HANDLE
> gShellDriver1HiiHandle = NULL;
> +EFI_HII_HANDLE gShellDriver1HiiHandle = NULL;
> BOOLEAN gInReconnect = FALSE;
>
> /**
> diff --git
> a/ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1Commands
> Lib.c
> b/ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1Commands
> Lib.c
> index ecbee99e3b3d..88cddd88ddc4 100644
> ---
> a/ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1Commands
> Lib.c
> +++
> b/ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1Command
> +++ sLib.c
> @@ -10,7 +10,7 @@
> #include "UefiShellLevel1CommandsLib.h"
>
> STATIC CONST CHAR16 mFileName[] = L"ShellCommands"; -EFI_HANDLE
> gShellLevel1HiiHandle = NULL;
> +EFI_HII_HANDLE gShellLevel1HiiHandle = NULL;
>
> /**
> Return the help text filename. Only used if no HII information found.
> diff --git
> a/ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2Commands
> Lib.c
> b/ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2Commands
> Lib.c
> index c2a0bb492fbb..69427637bb87 100644
> ---
> a/ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2Commands
> Lib.c
> +++
> b/ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2Command
> +++ sLib.c
> @@ -29,7 +29,7 @@
> #include "UefiShellLevel2CommandsLib.h"
>
> CONST CHAR16 mFileName[] = L"ShellCommands"; -EFI_HANDLE
> gShellLevel2HiiHandle = NULL;
> +EFI_HII_HANDLE gShellLevel2HiiHandle = NULL;
>
> /**
> Get the filename to get help text from if not using HII.
> diff --git
> a/ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3Commands
> Lib.c
> b/ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3Commands
> Lib.c
> index 7d2cc4a48371..ce4afd117aa1 100644
> ---
> a/ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3Commands
> Lib.c
> +++
> b/ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3Command
> +++ sLib.c
> @@ -9,7 +9,7 @@
> #include "UefiShellLevel3CommandsLib.h"
>
> CONST CHAR16 gShellLevel3FileName[] = L"ShellCommands"; -EFI_HANDLE
> gShellLevel3HiiHandle = NULL;
> +EFI_HII_HANDLE gShellLevel3HiiHandle = NULL;
>
> /**
> return the filename to get help from is not using HII.
> diff --git a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> index 5be530092e1b..835d0f88ca74 100644
> --- a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> +++ b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> @@ -2997,7 +2997,7 @@ ShellPrintHiiEx(
> IN INT32 Row OPTIONAL,
> IN CONST CHAR8 *Language OPTIONAL,
> IN CONST EFI_STRING_ID HiiFormatStringId,
> - IN CONST EFI_HANDLE HiiFormatHandle,
> + IN CONST EFI_HII_HANDLE HiiFormatHandle,
> ...
> )
> {
> @@ -3609,7 +3609,7 @@ EFIAPI
> ShellPromptForResponseHii (
> IN SHELL_PROMPT_REQUEST_TYPE Type,
> IN CONST EFI_STRING_ID HiiFormatStringId,
> - IN CONST EFI_HANDLE HiiFormatHandle,
> + IN CONST EFI_HII_HANDLE HiiFormatHandle,
> IN OUT VOID **Response
> )
> {
> diff --git
> a/ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1Com
> mandsLib.c
> b/ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1Com
> mandsLib.c
> index 7e823cabd2fe..9a2b23fdc5ba 100644
> ---
> a/ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1Com
> mandsLib.c
> +++
> b/ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1Com
> +++ mandsLib.c
> @@ -8,7 +8,7 @@
> #include "UefiShellNetwork1CommandsLib.h"
>
> CONST CHAR16 gShellNetwork1FileName[] = L"ShellCommands"; -
> EFI_HANDLE gShellNetwork1HiiHandle = NULL;
> +EFI_HII_HANDLE gShellNetwork1HiiHandle = NULL;
>
> /**
> return the file name of the help text file if not using HII.
> diff --git
> a/ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2Com
> mandsLib.c
> b/ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2Com
> mandsLib.c
> index 5a7ffbfa19eb..4aab4295c1ba 100644
> ---
> a/ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2Com
> mandsLib.c
> +++
> b/ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2Com
> +++ mandsLib.c
> @@ -8,7 +8,7 @@
> #include "UefiShellNetwork2CommandsLib.h"
>
> CONST CHAR16 gShellNetwork2FileName[] = L"ShellCommands"; -
> EFI_HANDLE gShellNetwork2HiiHandle = NULL;
> +EFI_HII_HANDLE gShellNetwork2HiiHandle = NULL;
>
> /**
> return the file name of the help text file if not using HII.
> --
> 2.19.1.3.g30247aa5d201
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 28/35] ShellPkg/UefiShellDriver1CommandsLib: fix parameter list typo
2019-09-17 19:49 ` [PATCH 28/35] ShellPkg/UefiShellDriver1CommandsLib: fix parameter list typo Laszlo Ersek
2019-09-24 15:44 ` [edk2-devel] " Philippe Mathieu-Daudé
@ 2019-09-26 2:46 ` Gao, Zhichao
1 sibling, 0 replies; 155+ messages in thread
From: Gao, Zhichao @ 2019-09-26 2:46 UTC (permalink / raw)
To: Laszlo Ersek, edk2-devel-groups-io; +Cc: Carsey, Jaben, Ni, Ray
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
> -----Original Message-----
> From: Laszlo Ersek [mailto:lersek@redhat.com]
> Sent: Wednesday, September 18, 2019 3:49 AM
> To: edk2-devel-groups-io <devel@edk2.groups.io>
> Cc: Carsey, Jaben <jaben.carsey@intel.com>; Ni, Ray <ray.ni@intel.com>;
> Gao, Zhichao <zhichao.gao@intel.com>
> Subject: [PATCH 28/35] ShellPkg/UefiShellDriver1CommandsLib: fix
> parameter list typo
>
> The ShellCommandRunConnect() function passes EFI_HANDLE -- (VOID*) --
> objects to ConvertAndConnectControllers(), and
> ConvertAndConnectControllers() passes those to gBS->OpenProtocol().
>
> Accordingly, ConvertAndConnectControllers() should specify EFI_HANDLE
> parameter types, not (EFI_HANDLE*) -- (VOID**) -- types.
>
> This typo is masked because (VOID*) converts to and from any pointer-to-
> object type silently.
>
> Note that functionally speaking there is no problem, so this patch does not
> change beavior, only cleans up the code.
>
> Cc: Jaben Carsey <jaben.carsey@intel.com>
> Cc: Ray Ni <ray.ni@intel.com>
> Cc: Zhichao Gao <zhichao.gao@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> tested with "connect -r"
>
> ShellPkg/Library/UefiShellDriver1CommandsLib/Connect.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/ShellPkg/Library/UefiShellDriver1CommandsLib/Connect.c
> b/ShellPkg/Library/UefiShellDriver1CommandsLib/Connect.c
> index 359394dfd291..3f4e132674ea 100644
> --- a/ShellPkg/Library/UefiShellDriver1CommandsLib/Connect.c
> +++ b/ShellPkg/Library/UefiShellDriver1CommandsLib/Connect.c
> @@ -346,8 +346,8 @@ ShellConnectFromDevPaths ( **/ EFI_STATUS
> ConvertAndConnectControllers (
> - IN EFI_HANDLE *Handle1 OPTIONAL,
> - IN EFI_HANDLE *Handle2 OPTIONAL,
> + IN EFI_HANDLE Handle1 OPTIONAL,
> + IN EFI_HANDLE Handle2 OPTIONAL,
> IN CONST BOOLEAN Recursive,
> IN CONST BOOLEAN Output
> )
> --
> 2.19.1.3.g30247aa5d201
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 30/35] ShellPkg: stop taking EFI_HANDLE in place of SHELL_FILE_HANDLE
2019-09-17 19:49 ` [PATCH 30/35] ShellPkg: stop taking EFI_HANDLE in place of SHELL_FILE_HANDLE Laszlo Ersek
2019-09-23 9:58 ` [edk2-devel] " Philippe Mathieu-Daudé
@ 2019-09-26 2:53 ` Gao, Zhichao
2019-09-26 12:08 ` Laszlo Ersek
1 sibling, 1 reply; 155+ messages in thread
From: Gao, Zhichao @ 2019-09-26 2:53 UTC (permalink / raw)
To: devel@edk2.groups.io, lersek@redhat.com; +Cc: Carsey, Jaben, Ni, Ray
> -----Original Message-----
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Laszlo Ersek
> Sent: Wednesday, September 18, 2019 3:50 AM
> To: edk2-devel-groups-io <devel@edk2.groups.io>
> Cc: Carsey, Jaben <jaben.carsey@intel.com>; Ni, Ray <ray.ni@intel.com>;
> Gao, Zhichao <zhichao.gao@intel.com>
> Subject: [edk2-devel] [PATCH 30/35] ShellPkg: stop taking EFI_HANDLE in
> place of SHELL_FILE_HANDLE
>
> The TouchFileByHandle() and IsDirectoryEmpty() functions are passed
> SHELL_FILE_HANDLE parameters, and they use those parameters correctly.
> However, their parameter lists say EFI_HANDLE.
>
> Spell out the right type in the parameter lists.
>
> In practice, this change is a no-op (because, quite regrettably, both
> EFI_HANDLE and SHELL_FILE_HANDLE are specified to be typedefs of
> (VOID*)).
>
> Cc: Jaben Carsey <jaben.carsey@intel.com>
> Cc: Ray Ni <ray.ni@intel.com>
> Cc: Zhichao Gao <zhichao.gao@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> tested: rm, touch
>
> ShellPkg/Library/UefiShellLevel2CommandsLib/Rm.c | 2 +-
> ShellPkg/Library/UefiShellLevel3CommandsLib/Touch.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/ShellPkg/Library/UefiShellLevel2CommandsLib/Rm.c
> b/ShellPkg/Library/UefiShellLevel2CommandsLib/Rm.c
> index 3a1196f1529e..59f7eec376f2 100644
> --- a/ShellPkg/Library/UefiShellLevel2CommandsLib/Rm.c
> +++ b/ShellPkg/Library/UefiShellLevel2CommandsLib/Rm.c
> @@ -24,7 +24,7 @@ STATIC CONST SHELL_PARAM_ITEM ParamList[] = { **/
> BOOLEAN IsDirectoryEmpty (
> - IN EFI_HANDLE FileHandle
> + IN SHELL_FILE_HANDLE FileHandle
Here may be EFI_FILE_HANDLE.
> )
> {
> EFI_STATUS Status;
> diff --git a/ShellPkg/Library/UefiShellLevel3CommandsLib/Touch.c
> b/ShellPkg/Library/UefiShellLevel3CommandsLib/Touch.c
> index 0f00344c815e..a215f5774c69 100644
> --- a/ShellPkg/Library/UefiShellLevel3CommandsLib/Touch.c
> +++ b/ShellPkg/Library/UefiShellLevel3CommandsLib/Touch.c
> @@ -21,7 +21,7 @@
> **/
> EFI_STATUS
> TouchFileByHandle (
> - IN EFI_HANDLE Handle
> + IN SHELL_FILE_HANDLE Handle
Here is OK.
Thanks,
Zhichao
> )
> {
> EFI_STATUS Status;
> --
> 2.19.1.3.g30247aa5d201
>
>
>
> -=-=-=-=-=-=
> Groups.io Links: You receive all messages sent to this group.
>
> View/Reply Online (#47417): https://edk2.groups.io/g/devel/message/47417
> Mute This Topic: https://groups.io/mt/34180233/1768756
> Group Owner: devel+owner@edk2.groups.io
> Unsubscribe: https://edk2.groups.io/g/devel/unsub
> [zhichao.gao@intel.com]
> -=-=-=-=-=-=
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 29/35] ShellPkg: stop using EFI_HANDLE in place of EFI_HII_HANDLE
2019-09-25 18:04 ` [edk2-devel] " Philippe Mathieu-Daudé
@ 2019-09-26 11:48 ` Laszlo Ersek
0 siblings, 0 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-26 11:48 UTC (permalink / raw)
To: devel, philmd; +Cc: Jaben Carsey, Ray Ni, Zhichao Gao
On 09/25/19 20:04, Philippe Mathieu-Daudé wrote:
> On 9/17/19 9:49 PM, Laszlo Ersek wrote:
>> 25 files changed, 33 insertions(+), 33 deletions(-)
> I checked every case, entertaining.
> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Many thanks for the effort! :)
Laszlo
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 30/35] ShellPkg: stop taking EFI_HANDLE in place of SHELL_FILE_HANDLE
2019-09-26 2:53 ` Gao, Zhichao
@ 2019-09-26 12:08 ` Laszlo Ersek
2019-09-26 14:43 ` Gao, Zhichao
0 siblings, 1 reply; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-26 12:08 UTC (permalink / raw)
To: devel, zhichao.gao; +Cc: Carsey, Jaben, Ni, Ray
On 09/26/19 04:53, Gao, Zhichao wrote:
>
>
>> -----Original Message-----
>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
>> Laszlo Ersek
>> Sent: Wednesday, September 18, 2019 3:50 AM
>> To: edk2-devel-groups-io <devel@edk2.groups.io>
>> Cc: Carsey, Jaben <jaben.carsey@intel.com>; Ni, Ray <ray.ni@intel.com>;
>> Gao, Zhichao <zhichao.gao@intel.com>
>> Subject: [edk2-devel] [PATCH 30/35] ShellPkg: stop taking EFI_HANDLE in
>> place of SHELL_FILE_HANDLE
>>
>> The TouchFileByHandle() and IsDirectoryEmpty() functions are passed
>> SHELL_FILE_HANDLE parameters, and they use those parameters correctly.
>> However, their parameter lists say EFI_HANDLE.
>>
>> Spell out the right type in the parameter lists.
>>
>> In practice, this change is a no-op (because, quite regrettably, both
>> EFI_HANDLE and SHELL_FILE_HANDLE are specified to be typedefs of
>> (VOID*)).
>>
>> Cc: Jaben Carsey <jaben.carsey@intel.com>
>> Cc: Ray Ni <ray.ni@intel.com>
>> Cc: Zhichao Gao <zhichao.gao@intel.com>
>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>> ---
>>
>> Notes:
>> tested: rm, touch
>>
>> ShellPkg/Library/UefiShellLevel2CommandsLib/Rm.c | 2 +-
>> ShellPkg/Library/UefiShellLevel3CommandsLib/Touch.c | 2 +-
>> 2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/ShellPkg/Library/UefiShellLevel2CommandsLib/Rm.c
>> b/ShellPkg/Library/UefiShellLevel2CommandsLib/Rm.c
>> index 3a1196f1529e..59f7eec376f2 100644
>> --- a/ShellPkg/Library/UefiShellLevel2CommandsLib/Rm.c
>> +++ b/ShellPkg/Library/UefiShellLevel2CommandsLib/Rm.c
>> @@ -24,7 +24,7 @@ STATIC CONST SHELL_PARAM_ITEM ParamList[] = { **/
>> BOOLEAN IsDirectoryEmpty (
>> - IN EFI_HANDLE FileHandle
>> + IN SHELL_FILE_HANDLE FileHandle
>
> Here may be EFI_FILE_HANDLE.
Yes, it *may*, but doesn't *have* to.
We have the following call tree:
CascadeDelete()
IsDirectoryEmpty()
FileHandleFindFirstFile()
FileHandleFindNextFile()
With this patch, we have:
"Node->Handle"
|
[SHELL_FILE_HANDLE]
|
v
CascadeDelete()
|
[SHELL_FILE_HANDLE]
|
v
IsDirectoryEmpty()
|
[EFI_FILE_HANDLE]
|
v
FileHandleFindFirstFile()
FileHandleFindNextFile()
with your proposal, we would have:
"Node->Handle"
|
[SHELL_FILE_HANDLE]
|
v
CascadeDelete()
|
[EFI_FILE_HANDLE]
|
v
IsDirectoryEmpty()
|
[EFI_FILE_HANDLE]
|
v
FileHandleFindFirstFile()
FileHandleFindNextFile()
In both cases, we depend on SHELL_FILE_HANDLE being equivalent to
EFI_FILE_HANDLE. In the end, both types are:
(struct _EFI_FILE_PROTOCOL *)
In both cases, we go from SHELL_FILE_HANDLE to EFI_FILE_HANDLE, and
exploit that they are identical; the difference is only *where* we
exploit that.
- In this patch, we exploit the identity in IsDirectoryEmpty(): we take
a SHELL_FILE_HANDLE, and give it to functions that take EFI_FILE_HANDLE.
- In your proposal, we would exploit the exact same identity, just in
CascadeDelete(): "Node->Handle" is a SHELL_FILE_HANDLE (see
EFI_SHELL_FILE_INFO.Handle), and we'd pass it to a function (namely
IsDirectoryEmpty()) taking an EFI_FILE_HANDLE.
Given that your proposal wouldn't change our dependence on the
SHELL_FILE_HANDLE===EFI_FILE_HANDLE identity, I prefer to stick with the
current patch.
Thanks
Laszlo
>
>> )
>> {
>> EFI_STATUS Status;
>> diff --git a/ShellPkg/Library/UefiShellLevel3CommandsLib/Touch.c
>> b/ShellPkg/Library/UefiShellLevel3CommandsLib/Touch.c
>> index 0f00344c815e..a215f5774c69 100644
>> --- a/ShellPkg/Library/UefiShellLevel3CommandsLib/Touch.c
>> +++ b/ShellPkg/Library/UefiShellLevel3CommandsLib/Touch.c
>> @@ -21,7 +21,7 @@
>> **/
>> EFI_STATUS
>> TouchFileByHandle (
>> - IN EFI_HANDLE Handle
>> + IN SHELL_FILE_HANDLE Handle
>
> Here is OK.
>
> Thanks,
> Zhichao
>
>> )
>> {
>> EFI_STATUS Status;
>> --
>> 2.19.1.3.g30247aa5d201
>>
>>
>>
>> -=-=-=-=-=-=
>> Groups.io Links: You receive all messages sent to this group.
>>
>> View/Reply Online (#47417): https://edk2.groups.io/g/devel/message/47417
>> Mute This Topic: https://groups.io/mt/34180233/1768756
>> Group Owner: devel+owner@edk2.groups.io
>> Unsubscribe: https://edk2.groups.io/g/devel/unsub
>> [zhichao.gao@intel.com]
>> -=-=-=-=-=-=
>
>
>
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 09/35] MdeModulePkg: stop abusing EFI_EVENT for protocol notify registration
2019-09-25 16:02 ` [edk2-devel] " Philippe Mathieu-Daudé
@ 2019-09-26 12:10 ` Laszlo Ersek
0 siblings, 0 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-26 12:10 UTC (permalink / raw)
To: devel, philmd; +Cc: Hao A Wu, Jian J Wang, Liming Gao, Ray Ni, Zhichao Gao
On 09/25/19 18:02, Philippe Mathieu-Daudé wrote:
> On 9/17/19 9:49 PM, Laszlo Ersek wrote:
>> EfiCreateProtocolNotifyEvent() takes a (VOID**) for "Registration",
>> similarly to gBS->RegisterProtocolNotify(). We should pass the address of
>> an actual pointer-to-VOID, and not the address of an EFI_EVENT. EFI_EVENT
>> just happens to be specified as (VOID*), and has nothing to do with the
>> registration.
>>
>> The same applies to gMmst->MmRegisterProtocolNotify().
>>
>> "mFtwRegistration", "mFvRegistration", and "mFvbRegistration" are used for
>> nothing else.
>>
>> This change is a no-op in practice; it's a semantic improvement.
>>
>> Cc: Hao A Wu <hao.a.wu@intel.com>
>> Cc: Jian J Wang <jian.j.wang@intel.com>
>> Cc: Liming Gao <liming.gao@intel.com>
>> Cc: Ray Ni <ray.ni@intel.com>
>> Cc: Zhichao Gao <zhichao.gao@intel.com>
>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>> ---
>>
>> Notes:
>> lightly tested, as these modules (except LoadFileOnFv2) are part of the
>> ArmVirt and/or OVMF platforms
>>
>> MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c | 2 +-
>> MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c | 2 +-
>> MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.c | 2 +-
>> MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c | 2 +-
>> 4 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c
>> index ae8f117905cd..de38ea028af1 100644
>> --- a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c
>> +++ b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c
>> @@ -47,7 +47,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>>
>> #include <Library/UefiBootServicesTableLib.h>
>> #include "FaultTolerantWrite.h"
>> -EFI_EVENT mFvbRegistration = NULL;
>> +VOID *mFvbRegistration = NULL;
>>
>>
>> /**
>> diff --git a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c
>> index e8e935a85b5b..9612b394865b 100644
>> --- a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c
>> +++ b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c
>> @@ -56,7 +56,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>> #include "FaultTolerantWriteSmmCommon.h"
>> #include <Protocol/MmEndOfDxe.h>
>>
>> -EFI_EVENT mFvbRegistration = NULL;
>> +VOID *mFvbRegistration = NULL;
>> EFI_FTW_DEVICE *mFtwDevice = NULL;
>>
>> ///
>> diff --git a/MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.c b/MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.c
>> index 4af2da05e145..43fa6ce12875 100644
>> --- a/MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.c
>> +++ b/MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.c
>> @@ -36,7 +36,7 @@ typedef struct {
>> #define LOAD_FILE_ON_FV2_PRIVATE_DATA_FROM_THIS(a) CR (a, LOAD_FILE_ON_FV2_PRIVATE_DATA, LoadFile, LOAD_FILE_ON_FV2_PRIVATE_DATA_SIGNATURE)
>> #define LOAD_FILE_ON_FV2_PRIVATE_DATA_FROM_LINK(a) CR (a, LOAD_FILE_ON_FV2_PRIVATE_DATA, Link, LOAD_FILE_ON_FV2_PRIVATE_DATA_SIGNATURE)
>>
>> -EFI_EVENT mFvRegistration;
>> +VOID *mFvRegistration;
>> LIST_ENTRY mPrivateDataList;
>>
>> /**
>> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
>> index 3d232bb36cb4..7d2b6c8e1fad 100644
>> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
>> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
>> @@ -13,7 +13,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>>
>> EFI_HANDLE mHandle = NULL;
>> EFI_EVENT mVirtualAddressChangeEvent = NULL;
>> -EFI_EVENT mFtwRegistration = NULL;
>> +VOID *mFtwRegistration = NULL;
>> VOID ***mVarCheckAddressPointer = NULL;
>> UINTN mVarCheckAddressPointerCount = 0;
>> EDKII_VARIABLE_LOCK_PROTOCOL mVariableLock = { VariableLockRequestToLock };
>
> Surprisingly the one declared in
> MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c is correct :)
Indeed!
>
> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Thanks!
Laszlo
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 03/35] EmbeddedPkg/AndroidFastbootTransportTcpDxe: fix DestroyChild() call
2019-09-17 19:49 ` [PATCH 03/35] EmbeddedPkg/AndroidFastbootTransportTcpDxe: fix DestroyChild() call Laszlo Ersek
2019-09-24 10:47 ` [edk2-devel] " Philippe Mathieu-Daudé
@ 2019-09-26 12:12 ` Laszlo Ersek
2019-09-26 12:16 ` Ard Biesheuvel
2 siblings, 0 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-26 12:12 UTC (permalink / raw)
To: edk2-devel-groups-io; +Cc: Ard Biesheuvel, Leif Lindholm
Leif, Ard,
On 09/17/19 21:49, Laszlo Ersek wrote:
> - The 2nd parameter of EFI_SERVICE_BINDING_CREATE_CHILD is:
>
> IN OUT EFI_HANDLE *ChildHandle
>
> - The 2nd parameter of EFI_SERVICE_BINDING_DESTROY_CHILD is:
>
> IN EFI_HANDLE ChildHandle
>
> Fix the DestroyChild() call in TcpFastbootTransportStop().
>
> This is an actual bugfix; I don't know why the current code doesn't crash.
> Perhaps the function is never reached in practice? (It could be tied to an
> error path.)
>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Leif Lindholm <leif.lindholm@linaro.org>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> build-tested only
>
> EmbeddedPkg/Drivers/AndroidFastbootTransportTcpDxe/FastbootTransportTcp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
can you please ACK this one too? (Apologies if it's already on your radar.)
Thanks!
Laszlo
> diff --git a/EmbeddedPkg/Drivers/AndroidFastbootTransportTcpDxe/FastbootTransportTcp.c b/EmbeddedPkg/Drivers/AndroidFastbootTransportTcpDxe/FastbootTransportTcp.c
> index 29f23a82c75f..34f9ba74e4db 100644
> --- a/EmbeddedPkg/Drivers/AndroidFastbootTransportTcpDxe/FastbootTransportTcp.c
> +++ b/EmbeddedPkg/Drivers/AndroidFastbootTransportTcpDxe/FastbootTransportTcp.c
> @@ -503,7 +503,7 @@ TcpFastbootTransportStop (
> Status = mTcpListener->Configure (mTcpListener, NULL);
> ASSERT_EFI_ERROR (Status);
>
> - Status = mTcpServiceBinding->DestroyChild (mTcpServiceBinding, &mTcpHandle);
> + Status = mTcpServiceBinding->DestroyChild (mTcpServiceBinding, mTcpHandle);
>
> // Free any data the user didn't pick up
> Entry = (FASTBOOT_TCP_PACKET_LIST *) GetFirstNode (&mPacketListHead);
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 18/35] NetworkPkg/DxeNetLib: fix type typo in NetLibGetMacAddress()
2019-09-17 19:49 ` [PATCH 18/35] NetworkPkg/DxeNetLib: fix type typo in NetLibGetMacAddress() Laszlo Ersek
2019-09-24 11:00 ` [edk2-devel] " Philippe Mathieu-Daudé
@ 2019-09-26 12:14 ` Laszlo Ersek
2019-10-03 11:05 ` Laszlo Ersek
2019-10-07 18:15 ` Michael D Kinney
2 siblings, 1 reply; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-26 12:14 UTC (permalink / raw)
To: Jiaxin Wu, Siyuan Fu; +Cc: edk2-devel-groups-io
Jiaxin, Siyuan,
can you please review this patch?
Thanks
Laszlo
On 09/17/19 21:49, Laszlo Ersek wrote:
> NetLibGetSnpHandle() returns an EFI_HANDLE, not an (EFI_HANDLE*).
> NetLibGetMacAddress() only uses the return value ("SnpHandle") for a
> NULL-check. Fix the type of "SnpHandle".
>
> This patch is a no-op.
>
> Cc: Jiaxin Wu <jiaxin.wu@intel.com>
> Cc: Siyuan Fu <siyuan.fu@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> lightly tested: MAC strings are displayed in UiApp
>
> NetworkPkg/Library/DxeNetLib/DxeNetLib.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/NetworkPkg/Library/DxeNetLib/DxeNetLib.c b/NetworkPkg/Library/DxeNetLib/DxeNetLib.c
> index 8e2f720666ea..a39c20be3d34 100644
> --- a/NetworkPkg/Library/DxeNetLib/DxeNetLib.c
> +++ b/NetworkPkg/Library/DxeNetLib/DxeNetLib.c
> @@ -2182,7 +2182,7 @@ NetLibGetMacAddress (
> EFI_SIMPLE_NETWORK_MODE SnpModeData;
> EFI_MANAGED_NETWORK_PROTOCOL *Mnp;
> EFI_SERVICE_BINDING_PROTOCOL *MnpSb;
> - EFI_HANDLE *SnpHandle;
> + EFI_HANDLE SnpHandle;
> EFI_HANDLE MnpChildHandle;
>
> ASSERT (MacAddress != NULL);
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 19/35] NetworkPkg: fix CloseProtocol & UninstallMultipleProtocolInterfaces calls
2019-09-17 19:49 ` [PATCH 19/35] NetworkPkg: fix CloseProtocol & UninstallMultipleProtocolInterfaces calls Laszlo Ersek
@ 2019-09-26 12:14 ` Laszlo Ersek
2019-09-26 12:42 ` Philippe Mathieu-Daudé
2019-09-27 0:03 ` Siyuan, Fu
2 siblings, 0 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-26 12:14 UTC (permalink / raw)
To: Jiaxin Wu, Siyuan Fu; +Cc: edk2-devel-groups-io
Jiaxin, Siyuan,
can you please review this patch?
Thanks
Laszlo
On 09/17/19 21:49, Laszlo Ersek wrote:
> Both the "ControllerHandle" parameter of CloseProtocol() and the "Handle"
> parameter of UninstallMultipleProtocolInterfaces() have type EFI_HANDLE,
> not (EFI_HANDLE*).
>
> This patch fixes actual bugs. The issues have been dormant likely because
> they are on error paths. (Or, in case of TlsAuthConfigDxe, because the
> driver is unloaded likely very infrequently.)
>
> Cc: Jiaxin Wu <jiaxin.wu@intel.com>
> Cc: Siyuan Fu <siyuan.fu@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> build-tested only
>
> NetworkPkg/DnsDxe/DnsDriver.c | 4 ++--
> NetworkPkg/IScsiDxe/IScsiConfig.c | 2 +-
> NetworkPkg/Ip4Dxe/Ip4Driver.c | 2 +-
> NetworkPkg/Ip6Dxe/Ip6Driver.c | 2 +-
> NetworkPkg/Mtftp4Dxe/Mtftp4Driver.c | 2 +-
> NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.c | 2 +-
> 6 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/NetworkPkg/DnsDxe/DnsDriver.c b/NetworkPkg/DnsDxe/DnsDriver.c
> index 94d072159a4d..ad007da8b7d6 100644
> --- a/NetworkPkg/DnsDxe/DnsDriver.c
> +++ b/NetworkPkg/DnsDxe/DnsDriver.c
> @@ -1145,7 +1145,7 @@ Dns4ServiceBindingCreateChild (
> DnsSb->ConnectUdp->UdpHandle,
> &gEfiUdp4ProtocolGuid,
> gDns4DriverBinding.DriverBindingHandle,
> - ChildHandle
> + *ChildHandle
> );
>
> gBS->UninstallMultipleProtocolInterfaces (
> @@ -1388,7 +1388,7 @@ Dns6ServiceBindingCreateChild (
> DnsSb->ConnectUdp->UdpHandle,
> &gEfiUdp6ProtocolGuid,
> gDns6DriverBinding.DriverBindingHandle,
> - ChildHandle
> + *ChildHandle
> );
>
> gBS->UninstallMultipleProtocolInterfaces (
> diff --git a/NetworkPkg/IScsiDxe/IScsiConfig.c b/NetworkPkg/IScsiDxe/IScsiConfig.c
> index b876da7f5ccd..d773849fd3b0 100644
> --- a/NetworkPkg/IScsiDxe/IScsiConfig.c
> +++ b/NetworkPkg/IScsiDxe/IScsiConfig.c
> @@ -3852,7 +3852,7 @@ IScsiConfigFormInit (
> );
> if (CallbackInfo->RegisteredHandle == NULL) {
> gBS->UninstallMultipleProtocolInterfaces (
> - &CallbackInfo->DriverHandle,
> + CallbackInfo->DriverHandle,
> &gEfiDevicePathProtocolGuid,
> &mIScsiHiiVendorDevicePath,
> &gEfiHiiConfigAccessProtocolGuid,
> diff --git a/NetworkPkg/Ip4Dxe/Ip4Driver.c b/NetworkPkg/Ip4Dxe/Ip4Driver.c
> index ebd4dec1dfe4..62be8b681a18 100644
> --- a/NetworkPkg/Ip4Dxe/Ip4Driver.c
> +++ b/NetworkPkg/Ip4Dxe/Ip4Driver.c
> @@ -891,7 +891,7 @@ Ip4ServiceBindingCreateChild (
> );
> if (EFI_ERROR (Status)) {
> gBS->UninstallMultipleProtocolInterfaces (
> - ChildHandle,
> + *ChildHandle,
> &gEfiIp4ProtocolGuid,
> &IpInstance->Ip4Proto,
> NULL
> diff --git a/NetworkPkg/Ip6Dxe/Ip6Driver.c b/NetworkPkg/Ip6Dxe/Ip6Driver.c
> index 7dc9e45af7b6..63d8428dbced 100644
> --- a/NetworkPkg/Ip6Dxe/Ip6Driver.c
> +++ b/NetworkPkg/Ip6Dxe/Ip6Driver.c
> @@ -888,7 +888,7 @@ Ip6ServiceBindingCreateChild (
> );
> if (EFI_ERROR (Status)) {
> gBS->UninstallMultipleProtocolInterfaces (
> - ChildHandle,
> + *ChildHandle,
> &gEfiIp6ProtocolGuid,
> &IpInstance->Ip6Proto,
> NULL
> diff --git a/NetworkPkg/Mtftp4Dxe/Mtftp4Driver.c b/NetworkPkg/Mtftp4Dxe/Mtftp4Driver.c
> index ae9e65544a86..06c4e202d3ef 100644
> --- a/NetworkPkg/Mtftp4Dxe/Mtftp4Driver.c
> +++ b/NetworkPkg/Mtftp4Dxe/Mtftp4Driver.c
> @@ -592,7 +592,7 @@ Mtftp4ServiceBindingCreateChild (
> MtftpSb->ConnectUdp->UdpHandle,
> &gEfiUdp4ProtocolGuid,
> gMtftp4DriverBinding.DriverBindingHandle,
> - ChildHandle
> + *ChildHandle
> );
> goto ON_ERROR;
> }
> diff --git a/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.c b/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.c
> index 18ee763002b4..c0870ab9979c 100644
> --- a/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.c
> +++ b/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.c
> @@ -39,7 +39,7 @@ TlsAuthConfigDxeUnload (
> ASSERT (PrivateData->Signature == TLS_AUTH_CONFIG_PRIVATE_DATA_SIGNATURE);
>
> gBS->UninstallMultipleProtocolInterfaces (
> - &ImageHandle,
> + ImageHandle,
> &gEfiCallerIdGuid,
> PrivateData,
> NULL
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 20/35] NetworkPkg/Ip4Dxe: fix NetLibDestroyServiceChild() call
2019-09-17 19:49 ` [PATCH 20/35] NetworkPkg/Ip4Dxe: fix NetLibDestroyServiceChild() call Laszlo Ersek
2019-09-23 16:03 ` [edk2-devel] " Philippe Mathieu-Daudé
@ 2019-09-26 12:14 ` Laszlo Ersek
1 sibling, 0 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-26 12:14 UTC (permalink / raw)
To: Jiaxin Wu, Siyuan Fu; +Cc: edk2-devel-groups-io
Jiaxin, Siyuan,
can you please review this patch?
Thanks
Laszlo
On 09/17/19 21:49, Laszlo Ersek wrote:
> Both NetLibDestroyServiceChild() and EFI_SERVICE_BINDING_DESTROY_CHILD
> take an EFI_HANDLE for the "ChildHandle" parameter, not an (EFI_HANDLE*).
>
> This patch fixes a real bug.
>
> Cc: Jiaxin Wu <jiaxin.wu@intel.com>
> Cc: Siyuan Fu <siyuan.fu@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> possibly only build-tested
>
> NetworkPkg/Ip4Dxe/Ip4If.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/NetworkPkg/Ip4Dxe/Ip4If.c b/NetworkPkg/Ip4Dxe/Ip4If.c
> index 44b8d9fc8faf..53a333037f94 100644
> --- a/NetworkPkg/Ip4Dxe/Ip4If.c
> +++ b/NetworkPkg/Ip4Dxe/Ip4If.c
> @@ -592,7 +592,7 @@ Ip4SetAddress (
> Interface->Controller,
> Interface->Image,
> &gEfiArpServiceBindingProtocolGuid,
> - &Interface->ArpHandle
> + Interface->ArpHandle
> );
>
> Interface->ArpHandle = NULL;
> @@ -657,7 +657,7 @@ ON_ERROR:
> Interface->Controller,
> Interface->Image,
> &gEfiArpServiceBindingProtocolGuid,
> - &Interface->ArpHandle
> + Interface->ArpHandle
> );
>
> return Status;
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 21/35] NetworkPkg/TcpDxe: fix SockFreeFoo() parameter list
2019-09-17 19:49 ` [PATCH 21/35] NetworkPkg/TcpDxe: fix SockFreeFoo() parameter list Laszlo Ersek
2019-09-23 15:09 ` [edk2-devel] " Philippe Mathieu-Daudé
@ 2019-09-26 12:14 ` Laszlo Ersek
2019-09-27 0:06 ` Siyuan, Fu
2 siblings, 0 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-26 12:14 UTC (permalink / raw)
To: Jiaxin Wu, Siyuan Fu; +Cc: edk2-devel-groups-io
Jiaxin, Siyuan,
can you please review this patch?
Thanks
Laszlo
On 09/17/19 21:49, Laszlo Ersek wrote:
> The SockFreeFoo() callback function for NetbufFromExt() has to match the
> NET_VECTOR_EXT_FREE prototype, which takes a (VOID*) as callback argument
> (Arg). EFI_EVENT has nothing to do with NET_VECTOR_EXT_FREE. Fix the
> SockFreeFoo() parameter list.
>
> This change is a no-op in practice.
>
> Cc: Jiaxin Wu <jiaxin.wu@intel.com>
> Cc: Siyuan Fu <siyuan.fu@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> build-tested only
>
> NetworkPkg/TcpDxe/SockImpl.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/NetworkPkg/TcpDxe/SockImpl.c b/NetworkPkg/TcpDxe/SockImpl.c
> index f5e01771e2a8..fb28e2ed40d3 100644
> --- a/NetworkPkg/TcpDxe/SockImpl.c
> +++ b/NetworkPkg/TcpDxe/SockImpl.c
> @@ -67,13 +67,13 @@ SockBufNext (
> /**
> User provided callback function for NetbufFromExt.
>
> - @param[in] Event The Event this notify function registered to, ignored.
> + @param[in] Arg The Arg parameter forwarded by NetbufFromExt(). Ignored.
>
> **/
> VOID
> EFIAPI
> SockFreeFoo (
> - IN EFI_EVENT Event
> + IN VOID *Arg
> )
> {
> return;
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 23/35] OvmfPkg/VirtioNetDxe: fix SignalEvent() call
2019-09-17 19:49 ` [PATCH 23/35] OvmfPkg/VirtioNetDxe: fix SignalEvent() call Laszlo Ersek
2019-09-20 14:59 ` [edk2-devel] " Philippe Mathieu-Daudé
@ 2019-09-26 12:16 ` Laszlo Ersek
2019-09-26 12:17 ` Ard Biesheuvel
2 siblings, 0 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-26 12:16 UTC (permalink / raw)
To: Ard Biesheuvel, Jordan Justen; +Cc: edk2-devel-groups-io
Jordan, Ard,
may I please get an R-b for this patch? It's quite simple. (Sorry if
it's already in your queue.)
Thank you,
Laszlo
On 09/17/19 21:49, Laszlo Ersek wrote:
> The SignalEvent() boot service takes an EFI_EVENT, not an (EFI_EVENT*).
> Fix the call in the notification function of
> "EFI_SIMPLE_NETWORK_PROTOCOL.WaitForPacket".
>
> This is an actual bug. The reason it's never been triggered is likely that
> the "SNP.WaitForPacket" event is rarely waited for by applications -- edk2
> itself has zero instances of that, for example.
>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Jordan Justen <jordan.l.justen@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> build-tested only
>
> OvmfPkg/VirtioNetDxe/Events.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/OvmfPkg/VirtioNetDxe/Events.c b/OvmfPkg/VirtioNetDxe/Events.c
> index 620910774bc5..83e96e5e5d91 100644
> --- a/OvmfPkg/VirtioNetDxe/Events.c
> +++ b/OvmfPkg/VirtioNetDxe/Events.c
> @@ -58,7 +58,7 @@ VirtioNetIsPacketAvailable (
> MemoryFence ();
>
> if (Dev->RxLastUsed != RxCurUsed) {
> - gBS->SignalEvent (&Dev->Snp.WaitForPacket);
> + gBS->SignalEvent (Dev->Snp.WaitForPacket);
> }
> }
>
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 03/35] EmbeddedPkg/AndroidFastbootTransportTcpDxe: fix DestroyChild() call
2019-09-17 19:49 ` [PATCH 03/35] EmbeddedPkg/AndroidFastbootTransportTcpDxe: fix DestroyChild() call Laszlo Ersek
2019-09-24 10:47 ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-26 12:12 ` Laszlo Ersek
@ 2019-09-26 12:16 ` Ard Biesheuvel
2 siblings, 0 replies; 155+ messages in thread
From: Ard Biesheuvel @ 2019-09-26 12:16 UTC (permalink / raw)
To: Laszlo Ersek; +Cc: edk2-devel-groups-io, Leif Lindholm
On Tue, 17 Sep 2019 at 21:49, Laszlo Ersek <lersek@redhat.com> wrote:
>
> - The 2nd parameter of EFI_SERVICE_BINDING_CREATE_CHILD is:
>
> IN OUT EFI_HANDLE *ChildHandle
>
> - The 2nd parameter of EFI_SERVICE_BINDING_DESTROY_CHILD is:
>
> IN EFI_HANDLE ChildHandle
>
> Fix the DestroyChild() call in TcpFastbootTransportStop().
>
> This is an actual bugfix; I don't know why the current code doesn't crash.
> Perhaps the function is never reached in practice? (It could be tied to an
> error path.)
>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Leif Lindholm <leif.lindholm@linaro.org>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
>
> Notes:
> build-tested only
>
> EmbeddedPkg/Drivers/AndroidFastbootTransportTcpDxe/FastbootTransportTcp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/EmbeddedPkg/Drivers/AndroidFastbootTransportTcpDxe/FastbootTransportTcp.c b/EmbeddedPkg/Drivers/AndroidFastbootTransportTcpDxe/FastbootTransportTcp.c
> index 29f23a82c75f..34f9ba74e4db 100644
> --- a/EmbeddedPkg/Drivers/AndroidFastbootTransportTcpDxe/FastbootTransportTcp.c
> +++ b/EmbeddedPkg/Drivers/AndroidFastbootTransportTcpDxe/FastbootTransportTcp.c
> @@ -503,7 +503,7 @@ TcpFastbootTransportStop (
> Status = mTcpListener->Configure (mTcpListener, NULL);
> ASSERT_EFI_ERROR (Status);
>
> - Status = mTcpServiceBinding->DestroyChild (mTcpServiceBinding, &mTcpHandle);
> + Status = mTcpServiceBinding->DestroyChild (mTcpServiceBinding, mTcpHandle);
>
> // Free any data the user didn't pick up
> Entry = (FASTBOOT_TCP_PACKET_LIST *) GetFirstNode (&mPacketListHead);
> --
> 2.19.1.3.g30247aa5d201
>
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 23/35] OvmfPkg/VirtioNetDxe: fix SignalEvent() call
2019-09-17 19:49 ` [PATCH 23/35] OvmfPkg/VirtioNetDxe: fix SignalEvent() call Laszlo Ersek
2019-09-20 14:59 ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-26 12:16 ` Laszlo Ersek
@ 2019-09-26 12:17 ` Ard Biesheuvel
2 siblings, 0 replies; 155+ messages in thread
From: Ard Biesheuvel @ 2019-09-26 12:17 UTC (permalink / raw)
To: Laszlo Ersek; +Cc: edk2-devel-groups-io, Jordan Justen
On Tue, 17 Sep 2019 at 21:50, Laszlo Ersek <lersek@redhat.com> wrote:
>
> The SignalEvent() boot service takes an EFI_EVENT, not an (EFI_EVENT*).
> Fix the call in the notification function of
> "EFI_SIMPLE_NETWORK_PROTOCOL.WaitForPacket".
>
> This is an actual bug. The reason it's never been triggered is likely that
> the "SNP.WaitForPacket" event is rarely waited for by applications -- edk2
> itself has zero instances of that, for example.
>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Jordan Justen <jordan.l.justen@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
>
> Notes:
> build-tested only
>
> OvmfPkg/VirtioNetDxe/Events.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/OvmfPkg/VirtioNetDxe/Events.c b/OvmfPkg/VirtioNetDxe/Events.c
> index 620910774bc5..83e96e5e5d91 100644
> --- a/OvmfPkg/VirtioNetDxe/Events.c
> +++ b/OvmfPkg/VirtioNetDxe/Events.c
> @@ -58,7 +58,7 @@ VirtioNetIsPacketAvailable (
> MemoryFence ();
>
> if (Dev->RxLastUsed != RxCurUsed) {
> - gBS->SignalEvent (&Dev->Snp.WaitForPacket);
> + gBS->SignalEvent (Dev->Snp.WaitForPacket);
> }
> }
>
> --
> 2.19.1.3.g30247aa5d201
>
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 19/35] NetworkPkg: fix CloseProtocol & UninstallMultipleProtocolInterfaces calls
2019-09-17 19:49 ` [PATCH 19/35] NetworkPkg: fix CloseProtocol & UninstallMultipleProtocolInterfaces calls Laszlo Ersek
2019-09-26 12:14 ` [edk2-devel] " Laszlo Ersek
@ 2019-09-26 12:42 ` Philippe Mathieu-Daudé
2019-09-30 20:16 ` Laszlo Ersek
2019-09-27 0:03 ` Siyuan, Fu
2 siblings, 1 reply; 155+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-09-26 12:42 UTC (permalink / raw)
To: devel, lersek; +Cc: Jiaxin Wu, Siyuan Fu
Hi Laszlo,
On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> Both the "ControllerHandle" parameter of CloseProtocol()
Maybe worth adding "of type EFI_CLOSE_PROTOCOL"
> and the "Handle"
> parameter of UninstallMultipleProtocolInterfaces()
"of type EFI_UNINSTALL_MULTIPLE_PROTOCOL_INTERFACES"
have type EFI_HANDLE,
> not (EFI_HANDLE*).
>
> This patch fixes actual bugs. The issues have been dormant likely because
> they are on error paths. (Or, in case of TlsAuthConfigDxe, because the
> driver is unloaded likely very infrequently.)
>
> Cc: Jiaxin Wu <jiaxin.wu@intel.com>
> Cc: Siyuan Fu <siyuan.fu@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> build-tested only
>
> NetworkPkg/DnsDxe/DnsDriver.c | 4 ++--
> NetworkPkg/IScsiDxe/IScsiConfig.c | 2 +-
> NetworkPkg/Ip4Dxe/Ip4Driver.c | 2 +-
> NetworkPkg/Ip6Dxe/Ip6Driver.c | 2 +-
> NetworkPkg/Mtftp4Dxe/Mtftp4Driver.c | 2 +-
> NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.c | 2 +-
> 6 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/NetworkPkg/DnsDxe/DnsDriver.c b/NetworkPkg/DnsDxe/DnsDriver.c
> index 94d072159a4d..ad007da8b7d6 100644
> --- a/NetworkPkg/DnsDxe/DnsDriver.c
> +++ b/NetworkPkg/DnsDxe/DnsDriver.c
> @@ -1145,7 +1145,7 @@ Dns4ServiceBindingCreateChild (
> DnsSb->ConnectUdp->UdpHandle,
> &gEfiUdp4ProtocolGuid,
> gDns4DriverBinding.DriverBindingHandle,
> - ChildHandle
> + *ChildHandle
EFI_CLOSE_PROTOCOL, OK.
> );
>
> gBS->UninstallMultipleProtocolInterfaces (
> @@ -1388,7 +1388,7 @@ Dns6ServiceBindingCreateChild (
> DnsSb->ConnectUdp->UdpHandle,
> &gEfiUdp6ProtocolGuid,
> gDns6DriverBinding.DriverBindingHandle,
> - ChildHandle
> + *ChildHandle
EFI_CLOSE_PROTOCOL, OK.
> );
>
> gBS->UninstallMultipleProtocolInterfaces (
> diff --git a/NetworkPkg/IScsiDxe/IScsiConfig.c b/NetworkPkg/IScsiDxe/IScsiConfig.c
> index b876da7f5ccd..d773849fd3b0 100644
> --- a/NetworkPkg/IScsiDxe/IScsiConfig.c
> +++ b/NetworkPkg/IScsiDxe/IScsiConfig.c
> @@ -3852,7 +3852,7 @@ IScsiConfigFormInit (
> );
> if (CallbackInfo->RegisteredHandle == NULL) {
> gBS->UninstallMultipleProtocolInterfaces (
> - &CallbackInfo->DriverHandle,
> + CallbackInfo->DriverHandle,
EFI_UNINSTALL_MULTIPLE_PROTOCOL_INTERFACES, OK.
> &gEfiDevicePathProtocolGuid,
> &mIScsiHiiVendorDevicePath,
> &gEfiHiiConfigAccessProtocolGuid,
> diff --git a/NetworkPkg/Ip4Dxe/Ip4Driver.c b/NetworkPkg/Ip4Dxe/Ip4Driver.c
> index ebd4dec1dfe4..62be8b681a18 100644
> --- a/NetworkPkg/Ip4Dxe/Ip4Driver.c
> +++ b/NetworkPkg/Ip4Dxe/Ip4Driver.c
> @@ -891,7 +891,7 @@ Ip4ServiceBindingCreateChild (
> );
> if (EFI_ERROR (Status)) {
> gBS->UninstallMultipleProtocolInterfaces (
> - ChildHandle,
> + *ChildHandle,
EFI_UNINSTALL_MULTIPLE_PROTOCOL_INTERFACES, OK.
> &gEfiIp4ProtocolGuid,
> &IpInstance->Ip4Proto,
> NULL
> diff --git a/NetworkPkg/Ip6Dxe/Ip6Driver.c b/NetworkPkg/Ip6Dxe/Ip6Driver.c
> index 7dc9e45af7b6..63d8428dbced 100644
> --- a/NetworkPkg/Ip6Dxe/Ip6Driver.c
> +++ b/NetworkPkg/Ip6Dxe/Ip6Driver.c
> @@ -888,7 +888,7 @@ Ip6ServiceBindingCreateChild (
> );
> if (EFI_ERROR (Status)) {
> gBS->UninstallMultipleProtocolInterfaces (
> - ChildHandle,
> + *ChildHandle,
EFI_UNINSTALL_MULTIPLE_PROTOCOL_INTERFACES, OK.
> &gEfiIp6ProtocolGuid,
> &IpInstance->Ip6Proto,
> NULL
> diff --git a/NetworkPkg/Mtftp4Dxe/Mtftp4Driver.c b/NetworkPkg/Mtftp4Dxe/Mtftp4Driver.c
> index ae9e65544a86..06c4e202d3ef 100644
> --- a/NetworkPkg/Mtftp4Dxe/Mtftp4Driver.c
> +++ b/NetworkPkg/Mtftp4Dxe/Mtftp4Driver.c
> @@ -592,7 +592,7 @@ Mtftp4ServiceBindingCreateChild (
> MtftpSb->ConnectUdp->UdpHandle,
> &gEfiUdp4ProtocolGuid,
> gMtftp4DriverBinding.DriverBindingHandle,
> - ChildHandle
> + *ChildHandle
EFI_CLOSE_PROTOCOL, OK.
> );
> goto ON_ERROR;
> }
> diff --git a/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.c b/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.c
> index 18ee763002b4..c0870ab9979c 100644
> --- a/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.c
> +++ b/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.c
> @@ -39,7 +39,7 @@ TlsAuthConfigDxeUnload (
> ASSERT (PrivateData->Signature == TLS_AUTH_CONFIG_PRIVATE_DATA_SIGNATURE);
>
> gBS->UninstallMultipleProtocolInterfaces (
> - &ImageHandle,
> + ImageHandle,
EFI_UNINSTALL_MULTIPLE_PROTOCOL_INTERFACES, OK.
> &gEfiCallerIdGuid,
> PrivateData,
> NULL
>
I'd have split this patch in 2 for easier review (one fixing
EFI_CLOSE_PROTOCOL, another fixing
EFI_UNINSTALL_MULTIPLE_PROTOCOL_INTERFACES).
As it or split:
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Regards,
Phil.
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 25/35] OvmfPkg/VideoDxe: document EFI_EDID_OVERRIDE_PROTOCOL.GetEdid() call
2019-09-23 15:59 ` [edk2-devel] " Philippe Mathieu-Daudé
@ 2019-09-26 12:43 ` Laszlo Ersek
2019-10-04 20:01 ` Laszlo Ersek
0 siblings, 1 reply; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-26 12:43 UTC (permalink / raw)
To: devel, philmd; +Cc: Ard Biesheuvel, David Woodhouse, Jordan Justen
On 09/23/19 17:59, Philippe Mathieu-Daudé wrote:
> Hi Laszlo,
>
> On 9/17/19 9:49 PM, Laszlo Ersek wrote:
>> According to the UEFI spec -- and to the edk2 header
>> "MdePkg/Include/Protocol/EdidOverride.h" too --,
>> EFI_EDID_OVERRIDE_PROTOCOL_GET_EDID takes an (EFI_HANDLE*), and not an
>> EFI_HANDLE, as second parameter ("ChildHandle").
>>
>> This is probably [*] a bug in the UEFI spec. Given that this CSM module
>> (VideoDxe) had been used for a long time on physical platforms before it
>> was moved to OvmfPkg, keep the current "ChildHandle" argument, just cast
>> it explicitly.
>>
>> [*] The edk2 tree contains no other GetEdid() call, and also no GetEdid()
>> implementation.
>>
>> The edk2-platforms tree contains two GetEdid() calls, at commit
>> 022c212167e0, in files
>> - "Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/Edid.c",
>> - "Drivers/OptionRomPkg/CirrusLogic5430Dxe/Edid.c".
>>
>> From these, the first passes an (EFI_HANDLE*) as "ChildHandle", the
>> second passes an EFI_HANDLE. It's difficult to draw a conclusion. :/
>>
>> No functional changes.
>>
>> (I've also requested a non-normative (informative) clarification for the
>> UEFI spec: <https://mantis.uefi.org/mantis/view.php?id=2018>, in the
>> direction that matches this patch.)
>
> (EFI_HANDLE*) makes sense to me, but I'd rather wait for the spec
> clarification before Acking this patch, I don't want we silent a bug
> with this cast.
Right, there's been some movement in Mantis#2018.
It looks like the spec is wrong, but all [*] consumers and producers of
GetEdid(), investigated thus far, have simply ignored the mistake in the
spec, and done the right thing in practice.
So there seems to be a chance for the spec to be fixed. That would be
followed by fixing the GetEdid() prototype in edk2. And then this patch
would be dropped.
[*] the only exception found thus far is the call site in
edk2-platform's "DisplayLinkPkg", mentioned above in the commit message.
However, that is a very recent code addition (commit 9df63499ea01,
2019-09-09), and it might not reflect "historical" usage, but an attempt
to write brand new code, conforming to the *letter* of the spec. So in
case the spec gets fixed, the DisplayLinkPkg code could be fixed in
tandem, perhaps.
Thanks
Laszlo
>
>> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> Cc: David Woodhouse <dwmw2@infradead.org>
>> Cc: Jordan Justen <jordan.l.justen@intel.com>
>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>> ---
>>
>> Notes:
>> build-tested only
>>
>> OvmfPkg/Csm/BiosThunk/VideoDxe/BiosVideo.c | 6 +++++-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/OvmfPkg/Csm/BiosThunk/VideoDxe/BiosVideo.c b/OvmfPkg/Csm/BiosThunk/VideoDxe/BiosVideo.c
>> index 0640656dba14..995136adee27 100644
>> --- a/OvmfPkg/Csm/BiosThunk/VideoDxe/BiosVideo.c
>> +++ b/OvmfPkg/Csm/BiosThunk/VideoDxe/BiosVideo.c
>> @@ -1402,9 +1402,13 @@ BiosVideoCheckForVbe (
>> goto Done;
>> }
>>
>> + //
>> + // Cast "ChildHandle" to (EFI_HANDLE*) in order to work around the spec bug
>> + // in UEFI v2.8, reported as Mantis#2018.
>> + //
>> Status = EdidOverride->GetEdid (
>> EdidOverride,
>> - BiosVideoPrivate->Handle,
>> + (EFI_HANDLE *) BiosVideoPrivate->Handle,
>> &EdidAttributes,
>> &EdidOverrideDataSize,
>> (UINT8 **) &EdidOverrideDataBlock
>>
>
>
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 26/35] SecurityPkg: fix UninstallMultipleProtocolInterfaces() calls
2019-09-17 19:49 ` [PATCH 26/35] SecurityPkg: fix UninstallMultipleProtocolInterfaces() calls Laszlo Ersek
2019-09-23 9:55 ` [edk2-devel] " Philippe Mathieu-Daudé
@ 2019-09-26 12:45 ` Laszlo Ersek
2019-10-03 11:06 ` Laszlo Ersek
1 sibling, 1 reply; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-26 12:45 UTC (permalink / raw)
To: Chao Zhang, Jian Wang, Jiewen Yao; +Cc: edk2-devel-groups-io
Chao, Jian, Jiewen,
can you please review this patch?
Thanks,
Laszlo
On 09/17/19 21:49, Laszlo Ersek wrote:
> Unlike the InstallMultipleProtocolInterfaces() boot service, which takes
> an (EFI_HANDLE*) as first parameter, the
> UninstallMultipleProtocolInterfaces() boot service takes an EFI_HANDLE as
> first parameter.
>
> These are actual bugs. They must have remained hidden until now because
> they are all in Unload() functions, which are probably exercised
> infrequently. Fix the UninstallMultipleProtocolInterfaces() calls.
>
> Cc: Chao Zhang <chao.b.zhang@intel.com>
> Cc: Jian Wang <jian.j.wang@intel.com>
> Cc: Jiewen Yao <jiewen.yao@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> build-tested only
>
> SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c | 2 +-
> SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c | 2 +-
> SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDriver.c | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c b/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c
> index 54155a338100..9052eced757d 100644
> --- a/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c
> +++ b/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c
> @@ -443,7 +443,7 @@ Tcg2ConfigDriverUnload (
> ASSERT (PrivateData->Signature == TCG2_CONFIG_PRIVATE_DATA_SIGNATURE);
>
> gBS->UninstallMultipleProtocolInterfaces (
> - &ImageHandle,
> + ImageHandle,
> &gEfiCallerIdGuid,
> PrivateData,
> NULL
> diff --git a/SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c b/SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c
> index 341879e4c4ba..fb06624fdb8f 100644
> --- a/SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c
> +++ b/SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c
> @@ -138,7 +138,7 @@ TcgConfigDriverUnload (
> ASSERT (PrivateData->Signature == TCG_CONFIG_PRIVATE_DATA_SIGNATURE);
>
> gBS->UninstallMultipleProtocolInterfaces (
> - &ImageHandle,
> + ImageHandle,
> &gEfiCallerIdGuid,
> PrivateData,
> NULL
> diff --git a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDriver.c b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDriver.c
> index 798ef9cfbc01..6c0294151e6c 100644
> --- a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDriver.c
> +++ b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDriver.c
> @@ -115,7 +115,7 @@ SecureBootConfigDriverUnload (
> ASSERT (PrivateData->Signature == SECUREBOOT_CONFIG_PRIVATE_DATA_SIGNATURE);
>
> gBS->UninstallMultipleProtocolInterfaces (
> - &ImageHandle,
> + ImageHandle,
> &gEfiCallerIdGuid,
> PrivateData,
> NULL
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 27/35] SecurityPkg: stop abusing EFI_EVENT for protocol notify registration
2019-09-17 19:49 ` [PATCH 27/35] SecurityPkg: stop abusing EFI_EVENT for protocol notify registration Laszlo Ersek
2019-09-23 9:56 ` [edk2-devel] " Philippe Mathieu-Daudé
@ 2019-09-26 12:46 ` Laszlo Ersek
2019-10-03 11:06 ` Laszlo Ersek
1 sibling, 1 reply; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-26 12:46 UTC (permalink / raw)
To: Chao Zhang, Jian Wang, Jiewen Yao; +Cc: edk2-devel-groups-io
Chao, Jian, Jiewen,
can you please review this patch?
Thanks,
Laszlo
On 09/17/19 21:49, Laszlo Ersek wrote:
> EfiCreateProtocolNotifyEvent() takes a (VOID**) for "Registration",
> similarly to gBS->RegisterProtocolNotify(). We should pass the address of
> an actual pointer-to-VOID, and not the address of an EFI_EVENT. EFI_EVENT
> just happens to be specified as (VOID*), and has nothing to do with the
> registration.
>
> This change is a no-op in practice; it's a semantic improvement.
>
> Cc: Chao Zhang <chao.b.zhang@intel.com>
> Cc: Jian Wang <jian.j.wang@intel.com>
> Cc: Jiewen Yao <jiewen.yao@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> build-tested only
>
> SecurityPkg/HddPassword/HddPasswordDxe.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/SecurityPkg/HddPassword/HddPasswordDxe.c b/SecurityPkg/HddPassword/HddPasswordDxe.c
> index b0d795b6597f..051e64091d7f 100644
> --- a/SecurityPkg/HddPassword/HddPasswordDxe.c
> +++ b/SecurityPkg/HddPassword/HddPasswordDxe.c
> @@ -2770,7 +2770,7 @@ HddPasswordDxeInit (
> {
> EFI_STATUS Status;
> HDD_PASSWORD_DXE_PRIVATE_DATA *Private;
> - EFI_EVENT Registration;
> + VOID *Registration;
> EFI_EVENT EndOfDxeEvent;
> EDKII_VARIABLE_LOCK_PROTOCOL *VariableLock;
>
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 32/35] ShellPkg/UefiShellLib: clarify workaround for unfixable EdkShell bug
2019-09-17 19:49 ` [PATCH 32/35] ShellPkg/UefiShellLib: clarify workaround for unfixable EdkShell bug Laszlo Ersek
@ 2019-09-26 12:47 ` Laszlo Ersek
2019-09-26 14:05 ` Gao, Zhichao
2019-09-26 14:58 ` Carsey, Jaben
0 siblings, 2 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-26 12:47 UTC (permalink / raw)
To: Jaben Carsey, Ray Ni, Zhichao Gao; +Cc: edk2-devel-groups-io
Jaben, Ray, Zhichao,
can one of you guys please review this patch?
Thanks
Laszlo
On 09/17/19 21:49, Laszlo Ersek wrote:
> The EDK 1 Shell (available at <https://github.com/tianocore/edk-Shell>)
> has a bug in its EFI_SHELL_ENVIRONMENT2.Execute() implementation that
> edk2's UefiShellLib has no choice but to work around.
>
> Improve the explanation in the code. Also, document the implicit
> EFI_HANDLE -> (EFI_HANDLE*) conversion, which happens implicitly after
> dereferencing ParentHandle, with an explicit cast.
>
> In practice, this patch is a no-op.
>
> Cc: Jaben Carsey <jaben.carsey@intel.com>
> Cc: Ray Ni <ray.ni@intel.com>
> Cc: Zhichao Gao <zhichao.gao@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> build-tested only
>
> ShellPkg/Library/UefiShellLib/UefiShellLib.c | 22 ++++++++++++++++++--
> 1 file changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/ShellPkg/Library/UefiShellLib/UefiShellLib.c b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> index 835d0f88ca74..9f07a58eb23d 100644
> --- a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> +++ b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> @@ -1291,9 +1291,27 @@ ShellExecute (
> if (mEfiShellEnvironment2 != NULL) {
> //
> // Call EFI Shell version.
> - // Due to oddity in the EFI shell we want to dereference the ParentHandle here
> //
> - CmdStatus = (mEfiShellEnvironment2->Execute(*ParentHandle,
> + // Due to an unfixable bug in the EdkShell implementation, we must
> + // dereference "ParentHandle" here:
> + //
> + // 1. The EFI shell installs the EFI_SHELL_ENVIRONMENT2 protocol,
> + // identified by gEfiShellEnvironment2Guid.
> + // 2. The Execute() member function takes "ParentImageHandle" as first
> + // parameter, with type (EFI_HANDLE*).
> + // 3. In the EdkShell implementation, SEnvExecute() implements the
> + // Execute() member function. It passes "ParentImageHandle" correctly to
> + // SEnvDoExecute().
> + // 4. SEnvDoExecute() takes the (EFI_HANDLE*), and passes it directly --
> + // without de-referencing -- to the HandleProtocol() boot service.
> + // 5. But HandleProtocol() takes an EFI_HANDLE.
> + //
> + // Therefore we must
> + // - de-reference "ParentHandle" here, to mask the bug in
> + // SEnvDoExecute(), and
> + // - pass the resultant EFI_HANDLE as an (EFI_HANDLE*).
> + //
> + CmdStatus = (mEfiShellEnvironment2->Execute((EFI_HANDLE *)*ParentHandle,
> CommandLine,
> Output));
> //
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 33/35] StandaloneMmPkg/Core: stop abusing EFI_HANDLE for FwVolHeader tracking
2019-09-17 19:49 ` [PATCH 33/35] StandaloneMmPkg/Core: stop abusing EFI_HANDLE for FwVolHeader tracking Laszlo Ersek
@ 2019-09-26 12:48 ` Laszlo Ersek
2019-10-03 11:10 ` Laszlo Ersek
0 siblings, 1 reply; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-26 12:48 UTC (permalink / raw)
To: Achin Gupta, Jiewen Yao, Supreeth Venkatesh; +Cc: edk2-devel-groups-io
Achin, Jiewen, Supreeth,
can one of you guys please review this patch?
Thanks
Laszlo
On 09/17/19 21:49, Laszlo Ersek wrote:
> The FvHasBeenProcessed() and FvIsBeingProcesssed() functions make sure
> that every firmware volume is processed only once (every driver in every
> firmware volume should be discovered only once). For this, the functions
> use a linked list.
>
> In MdeModulePkg's DXE Core and SMM Core, the key used for identifying
> those firmware volumes that have been processed is the EFI_HANDLE on which
> the DXE or SMM firmware volume protocol is installed. In the
> StandaloneMmPkg core however, the key is the address of the firmware
> volume header; that is, it has type (EFI_FIRMWARE_VOLUME_HEADER*).
>
> (EFI_FIRMWARE_VOLUME_HEADER*) has nothing to do with EFI_HANDLE.
> EFI_HANDLE just happens to be specified as (VOID*), and therefore the
> conversion between (EFI_FIRMWARE_VOLUME_HEADER*) and EFI_HANDLE is silent.
>
> (The FvHasBeenProcessed() and FvIsBeingProcesssed() functions were likely
> copied verbatim from MdeModulePkg's DXE Core and/or the SMM Core, and not
> flagged by the compiler in StandaloneMmPkg due to UEFI regrettably
> specifying EFI_HANDLE as (VOID*), thereby enabling the above implicit
> conversion.)
>
> We should not exploit this circumstance. Represent the key type faithfully
> instead.
>
> This is a semantic fix; there is no change in operation.
>
> Cc: Achin Gupta <achin.gupta@arm.com>
> Cc: Jiewen Yao <jiewen.yao@intel.com>
> Cc: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> build-tested only
>
> StandaloneMmPkg/Core/StandaloneMmCore.h | 2 +-
> StandaloneMmPkg/Core/Dispatcher.c | 80 +++++++++++---------
> StandaloneMmPkg/Core/FwVol.c | 16 ++--
> 3 files changed, 52 insertions(+), 46 deletions(-)
>
> diff --git a/StandaloneMmPkg/Core/StandaloneMmCore.h b/StandaloneMmPkg/Core/StandaloneMmCore.h
> index dcf91bc5e916..23ddbe169faf 100644
> --- a/StandaloneMmPkg/Core/StandaloneMmCore.h
> +++ b/StandaloneMmPkg/Core/StandaloneMmCore.h
> @@ -67,7 +67,7 @@ typedef struct {
>
> LIST_ENTRY ScheduledLink; // mScheduledQueue
>
> - EFI_HANDLE FvHandle;
> + EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader;
> EFI_GUID FileName;
> VOID *Pe32Data;
> UINTN Pe32DataSize;
> diff --git a/StandaloneMmPkg/Core/Dispatcher.c b/StandaloneMmPkg/Core/Dispatcher.c
> index 3788389f95ed..9853445a64a1 100644
> --- a/StandaloneMmPkg/Core/Dispatcher.c
> +++ b/StandaloneMmPkg/Core/Dispatcher.c
> @@ -5,7 +5,7 @@
> is added to the mDiscoveredList. The Before, and After Depex are
> pre-processed as drivers are added to the mDiscoveredList. If an Apriori
> file exists in the FV those drivers are addeded to the
> - mScheduledQueue. The mFvHandleList is used to make sure a
> + mScheduledQueue. The mFwVolList is used to make sure a
> FV is only processed once.
>
> Step #2 - Dispatch. Remove driver from the mScheduledQueue and load and
> @@ -40,13 +40,13 @@
> //
> // MM Dispatcher Data structures
> //
> -#define KNOWN_HANDLE_SIGNATURE SIGNATURE_32('k','n','o','w')
> +#define KNOWN_FWVOL_SIGNATURE SIGNATURE_32('k','n','o','w')
>
> typedef struct {
> - UINTN Signature;
> - LIST_ENTRY Link; // mFvHandleList
> - EFI_HANDLE Handle;
> -} KNOWN_HANDLE;
> + UINTN Signature;
> + LIST_ENTRY Link; // mFwVolList
> + EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader;
> +} KNOWN_FWVOL;
>
> //
> // Function Prototypes
> @@ -86,9 +86,10 @@ LIST_ENTRY mDiscoveredList = INITIALIZE_LIST_HEAD_VARIABLE (mDiscoveredList);
> LIST_ENTRY mScheduledQueue = INITIALIZE_LIST_HEAD_VARIABLE (mScheduledQueue);
>
> //
> -// List of handles who's Fv's have been parsed and added to the mFwDriverList.
> +// List of firmware volume headers whose containing firmware volumes have been
> +// parsed and added to the mFwDriverList.
> //
> -LIST_ENTRY mFvHandleList = INITIALIZE_LIST_HEAD_VARIABLE (mFvHandleList);
> +LIST_ENTRY mFwVolList = INITIALIZE_LIST_HEAD_VARIABLE (mFwVolList);
>
> //
> // Flag for the MM Dispacher. TRUE if dispatcher is execuing.
> @@ -769,26 +770,30 @@ MmInsertOnScheduledQueueWhileProcessingBeforeAndAfter (
> }
>
> /**
> - Return TRUE if the Fv has been processed, FALSE if not.
> + Return TRUE if the firmware volume has been processed, FALSE if not.
>
> - @param FvHandle The handle of a FV that's being tested
> + @param FwVolHeader The header of the firmware volume that's being
> + tested.
>
> - @retval TRUE Fv protocol on FvHandle has been processed
> - @retval FALSE Fv protocol on FvHandle has not yet been
> - processed
> + @retval TRUE The firmware volume denoted by FwVolHeader has
> + been processed
> + @retval FALSE The firmware volume denoted by FwVolHeader has
> + not yet been processed
>
> **/
> BOOLEAN
> FvHasBeenProcessed (
> - IN EFI_HANDLE FvHandle
> + IN EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader
> )
> {
> LIST_ENTRY *Link;
> - KNOWN_HANDLE *KnownHandle;
> + KNOWN_FWVOL *KnownFwVol;
>
> - for (Link = mFvHandleList.ForwardLink; Link != &mFvHandleList; Link = Link->ForwardLink) {
> - KnownHandle = CR (Link, KNOWN_HANDLE, Link, KNOWN_HANDLE_SIGNATURE);
> - if (KnownHandle->Handle == FvHandle) {
> + for (Link = mFwVolList.ForwardLink;
> + Link != &mFwVolList;
> + Link = Link->ForwardLink) {
> + KnownFwVol = CR (Link, KNOWN_FWVOL, Link, KNOWN_FWVOL_SIGNATURE);
> + if (KnownFwVol->FwVolHeader == FwVolHeader) {
> return TRUE;
> }
> }
> @@ -796,28 +801,29 @@ FvHasBeenProcessed (
> }
>
> /**
> - Remember that Fv protocol on FvHandle has had it's drivers placed on the
> - mDiscoveredList. This fucntion adds entries on the mFvHandleList. Items are
> - never removed/freed from the mFvHandleList.
> + Remember that the firmware volume denoted by FwVolHeader has had its drivers
> + placed on mDiscoveredList. This function adds entries to mFwVolList. Items
> + are never removed/freed from mFwVolList.
>
> - @param FvHandle The handle of a FV that has been processed
> + @param FwVolHeader The header of the firmware volume that's being
> + processed.
>
> **/
> VOID
> FvIsBeingProcesssed (
> - IN EFI_HANDLE FvHandle
> + IN EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader
> )
> {
> - KNOWN_HANDLE *KnownHandle;
> + KNOWN_FWVOL *KnownFwVol;
>
> - DEBUG ((DEBUG_INFO, "FvIsBeingProcesssed - 0x%08x\n", FvHandle));
> + DEBUG ((DEBUG_INFO, "FvIsBeingProcesssed - 0x%08x\n", KnownFwVol));
>
> - KnownHandle = AllocatePool (sizeof (KNOWN_HANDLE));
> - ASSERT (KnownHandle != NULL);
> + KnownFwVol = AllocatePool (sizeof (KNOWN_FWVOL));
> + ASSERT (KnownFwVol != NULL);
>
> - KnownHandle->Signature = KNOWN_HANDLE_SIGNATURE;
> - KnownHandle->Handle = FvHandle;
> - InsertTailList (&mFvHandleList, &KnownHandle->Link);
> + KnownFwVol->Signature = KNOWN_FWVOL_SIGNATURE;
> + KnownFwVol->FwVolHeader = FwVolHeader;
> + InsertTailList (&mFwVolList, &KnownFwVol->Link);
> }
>
> /**
> @@ -842,12 +848,12 @@ FvIsBeingProcesssed (
> **/
> EFI_STATUS
> MmAddToDriverList (
> - IN EFI_HANDLE FvHandle,
> - IN VOID *Pe32Data,
> - IN UINTN Pe32DataSize,
> - IN VOID *Depex,
> - IN UINTN DepexSize,
> - IN EFI_GUID *DriverName
> + IN EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader,
> + IN VOID *Pe32Data,
> + IN UINTN Pe32DataSize,
> + IN VOID *Depex,
> + IN UINTN DepexSize,
> + IN EFI_GUID *DriverName
> )
> {
> EFI_MM_DRIVER_ENTRY *DriverEntry;
> @@ -863,7 +869,7 @@ MmAddToDriverList (
>
> DriverEntry->Signature = EFI_MM_DRIVER_ENTRY_SIGNATURE;
> CopyGuid (&DriverEntry->FileName, DriverName);
> - DriverEntry->FvHandle = FvHandle;
> + DriverEntry->FwVolHeader = FwVolHeader;
> DriverEntry->Pe32Data = Pe32Data;
> DriverEntry->Pe32DataSize = Pe32DataSize;
> DriverEntry->Depex = Depex;
> diff --git a/StandaloneMmPkg/Core/FwVol.c b/StandaloneMmPkg/Core/FwVol.c
> index 9fe0c257a43a..99ecf4af4714 100644
> --- a/StandaloneMmPkg/Core/FwVol.c
> +++ b/StandaloneMmPkg/Core/FwVol.c
> @@ -24,22 +24,22 @@ EFI_FV_FILETYPE mMmFileTypes[] = {
>
> EFI_STATUS
> MmAddToDriverList (
> - IN EFI_HANDLE FvHandle,
> - IN VOID *Pe32Data,
> - IN UINTN Pe32DataSize,
> - IN VOID *Depex,
> - IN UINTN DepexSize,
> - IN EFI_GUID *DriverName
> + IN EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader,
> + IN VOID *Pe32Data,
> + IN UINTN Pe32DataSize,
> + IN VOID *Depex,
> + IN UINTN DepexSize,
> + IN EFI_GUID *DriverName
> );
>
> BOOLEAN
> FvHasBeenProcessed (
> - IN EFI_HANDLE FvHandle
> + IN EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader
> );
>
> VOID
> FvIsBeingProcesssed (
> - IN EFI_HANDLE FvHandle
> + IN EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader
> );
>
> EFI_STATUS
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 34/35] UefiPayloadPkg/BlSupportPei: fix MMCONFIG assignment from XSDT
2019-09-17 19:49 ` [PATCH 34/35] UefiPayloadPkg/BlSupportPei: fix MMCONFIG assignment from XSDT Laszlo Ersek
2019-09-23 2:30 ` Guo Dong
@ 2019-09-26 13:17 ` Philippe Mathieu-Daudé
1 sibling, 0 replies; 155+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-09-26 13:17 UTC (permalink / raw)
To: devel, lersek; +Cc: Benjamin You, Guo Dong, Maurice Ma
On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> (This patch is unrelated to the rest of this series; its purpose is to
> enable building the UefiPayloadPkg DSC files with GCC.)
>
> When building "UefiPayloadPkg/UefiPayloadPkgIa32.dsc" with GCC48 for the
> DEBUG target, the compiler reports that "Entry32" may be used
> uninitialized in ParseAcpiInfo(), in the XSDT branch.
>
> Code inspection proves the compiler right. In the XSDT branch, the code
> from the RSDT branch must have been duplicated, and "Entry32" references
> were replaced with "Entry64" -- except where "MmCfgHdr" is assigned.
>
> Fix this bug by introducing a helper variable called "Signature", so that
> we have to refer to "Entry32" or "Entry64" only once per loop body.
>
> Cc: Benjamin You <benjamin.you@intel.com>
> Cc: Guo Dong <guo.dong@intel.com>
> Cc: Maurice Ma <maurice.ma@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> build-tested only
>
> UefiPayloadPkg/BlSupportPei/BlSupportPei.c | 19 +++++++++++--------
> 1 file changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/UefiPayloadPkg/BlSupportPei/BlSupportPei.c b/UefiPayloadPkg/BlSupportPei/BlSupportPei.c
> index 90433b609f22..22972453117a 100644
> --- a/UefiPayloadPkg/BlSupportPei/BlSupportPei.c
> +++ b/UefiPayloadPkg/BlSupportPei/BlSupportPei.c
> @@ -164,6 +164,7 @@ ParseAcpiInfo (
> UINT64 *Entry64;
> UINTN Entry64Num;
> UINTN Idx;
> + UINT32 *Signature;
> EFI_ACPI_MEMORY_MAPPED_CONFIGURATION_BASE_ADDRESS_TABLE_HEADER *MmCfgHdr;
> EFI_ACPI_MEMORY_MAPPED_ENHANCED_CONFIGURATION_SPACE_BASE_ADDRESS_ALLOCATION_STRUCTURE *MmCfgBase;
>
> @@ -181,13 +182,14 @@ ParseAcpiInfo (
> Entry32 = (UINT32 *)(Rsdt + 1);
> Entry32Num = (Rsdt->Length - sizeof(EFI_ACPI_DESCRIPTION_HEADER)) >> 2;
> for (Idx = 0; Idx < Entry32Num; Idx++) {
> - if (*(UINT32 *)(UINTN)(Entry32[Idx]) == EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE_SIGNATURE) {
> - Fadt = (EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE *)(UINTN)(Entry32[Idx]);
> + Signature = (UINT32 *)(UINTN)Entry32[Idx];
> + if (*Signature == EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE_SIGNATURE) {
> + Fadt = (EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE *)Signature;
> DEBUG ((DEBUG_INFO, "Found Fadt in Rsdt\n"));
> }
>
> - if (*(UINT32 *)(UINTN)(Entry32[Idx]) == EFI_ACPI_5_0_PCI_EXPRESS_MEMORY_MAPPED_CONFIGURATION_SPACE_BASE_ADDRESS_DESCRIPTION_TABLE_SIGNATURE) {
> - MmCfgHdr = (EFI_ACPI_MEMORY_MAPPED_CONFIGURATION_BASE_ADDRESS_TABLE_HEADER *)(UINTN)(Entry32[Idx]);
> + if (*Signature == EFI_ACPI_5_0_PCI_EXPRESS_MEMORY_MAPPED_CONFIGURATION_SPACE_BASE_ADDRESS_DESCRIPTION_TABLE_SIGNATURE) {
> + MmCfgHdr = (EFI_ACPI_MEMORY_MAPPED_CONFIGURATION_BASE_ADDRESS_TABLE_HEADER *)Signature;
> DEBUG ((DEBUG_INFO, "Found MM config address in Rsdt\n"));
> }
>
> @@ -205,13 +207,14 @@ ParseAcpiInfo (
> Entry64 = (UINT64 *)(Xsdt + 1);
> Entry64Num = (Xsdt->Length - sizeof(EFI_ACPI_DESCRIPTION_HEADER)) >> 3;
> for (Idx = 0; Idx < Entry64Num; Idx++) {
> - if (*(UINT32 *)(UINTN)(Entry64[Idx]) == EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE_SIGNATURE) {
> - Fadt = (EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE *)(UINTN)(Entry64[Idx]);
> + Signature = (UINT32 *)(UINTN)Entry64[Idx];
> + if (*Signature == EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE_SIGNATURE) {
> + Fadt = (EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE *)Signature;
> DEBUG ((DEBUG_INFO, "Found Fadt in Xsdt\n"));
> }
>
> - if (*(UINT32 *)(UINTN)(Entry64[Idx]) == EFI_ACPI_5_0_PCI_EXPRESS_MEMORY_MAPPED_CONFIGURATION_SPACE_BASE_ADDRESS_DESCRIPTION_TABLE_SIGNATURE) {
> - MmCfgHdr = (EFI_ACPI_MEMORY_MAPPED_CONFIGURATION_BASE_ADDRESS_TABLE_HEADER *)(UINTN)(Entry32[Idx]);
Ah! Thanks GCC.
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
> + if (*Signature == EFI_ACPI_5_0_PCI_EXPRESS_MEMORY_MAPPED_CONFIGURATION_SPACE_BASE_ADDRESS_DESCRIPTION_TABLE_SIGNATURE) {
> + MmCfgHdr = (EFI_ACPI_MEMORY_MAPPED_CONFIGURATION_BASE_ADDRESS_TABLE_HEADER *)Signature;
> DEBUG ((DEBUG_INFO, "Found MM config address in Xsdt\n"));
> }
>
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 32/35] ShellPkg/UefiShellLib: clarify workaround for unfixable EdkShell bug
2019-09-26 12:47 ` [edk2-devel] " Laszlo Ersek
@ 2019-09-26 14:05 ` Gao, Zhichao
2019-09-26 14:58 ` Carsey, Jaben
1 sibling, 0 replies; 155+ messages in thread
From: Gao, Zhichao @ 2019-09-26 14:05 UTC (permalink / raw)
To: devel@edk2.groups.io, lersek@redhat.com, Carsey, Jaben, Ni, Ray
Sorry for miss this.
The comment is nice to help understand the type conversion.
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
> -----Original Message-----
> From: Laszlo Ersek <lersek@redhat.com>
> Sent: Thursday, September 26, 2019 8:47 PM
> To: Carsey, Jaben <jaben.carsey@intel.com>; Ni, Ray <ray.ni@intel.com>;
> Gao, Zhichao <zhichao.gao@intel.com>
> Cc: edk2-devel-groups-io <devel@edk2.groups.io>
> Subject: Re: [edk2-devel] [PATCH 32/35] ShellPkg/UefiShellLib: clarify
> workaround for unfixable EdkShell bug
>
> Jaben, Ray, Zhichao,
>
> can one of you guys please review this patch?
>
> Thanks
> Laszlo
>
> On 09/17/19 21:49, Laszlo Ersek wrote:
> > The EDK 1 Shell (available at
> > <https://github.com/tianocore/edk-Shell>)
> > has a bug in its EFI_SHELL_ENVIRONMENT2.Execute() implementation that
> > edk2's UefiShellLib has no choice but to work around.
> >
> > Improve the explanation in the code. Also, document the implicit
> > EFI_HANDLE -> (EFI_HANDLE*) conversion, which happens implicitly after
> > dereferencing ParentHandle, with an explicit cast.
> >
> > In practice, this patch is a no-op.
> >
> > Cc: Jaben Carsey <jaben.carsey@intel.com>
> > Cc: Ray Ni <ray.ni@intel.com>
> > Cc: Zhichao Gao <zhichao.gao@intel.com>
> > Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> > ---
> >
> > Notes:
> > build-tested only
> >
> > ShellPkg/Library/UefiShellLib/UefiShellLib.c | 22
> > ++++++++++++++++++--
> > 1 file changed, 20 insertions(+), 2 deletions(-)
> >
> > diff --git a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> > b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> > index 835d0f88ca74..9f07a58eb23d 100644
> > --- a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> > +++ b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> > @@ -1291,9 +1291,27 @@ ShellExecute (
> > if (mEfiShellEnvironment2 != NULL) {
> > //
> > // Call EFI Shell version.
> > - // Due to oddity in the EFI shell we want to dereference the
> ParentHandle here
> > //
> > - CmdStatus = (mEfiShellEnvironment2->Execute(*ParentHandle,
> > + // Due to an unfixable bug in the EdkShell implementation, we must
> > + // dereference "ParentHandle" here:
> > + //
> > + // 1. The EFI shell installs the EFI_SHELL_ENVIRONMENT2 protocol,
> > + // identified by gEfiShellEnvironment2Guid.
> > + // 2. The Execute() member function takes "ParentImageHandle" as
> first
> > + // parameter, with type (EFI_HANDLE*).
> > + // 3. In the EdkShell implementation, SEnvExecute() implements the
> > + // Execute() member function. It passes "ParentImageHandle"
> correctly to
> > + // SEnvDoExecute().
> > + // 4. SEnvDoExecute() takes the (EFI_HANDLE*), and passes it directly --
> > + // without de-referencing -- to the HandleProtocol() boot service.
> > + // 5. But HandleProtocol() takes an EFI_HANDLE.
> > + //
> > + // Therefore we must
> > + // - de-reference "ParentHandle" here, to mask the bug in
> > + // SEnvDoExecute(), and
> > + // - pass the resultant EFI_HANDLE as an (EFI_HANDLE*).
> > + //
> > + CmdStatus = (mEfiShellEnvironment2->Execute((EFI_HANDLE
> > + *)*ParentHandle,
> > CommandLine,
> > Output));
> > //
> >
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 30/35] ShellPkg: stop taking EFI_HANDLE in place of SHELL_FILE_HANDLE
2019-09-26 12:08 ` Laszlo Ersek
@ 2019-09-26 14:43 ` Gao, Zhichao
2019-09-30 19:52 ` Laszlo Ersek
0 siblings, 1 reply; 155+ messages in thread
From: Gao, Zhichao @ 2019-09-26 14:43 UTC (permalink / raw)
To: devel@edk2.groups.io, lersek@redhat.com; +Cc: Carsey, Jaben, Ni, Ray
OK. I didn't view the whole calling stack. Thanks for your clear explain.
Then why we need two exact same handle type? May be we should keep only one of them. Same with the DEBUG_XXX and EFI_D_XXX.
Back to the patch, it is OK to me now. Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
> -----Original Message-----
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Laszlo Ersek
> Sent: Thursday, September 26, 2019 8:09 PM
> To: devel@edk2.groups.io; Gao, Zhichao <zhichao.gao@intel.com>
> Cc: Carsey, Jaben <jaben.carsey@intel.com>; Ni, Ray <ray.ni@intel.com>
> Subject: Re: [edk2-devel] [PATCH 30/35] ShellPkg: stop taking EFI_HANDLE in
> place of SHELL_FILE_HANDLE
>
> On 09/26/19 04:53, Gao, Zhichao wrote:
> >
> >
> >> -----Original Message-----
> >> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> >> Laszlo Ersek
> >> Sent: Wednesday, September 18, 2019 3:50 AM
> >> To: edk2-devel-groups-io <devel@edk2.groups.io>
> >> Cc: Carsey, Jaben <jaben.carsey@intel.com>; Ni, Ray
> >> <ray.ni@intel.com>; Gao, Zhichao <zhichao.gao@intel.com>
> >> Subject: [edk2-devel] [PATCH 30/35] ShellPkg: stop taking EFI_HANDLE
> >> in place of SHELL_FILE_HANDLE
> >>
> >> The TouchFileByHandle() and IsDirectoryEmpty() functions are passed
> >> SHELL_FILE_HANDLE parameters, and they use those parameters
> correctly.
> >> However, their parameter lists say EFI_HANDLE.
> >>
> >> Spell out the right type in the parameter lists.
> >>
> >> In practice, this change is a no-op (because, quite regrettably, both
> >> EFI_HANDLE and SHELL_FILE_HANDLE are specified to be typedefs of
> >> (VOID*)).
> >>
> >> Cc: Jaben Carsey <jaben.carsey@intel.com>
> >> Cc: Ray Ni <ray.ni@intel.com>
> >> Cc: Zhichao Gao <zhichao.gao@intel.com>
> >> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> >> ---
> >>
> >> Notes:
> >> tested: rm, touch
> >>
> >> ShellPkg/Library/UefiShellLevel2CommandsLib/Rm.c | 2 +-
> >> ShellPkg/Library/UefiShellLevel3CommandsLib/Touch.c | 2 +-
> >> 2 files changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/ShellPkg/Library/UefiShellLevel2CommandsLib/Rm.c
> >> b/ShellPkg/Library/UefiShellLevel2CommandsLib/Rm.c
> >> index 3a1196f1529e..59f7eec376f2 100644
> >> --- a/ShellPkg/Library/UefiShellLevel2CommandsLib/Rm.c
> >> +++ b/ShellPkg/Library/UefiShellLevel2CommandsLib/Rm.c
> >> @@ -24,7 +24,7 @@ STATIC CONST SHELL_PARAM_ITEM ParamList[] =
> { **/
> >> BOOLEAN IsDirectoryEmpty (
> >> - IN EFI_HANDLE FileHandle
> >> + IN SHELL_FILE_HANDLE FileHandle
> >
> > Here may be EFI_FILE_HANDLE.
>
> Yes, it *may*, but doesn't *have* to.
>
> We have the following call tree:
>
> CascadeDelete()
> IsDirectoryEmpty()
> FileHandleFindFirstFile()
> FileHandleFindNextFile()
>
> With this patch, we have:
>
> "Node->Handle"
> |
> [SHELL_FILE_HANDLE]
> |
> v
> CascadeDelete()
> |
> [SHELL_FILE_HANDLE]
> |
> v
> IsDirectoryEmpty()
> |
> [EFI_FILE_HANDLE]
> |
> v
> FileHandleFindFirstFile()
> FileHandleFindNextFile()
>
> with your proposal, we would have:
>
> "Node->Handle"
> |
> [SHELL_FILE_HANDLE]
> |
> v
> CascadeDelete()
> |
> [EFI_FILE_HANDLE]
> |
> v
> IsDirectoryEmpty()
> |
> [EFI_FILE_HANDLE]
> |
> v
> FileHandleFindFirstFile()
> FileHandleFindNextFile()
>
> In both cases, we depend on SHELL_FILE_HANDLE being equivalent to
> EFI_FILE_HANDLE. In the end, both types are:
>
> (struct _EFI_FILE_PROTOCOL *)
>
> In both cases, we go from SHELL_FILE_HANDLE to EFI_FILE_HANDLE, and
> exploit that they are identical; the difference is only *where* we exploit that.
>
> - In this patch, we exploit the identity in IsDirectoryEmpty(): we take a
> SHELL_FILE_HANDLE, and give it to functions that take EFI_FILE_HANDLE.
>
> - In your proposal, we would exploit the exact same identity, just in
> CascadeDelete(): "Node->Handle" is a SHELL_FILE_HANDLE (see
> EFI_SHELL_FILE_INFO.Handle), and we'd pass it to a function (namely
> IsDirectoryEmpty()) taking an EFI_FILE_HANDLE.
>
> Given that your proposal wouldn't change our dependence on the
> SHELL_FILE_HANDLE===EFI_FILE_HANDLE identity, I prefer to stick with the
> current patch.
>
> Thanks
> Laszlo
>
> >
> >> )
> >> {
> >> EFI_STATUS Status;
> >> diff --git a/ShellPkg/Library/UefiShellLevel3CommandsLib/Touch.c
> >> b/ShellPkg/Library/UefiShellLevel3CommandsLib/Touch.c
> >> index 0f00344c815e..a215f5774c69 100644
> >> --- a/ShellPkg/Library/UefiShellLevel3CommandsLib/Touch.c
> >> +++ b/ShellPkg/Library/UefiShellLevel3CommandsLib/Touch.c
> >> @@ -21,7 +21,7 @@
> >> **/
> >> EFI_STATUS
> >> TouchFileByHandle (
> >> - IN EFI_HANDLE Handle
> >> + IN SHELL_FILE_HANDLE Handle
> >
> > Here is OK.
> >
> > Thanks,
> > Zhichao
> >
> >> )
> >> {
> >> EFI_STATUS Status;
> >> --
> >> 2.19.1.3.g30247aa5d201
> >>
> >>
> >>
> >> -=-=-=-=-=-=
> >> Groups.io Links: You receive all messages sent to this group.
> >>
> >> View/Reply Online (#47417):
> >> https://edk2.groups.io/g/devel/message/47417
> >> Mute This Topic: https://groups.io/mt/34180233/1768756
> >> Group Owner: devel+owner@edk2.groups.io
> >> Unsubscribe: https://edk2.groups.io/g/devel/unsub
> >> [zhichao.gao@intel.com]
> >> -=-=-=-=-=-=
> >
> >
> >
> >
>
>
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 32/35] ShellPkg/UefiShellLib: clarify workaround for unfixable EdkShell bug
2019-09-26 12:47 ` [edk2-devel] " Laszlo Ersek
2019-09-26 14:05 ` Gao, Zhichao
@ 2019-09-26 14:58 ` Carsey, Jaben
1 sibling, 0 replies; 155+ messages in thread
From: Carsey, Jaben @ 2019-09-26 14:58 UTC (permalink / raw)
To: devel@edk2.groups.io, lersek@redhat.com, Ni, Ray, Gao, Zhichao
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Given the time gap between now and when this library was originally written, I think that we should revisit maintaining support for EFI Shell. Do we still need to have UEFI Applications that can go between EFI and UEFI versions of the shell? Are there really many EFI Shell instances that currently developed applications need to maintain support for?
Thanks
-Jaben
> -----Original Message-----
> From: Laszlo Ersek [mailto:lersek@redhat.com]
> Sent: Thursday, September 26, 2019 5:47 AM
> To: Carsey, Jaben <jaben.carsey@intel.com>; Ni, Ray <ray.ni@intel.com>;
> Gao, Zhichao <zhichao.gao@intel.com>
> Cc: edk2-devel-groups-io <devel@edk2.groups.io>
> Subject: Re: [edk2-devel] [PATCH 32/35] ShellPkg/UefiShellLib: clarify
> workaround for unfixable EdkShell bug
>
> Jaben, Ray, Zhichao,
>
> can one of you guys please review this patch?
>
> Thanks
> Laszlo
>
> On 09/17/19 21:49, Laszlo Ersek wrote:
> > The EDK 1 Shell (available at <https://github.com/tianocore/edk-Shell>)
> > has a bug in its EFI_SHELL_ENVIRONMENT2.Execute() implementation that
> > edk2's UefiShellLib has no choice but to work around.
> >
> > Improve the explanation in the code. Also, document the implicit
> > EFI_HANDLE -> (EFI_HANDLE*) conversion, which happens implicitly after
> > dereferencing ParentHandle, with an explicit cast.
> >
> > In practice, this patch is a no-op.
> >
> > Cc: Jaben Carsey <jaben.carsey@intel.com>
> > Cc: Ray Ni <ray.ni@intel.com>
> > Cc: Zhichao Gao <zhichao.gao@intel.com>
> > Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> > ---
> >
> > Notes:
> > build-tested only
> >
> > ShellPkg/Library/UefiShellLib/UefiShellLib.c | 22 ++++++++++++++++++--
> > 1 file changed, 20 insertions(+), 2 deletions(-)
> >
> > diff --git a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> > index 835d0f88ca74..9f07a58eb23d 100644
> > --- a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> > +++ b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> > @@ -1291,9 +1291,27 @@ ShellExecute (
> > if (mEfiShellEnvironment2 != NULL) {
> > //
> > // Call EFI Shell version.
> > - // Due to oddity in the EFI shell we want to dereference the
> ParentHandle here
> > //
> > - CmdStatus = (mEfiShellEnvironment2->Execute(*ParentHandle,
> > + // Due to an unfixable bug in the EdkShell implementation, we must
> > + // dereference "ParentHandle" here:
> > + //
> > + // 1. The EFI shell installs the EFI_SHELL_ENVIRONMENT2 protocol,
> > + // identified by gEfiShellEnvironment2Guid.
> > + // 2. The Execute() member function takes "ParentImageHandle" as
> first
> > + // parameter, with type (EFI_HANDLE*).
> > + // 3. In the EdkShell implementation, SEnvExecute() implements the
> > + // Execute() member function. It passes "ParentImageHandle"
> correctly to
> > + // SEnvDoExecute().
> > + // 4. SEnvDoExecute() takes the (EFI_HANDLE*), and passes it directly --
> > + // without de-referencing -- to the HandleProtocol() boot service.
> > + // 5. But HandleProtocol() takes an EFI_HANDLE.
> > + //
> > + // Therefore we must
> > + // - de-reference "ParentHandle" here, to mask the bug in
> > + // SEnvDoExecute(), and
> > + // - pass the resultant EFI_HANDLE as an (EFI_HANDLE*).
> > + //
> > + CmdStatus = (mEfiShellEnvironment2->Execute((EFI_HANDLE
> *)*ParentHandle,
> > CommandLine,
> > Output));
> > //
> >
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 19/35] NetworkPkg: fix CloseProtocol & UninstallMultipleProtocolInterfaces calls
2019-09-17 19:49 ` [PATCH 19/35] NetworkPkg: fix CloseProtocol & UninstallMultipleProtocolInterfaces calls Laszlo Ersek
2019-09-26 12:14 ` [edk2-devel] " Laszlo Ersek
2019-09-26 12:42 ` Philippe Mathieu-Daudé
@ 2019-09-27 0:03 ` Siyuan, Fu
2 siblings, 0 replies; 155+ messages in thread
From: Siyuan, Fu @ 2019-09-27 0:03 UTC (permalink / raw)
To: Laszlo Ersek, edk2-devel-groups-io; +Cc: Wu, Jiaxin
Reviewed-by: Siyuan Fu <siyuan.fu@intel.com>
> -----Original Message-----
> From: Laszlo Ersek <lersek@redhat.com>
> Sent: 2019年9月18日 3:49
> To: edk2-devel-groups-io <devel@edk2.groups.io>
> Cc: Wu, Jiaxin <jiaxin.wu@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>
> Subject: [PATCH 19/35] NetworkPkg: fix CloseProtocol &
> UninstallMultipleProtocolInterfaces calls
>
> Both the "ControllerHandle" parameter of CloseProtocol() and the "Handle"
> parameter of UninstallMultipleProtocolInterfaces() have type EFI_HANDLE,
> not (EFI_HANDLE*).
>
> This patch fixes actual bugs. The issues have been dormant likely because
> they are on error paths. (Or, in case of TlsAuthConfigDxe, because the
> driver is unloaded likely very infrequently.)
>
> Cc: Jiaxin Wu <jiaxin.wu@intel.com>
> Cc: Siyuan Fu <siyuan.fu@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> build-tested only
>
> NetworkPkg/DnsDxe/DnsDriver.c | 4 ++--
> NetworkPkg/IScsiDxe/IScsiConfig.c | 2 +-
> NetworkPkg/Ip4Dxe/Ip4Driver.c | 2 +-
> NetworkPkg/Ip6Dxe/Ip6Driver.c | 2 +-
> NetworkPkg/Mtftp4Dxe/Mtftp4Driver.c | 2 +-
> NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.c | 2 +-
> 6 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/NetworkPkg/DnsDxe/DnsDriver.c
> b/NetworkPkg/DnsDxe/DnsDriver.c
> index 94d072159a4d..ad007da8b7d6 100644
> --- a/NetworkPkg/DnsDxe/DnsDriver.c
> +++ b/NetworkPkg/DnsDxe/DnsDriver.c
> @@ -1145,7 +1145,7 @@ Dns4ServiceBindingCreateChild (
> DnsSb->ConnectUdp->UdpHandle,
> &gEfiUdp4ProtocolGuid,
> gDns4DriverBinding.DriverBindingHandle,
> - ChildHandle
> + *ChildHandle
> );
>
> gBS->UninstallMultipleProtocolInterfaces (
> @@ -1388,7 +1388,7 @@ Dns6ServiceBindingCreateChild (
> DnsSb->ConnectUdp->UdpHandle,
> &gEfiUdp6ProtocolGuid,
> gDns6DriverBinding.DriverBindingHandle,
> - ChildHandle
> + *ChildHandle
> );
>
> gBS->UninstallMultipleProtocolInterfaces (
> diff --git a/NetworkPkg/IScsiDxe/IScsiConfig.c
> b/NetworkPkg/IScsiDxe/IScsiConfig.c
> index b876da7f5ccd..d773849fd3b0 100644
> --- a/NetworkPkg/IScsiDxe/IScsiConfig.c
> +++ b/NetworkPkg/IScsiDxe/IScsiConfig.c
> @@ -3852,7 +3852,7 @@ IScsiConfigFormInit (
> );
> if (CallbackInfo->RegisteredHandle == NULL) {
> gBS->UninstallMultipleProtocolInterfaces (
> - &CallbackInfo->DriverHandle,
> + CallbackInfo->DriverHandle,
> &gEfiDevicePathProtocolGuid,
> &mIScsiHiiVendorDevicePath,
> &gEfiHiiConfigAccessProtocolGuid,
> diff --git a/NetworkPkg/Ip4Dxe/Ip4Driver.c
> b/NetworkPkg/Ip4Dxe/Ip4Driver.c
> index ebd4dec1dfe4..62be8b681a18 100644
> --- a/NetworkPkg/Ip4Dxe/Ip4Driver.c
> +++ b/NetworkPkg/Ip4Dxe/Ip4Driver.c
> @@ -891,7 +891,7 @@ Ip4ServiceBindingCreateChild (
> );
> if (EFI_ERROR (Status)) {
> gBS->UninstallMultipleProtocolInterfaces (
> - ChildHandle,
> + *ChildHandle,
> &gEfiIp4ProtocolGuid,
> &IpInstance->Ip4Proto,
> NULL
> diff --git a/NetworkPkg/Ip6Dxe/Ip6Driver.c
> b/NetworkPkg/Ip6Dxe/Ip6Driver.c
> index 7dc9e45af7b6..63d8428dbced 100644
> --- a/NetworkPkg/Ip6Dxe/Ip6Driver.c
> +++ b/NetworkPkg/Ip6Dxe/Ip6Driver.c
> @@ -888,7 +888,7 @@ Ip6ServiceBindingCreateChild (
> );
> if (EFI_ERROR (Status)) {
> gBS->UninstallMultipleProtocolInterfaces (
> - ChildHandle,
> + *ChildHandle,
> &gEfiIp6ProtocolGuid,
> &IpInstance->Ip6Proto,
> NULL
> diff --git a/NetworkPkg/Mtftp4Dxe/Mtftp4Driver.c
> b/NetworkPkg/Mtftp4Dxe/Mtftp4Driver.c
> index ae9e65544a86..06c4e202d3ef 100644
> --- a/NetworkPkg/Mtftp4Dxe/Mtftp4Driver.c
> +++ b/NetworkPkg/Mtftp4Dxe/Mtftp4Driver.c
> @@ -592,7 +592,7 @@ Mtftp4ServiceBindingCreateChild (
> MtftpSb->ConnectUdp->UdpHandle,
> &gEfiUdp4ProtocolGuid,
> gMtftp4DriverBinding.DriverBindingHandle,
> - ChildHandle
> + *ChildHandle
> );
> goto ON_ERROR;
> }
> diff --git a/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.c
> b/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.c
> index 18ee763002b4..c0870ab9979c 100644
> --- a/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.c
> +++ b/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.c
> @@ -39,7 +39,7 @@ TlsAuthConfigDxeUnload (
> ASSERT (PrivateData->Signature ==
> TLS_AUTH_CONFIG_PRIVATE_DATA_SIGNATURE);
>
> gBS->UninstallMultipleProtocolInterfaces (
> - &ImageHandle,
> + ImageHandle,
> &gEfiCallerIdGuid,
> PrivateData,
> NULL
> --
> 2.19.1.3.g30247aa5d201
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 20/35] NetworkPkg/Ip4Dxe: fix NetLibDestroyServiceChild() call
2019-09-23 16:03 ` [edk2-devel] " Philippe Mathieu-Daudé
@ 2019-09-27 0:04 ` Siyuan, Fu
0 siblings, 0 replies; 155+ messages in thread
From: Siyuan, Fu @ 2019-09-27 0:04 UTC (permalink / raw)
To: Philippe Mathieu-Daudé, devel@edk2.groups.io,
lersek@redhat.com
Cc: Wu, Jiaxin
Reviewed-by: Siyuan Fu <siyuan.fu@intel.com>
> -----Original Message-----
> From: Philippe Mathieu-Daudé <philmd@redhat.com>
> Sent: 2019年9月24日 0:04
> To: devel@edk2.groups.io; lersek@redhat.com
> Cc: Wu, Jiaxin <jiaxin.wu@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>
> Subject: Re: [edk2-devel] [PATCH 20/35] NetworkPkg/Ip4Dxe: fix
> NetLibDestroyServiceChild() call
>
> On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> > Both NetLibDestroyServiceChild() and
> EFI_SERVICE_BINDING_DESTROY_CHILD
> > take an EFI_HANDLE for the "ChildHandle" parameter, not an
> (EFI_HANDLE*).
> >
> > This patch fixes a real bug.
> >
> > Cc: Jiaxin Wu <jiaxin.wu@intel.com>
> > Cc: Siyuan Fu <siyuan.fu@intel.com>
> > Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> > ---
> >
> > Notes:
> > possibly only build-tested
> >
> > NetworkPkg/Ip4Dxe/Ip4If.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/NetworkPkg/Ip4Dxe/Ip4If.c b/NetworkPkg/Ip4Dxe/Ip4If.c
> > index 44b8d9fc8faf..53a333037f94 100644
> > --- a/NetworkPkg/Ip4Dxe/Ip4If.c
> > +++ b/NetworkPkg/Ip4Dxe/Ip4If.c
> > @@ -592,7 +592,7 @@ Ip4SetAddress (
> > Interface->Controller,
> > Interface->Image,
> > &gEfiArpServiceBindingProtocolGuid,
> > - &Interface->ArpHandle
> > + Interface->ArpHandle
> > );
> >
> > Interface->ArpHandle = NULL;
> > @@ -657,7 +657,7 @@ ON_ERROR:
> > Interface->Controller,
> > Interface->Image,
> > &gEfiArpServiceBindingProtocolGuid,
> > - &Interface->ArpHandle
> > + Interface->ArpHandle
>
> I'm surprise this one never triggered unexpected behaviors, it
> looks easy to reach.
>
> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
>
> > );
> >
> > return Status;
> >
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 21/35] NetworkPkg/TcpDxe: fix SockFreeFoo() parameter list
2019-09-17 19:49 ` [PATCH 21/35] NetworkPkg/TcpDxe: fix SockFreeFoo() parameter list Laszlo Ersek
2019-09-23 15:09 ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-26 12:14 ` Laszlo Ersek
@ 2019-09-27 0:06 ` Siyuan, Fu
2 siblings, 0 replies; 155+ messages in thread
From: Siyuan, Fu @ 2019-09-27 0:06 UTC (permalink / raw)
To: devel@edk2.groups.io, lersek@redhat.com; +Cc: Wu, Jiaxin
Reviewed-by: Siyuan Fu <siyuan.fu@intel.com>
> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Laszlo
> Ersek
> Sent: 2019年9月18日 3:49
> To: edk2-devel-groups-io <devel@edk2.groups.io>
> Cc: Wu, Jiaxin <jiaxin.wu@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>
> Subject: [edk2-devel] [PATCH 21/35] NetworkPkg/TcpDxe: fix SockFreeFoo()
> parameter list
>
> The SockFreeFoo() callback function for NetbufFromExt() has to match the
> NET_VECTOR_EXT_FREE prototype, which takes a (VOID*) as callback
> argument
> (Arg). EFI_EVENT has nothing to do with NET_VECTOR_EXT_FREE. Fix the
> SockFreeFoo() parameter list.
>
> This change is a no-op in practice.
>
> Cc: Jiaxin Wu <jiaxin.wu@intel.com>
> Cc: Siyuan Fu <siyuan.fu@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> build-tested only
>
> NetworkPkg/TcpDxe/SockImpl.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/NetworkPkg/TcpDxe/SockImpl.c
> b/NetworkPkg/TcpDxe/SockImpl.c
> index f5e01771e2a8..fb28e2ed40d3 100644
> --- a/NetworkPkg/TcpDxe/SockImpl.c
> +++ b/NetworkPkg/TcpDxe/SockImpl.c
> @@ -67,13 +67,13 @@ SockBufNext (
> /**
> User provided callback function for NetbufFromExt.
>
> - @param[in] Event The Event this notify function registered to, ignored.
> + @param[in] Arg The Arg parameter forwarded by NetbufFromExt().
> Ignored.
>
> **/
> VOID
> EFIAPI
> SockFreeFoo (
> - IN EFI_EVENT Event
> + IN VOID *Arg
> )
> {
> return;
> --
> 2.19.1.3.g30247aa5d201
>
>
>
> -=-=-=-=-=-=
> Groups.io Links: You receive all messages sent to this group.
>
> View/Reply Online (#47408): https://edk2.groups.io/g/devel/message/47408
> Mute This Topic: https://groups.io/mt/34180222/1712935
> Group Owner: devel+owner@edk2.groups.io
> Unsubscribe: https://edk2.groups.io/g/devel/unsub [siyuan.fu@intel.com]
> -=-=-=-=-=-=
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 30/35] ShellPkg: stop taking EFI_HANDLE in place of SHELL_FILE_HANDLE
2019-09-26 14:43 ` Gao, Zhichao
@ 2019-09-30 19:52 ` Laszlo Ersek
0 siblings, 0 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-30 19:52 UTC (permalink / raw)
To: Gao, Zhichao, devel@edk2.groups.io; +Cc: Carsey, Jaben, Ni, Ray
On 09/26/19 16:43, Gao, Zhichao wrote:
> OK. I didn't view the whole calling stack. Thanks for your clear explain.
> Then why we need two exact same handle type?
Unfortunately, I have no clue.
> May be we should keep only one of them. Same with the DEBUG_XXX and EFI_D_XXX.
In the long term, EFI_FILE_HANDLE should likely be eliminated
completely. It starts with the EFI_ prefix, suggesting it's a standard
type. But none of the UEFI, PI, and Shell specs define EFI_FILE_HANDLE.
The Shell spec does define SHELL_FILE_HANDLE, so that should be
preserved in the long term. Luckily, that's what the patch uses anyway.
>
> Back to the patch, it is OK to me now. Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Thank you!
Laszlo
>
>> -----Original Message-----
>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
>> Laszlo Ersek
>> Sent: Thursday, September 26, 2019 8:09 PM
>> To: devel@edk2.groups.io; Gao, Zhichao <zhichao.gao@intel.com>
>> Cc: Carsey, Jaben <jaben.carsey@intel.com>; Ni, Ray <ray.ni@intel.com>
>> Subject: Re: [edk2-devel] [PATCH 30/35] ShellPkg: stop taking EFI_HANDLE in
>> place of SHELL_FILE_HANDLE
>>
>> On 09/26/19 04:53, Gao, Zhichao wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
>>>> Laszlo Ersek
>>>> Sent: Wednesday, September 18, 2019 3:50 AM
>>>> To: edk2-devel-groups-io <devel@edk2.groups.io>
>>>> Cc: Carsey, Jaben <jaben.carsey@intel.com>; Ni, Ray
>>>> <ray.ni@intel.com>; Gao, Zhichao <zhichao.gao@intel.com>
>>>> Subject: [edk2-devel] [PATCH 30/35] ShellPkg: stop taking EFI_HANDLE
>>>> in place of SHELL_FILE_HANDLE
>>>>
>>>> The TouchFileByHandle() and IsDirectoryEmpty() functions are passed
>>>> SHELL_FILE_HANDLE parameters, and they use those parameters
>> correctly.
>>>> However, their parameter lists say EFI_HANDLE.
>>>>
>>>> Spell out the right type in the parameter lists.
>>>>
>>>> In practice, this change is a no-op (because, quite regrettably, both
>>>> EFI_HANDLE and SHELL_FILE_HANDLE are specified to be typedefs of
>>>> (VOID*)).
>>>>
>>>> Cc: Jaben Carsey <jaben.carsey@intel.com>
>>>> Cc: Ray Ni <ray.ni@intel.com>
>>>> Cc: Zhichao Gao <zhichao.gao@intel.com>
>>>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>>>> ---
>>>>
>>>> Notes:
>>>> tested: rm, touch
>>>>
>>>> ShellPkg/Library/UefiShellLevel2CommandsLib/Rm.c | 2 +-
>>>> ShellPkg/Library/UefiShellLevel3CommandsLib/Touch.c | 2 +-
>>>> 2 files changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/ShellPkg/Library/UefiShellLevel2CommandsLib/Rm.c
>>>> b/ShellPkg/Library/UefiShellLevel2CommandsLib/Rm.c
>>>> index 3a1196f1529e..59f7eec376f2 100644
>>>> --- a/ShellPkg/Library/UefiShellLevel2CommandsLib/Rm.c
>>>> +++ b/ShellPkg/Library/UefiShellLevel2CommandsLib/Rm.c
>>>> @@ -24,7 +24,7 @@ STATIC CONST SHELL_PARAM_ITEM ParamList[] =
>> { **/
>>>> BOOLEAN IsDirectoryEmpty (
>>>> - IN EFI_HANDLE FileHandle
>>>> + IN SHELL_FILE_HANDLE FileHandle
>>>
>>> Here may be EFI_FILE_HANDLE.
>>
>> Yes, it *may*, but doesn't *have* to.
>>
>> We have the following call tree:
>>
>> CascadeDelete()
>> IsDirectoryEmpty()
>> FileHandleFindFirstFile()
>> FileHandleFindNextFile()
>>
>> With this patch, we have:
>>
>> "Node->Handle"
>> |
>> [SHELL_FILE_HANDLE]
>> |
>> v
>> CascadeDelete()
>> |
>> [SHELL_FILE_HANDLE]
>> |
>> v
>> IsDirectoryEmpty()
>> |
>> [EFI_FILE_HANDLE]
>> |
>> v
>> FileHandleFindFirstFile()
>> FileHandleFindNextFile()
>>
>> with your proposal, we would have:
>>
>> "Node->Handle"
>> |
>> [SHELL_FILE_HANDLE]
>> |
>> v
>> CascadeDelete()
>> |
>> [EFI_FILE_HANDLE]
>> |
>> v
>> IsDirectoryEmpty()
>> |
>> [EFI_FILE_HANDLE]
>> |
>> v
>> FileHandleFindFirstFile()
>> FileHandleFindNextFile()
>>
>> In both cases, we depend on SHELL_FILE_HANDLE being equivalent to
>> EFI_FILE_HANDLE. In the end, both types are:
>>
>> (struct _EFI_FILE_PROTOCOL *)
>>
>> In both cases, we go from SHELL_FILE_HANDLE to EFI_FILE_HANDLE, and
>> exploit that they are identical; the difference is only *where* we exploit that.
>>
>> - In this patch, we exploit the identity in IsDirectoryEmpty(): we take a
>> SHELL_FILE_HANDLE, and give it to functions that take EFI_FILE_HANDLE.
>>
>> - In your proposal, we would exploit the exact same identity, just in
>> CascadeDelete(): "Node->Handle" is a SHELL_FILE_HANDLE (see
>> EFI_SHELL_FILE_INFO.Handle), and we'd pass it to a function (namely
>> IsDirectoryEmpty()) taking an EFI_FILE_HANDLE.
>>
>> Given that your proposal wouldn't change our dependence on the
>> SHELL_FILE_HANDLE===EFI_FILE_HANDLE identity, I prefer to stick with the
>> current patch.
>>
>> Thanks
>> Laszlo
>>
>>>
>>>> )
>>>> {
>>>> EFI_STATUS Status;
>>>> diff --git a/ShellPkg/Library/UefiShellLevel3CommandsLib/Touch.c
>>>> b/ShellPkg/Library/UefiShellLevel3CommandsLib/Touch.c
>>>> index 0f00344c815e..a215f5774c69 100644
>>>> --- a/ShellPkg/Library/UefiShellLevel3CommandsLib/Touch.c
>>>> +++ b/ShellPkg/Library/UefiShellLevel3CommandsLib/Touch.c
>>>> @@ -21,7 +21,7 @@
>>>> **/
>>>> EFI_STATUS
>>>> TouchFileByHandle (
>>>> - IN EFI_HANDLE Handle
>>>> + IN SHELL_FILE_HANDLE Handle
>>>
>>> Here is OK.
>>>
>>> Thanks,
>>> Zhichao
>>>
>>>> )
>>>> {
>>>> EFI_STATUS Status;
>>>> --
>>>> 2.19.1.3.g30247aa5d201
>>>>
>>>>
>>>>
>>>> -=-=-=-=-=-=
>>>> Groups.io Links: You receive all messages sent to this group.
>>>>
>>>> View/Reply Online (#47417):
>>>> https://edk2.groups.io/g/devel/message/47417
>>>> Mute This Topic: https://groups.io/mt/34180233/1768756
>>>> Group Owner: devel+owner@edk2.groups.io
>>>> Unsubscribe: https://edk2.groups.io/g/devel/unsub
>>>> [zhichao.gao@intel.com]
>>>> -=-=-=-=-=-=
>>>
>>>
>>>
>>>
>>
>>
>>
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 19/35] NetworkPkg: fix CloseProtocol & UninstallMultipleProtocolInterfaces calls
2019-09-26 12:42 ` Philippe Mathieu-Daudé
@ 2019-09-30 20:16 ` Laszlo Ersek
2019-10-01 7:18 ` Philippe Mathieu-Daudé
0 siblings, 1 reply; 155+ messages in thread
From: Laszlo Ersek @ 2019-09-30 20:16 UTC (permalink / raw)
To: Philippe Mathieu-Daudé, devel; +Cc: Jiaxin Wu, Siyuan Fu
Hi Phil,
On 09/26/19 14:42, Philippe Mathieu-Daudé wrote:
> Hi Laszlo,
>
> On 9/17/19 9:49 PM, Laszlo Ersek wrote:
>> Both the "ControllerHandle" parameter of CloseProtocol()
>
> Maybe worth adding "of type EFI_CLOSE_PROTOCOL"
>
>> and the "Handle"
>> parameter of UninstallMultipleProtocolInterfaces()
>
> "of type EFI_UNINSTALL_MULTIPLE_PROTOCOL_INTERFACES"
I don't think these changes would add much information.
The above names are -- strictly speaking -- field names in the
EFI_BOOT_SERVICES structure. However, in UEFI code, they are so
frequently used that people simply refer to them
- either by just the member name,
- or by the pointer type *in itself*.
So using EFI_CLOSE_PROTOCOL in itself would certainly be correct and
directly understandable, same as CloseProtocol(). Using both at the same
type is redundant.
You can observe this simplification in the spec as well, BTW. For
example, in UEFI-2.8 "2.5.4 Device Drivers", we find
OpenProtocol() and CloseProtocol() update the handle database
maintained by the system firmware to track which drivers are
consuming protocol interfaces.
Another comment below:
>
> have type EFI_HANDLE,
>> not (EFI_HANDLE*).
>>
>> This patch fixes actual bugs. The issues have been dormant likely because
>> they are on error paths. (Or, in case of TlsAuthConfigDxe, because the
>> driver is unloaded likely very infrequently.)
>>
>> Cc: Jiaxin Wu <jiaxin.wu@intel.com>
>> Cc: Siyuan Fu <siyuan.fu@intel.com>
>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>> ---
>>
>> Notes:
>> build-tested only
>>
>> NetworkPkg/DnsDxe/DnsDriver.c | 4 ++--
>> NetworkPkg/IScsiDxe/IScsiConfig.c | 2 +-
>> NetworkPkg/Ip4Dxe/Ip4Driver.c | 2 +-
>> NetworkPkg/Ip6Dxe/Ip6Driver.c | 2 +-
>> NetworkPkg/Mtftp4Dxe/Mtftp4Driver.c | 2 +-
>> NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.c | 2 +-
>> 6 files changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/NetworkPkg/DnsDxe/DnsDriver.c b/NetworkPkg/DnsDxe/DnsDriver.c
>> index 94d072159a4d..ad007da8b7d6 100644
>> --- a/NetworkPkg/DnsDxe/DnsDriver.c
>> +++ b/NetworkPkg/DnsDxe/DnsDriver.c
>> @@ -1145,7 +1145,7 @@ Dns4ServiceBindingCreateChild (
>> DnsSb->ConnectUdp->UdpHandle,
>> &gEfiUdp4ProtocolGuid,
>> gDns4DriverBinding.DriverBindingHandle,
>> - ChildHandle
>> + *ChildHandle
>
> EFI_CLOSE_PROTOCOL, OK.
>
>> );
>>
>> gBS->UninstallMultipleProtocolInterfaces (
>> @@ -1388,7 +1388,7 @@ Dns6ServiceBindingCreateChild (
>> DnsSb->ConnectUdp->UdpHandle,
>> &gEfiUdp6ProtocolGuid,
>> gDns6DriverBinding.DriverBindingHandle,
>> - ChildHandle
>> + *ChildHandle
>
> EFI_CLOSE_PROTOCOL, OK.
>
>> );
>>
>> gBS->UninstallMultipleProtocolInterfaces (
>> diff --git a/NetworkPkg/IScsiDxe/IScsiConfig.c b/NetworkPkg/IScsiDxe/IScsiConfig.c
>> index b876da7f5ccd..d773849fd3b0 100644
>> --- a/NetworkPkg/IScsiDxe/IScsiConfig.c
>> +++ b/NetworkPkg/IScsiDxe/IScsiConfig.c
>> @@ -3852,7 +3852,7 @@ IScsiConfigFormInit (
>> );
>> if (CallbackInfo->RegisteredHandle == NULL) {
>> gBS->UninstallMultipleProtocolInterfaces (
>> - &CallbackInfo->DriverHandle,
>> + CallbackInfo->DriverHandle,
>
> EFI_UNINSTALL_MULTIPLE_PROTOCOL_INTERFACES, OK.
>
>> &gEfiDevicePathProtocolGuid,
>> &mIScsiHiiVendorDevicePath,
>> &gEfiHiiConfigAccessProtocolGuid,
>> diff --git a/NetworkPkg/Ip4Dxe/Ip4Driver.c b/NetworkPkg/Ip4Dxe/Ip4Driver.c
>> index ebd4dec1dfe4..62be8b681a18 100644
>> --- a/NetworkPkg/Ip4Dxe/Ip4Driver.c
>> +++ b/NetworkPkg/Ip4Dxe/Ip4Driver.c
>> @@ -891,7 +891,7 @@ Ip4ServiceBindingCreateChild (
>> );
>> if (EFI_ERROR (Status)) {
>> gBS->UninstallMultipleProtocolInterfaces (
>> - ChildHandle,
>> + *ChildHandle,
>
> EFI_UNINSTALL_MULTIPLE_PROTOCOL_INTERFACES, OK.
>
>> &gEfiIp4ProtocolGuid,
>> &IpInstance->Ip4Proto,
>> NULL
>> diff --git a/NetworkPkg/Ip6Dxe/Ip6Driver.c b/NetworkPkg/Ip6Dxe/Ip6Driver.c
>> index 7dc9e45af7b6..63d8428dbced 100644
>> --- a/NetworkPkg/Ip6Dxe/Ip6Driver.c
>> +++ b/NetworkPkg/Ip6Dxe/Ip6Driver.c
>> @@ -888,7 +888,7 @@ Ip6ServiceBindingCreateChild (
>> );
>> if (EFI_ERROR (Status)) {
>> gBS->UninstallMultipleProtocolInterfaces (
>> - ChildHandle,
>> + *ChildHandle,
>
> EFI_UNINSTALL_MULTIPLE_PROTOCOL_INTERFACES, OK.
>
>> &gEfiIp6ProtocolGuid,
>> &IpInstance->Ip6Proto,
>> NULL
>> diff --git a/NetworkPkg/Mtftp4Dxe/Mtftp4Driver.c b/NetworkPkg/Mtftp4Dxe/Mtftp4Driver.c
>> index ae9e65544a86..06c4e202d3ef 100644
>> --- a/NetworkPkg/Mtftp4Dxe/Mtftp4Driver.c
>> +++ b/NetworkPkg/Mtftp4Dxe/Mtftp4Driver.c
>> @@ -592,7 +592,7 @@ Mtftp4ServiceBindingCreateChild (
>> MtftpSb->ConnectUdp->UdpHandle,
>> &gEfiUdp4ProtocolGuid,
>> gMtftp4DriverBinding.DriverBindingHandle,
>> - ChildHandle
>> + *ChildHandle
>
> EFI_CLOSE_PROTOCOL, OK.
>
>> );
>> goto ON_ERROR;
>> }
>> diff --git a/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.c b/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.c
>> index 18ee763002b4..c0870ab9979c 100644
>> --- a/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.c
>> +++ b/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.c
>> @@ -39,7 +39,7 @@ TlsAuthConfigDxeUnload (
>> ASSERT (PrivateData->Signature == TLS_AUTH_CONFIG_PRIVATE_DATA_SIGNATURE);
>>
>> gBS->UninstallMultipleProtocolInterfaces (
>> - &ImageHandle,
>> + ImageHandle,
>
> EFI_UNINSTALL_MULTIPLE_PROTOCOL_INTERFACES, OK.
>
>> &gEfiCallerIdGuid,
>> PrivateData,
>> NULL
>>
>
> I'd have split this patch in 2 for easier review (one fixing
> EFI_CLOSE_PROTOCOL, another fixing
> EFI_UNINSTALL_MULTIPLE_PROTOCOL_INTERFACES).
>
> As it or split:
> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Splitting these patches the right way was a difficult question for me. I
didn't want to give each fix its own patch (because, presumably, nobody
likes a ~100-patch series, with one-liner fixes, except me, I guess... I
do like that, after all that's how I fixed the issues, one by one). And
once I opted for a coarser granularity, it was hard to tell how much
coarser it should get. As you can see, it varies over the series --
sometimes it's Pkg-level, sometimes it's module-level...
Unless there's a critical issue, I'd like to stick with the present
version. (Managing the feedback tags manually hasn't been trivial!) So
I'll take your R-b for the patch as-is, if that's OK with you.
Thanks!
Laszlo
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 19/35] NetworkPkg: fix CloseProtocol & UninstallMultipleProtocolInterfaces calls
2019-09-30 20:16 ` Laszlo Ersek
@ 2019-10-01 7:18 ` Philippe Mathieu-Daudé
0 siblings, 0 replies; 155+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-10-01 7:18 UTC (permalink / raw)
To: Laszlo Ersek, devel; +Cc: Jiaxin Wu, Siyuan Fu
On 9/30/19 10:16 PM, Laszlo Ersek wrote:
> Hi Phil,
>
> On 09/26/19 14:42, Philippe Mathieu-Daudé wrote:
>> Hi Laszlo,
>>
>> On 9/17/19 9:49 PM, Laszlo Ersek wrote:
>>> Both the "ControllerHandle" parameter of CloseProtocol()
>>
>> Maybe worth adding "of type EFI_CLOSE_PROTOCOL"
>>
>>> and the "Handle"
>>> parameter of UninstallMultipleProtocolInterfaces()
>>
>> "of type EFI_UNINSTALL_MULTIPLE_PROTOCOL_INTERFACES"
>
> I don't think these changes would add much information.
>
> The above names are -- strictly speaking -- field names in the
> EFI_BOOT_SERVICES structure. However, in UEFI code, they are so
> frequently used that people simply refer to them
> - either by just the member name,
> - or by the pointer type *in itself*.
>
> So using EFI_CLOSE_PROTOCOL in itself would certainly be correct and
> directly understandable, same as CloseProtocol(). Using both at the same
> type is redundant.
>
> You can observe this simplification in the spec as well, BTW. For
> example, in UEFI-2.8 "2.5.4 Device Drivers", we find
>
> OpenProtocol() and CloseProtocol() update the handle database
> maintained by the system firmware to track which drivers are
> consuming protocol interfaces.
Fine.
> Another comment below:
>
>>
>> have type EFI_HANDLE,
>>> not (EFI_HANDLE*).
>>>
>>> This patch fixes actual bugs. The issues have been dormant likely because
>>> they are on error paths. (Or, in case of TlsAuthConfigDxe, because the
>>> driver is unloaded likely very infrequently.)
>>>
>>> Cc: Jiaxin Wu <jiaxin.wu@intel.com>
>>> Cc: Siyuan Fu <siyuan.fu@intel.com>
>>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>>> ---
>>>
>>> Notes:
>>> build-tested only
>>>
>>> NetworkPkg/DnsDxe/DnsDriver.c | 4 ++--
>>> NetworkPkg/IScsiDxe/IScsiConfig.c | 2 +-
>>> NetworkPkg/Ip4Dxe/Ip4Driver.c | 2 +-
>>> NetworkPkg/Ip6Dxe/Ip6Driver.c | 2 +-
>>> NetworkPkg/Mtftp4Dxe/Mtftp4Driver.c | 2 +-
>>> NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.c | 2 +-
>>> 6 files changed, 7 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/NetworkPkg/DnsDxe/DnsDriver.c b/NetworkPkg/DnsDxe/DnsDriver.c
>>> index 94d072159a4d..ad007da8b7d6 100644
>>> --- a/NetworkPkg/DnsDxe/DnsDriver.c
>>> +++ b/NetworkPkg/DnsDxe/DnsDriver.c
>>> @@ -1145,7 +1145,7 @@ Dns4ServiceBindingCreateChild (
>>> DnsSb->ConnectUdp->UdpHandle,
>>> &gEfiUdp4ProtocolGuid,
>>> gDns4DriverBinding.DriverBindingHandle,
>>> - ChildHandle
>>> + *ChildHandle
>>
>> EFI_CLOSE_PROTOCOL, OK.
>>
>>> );
>>>
>>> gBS->UninstallMultipleProtocolInterfaces (
>>> @@ -1388,7 +1388,7 @@ Dns6ServiceBindingCreateChild (
>>> DnsSb->ConnectUdp->UdpHandle,
>>> &gEfiUdp6ProtocolGuid,
>>> gDns6DriverBinding.DriverBindingHandle,
>>> - ChildHandle
>>> + *ChildHandle
>>
>> EFI_CLOSE_PROTOCOL, OK.
>>
>>> );
>>>
>>> gBS->UninstallMultipleProtocolInterfaces (
>>> diff --git a/NetworkPkg/IScsiDxe/IScsiConfig.c b/NetworkPkg/IScsiDxe/IScsiConfig.c
>>> index b876da7f5ccd..d773849fd3b0 100644
>>> --- a/NetworkPkg/IScsiDxe/IScsiConfig.c
>>> +++ b/NetworkPkg/IScsiDxe/IScsiConfig.c
>>> @@ -3852,7 +3852,7 @@ IScsiConfigFormInit (
>>> );
>>> if (CallbackInfo->RegisteredHandle == NULL) {
>>> gBS->UninstallMultipleProtocolInterfaces (
>>> - &CallbackInfo->DriverHandle,
>>> + CallbackInfo->DriverHandle,
>>
>> EFI_UNINSTALL_MULTIPLE_PROTOCOL_INTERFACES, OK.
>>
>>> &gEfiDevicePathProtocolGuid,
>>> &mIScsiHiiVendorDevicePath,
>>> &gEfiHiiConfigAccessProtocolGuid,
>>> diff --git a/NetworkPkg/Ip4Dxe/Ip4Driver.c b/NetworkPkg/Ip4Dxe/Ip4Driver.c
>>> index ebd4dec1dfe4..62be8b681a18 100644
>>> --- a/NetworkPkg/Ip4Dxe/Ip4Driver.c
>>> +++ b/NetworkPkg/Ip4Dxe/Ip4Driver.c
>>> @@ -891,7 +891,7 @@ Ip4ServiceBindingCreateChild (
>>> );
>>> if (EFI_ERROR (Status)) {
>>> gBS->UninstallMultipleProtocolInterfaces (
>>> - ChildHandle,
>>> + *ChildHandle,
>>
>> EFI_UNINSTALL_MULTIPLE_PROTOCOL_INTERFACES, OK.
>>
>>> &gEfiIp4ProtocolGuid,
>>> &IpInstance->Ip4Proto,
>>> NULL
>>> diff --git a/NetworkPkg/Ip6Dxe/Ip6Driver.c b/NetworkPkg/Ip6Dxe/Ip6Driver.c
>>> index 7dc9e45af7b6..63d8428dbced 100644
>>> --- a/NetworkPkg/Ip6Dxe/Ip6Driver.c
>>> +++ b/NetworkPkg/Ip6Dxe/Ip6Driver.c
>>> @@ -888,7 +888,7 @@ Ip6ServiceBindingCreateChild (
>>> );
>>> if (EFI_ERROR (Status)) {
>>> gBS->UninstallMultipleProtocolInterfaces (
>>> - ChildHandle,
>>> + *ChildHandle,
>>
>> EFI_UNINSTALL_MULTIPLE_PROTOCOL_INTERFACES, OK.
>>
>>> &gEfiIp6ProtocolGuid,
>>> &IpInstance->Ip6Proto,
>>> NULL
>>> diff --git a/NetworkPkg/Mtftp4Dxe/Mtftp4Driver.c b/NetworkPkg/Mtftp4Dxe/Mtftp4Driver.c
>>> index ae9e65544a86..06c4e202d3ef 100644
>>> --- a/NetworkPkg/Mtftp4Dxe/Mtftp4Driver.c
>>> +++ b/NetworkPkg/Mtftp4Dxe/Mtftp4Driver.c
>>> @@ -592,7 +592,7 @@ Mtftp4ServiceBindingCreateChild (
>>> MtftpSb->ConnectUdp->UdpHandle,
>>> &gEfiUdp4ProtocolGuid,
>>> gMtftp4DriverBinding.DriverBindingHandle,
>>> - ChildHandle
>>> + *ChildHandle
>>
>> EFI_CLOSE_PROTOCOL, OK.
>>
>>> );
>>> goto ON_ERROR;
>>> }
>>> diff --git a/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.c b/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.c
>>> index 18ee763002b4..c0870ab9979c 100644
>>> --- a/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.c
>>> +++ b/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.c
>>> @@ -39,7 +39,7 @@ TlsAuthConfigDxeUnload (
>>> ASSERT (PrivateData->Signature == TLS_AUTH_CONFIG_PRIVATE_DATA_SIGNATURE);
>>>
>>> gBS->UninstallMultipleProtocolInterfaces (
>>> - &ImageHandle,
>>> + ImageHandle,
>>
>> EFI_UNINSTALL_MULTIPLE_PROTOCOL_INTERFACES, OK.
>>
>>> &gEfiCallerIdGuid,
>>> PrivateData,
>>> NULL
>>>
>>
>> I'd have split this patch in 2 for easier review (one fixing
>> EFI_CLOSE_PROTOCOL, another fixing
>> EFI_UNINSTALL_MULTIPLE_PROTOCOL_INTERFACES).
>>
>> As it or split:
>> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
>
> Splitting these patches the right way was a difficult question for me. I
> didn't want to give each fix its own patch (because, presumably, nobody
> likes a ~100-patch series, with one-liner fixes, except me, I guess... I
> do like that, after all that's how I fixed the issues, one by one). And
> once I opted for a coarser granularity, it was hard to tell how much
> coarser it should get. As you can see, it varies over the series --
> sometimes it's Pkg-level, sometimes it's module-level...
>
> Unless there's a critical issue, I'd like to stick with the present
> version. (Managing the feedback tags manually hasn't been trivial!) So
> I'll take your R-b for the patch as-is, if that's OK with you.
Sure, no problem!
I guess I reviewed ~32/35 patches of this series, so I could feel your pain.
Regards,
Phil.
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 18/35] NetworkPkg/DxeNetLib: fix type typo in NetLibGetMacAddress()
2019-09-26 12:14 ` Laszlo Ersek
@ 2019-10-03 11:05 ` Laszlo Ersek
2019-10-04 19:18 ` Laszlo Ersek
0 siblings, 1 reply; 155+ messages in thread
From: Laszlo Ersek @ 2019-10-03 11:05 UTC (permalink / raw)
To: Jiaxin Wu, Siyuan Fu; +Cc: edk2-devel-groups-io
Pinging NetworkPkg maintainers again. Please?
Thanks
Laszlo
On 09/26/19 14:14, Laszlo Ersek wrote:
> Jiaxin, Siyuan,
>
> can you please review this patch?
>
> Thanks
> Laszlo
>
> On 09/17/19 21:49, Laszlo Ersek wrote:
>> NetLibGetSnpHandle() returns an EFI_HANDLE, not an (EFI_HANDLE*).
>> NetLibGetMacAddress() only uses the return value ("SnpHandle") for a
>> NULL-check. Fix the type of "SnpHandle".
>>
>> This patch is a no-op.
>>
>> Cc: Jiaxin Wu <jiaxin.wu@intel.com>
>> Cc: Siyuan Fu <siyuan.fu@intel.com>
>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>> ---
>>
>> Notes:
>> lightly tested: MAC strings are displayed in UiApp
>>
>> NetworkPkg/Library/DxeNetLib/DxeNetLib.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/NetworkPkg/Library/DxeNetLib/DxeNetLib.c b/NetworkPkg/Library/DxeNetLib/DxeNetLib.c
>> index 8e2f720666ea..a39c20be3d34 100644
>> --- a/NetworkPkg/Library/DxeNetLib/DxeNetLib.c
>> +++ b/NetworkPkg/Library/DxeNetLib/DxeNetLib.c
>> @@ -2182,7 +2182,7 @@ NetLibGetMacAddress (
>> EFI_SIMPLE_NETWORK_MODE SnpModeData;
>> EFI_MANAGED_NETWORK_PROTOCOL *Mnp;
>> EFI_SERVICE_BINDING_PROTOCOL *MnpSb;
>> - EFI_HANDLE *SnpHandle;
>> + EFI_HANDLE SnpHandle;
>> EFI_HANDLE MnpChildHandle;
>>
>> ASSERT (MacAddress != NULL);
>>
>
>
>
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 26/35] SecurityPkg: fix UninstallMultipleProtocolInterfaces() calls
2019-09-26 12:45 ` Laszlo Ersek
@ 2019-10-03 11:06 ` Laszlo Ersek
2019-10-04 0:05 ` Yao, Jiewen
` (2 more replies)
0 siblings, 3 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-10-03 11:06 UTC (permalink / raw)
To: Chao Zhang, Jian Wang, Jiewen Yao; +Cc: edk2-devel-groups-io
Pinging SecurityPkg maintainers again, for reviewing this patch.
Thanks
Laszlo
On 09/26/19 14:45, Laszlo Ersek wrote:
> Chao, Jian, Jiewen,
>
> can you please review this patch?
>
> Thanks,
> Laszlo
>
> On 09/17/19 21:49, Laszlo Ersek wrote:
>> Unlike the InstallMultipleProtocolInterfaces() boot service, which takes
>> an (EFI_HANDLE*) as first parameter, the
>> UninstallMultipleProtocolInterfaces() boot service takes an EFI_HANDLE as
>> first parameter.
>>
>> These are actual bugs. They must have remained hidden until now because
>> they are all in Unload() functions, which are probably exercised
>> infrequently. Fix the UninstallMultipleProtocolInterfaces() calls.
>>
>> Cc: Chao Zhang <chao.b.zhang@intel.com>
>> Cc: Jian Wang <jian.j.wang@intel.com>
>> Cc: Jiewen Yao <jiewen.yao@intel.com>
>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>> ---
>>
>> Notes:
>> build-tested only
>>
>> SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c | 2 +-
>> SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c | 2 +-
>> SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDriver.c | 2 +-
>> 3 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c b/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c
>> index 54155a338100..9052eced757d 100644
>> --- a/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c
>> +++ b/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c
>> @@ -443,7 +443,7 @@ Tcg2ConfigDriverUnload (
>> ASSERT (PrivateData->Signature == TCG2_CONFIG_PRIVATE_DATA_SIGNATURE);
>>
>> gBS->UninstallMultipleProtocolInterfaces (
>> - &ImageHandle,
>> + ImageHandle,
>> &gEfiCallerIdGuid,
>> PrivateData,
>> NULL
>> diff --git a/SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c b/SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c
>> index 341879e4c4ba..fb06624fdb8f 100644
>> --- a/SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c
>> +++ b/SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c
>> @@ -138,7 +138,7 @@ TcgConfigDriverUnload (
>> ASSERT (PrivateData->Signature == TCG_CONFIG_PRIVATE_DATA_SIGNATURE);
>>
>> gBS->UninstallMultipleProtocolInterfaces (
>> - &ImageHandle,
>> + ImageHandle,
>> &gEfiCallerIdGuid,
>> PrivateData,
>> NULL
>> diff --git a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDriver.c b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDriver.c
>> index 798ef9cfbc01..6c0294151e6c 100644
>> --- a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDriver.c
>> +++ b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDriver.c
>> @@ -115,7 +115,7 @@ SecureBootConfigDriverUnload (
>> ASSERT (PrivateData->Signature == SECUREBOOT_CONFIG_PRIVATE_DATA_SIGNATURE);
>>
>> gBS->UninstallMultipleProtocolInterfaces (
>> - &ImageHandle,
>> + ImageHandle,
>> &gEfiCallerIdGuid,
>> PrivateData,
>> NULL
>>
>
>
>
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 27/35] SecurityPkg: stop abusing EFI_EVENT for protocol notify registration
2019-09-26 12:46 ` Laszlo Ersek
@ 2019-10-03 11:06 ` Laszlo Ersek
2019-10-04 0:05 ` Yao, Jiewen
` (2 more replies)
0 siblings, 3 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-10-03 11:06 UTC (permalink / raw)
To: Chao Zhang, Jian Wang, Jiewen Yao; +Cc: edk2-devel-groups-io
Pinging SecurityPkg maintainers again, for reviewing this patch.
Thanks
Laszlo
On 09/26/19 14:46, Laszlo Ersek wrote:
> Chao, Jian, Jiewen,
>
> can you please review this patch?
>
> Thanks,
> Laszlo
>
>
> On 09/17/19 21:49, Laszlo Ersek wrote:
>> EfiCreateProtocolNotifyEvent() takes a (VOID**) for "Registration",
>> similarly to gBS->RegisterProtocolNotify(). We should pass the address of
>> an actual pointer-to-VOID, and not the address of an EFI_EVENT. EFI_EVENT
>> just happens to be specified as (VOID*), and has nothing to do with the
>> registration.
>>
>> This change is a no-op in practice; it's a semantic improvement.
>>
>> Cc: Chao Zhang <chao.b.zhang@intel.com>
>> Cc: Jian Wang <jian.j.wang@intel.com>
>> Cc: Jiewen Yao <jiewen.yao@intel.com>
>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>> ---
>>
>> Notes:
>> build-tested only
>>
>> SecurityPkg/HddPassword/HddPasswordDxe.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/SecurityPkg/HddPassword/HddPasswordDxe.c b/SecurityPkg/HddPassword/HddPasswordDxe.c
>> index b0d795b6597f..051e64091d7f 100644
>> --- a/SecurityPkg/HddPassword/HddPasswordDxe.c
>> +++ b/SecurityPkg/HddPassword/HddPasswordDxe.c
>> @@ -2770,7 +2770,7 @@ HddPasswordDxeInit (
>> {
>> EFI_STATUS Status;
>> HDD_PASSWORD_DXE_PRIVATE_DATA *Private;
>> - EFI_EVENT Registration;
>> + VOID *Registration;
>> EFI_EVENT EndOfDxeEvent;
>> EDKII_VARIABLE_LOCK_PROTOCOL *VariableLock;
>>
>>
>
>
>
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 33/35] StandaloneMmPkg/Core: stop abusing EFI_HANDLE for FwVolHeader tracking
2019-09-26 12:48 ` [edk2-devel] " Laszlo Ersek
@ 2019-10-03 11:10 ` Laszlo Ersek
2019-10-03 11:17 ` Achin Gupta
` (2 more replies)
0 siblings, 3 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-10-03 11:10 UTC (permalink / raw)
To: Achin Gupta, Jiewen Yao, Supreeth Venkatesh; +Cc: edk2-devel-groups-io
Pinging StandaloneMmPkg maintainers again, for reviewing this patch.
Thanks
Laszlo
On 09/26/19 14:48, Laszlo Ersek wrote:
> Achin, Jiewen, Supreeth,
>
> can one of you guys please review this patch?
>
> Thanks
> Laszlo
>
> On 09/17/19 21:49, Laszlo Ersek wrote:
>> The FvHasBeenProcessed() and FvIsBeingProcesssed() functions make sure
>> that every firmware volume is processed only once (every driver in every
>> firmware volume should be discovered only once). For this, the functions
>> use a linked list.
>>
>> In MdeModulePkg's DXE Core and SMM Core, the key used for identifying
>> those firmware volumes that have been processed is the EFI_HANDLE on which
>> the DXE or SMM firmware volume protocol is installed. In the
>> StandaloneMmPkg core however, the key is the address of the firmware
>> volume header; that is, it has type (EFI_FIRMWARE_VOLUME_HEADER*).
>>
>> (EFI_FIRMWARE_VOLUME_HEADER*) has nothing to do with EFI_HANDLE.
>> EFI_HANDLE just happens to be specified as (VOID*), and therefore the
>> conversion between (EFI_FIRMWARE_VOLUME_HEADER*) and EFI_HANDLE is silent.
>>
>> (The FvHasBeenProcessed() and FvIsBeingProcesssed() functions were likely
>> copied verbatim from MdeModulePkg's DXE Core and/or the SMM Core, and not
>> flagged by the compiler in StandaloneMmPkg due to UEFI regrettably
>> specifying EFI_HANDLE as (VOID*), thereby enabling the above implicit
>> conversion.)
>>
>> We should not exploit this circumstance. Represent the key type faithfully
>> instead.
>>
>> This is a semantic fix; there is no change in operation.
>>
>> Cc: Achin Gupta <achin.gupta@arm.com>
>> Cc: Jiewen Yao <jiewen.yao@intel.com>
>> Cc: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>> ---
>>
>> Notes:
>> build-tested only
>>
>> StandaloneMmPkg/Core/StandaloneMmCore.h | 2 +-
>> StandaloneMmPkg/Core/Dispatcher.c | 80 +++++++++++---------
>> StandaloneMmPkg/Core/FwVol.c | 16 ++--
>> 3 files changed, 52 insertions(+), 46 deletions(-)
>>
>> diff --git a/StandaloneMmPkg/Core/StandaloneMmCore.h b/StandaloneMmPkg/Core/StandaloneMmCore.h
>> index dcf91bc5e916..23ddbe169faf 100644
>> --- a/StandaloneMmPkg/Core/StandaloneMmCore.h
>> +++ b/StandaloneMmPkg/Core/StandaloneMmCore.h
>> @@ -67,7 +67,7 @@ typedef struct {
>>
>> LIST_ENTRY ScheduledLink; // mScheduledQueue
>>
>> - EFI_HANDLE FvHandle;
>> + EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader;
>> EFI_GUID FileName;
>> VOID *Pe32Data;
>> UINTN Pe32DataSize;
>> diff --git a/StandaloneMmPkg/Core/Dispatcher.c b/StandaloneMmPkg/Core/Dispatcher.c
>> index 3788389f95ed..9853445a64a1 100644
>> --- a/StandaloneMmPkg/Core/Dispatcher.c
>> +++ b/StandaloneMmPkg/Core/Dispatcher.c
>> @@ -5,7 +5,7 @@
>> is added to the mDiscoveredList. The Before, and After Depex are
>> pre-processed as drivers are added to the mDiscoveredList. If an Apriori
>> file exists in the FV those drivers are addeded to the
>> - mScheduledQueue. The mFvHandleList is used to make sure a
>> + mScheduledQueue. The mFwVolList is used to make sure a
>> FV is only processed once.
>>
>> Step #2 - Dispatch. Remove driver from the mScheduledQueue and load and
>> @@ -40,13 +40,13 @@
>> //
>> // MM Dispatcher Data structures
>> //
>> -#define KNOWN_HANDLE_SIGNATURE SIGNATURE_32('k','n','o','w')
>> +#define KNOWN_FWVOL_SIGNATURE SIGNATURE_32('k','n','o','w')
>>
>> typedef struct {
>> - UINTN Signature;
>> - LIST_ENTRY Link; // mFvHandleList
>> - EFI_HANDLE Handle;
>> -} KNOWN_HANDLE;
>> + UINTN Signature;
>> + LIST_ENTRY Link; // mFwVolList
>> + EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader;
>> +} KNOWN_FWVOL;
>>
>> //
>> // Function Prototypes
>> @@ -86,9 +86,10 @@ LIST_ENTRY mDiscoveredList = INITIALIZE_LIST_HEAD_VARIABLE (mDiscoveredList);
>> LIST_ENTRY mScheduledQueue = INITIALIZE_LIST_HEAD_VARIABLE (mScheduledQueue);
>>
>> //
>> -// List of handles who's Fv's have been parsed and added to the mFwDriverList.
>> +// List of firmware volume headers whose containing firmware volumes have been
>> +// parsed and added to the mFwDriverList.
>> //
>> -LIST_ENTRY mFvHandleList = INITIALIZE_LIST_HEAD_VARIABLE (mFvHandleList);
>> +LIST_ENTRY mFwVolList = INITIALIZE_LIST_HEAD_VARIABLE (mFwVolList);
>>
>> //
>> // Flag for the MM Dispacher. TRUE if dispatcher is execuing.
>> @@ -769,26 +770,30 @@ MmInsertOnScheduledQueueWhileProcessingBeforeAndAfter (
>> }
>>
>> /**
>> - Return TRUE if the Fv has been processed, FALSE if not.
>> + Return TRUE if the firmware volume has been processed, FALSE if not.
>>
>> - @param FvHandle The handle of a FV that's being tested
>> + @param FwVolHeader The header of the firmware volume that's being
>> + tested.
>>
>> - @retval TRUE Fv protocol on FvHandle has been processed
>> - @retval FALSE Fv protocol on FvHandle has not yet been
>> - processed
>> + @retval TRUE The firmware volume denoted by FwVolHeader has
>> + been processed
>> + @retval FALSE The firmware volume denoted by FwVolHeader has
>> + not yet been processed
>>
>> **/
>> BOOLEAN
>> FvHasBeenProcessed (
>> - IN EFI_HANDLE FvHandle
>> + IN EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader
>> )
>> {
>> LIST_ENTRY *Link;
>> - KNOWN_HANDLE *KnownHandle;
>> + KNOWN_FWVOL *KnownFwVol;
>>
>> - for (Link = mFvHandleList.ForwardLink; Link != &mFvHandleList; Link = Link->ForwardLink) {
>> - KnownHandle = CR (Link, KNOWN_HANDLE, Link, KNOWN_HANDLE_SIGNATURE);
>> - if (KnownHandle->Handle == FvHandle) {
>> + for (Link = mFwVolList.ForwardLink;
>> + Link != &mFwVolList;
>> + Link = Link->ForwardLink) {
>> + KnownFwVol = CR (Link, KNOWN_FWVOL, Link, KNOWN_FWVOL_SIGNATURE);
>> + if (KnownFwVol->FwVolHeader == FwVolHeader) {
>> return TRUE;
>> }
>> }
>> @@ -796,28 +801,29 @@ FvHasBeenProcessed (
>> }
>>
>> /**
>> - Remember that Fv protocol on FvHandle has had it's drivers placed on the
>> - mDiscoveredList. This fucntion adds entries on the mFvHandleList. Items are
>> - never removed/freed from the mFvHandleList.
>> + Remember that the firmware volume denoted by FwVolHeader has had its drivers
>> + placed on mDiscoveredList. This function adds entries to mFwVolList. Items
>> + are never removed/freed from mFwVolList.
>>
>> - @param FvHandle The handle of a FV that has been processed
>> + @param FwVolHeader The header of the firmware volume that's being
>> + processed.
>>
>> **/
>> VOID
>> FvIsBeingProcesssed (
>> - IN EFI_HANDLE FvHandle
>> + IN EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader
>> )
>> {
>> - KNOWN_HANDLE *KnownHandle;
>> + KNOWN_FWVOL *KnownFwVol;
>>
>> - DEBUG ((DEBUG_INFO, "FvIsBeingProcesssed - 0x%08x\n", FvHandle));
>> + DEBUG ((DEBUG_INFO, "FvIsBeingProcesssed - 0x%08x\n", KnownFwVol));
>>
>> - KnownHandle = AllocatePool (sizeof (KNOWN_HANDLE));
>> - ASSERT (KnownHandle != NULL);
>> + KnownFwVol = AllocatePool (sizeof (KNOWN_FWVOL));
>> + ASSERT (KnownFwVol != NULL);
>>
>> - KnownHandle->Signature = KNOWN_HANDLE_SIGNATURE;
>> - KnownHandle->Handle = FvHandle;
>> - InsertTailList (&mFvHandleList, &KnownHandle->Link);
>> + KnownFwVol->Signature = KNOWN_FWVOL_SIGNATURE;
>> + KnownFwVol->FwVolHeader = FwVolHeader;
>> + InsertTailList (&mFwVolList, &KnownFwVol->Link);
>> }
>>
>> /**
>> @@ -842,12 +848,12 @@ FvIsBeingProcesssed (
>> **/
>> EFI_STATUS
>> MmAddToDriverList (
>> - IN EFI_HANDLE FvHandle,
>> - IN VOID *Pe32Data,
>> - IN UINTN Pe32DataSize,
>> - IN VOID *Depex,
>> - IN UINTN DepexSize,
>> - IN EFI_GUID *DriverName
>> + IN EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader,
>> + IN VOID *Pe32Data,
>> + IN UINTN Pe32DataSize,
>> + IN VOID *Depex,
>> + IN UINTN DepexSize,
>> + IN EFI_GUID *DriverName
>> )
>> {
>> EFI_MM_DRIVER_ENTRY *DriverEntry;
>> @@ -863,7 +869,7 @@ MmAddToDriverList (
>>
>> DriverEntry->Signature = EFI_MM_DRIVER_ENTRY_SIGNATURE;
>> CopyGuid (&DriverEntry->FileName, DriverName);
>> - DriverEntry->FvHandle = FvHandle;
>> + DriverEntry->FwVolHeader = FwVolHeader;
>> DriverEntry->Pe32Data = Pe32Data;
>> DriverEntry->Pe32DataSize = Pe32DataSize;
>> DriverEntry->Depex = Depex;
>> diff --git a/StandaloneMmPkg/Core/FwVol.c b/StandaloneMmPkg/Core/FwVol.c
>> index 9fe0c257a43a..99ecf4af4714 100644
>> --- a/StandaloneMmPkg/Core/FwVol.c
>> +++ b/StandaloneMmPkg/Core/FwVol.c
>> @@ -24,22 +24,22 @@ EFI_FV_FILETYPE mMmFileTypes[] = {
>>
>> EFI_STATUS
>> MmAddToDriverList (
>> - IN EFI_HANDLE FvHandle,
>> - IN VOID *Pe32Data,
>> - IN UINTN Pe32DataSize,
>> - IN VOID *Depex,
>> - IN UINTN DepexSize,
>> - IN EFI_GUID *DriverName
>> + IN EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader,
>> + IN VOID *Pe32Data,
>> + IN UINTN Pe32DataSize,
>> + IN VOID *Depex,
>> + IN UINTN DepexSize,
>> + IN EFI_GUID *DriverName
>> );
>>
>> BOOLEAN
>> FvHasBeenProcessed (
>> - IN EFI_HANDLE FvHandle
>> + IN EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader
>> );
>>
>> VOID
>> FvIsBeingProcesssed (
>> - IN EFI_HANDLE FvHandle
>> + IN EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader
>> );
>>
>> EFI_STATUS
>>
>
>
>
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 33/35] StandaloneMmPkg/Core: stop abusing EFI_HANDLE for FwVolHeader tracking
2019-10-03 11:10 ` Laszlo Ersek
@ 2019-10-03 11:17 ` Achin Gupta
2019-10-04 0:10 ` Yao, Jiewen
2019-10-04 14:53 ` Achin Gupta
2 siblings, 0 replies; 155+ messages in thread
From: Achin Gupta @ 2019-10-03 11:17 UTC (permalink / raw)
To: devel@edk2.groups.io, lersek@redhat.com
Cc: Jiewen Yao, Supreeth Venkatesh, nd
Hi Laszlo,
Apologies for not getting back earlier as I was travelling. I will have a look
and get back by tomorrow.
cheers,
Achin
On Thu, Oct 03, 2019 at 01:10:53PM +0200, Laszlo Ersek wrote:
> Pinging StandaloneMmPkg maintainers again, for reviewing this patch.
>
> Thanks
> Laszlo
>
> On 09/26/19 14:48, Laszlo Ersek wrote:
> > Achin, Jiewen, Supreeth,
> >
> > can one of you guys please review this patch?
> >
> > Thanks
> > Laszlo
> >
> > On 09/17/19 21:49, Laszlo Ersek wrote:
> >> The FvHasBeenProcessed() and FvIsBeingProcesssed() functions make sure
> >> that every firmware volume is processed only once (every driver in every
> >> firmware volume should be discovered only once). For this, the functions
> >> use a linked list.
> >>
> >> In MdeModulePkg's DXE Core and SMM Core, the key used for identifying
> >> those firmware volumes that have been processed is the EFI_HANDLE on which
> >> the DXE or SMM firmware volume protocol is installed. In the
> >> StandaloneMmPkg core however, the key is the address of the firmware
> >> volume header; that is, it has type (EFI_FIRMWARE_VOLUME_HEADER*).
> >>
> >> (EFI_FIRMWARE_VOLUME_HEADER*) has nothing to do with EFI_HANDLE.
> >> EFI_HANDLE just happens to be specified as (VOID*), and therefore the
> >> conversion between (EFI_FIRMWARE_VOLUME_HEADER*) and EFI_HANDLE is silent.
> >>
> >> (The FvHasBeenProcessed() and FvIsBeingProcesssed() functions were likely
> >> copied verbatim from MdeModulePkg's DXE Core and/or the SMM Core, and not
> >> flagged by the compiler in StandaloneMmPkg due to UEFI regrettably
> >> specifying EFI_HANDLE as (VOID*), thereby enabling the above implicit
> >> conversion.)
> >>
> >> We should not exploit this circumstance. Represent the key type faithfully
> >> instead.
> >>
> >> This is a semantic fix; there is no change in operation.
> >>
> >> Cc: Achin Gupta <achin.gupta@arm.com>
> >> Cc: Jiewen Yao <jiewen.yao@intel.com>
> >> Cc: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
> >> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> >> ---
> >>
> >> Notes:
> >> build-tested only
> >>
> >> StandaloneMmPkg/Core/StandaloneMmCore.h | 2 +-
> >> StandaloneMmPkg/Core/Dispatcher.c | 80 +++++++++++---------
> >> StandaloneMmPkg/Core/FwVol.c | 16 ++--
> >> 3 files changed, 52 insertions(+), 46 deletions(-)
> >>
> >> diff --git a/StandaloneMmPkg/Core/StandaloneMmCore.h b/StandaloneMmPkg/Core/StandaloneMmCore.h
> >> index dcf91bc5e916..23ddbe169faf 100644
> >> --- a/StandaloneMmPkg/Core/StandaloneMmCore.h
> >> +++ b/StandaloneMmPkg/Core/StandaloneMmCore.h
> >> @@ -67,7 +67,7 @@ typedef struct {
> >>
> >> LIST_ENTRY ScheduledLink; // mScheduledQueue
> >>
> >> - EFI_HANDLE FvHandle;
> >> + EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader;
> >> EFI_GUID FileName;
> >> VOID *Pe32Data;
> >> UINTN Pe32DataSize;
> >> diff --git a/StandaloneMmPkg/Core/Dispatcher.c b/StandaloneMmPkg/Core/Dispatcher.c
> >> index 3788389f95ed..9853445a64a1 100644
> >> --- a/StandaloneMmPkg/Core/Dispatcher.c
> >> +++ b/StandaloneMmPkg/Core/Dispatcher.c
> >> @@ -5,7 +5,7 @@
> >> is added to the mDiscoveredList. The Before, and After Depex are
> >> pre-processed as drivers are added to the mDiscoveredList. If an Apriori
> >> file exists in the FV those drivers are addeded to the
> >> - mScheduledQueue. The mFvHandleList is used to make sure a
> >> + mScheduledQueue. The mFwVolList is used to make sure a
> >> FV is only processed once.
> >>
> >> Step #2 - Dispatch. Remove driver from the mScheduledQueue and load and
> >> @@ -40,13 +40,13 @@
> >> //
> >> // MM Dispatcher Data structures
> >> //
> >> -#define KNOWN_HANDLE_SIGNATURE SIGNATURE_32('k','n','o','w')
> >> +#define KNOWN_FWVOL_SIGNATURE SIGNATURE_32('k','n','o','w')
> >>
> >> typedef struct {
> >> - UINTN Signature;
> >> - LIST_ENTRY Link; // mFvHandleList
> >> - EFI_HANDLE Handle;
> >> -} KNOWN_HANDLE;
> >> + UINTN Signature;
> >> + LIST_ENTRY Link; // mFwVolList
> >> + EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader;
> >> +} KNOWN_FWVOL;
> >>
> >> //
> >> // Function Prototypes
> >> @@ -86,9 +86,10 @@ LIST_ENTRY mDiscoveredList = INITIALIZE_LIST_HEAD_VARIABLE (mDiscoveredList);
> >> LIST_ENTRY mScheduledQueue = INITIALIZE_LIST_HEAD_VARIABLE (mScheduledQueue);
> >>
> >> //
> >> -// List of handles who's Fv's have been parsed and added to the mFwDriverList.
> >> +// List of firmware volume headers whose containing firmware volumes have been
> >> +// parsed and added to the mFwDriverList.
> >> //
> >> -LIST_ENTRY mFvHandleList = INITIALIZE_LIST_HEAD_VARIABLE (mFvHandleList);
> >> +LIST_ENTRY mFwVolList = INITIALIZE_LIST_HEAD_VARIABLE (mFwVolList);
> >>
> >> //
> >> // Flag for the MM Dispacher. TRUE if dispatcher is execuing.
> >> @@ -769,26 +770,30 @@ MmInsertOnScheduledQueueWhileProcessingBeforeAndAfter (
> >> }
> >>
> >> /**
> >> - Return TRUE if the Fv has been processed, FALSE if not.
> >> + Return TRUE if the firmware volume has been processed, FALSE if not.
> >>
> >> - @param FvHandle The handle of a FV that's being tested
> >> + @param FwVolHeader The header of the firmware volume that's being
> >> + tested.
> >>
> >> - @retval TRUE Fv protocol on FvHandle has been processed
> >> - @retval FALSE Fv protocol on FvHandle has not yet been
> >> - processed
> >> + @retval TRUE The firmware volume denoted by FwVolHeader has
> >> + been processed
> >> + @retval FALSE The firmware volume denoted by FwVolHeader has
> >> + not yet been processed
> >>
> >> **/
> >> BOOLEAN
> >> FvHasBeenProcessed (
> >> - IN EFI_HANDLE FvHandle
> >> + IN EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader
> >> )
> >> {
> >> LIST_ENTRY *Link;
> >> - KNOWN_HANDLE *KnownHandle;
> >> + KNOWN_FWVOL *KnownFwVol;
> >>
> >> - for (Link = mFvHandleList.ForwardLink; Link != &mFvHandleList; Link = Link->ForwardLink) {
> >> - KnownHandle = CR (Link, KNOWN_HANDLE, Link, KNOWN_HANDLE_SIGNATURE);
> >> - if (KnownHandle->Handle == FvHandle) {
> >> + for (Link = mFwVolList.ForwardLink;
> >> + Link != &mFwVolList;
> >> + Link = Link->ForwardLink) {
> >> + KnownFwVol = CR (Link, KNOWN_FWVOL, Link, KNOWN_FWVOL_SIGNATURE);
> >> + if (KnownFwVol->FwVolHeader == FwVolHeader) {
> >> return TRUE;
> >> }
> >> }
> >> @@ -796,28 +801,29 @@ FvHasBeenProcessed (
> >> }
> >>
> >> /**
> >> - Remember that Fv protocol on FvHandle has had it's drivers placed on the
> >> - mDiscoveredList. This fucntion adds entries on the mFvHandleList. Items are
> >> - never removed/freed from the mFvHandleList.
> >> + Remember that the firmware volume denoted by FwVolHeader has had its drivers
> >> + placed on mDiscoveredList. This function adds entries to mFwVolList. Items
> >> + are never removed/freed from mFwVolList.
> >>
> >> - @param FvHandle The handle of a FV that has been processed
> >> + @param FwVolHeader The header of the firmware volume that's being
> >> + processed.
> >>
> >> **/
> >> VOID
> >> FvIsBeingProcesssed (
> >> - IN EFI_HANDLE FvHandle
> >> + IN EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader
> >> )
> >> {
> >> - KNOWN_HANDLE *KnownHandle;
> >> + KNOWN_FWVOL *KnownFwVol;
> >>
> >> - DEBUG ((DEBUG_INFO, "FvIsBeingProcesssed - 0x%08x\n", FvHandle));
> >> + DEBUG ((DEBUG_INFO, "FvIsBeingProcesssed - 0x%08x\n", KnownFwVol));
> >>
> >> - KnownHandle = AllocatePool (sizeof (KNOWN_HANDLE));
> >> - ASSERT (KnownHandle != NULL);
> >> + KnownFwVol = AllocatePool (sizeof (KNOWN_FWVOL));
> >> + ASSERT (KnownFwVol != NULL);
> >>
> >> - KnownHandle->Signature = KNOWN_HANDLE_SIGNATURE;
> >> - KnownHandle->Handle = FvHandle;
> >> - InsertTailList (&mFvHandleList, &KnownHandle->Link);
> >> + KnownFwVol->Signature = KNOWN_FWVOL_SIGNATURE;
> >> + KnownFwVol->FwVolHeader = FwVolHeader;
> >> + InsertTailList (&mFwVolList, &KnownFwVol->Link);
> >> }
> >>
> >> /**
> >> @@ -842,12 +848,12 @@ FvIsBeingProcesssed (
> >> **/
> >> EFI_STATUS
> >> MmAddToDriverList (
> >> - IN EFI_HANDLE FvHandle,
> >> - IN VOID *Pe32Data,
> >> - IN UINTN Pe32DataSize,
> >> - IN VOID *Depex,
> >> - IN UINTN DepexSize,
> >> - IN EFI_GUID *DriverName
> >> + IN EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader,
> >> + IN VOID *Pe32Data,
> >> + IN UINTN Pe32DataSize,
> >> + IN VOID *Depex,
> >> + IN UINTN DepexSize,
> >> + IN EFI_GUID *DriverName
> >> )
> >> {
> >> EFI_MM_DRIVER_ENTRY *DriverEntry;
> >> @@ -863,7 +869,7 @@ MmAddToDriverList (
> >>
> >> DriverEntry->Signature = EFI_MM_DRIVER_ENTRY_SIGNATURE;
> >> CopyGuid (&DriverEntry->FileName, DriverName);
> >> - DriverEntry->FvHandle = FvHandle;
> >> + DriverEntry->FwVolHeader = FwVolHeader;
> >> DriverEntry->Pe32Data = Pe32Data;
> >> DriverEntry->Pe32DataSize = Pe32DataSize;
> >> DriverEntry->Depex = Depex;
> >> diff --git a/StandaloneMmPkg/Core/FwVol.c b/StandaloneMmPkg/Core/FwVol.c
> >> index 9fe0c257a43a..99ecf4af4714 100644
> >> --- a/StandaloneMmPkg/Core/FwVol.c
> >> +++ b/StandaloneMmPkg/Core/FwVol.c
> >> @@ -24,22 +24,22 @@ EFI_FV_FILETYPE mMmFileTypes[] = {
> >>
> >> EFI_STATUS
> >> MmAddToDriverList (
> >> - IN EFI_HANDLE FvHandle,
> >> - IN VOID *Pe32Data,
> >> - IN UINTN Pe32DataSize,
> >> - IN VOID *Depex,
> >> - IN UINTN DepexSize,
> >> - IN EFI_GUID *DriverName
> >> + IN EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader,
> >> + IN VOID *Pe32Data,
> >> + IN UINTN Pe32DataSize,
> >> + IN VOID *Depex,
> >> + IN UINTN DepexSize,
> >> + IN EFI_GUID *DriverName
> >> );
> >>
> >> BOOLEAN
> >> FvHasBeenProcessed (
> >> - IN EFI_HANDLE FvHandle
> >> + IN EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader
> >> );
> >>
> >> VOID
> >> FvIsBeingProcesssed (
> >> - IN EFI_HANDLE FvHandle
> >> + IN EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader
> >> );
> >>
> >> EFI_STATUS
> >>
> >
> >
> >
> >
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 26/35] SecurityPkg: fix UninstallMultipleProtocolInterfaces() calls
2019-10-03 11:06 ` Laszlo Ersek
@ 2019-10-04 0:05 ` Yao, Jiewen
2019-10-04 13:14 ` Zhang, Chao B
2019-10-05 14:28 ` Zhang, Chao B
2 siblings, 0 replies; 155+ messages in thread
From: Yao, Jiewen @ 2019-10-04 0:05 UTC (permalink / raw)
To: devel@edk2.groups.io, lersek@redhat.com, Zhang, Chao B,
Wang, Jian J
Good catch!
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
> -----Original Message-----
> From: Laszlo Ersek <lersek@redhat.com>
> Sent: Thursday, October 3, 2019 7:07 PM
> To: Zhang, Chao B <chao.b.zhang@intel.com>; Wang, Jian J
> <jian.j.wang@intel.com>; Yao, Jiewen <jiewen.yao@intel.com>
> Cc: edk2-devel-groups-io <devel@edk2.groups.io>
> Subject: Re: [edk2-devel] [PATCH 26/35] SecurityPkg: fix
> UninstallMultipleProtocolInterfaces() calls
>
> Pinging SecurityPkg maintainers again, for reviewing this patch.
>
> Thanks
> Laszlo
>
> On 09/26/19 14:45, Laszlo Ersek wrote:
> > Chao, Jian, Jiewen,
> >
> > can you please review this patch?
> >
> > Thanks,
> > Laszlo
> >
> > On 09/17/19 21:49, Laszlo Ersek wrote:
> >> Unlike the InstallMultipleProtocolInterfaces() boot service, which takes
> >> an (EFI_HANDLE*) as first parameter, the
> >> UninstallMultipleProtocolInterfaces() boot service takes an EFI_HANDLE as
> >> first parameter.
> >>
> >> These are actual bugs. They must have remained hidden until now because
> >> they are all in Unload() functions, which are probably exercised
> >> infrequently. Fix the UninstallMultipleProtocolInterfaces() calls.
> >>
> >> Cc: Chao Zhang <chao.b.zhang@intel.com>
> >> Cc: Jian Wang <jian.j.wang@intel.com>
> >> Cc: Jiewen Yao <jiewen.yao@intel.com>
> >> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> >> ---
> >>
> >> Notes:
> >> build-tested only
> >>
> >> SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c | 2 +-
> >> SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c | 2 +-
> >>
> SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDri
> ver.c | 2 +-
> >> 3 files changed, 3 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c
> b/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c
> >> index 54155a338100..9052eced757d 100644
> >> --- a/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c
> >> +++ b/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c
> >> @@ -443,7 +443,7 @@ Tcg2ConfigDriverUnload (
> >> ASSERT (PrivateData->Signature ==
> TCG2_CONFIG_PRIVATE_DATA_SIGNATURE);
> >>
> >> gBS->UninstallMultipleProtocolInterfaces (
> >> - &ImageHandle,
> >> + ImageHandle,
> >> &gEfiCallerIdGuid,
> >> PrivateData,
> >> NULL
> >> diff --git a/SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c
> b/SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c
> >> index 341879e4c4ba..fb06624fdb8f 100644
> >> --- a/SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c
> >> +++ b/SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c
> >> @@ -138,7 +138,7 @@ TcgConfigDriverUnload (
> >> ASSERT (PrivateData->Signature ==
> TCG_CONFIG_PRIVATE_DATA_SIGNATURE);
> >>
> >> gBS->UninstallMultipleProtocolInterfaces (
> >> - &ImageHandle,
> >> + ImageHandle,
> >> &gEfiCallerIdGuid,
> >> PrivateData,
> >> NULL
> >> diff --git
> a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfig
> Driver.c
> b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfig
> Driver.c
> >> index 798ef9cfbc01..6c0294151e6c 100644
> >> ---
> a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfig
> Driver.c
> >> +++
> b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfig
> Driver.c
> >> @@ -115,7 +115,7 @@ SecureBootConfigDriverUnload (
> >> ASSERT (PrivateData->Signature ==
> SECUREBOOT_CONFIG_PRIVATE_DATA_SIGNATURE);
> >>
> >> gBS->UninstallMultipleProtocolInterfaces (
> >> - &ImageHandle,
> >> + ImageHandle,
> >> &gEfiCallerIdGuid,
> >> PrivateData,
> >> NULL
> >>
> >
> >
> >
> >
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 27/35] SecurityPkg: stop abusing EFI_EVENT for protocol notify registration
2019-10-03 11:06 ` Laszlo Ersek
@ 2019-10-04 0:05 ` Yao, Jiewen
2019-10-04 13:16 ` Zhang, Chao B
2019-10-05 14:28 ` Zhang, Chao B
2 siblings, 0 replies; 155+ messages in thread
From: Yao, Jiewen @ 2019-10-04 0:05 UTC (permalink / raw)
To: devel@edk2.groups.io, lersek@redhat.com, Zhang, Chao B,
Wang, Jian J
Good catch!
Reviewed by: Jiewen Yao <Jiewen.yao@intel.com>
> -----Original Message-----
> From: Laszlo Ersek <lersek@redhat.com>
> Sent: Thursday, October 3, 2019 7:07 PM
> To: Zhang, Chao B <chao.b.zhang@intel.com>; Wang, Jian J
> <jian.j.wang@intel.com>; Yao, Jiewen <jiewen.yao@intel.com>
> Cc: edk2-devel-groups-io <devel@edk2.groups.io>
> Subject: Re: [edk2-devel] [PATCH 27/35] SecurityPkg: stop abusing EFI_EVENT
> for protocol notify registration
>
> Pinging SecurityPkg maintainers again, for reviewing this patch.
>
> Thanks
> Laszlo
>
> On 09/26/19 14:46, Laszlo Ersek wrote:
> > Chao, Jian, Jiewen,
> >
> > can you please review this patch?
> >
> > Thanks,
> > Laszlo
> >
> >
> > On 09/17/19 21:49, Laszlo Ersek wrote:
> >> EfiCreateProtocolNotifyEvent() takes a (VOID**) for "Registration",
> >> similarly to gBS->RegisterProtocolNotify(). We should pass the address of
> >> an actual pointer-to-VOID, and not the address of an EFI_EVENT. EFI_EVENT
> >> just happens to be specified as (VOID*), and has nothing to do with the
> >> registration.
> >>
> >> This change is a no-op in practice; it's a semantic improvement.
> >>
> >> Cc: Chao Zhang <chao.b.zhang@intel.com>
> >> Cc: Jian Wang <jian.j.wang@intel.com>
> >> Cc: Jiewen Yao <jiewen.yao@intel.com>
> >> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> >> ---
> >>
> >> Notes:
> >> build-tested only
> >>
> >> SecurityPkg/HddPassword/HddPasswordDxe.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/SecurityPkg/HddPassword/HddPasswordDxe.c
> b/SecurityPkg/HddPassword/HddPasswordDxe.c
> >> index b0d795b6597f..051e64091d7f 100644
> >> --- a/SecurityPkg/HddPassword/HddPasswordDxe.c
> >> +++ b/SecurityPkg/HddPassword/HddPasswordDxe.c
> >> @@ -2770,7 +2770,7 @@ HddPasswordDxeInit (
> >> {
> >> EFI_STATUS Status;
> >> HDD_PASSWORD_DXE_PRIVATE_DATA *Private;
> >> - EFI_EVENT Registration;
> >> + VOID *Registration;
> >> EFI_EVENT EndOfDxeEvent;
> >> EDKII_VARIABLE_LOCK_PROTOCOL *VariableLock;
> >>
> >>
> >
> >
> >
> >
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 33/35] StandaloneMmPkg/Core: stop abusing EFI_HANDLE for FwVolHeader tracking
2019-10-03 11:10 ` Laszlo Ersek
2019-10-03 11:17 ` Achin Gupta
@ 2019-10-04 0:10 ` Yao, Jiewen
2019-10-04 14:53 ` Achin Gupta
2 siblings, 0 replies; 155+ messages in thread
From: Yao, Jiewen @ 2019-10-04 0:10 UTC (permalink / raw)
To: devel@edk2.groups.io, lersek@redhat.com, Achin Gupta,
Supreeth Venkatesh
Good catch.
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Laszlo Ersek
> Sent: Thursday, October 3, 2019 7:11 PM
> To: Achin Gupta <achin.gupta@arm.com>; Yao, Jiewen
> <jiewen.yao@intel.com>; Supreeth Venkatesh <supreeth.venkatesh@arm.com>
> Cc: edk2-devel-groups-io <devel@edk2.groups.io>
> Subject: Re: [edk2-devel] [PATCH 33/35] StandaloneMmPkg/Core: stop abusing
> EFI_HANDLE for FwVolHeader tracking
>
> Pinging StandaloneMmPkg maintainers again, for reviewing this patch.
>
> Thanks
> Laszlo
>
> On 09/26/19 14:48, Laszlo Ersek wrote:
> > Achin, Jiewen, Supreeth,
> >
> > can one of you guys please review this patch?
> >
> > Thanks
> > Laszlo
> >
> > On 09/17/19 21:49, Laszlo Ersek wrote:
> >> The FvHasBeenProcessed() and FvIsBeingProcesssed() functions make sure
> >> that every firmware volume is processed only once (every driver in every
> >> firmware volume should be discovered only once). For this, the functions
> >> use a linked list.
> >>
> >> In MdeModulePkg's DXE Core and SMM Core, the key used for identifying
> >> those firmware volumes that have been processed is the EFI_HANDLE on
> which
> >> the DXE or SMM firmware volume protocol is installed. In the
> >> StandaloneMmPkg core however, the key is the address of the firmware
> >> volume header; that is, it has type (EFI_FIRMWARE_VOLUME_HEADER*).
> >>
> >> (EFI_FIRMWARE_VOLUME_HEADER*) has nothing to do with EFI_HANDLE.
> >> EFI_HANDLE just happens to be specified as (VOID*), and therefore the
> >> conversion between (EFI_FIRMWARE_VOLUME_HEADER*) and EFI_HANDLE
> is silent.
> >>
> >> (The FvHasBeenProcessed() and FvIsBeingProcesssed() functions were likely
> >> copied verbatim from MdeModulePkg's DXE Core and/or the SMM Core, and
> not
> >> flagged by the compiler in StandaloneMmPkg due to UEFI regrettably
> >> specifying EFI_HANDLE as (VOID*), thereby enabling the above implicit
> >> conversion.)
> >>
> >> We should not exploit this circumstance. Represent the key type faithfully
> >> instead.
> >>
> >> This is a semantic fix; there is no change in operation.
> >>
> >> Cc: Achin Gupta <achin.gupta@arm.com>
> >> Cc: Jiewen Yao <jiewen.yao@intel.com>
> >> Cc: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
> >> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> >> ---
> >>
> >> Notes:
> >> build-tested only
> >>
> >> StandaloneMmPkg/Core/StandaloneMmCore.h | 2 +-
> >> StandaloneMmPkg/Core/Dispatcher.c | 80 +++++++++++---------
> >> StandaloneMmPkg/Core/FwVol.c | 16 ++--
> >> 3 files changed, 52 insertions(+), 46 deletions(-)
> >>
> >> diff --git a/StandaloneMmPkg/Core/StandaloneMmCore.h
> b/StandaloneMmPkg/Core/StandaloneMmCore.h
> >> index dcf91bc5e916..23ddbe169faf 100644
> >> --- a/StandaloneMmPkg/Core/StandaloneMmCore.h
> >> +++ b/StandaloneMmPkg/Core/StandaloneMmCore.h
> >> @@ -67,7 +67,7 @@ typedef struct {
> >>
> >> LIST_ENTRY ScheduledLink; // mScheduledQueue
> >>
> >> - EFI_HANDLE FvHandle;
> >> + EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader;
> >> EFI_GUID FileName;
> >> VOID *Pe32Data;
> >> UINTN Pe32DataSize;
> >> diff --git a/StandaloneMmPkg/Core/Dispatcher.c
> b/StandaloneMmPkg/Core/Dispatcher.c
> >> index 3788389f95ed..9853445a64a1 100644
> >> --- a/StandaloneMmPkg/Core/Dispatcher.c
> >> +++ b/StandaloneMmPkg/Core/Dispatcher.c
> >> @@ -5,7 +5,7 @@
> >> is added to the mDiscoveredList. The Before, and After Depex are
> >> pre-processed as drivers are added to the mDiscoveredList. If an
> Apriori
> >> file exists in the FV those drivers are addeded to the
> >> - mScheduledQueue. The mFvHandleList is used to make sure a
> >> + mScheduledQueue. The mFwVolList is used to make sure a
> >> FV is only processed once.
> >>
> >> Step #2 - Dispatch. Remove driver from the mScheduledQueue and load and
> >> @@ -40,13 +40,13 @@
> >> //
> >> // MM Dispatcher Data structures
> >> //
> >> -#define KNOWN_HANDLE_SIGNATURE SIGNATURE_32('k','n','o','w')
> >> +#define KNOWN_FWVOL_SIGNATURE SIGNATURE_32('k','n','o','w')
> >>
> >> typedef struct {
> >> - UINTN Signature;
> >> - LIST_ENTRY Link; // mFvHandleList
> >> - EFI_HANDLE Handle;
> >> -} KNOWN_HANDLE;
> >> + UINTN Signature;
> >> + LIST_ENTRY Link; // mFwVolList
> >> + EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader;
> >> +} KNOWN_FWVOL;
> >>
> >> //
> >> // Function Prototypes
> >> @@ -86,9 +86,10 @@ LIST_ENTRY mDiscoveredList =
> INITIALIZE_LIST_HEAD_VARIABLE (mDiscoveredList);
> >> LIST_ENTRY mScheduledQueue = INITIALIZE_LIST_HEAD_VARIABLE
> (mScheduledQueue);
> >>
> >> //
> >> -// List of handles who's Fv's have been parsed and added to the
> mFwDriverList.
> >> +// List of firmware volume headers whose containing firmware volumes
> have been
> >> +// parsed and added to the mFwDriverList.
> >> //
> >> -LIST_ENTRY mFvHandleList = INITIALIZE_LIST_HEAD_VARIABLE
> (mFvHandleList);
> >> +LIST_ENTRY mFwVolList = INITIALIZE_LIST_HEAD_VARIABLE (mFwVolList);
> >>
> >> //
> >> // Flag for the MM Dispacher. TRUE if dispatcher is execuing.
> >> @@ -769,26 +770,30 @@
> MmInsertOnScheduledQueueWhileProcessingBeforeAndAfter (
> >> }
> >>
> >> /**
> >> - Return TRUE if the Fv has been processed, FALSE if not.
> >> + Return TRUE if the firmware volume has been processed, FALSE if not.
> >>
> >> - @param FvHandle The handle of a FV that's being tested
> >> + @param FwVolHeader The header of the firmware volume that's
> being
> >> + tested.
> >>
> >> - @retval TRUE Fv protocol on FvHandle has been processed
> >> - @retval FALSE Fv protocol on FvHandle has not yet been
> >> - processed
> >> + @retval TRUE The firmware volume denoted by FwVolHeader has
> >> + been processed
> >> + @retval FALSE The firmware volume denoted by FwVolHeader has
> >> + not yet been processed
> >>
> >> **/
> >> BOOLEAN
> >> FvHasBeenProcessed (
> >> - IN EFI_HANDLE FvHandle
> >> + IN EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader
> >> )
> >> {
> >> LIST_ENTRY *Link;
> >> - KNOWN_HANDLE *KnownHandle;
> >> + KNOWN_FWVOL *KnownFwVol;
> >>
> >> - for (Link = mFvHandleList.ForwardLink; Link != &mFvHandleList; Link = Link-
> >ForwardLink) {
> >> - KnownHandle = CR (Link, KNOWN_HANDLE, Link,
> KNOWN_HANDLE_SIGNATURE);
> >> - if (KnownHandle->Handle == FvHandle) {
> >> + for (Link = mFwVolList.ForwardLink;
> >> + Link != &mFwVolList;
> >> + Link = Link->ForwardLink) {
> >> + KnownFwVol = CR (Link, KNOWN_FWVOL, Link,
> KNOWN_FWVOL_SIGNATURE);
> >> + if (KnownFwVol->FwVolHeader == FwVolHeader) {
> >> return TRUE;
> >> }
> >> }
> >> @@ -796,28 +801,29 @@ FvHasBeenProcessed (
> >> }
> >>
> >> /**
> >> - Remember that Fv protocol on FvHandle has had it's drivers placed on the
> >> - mDiscoveredList. This fucntion adds entries on the mFvHandleList. Items
> are
> >> - never removed/freed from the mFvHandleList.
> >> + Remember that the firmware volume denoted by FwVolHeader has had its
> drivers
> >> + placed on mDiscoveredList. This function adds entries to mFwVolList. Items
> >> + are never removed/freed from mFwVolList.
> >>
> >> - @param FvHandle The handle of a FV that has been processed
> >> + @param FwVolHeader The header of the firmware volume that's
> being
> >> + processed.
> >>
> >> **/
> >> VOID
> >> FvIsBeingProcesssed (
> >> - IN EFI_HANDLE FvHandle
> >> + IN EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader
> >> )
> >> {
> >> - KNOWN_HANDLE *KnownHandle;
> >> + KNOWN_FWVOL *KnownFwVol;
> >>
> >> - DEBUG ((DEBUG_INFO, "FvIsBeingProcesssed - 0x%08x\n", FvHandle));
> >> + DEBUG ((DEBUG_INFO, "FvIsBeingProcesssed - 0x%08x\n", KnownFwVol));
> >>
> >> - KnownHandle = AllocatePool (sizeof (KNOWN_HANDLE));
> >> - ASSERT (KnownHandle != NULL);
> >> + KnownFwVol = AllocatePool (sizeof (KNOWN_FWVOL));
> >> + ASSERT (KnownFwVol != NULL);
> >>
> >> - KnownHandle->Signature = KNOWN_HANDLE_SIGNATURE;
> >> - KnownHandle->Handle = FvHandle;
> >> - InsertTailList (&mFvHandleList, &KnownHandle->Link);
> >> + KnownFwVol->Signature = KNOWN_FWVOL_SIGNATURE;
> >> + KnownFwVol->FwVolHeader = FwVolHeader;
> >> + InsertTailList (&mFwVolList, &KnownFwVol->Link);
> >> }
> >>
> >> /**
> >> @@ -842,12 +848,12 @@ FvIsBeingProcesssed (
> >> **/
> >> EFI_STATUS
> >> MmAddToDriverList (
> >> - IN EFI_HANDLE FvHandle,
> >> - IN VOID *Pe32Data,
> >> - IN UINTN Pe32DataSize,
> >> - IN VOID *Depex,
> >> - IN UINTN DepexSize,
> >> - IN EFI_GUID *DriverName
> >> + IN EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader,
> >> + IN VOID *Pe32Data,
> >> + IN UINTN Pe32DataSize,
> >> + IN VOID *Depex,
> >> + IN UINTN DepexSize,
> >> + IN EFI_GUID *DriverName
> >> )
> >> {
> >> EFI_MM_DRIVER_ENTRY *DriverEntry;
> >> @@ -863,7 +869,7 @@ MmAddToDriverList (
> >>
> >> DriverEntry->Signature = EFI_MM_DRIVER_ENTRY_SIGNATURE;
> >> CopyGuid (&DriverEntry->FileName, DriverName);
> >> - DriverEntry->FvHandle = FvHandle;
> >> + DriverEntry->FwVolHeader = FwVolHeader;
> >> DriverEntry->Pe32Data = Pe32Data;
> >> DriverEntry->Pe32DataSize = Pe32DataSize;
> >> DriverEntry->Depex = Depex;
> >> diff --git a/StandaloneMmPkg/Core/FwVol.c
> b/StandaloneMmPkg/Core/FwVol.c
> >> index 9fe0c257a43a..99ecf4af4714 100644
> >> --- a/StandaloneMmPkg/Core/FwVol.c
> >> +++ b/StandaloneMmPkg/Core/FwVol.c
> >> @@ -24,22 +24,22 @@ EFI_FV_FILETYPE mMmFileTypes[] = {
> >>
> >> EFI_STATUS
> >> MmAddToDriverList (
> >> - IN EFI_HANDLE FvHandle,
> >> - IN VOID *Pe32Data,
> >> - IN UINTN Pe32DataSize,
> >> - IN VOID *Depex,
> >> - IN UINTN DepexSize,
> >> - IN EFI_GUID *DriverName
> >> + IN EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader,
> >> + IN VOID *Pe32Data,
> >> + IN UINTN Pe32DataSize,
> >> + IN VOID *Depex,
> >> + IN UINTN DepexSize,
> >> + IN EFI_GUID *DriverName
> >> );
> >>
> >> BOOLEAN
> >> FvHasBeenProcessed (
> >> - IN EFI_HANDLE FvHandle
> >> + IN EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader
> >> );
> >>
> >> VOID
> >> FvIsBeingProcesssed (
> >> - IN EFI_HANDLE FvHandle
> >> + IN EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader
> >> );
> >>
> >> EFI_STATUS
> >>
> >
> >
> >
> >
>
>
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 26/35] SecurityPkg: fix UninstallMultipleProtocolInterfaces() calls
2019-10-03 11:06 ` Laszlo Ersek
2019-10-04 0:05 ` Yao, Jiewen
@ 2019-10-04 13:14 ` Zhang, Chao B
2019-10-04 18:15 ` Laszlo Ersek
2019-10-05 14:28 ` Zhang, Chao B
2 siblings, 1 reply; 155+ messages in thread
From: Zhang, Chao B @ 2019-10-04 13:14 UTC (permalink / raw)
To: devel@edk2.groups.io, lersek@redhat.com, Wang, Jian J,
Yao, Jiewen
Hi Laszlo:
Sorry for late response. The fix is good to me. I am also interested in how you find this issue, can you share it?
-----Original Message-----
From: Laszlo Ersek [mailto:lersek@redhat.com]
Sent: 2019年10月3日 19:07
To: Zhang, Chao B <chao.b.zhang@intel.com>; Wang, Jian J <jian.j.wang@intel.com>; Yao, Jiewen <jiewen.yao@intel.com>
Cc: edk2-devel-groups-io <devel@edk2.groups.io>
Subject: Re: [edk2-devel] [PATCH 26/35] SecurityPkg: fix UninstallMultipleProtocolInterfaces() calls
Pinging SecurityPkg maintainers again, for reviewing this patch.
Thanks
Laszlo
On 09/26/19 14:45, Laszlo Ersek wrote:
> Chao, Jian, Jiewen,
>
> can you please review this patch?
>
> Thanks,
> Laszlo
>
> On 09/17/19 21:49, Laszlo Ersek wrote:
>> Unlike the InstallMultipleProtocolInterfaces() boot service, which
>> takes an (EFI_HANDLE*) as first parameter, the
>> UninstallMultipleProtocolInterfaces() boot service takes an
>> EFI_HANDLE as first parameter.
>>
>> These are actual bugs. They must have remained hidden until now
>> because they are all in Unload() functions, which are probably
>> exercised infrequently. Fix the UninstallMultipleProtocolInterfaces() calls.
>>
>> Cc: Chao Zhang <chao.b.zhang@intel.com>
>> Cc: Jian Wang <jian.j.wang@intel.com>
>> Cc: Jiewen Yao <jiewen.yao@intel.com>
>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>> ---
>>
>> Notes:
>> build-tested only
>>
>> SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c | 2 +-
>> SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c | 2 +-
>>
>> SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfi
>> gDriver.c | 2 +-
>> 3 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c
>> b/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c
>> index 54155a338100..9052eced757d 100644
>> --- a/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c
>> +++ b/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c
>> @@ -443,7 +443,7 @@ Tcg2ConfigDriverUnload (
>> ASSERT (PrivateData->Signature ==
>> TCG2_CONFIG_PRIVATE_DATA_SIGNATURE);
>>
>> gBS->UninstallMultipleProtocolInterfaces (
>> - &ImageHandle,
>> + ImageHandle,
>> &gEfiCallerIdGuid,
>> PrivateData,
>> NULL
>> diff --git a/SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c
>> b/SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c
>> index 341879e4c4ba..fb06624fdb8f 100644
>> --- a/SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c
>> +++ b/SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c
>> @@ -138,7 +138,7 @@ TcgConfigDriverUnload (
>> ASSERT (PrivateData->Signature ==
>> TCG_CONFIG_PRIVATE_DATA_SIGNATURE);
>>
>> gBS->UninstallMultipleProtocolInterfaces (
>> - &ImageHandle,
>> + ImageHandle,
>> &gEfiCallerIdGuid,
>> PrivateData,
>> NULL
>> diff --git
>> a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootCon
>> figDriver.c
>> b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootCon
>> figDriver.c index 798ef9cfbc01..6c0294151e6c 100644
>> ---
>> a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootCon
>> figDriver.c
>> +++ b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBoo
>> +++ tConfigDriver.c
>> @@ -115,7 +115,7 @@ SecureBootConfigDriverUnload (
>> ASSERT (PrivateData->Signature ==
>> SECUREBOOT_CONFIG_PRIVATE_DATA_SIGNATURE);
>>
>> gBS->UninstallMultipleProtocolInterfaces (
>> - &ImageHandle,
>> + ImageHandle,
>> &gEfiCallerIdGuid,
>> PrivateData,
>> NULL
>>
>
>
>
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 27/35] SecurityPkg: stop abusing EFI_EVENT for protocol notify registration
2019-10-03 11:06 ` Laszlo Ersek
2019-10-04 0:05 ` Yao, Jiewen
@ 2019-10-04 13:16 ` Zhang, Chao B
2019-10-05 14:28 ` Zhang, Chao B
2 siblings, 0 replies; 155+ messages in thread
From: Zhang, Chao B @ 2019-10-04 13:16 UTC (permalink / raw)
To: devel@edk2.groups.io, lersek@redhat.com, Wang, Jian J,
Yao, Jiewen
Reviewed-by : Chao Zhang <chao.b.zhang@intel.com>
-----Original Message-----
From: Laszlo Ersek [mailto:lersek@redhat.com]
Sent: 2019年10月3日 19:07
To: Zhang, Chao B <chao.b.zhang@intel.com>; Wang, Jian J <jian.j.wang@intel.com>; Yao, Jiewen <jiewen.yao@intel.com>
Cc: edk2-devel-groups-io <devel@edk2.groups.io>
Subject: Re: [edk2-devel] [PATCH 27/35] SecurityPkg: stop abusing EFI_EVENT for protocol notify registration
Pinging SecurityPkg maintainers again, for reviewing this patch.
Thanks
Laszlo
On 09/26/19 14:46, Laszlo Ersek wrote:
> Chao, Jian, Jiewen,
>
> can you please review this patch?
>
> Thanks,
> Laszlo
>
>
> On 09/17/19 21:49, Laszlo Ersek wrote:
>> EfiCreateProtocolNotifyEvent() takes a (VOID**) for "Registration",
>> similarly to gBS->RegisterProtocolNotify(). We should pass the
>> address of an actual pointer-to-VOID, and not the address of an
>> EFI_EVENT. EFI_EVENT just happens to be specified as (VOID*), and has
>> nothing to do with the registration.
>>
>> This change is a no-op in practice; it's a semantic improvement.
>>
>> Cc: Chao Zhang <chao.b.zhang@intel.com>
>> Cc: Jian Wang <jian.j.wang@intel.com>
>> Cc: Jiewen Yao <jiewen.yao@intel.com>
>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>> ---
>>
>> Notes:
>> build-tested only
>>
>> SecurityPkg/HddPassword/HddPasswordDxe.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/SecurityPkg/HddPassword/HddPasswordDxe.c
>> b/SecurityPkg/HddPassword/HddPasswordDxe.c
>> index b0d795b6597f..051e64091d7f 100644
>> --- a/SecurityPkg/HddPassword/HddPasswordDxe.c
>> +++ b/SecurityPkg/HddPassword/HddPasswordDxe.c
>> @@ -2770,7 +2770,7 @@ HddPasswordDxeInit ( {
>> EFI_STATUS Status;
>> HDD_PASSWORD_DXE_PRIVATE_DATA *Private;
>> - EFI_EVENT Registration;
>> + VOID *Registration;
>> EFI_EVENT EndOfDxeEvent;
>> EDKII_VARIABLE_LOCK_PROTOCOL *VariableLock;
>>
>>
>
>
>
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 33/35] StandaloneMmPkg/Core: stop abusing EFI_HANDLE for FwVolHeader tracking
2019-10-03 11:10 ` Laszlo Ersek
2019-10-03 11:17 ` Achin Gupta
2019-10-04 0:10 ` Yao, Jiewen
@ 2019-10-04 14:53 ` Achin Gupta
2 siblings, 0 replies; 155+ messages in thread
From: Achin Gupta @ 2019-10-04 14:53 UTC (permalink / raw)
To: devel@edk2.groups.io, lersek@redhat.com
Cc: Jiewen Yao, Supreeth Venkatesh, nd
Makes sense!
Reviewed-by: Achin Gupta <achin.gupta@arm.com>
On Thu, Oct 03, 2019 at 01:10:53PM +0200, Laszlo Ersek wrote:
> Pinging StandaloneMmPkg maintainers again, for reviewing this patch.
>
> Thanks
> Laszlo
>
> On 09/26/19 14:48, Laszlo Ersek wrote:
> > Achin, Jiewen, Supreeth,
> >
> > can one of you guys please review this patch?
> >
> > Thanks
> > Laszlo
> >
> > On 09/17/19 21:49, Laszlo Ersek wrote:
> >> The FvHasBeenProcessed() and FvIsBeingProcesssed() functions make sure
> >> that every firmware volume is processed only once (every driver in every
> >> firmware volume should be discovered only once). For this, the functions
> >> use a linked list.
> >>
> >> In MdeModulePkg's DXE Core and SMM Core, the key used for identifying
> >> those firmware volumes that have been processed is the EFI_HANDLE on which
> >> the DXE or SMM firmware volume protocol is installed. In the
> >> StandaloneMmPkg core however, the key is the address of the firmware
> >> volume header; that is, it has type (EFI_FIRMWARE_VOLUME_HEADER*).
> >>
> >> (EFI_FIRMWARE_VOLUME_HEADER*) has nothing to do with EFI_HANDLE.
> >> EFI_HANDLE just happens to be specified as (VOID*), and therefore the
> >> conversion between (EFI_FIRMWARE_VOLUME_HEADER*) and EFI_HANDLE is silent.
> >>
> >> (The FvHasBeenProcessed() and FvIsBeingProcesssed() functions were likely
> >> copied verbatim from MdeModulePkg's DXE Core and/or the SMM Core, and not
> >> flagged by the compiler in StandaloneMmPkg due to UEFI regrettably
> >> specifying EFI_HANDLE as (VOID*), thereby enabling the above implicit
> >> conversion.)
> >>
> >> We should not exploit this circumstance. Represent the key type faithfully
> >> instead.
> >>
> >> This is a semantic fix; there is no change in operation.
> >>
> >> Cc: Achin Gupta <achin.gupta@arm.com>
> >> Cc: Jiewen Yao <jiewen.yao@intel.com>
> >> Cc: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
> >> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> >> ---
> >>
> >> Notes:
> >> build-tested only
> >>
> >> StandaloneMmPkg/Core/StandaloneMmCore.h | 2 +-
> >> StandaloneMmPkg/Core/Dispatcher.c | 80 +++++++++++---------
> >> StandaloneMmPkg/Core/FwVol.c | 16 ++--
> >> 3 files changed, 52 insertions(+), 46 deletions(-)
> >>
> >> diff --git a/StandaloneMmPkg/Core/StandaloneMmCore.h b/StandaloneMmPkg/Core/StandaloneMmCore.h
> >> index dcf91bc5e916..23ddbe169faf 100644
> >> --- a/StandaloneMmPkg/Core/StandaloneMmCore.h
> >> +++ b/StandaloneMmPkg/Core/StandaloneMmCore.h
> >> @@ -67,7 +67,7 @@ typedef struct {
> >>
> >> LIST_ENTRY ScheduledLink; // mScheduledQueue
> >>
> >> - EFI_HANDLE FvHandle;
> >> + EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader;
> >> EFI_GUID FileName;
> >> VOID *Pe32Data;
> >> UINTN Pe32DataSize;
> >> diff --git a/StandaloneMmPkg/Core/Dispatcher.c b/StandaloneMmPkg/Core/Dispatcher.c
> >> index 3788389f95ed..9853445a64a1 100644
> >> --- a/StandaloneMmPkg/Core/Dispatcher.c
> >> +++ b/StandaloneMmPkg/Core/Dispatcher.c
> >> @@ -5,7 +5,7 @@
> >> is added to the mDiscoveredList. The Before, and After Depex are
> >> pre-processed as drivers are added to the mDiscoveredList. If an Apriori
> >> file exists in the FV those drivers are addeded to the
> >> - mScheduledQueue. The mFvHandleList is used to make sure a
> >> + mScheduledQueue. The mFwVolList is used to make sure a
> >> FV is only processed once.
> >>
> >> Step #2 - Dispatch. Remove driver from the mScheduledQueue and load and
> >> @@ -40,13 +40,13 @@
> >> //
> >> // MM Dispatcher Data structures
> >> //
> >> -#define KNOWN_HANDLE_SIGNATURE SIGNATURE_32('k','n','o','w')
> >> +#define KNOWN_FWVOL_SIGNATURE SIGNATURE_32('k','n','o','w')
> >>
> >> typedef struct {
> >> - UINTN Signature;
> >> - LIST_ENTRY Link; // mFvHandleList
> >> - EFI_HANDLE Handle;
> >> -} KNOWN_HANDLE;
> >> + UINTN Signature;
> >> + LIST_ENTRY Link; // mFwVolList
> >> + EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader;
> >> +} KNOWN_FWVOL;
> >>
> >> //
> >> // Function Prototypes
> >> @@ -86,9 +86,10 @@ LIST_ENTRY mDiscoveredList = INITIALIZE_LIST_HEAD_VARIABLE (mDiscoveredList);
> >> LIST_ENTRY mScheduledQueue = INITIALIZE_LIST_HEAD_VARIABLE (mScheduledQueue);
> >>
> >> //
> >> -// List of handles who's Fv's have been parsed and added to the mFwDriverList.
> >> +// List of firmware volume headers whose containing firmware volumes have been
> >> +// parsed and added to the mFwDriverList.
> >> //
> >> -LIST_ENTRY mFvHandleList = INITIALIZE_LIST_HEAD_VARIABLE (mFvHandleList);
> >> +LIST_ENTRY mFwVolList = INITIALIZE_LIST_HEAD_VARIABLE (mFwVolList);
> >>
> >> //
> >> // Flag for the MM Dispacher. TRUE if dispatcher is execuing.
> >> @@ -769,26 +770,30 @@ MmInsertOnScheduledQueueWhileProcessingBeforeAndAfter (
> >> }
> >>
> >> /**
> >> - Return TRUE if the Fv has been processed, FALSE if not.
> >> + Return TRUE if the firmware volume has been processed, FALSE if not.
> >>
> >> - @param FvHandle The handle of a FV that's being tested
> >> + @param FwVolHeader The header of the firmware volume that's being
> >> + tested.
> >>
> >> - @retval TRUE Fv protocol on FvHandle has been processed
> >> - @retval FALSE Fv protocol on FvHandle has not yet been
> >> - processed
> >> + @retval TRUE The firmware volume denoted by FwVolHeader has
> >> + been processed
> >> + @retval FALSE The firmware volume denoted by FwVolHeader has
> >> + not yet been processed
> >>
> >> **/
> >> BOOLEAN
> >> FvHasBeenProcessed (
> >> - IN EFI_HANDLE FvHandle
> >> + IN EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader
> >> )
> >> {
> >> LIST_ENTRY *Link;
> >> - KNOWN_HANDLE *KnownHandle;
> >> + KNOWN_FWVOL *KnownFwVol;
> >>
> >> - for (Link = mFvHandleList.ForwardLink; Link != &mFvHandleList; Link = Link->ForwardLink) {
> >> - KnownHandle = CR (Link, KNOWN_HANDLE, Link, KNOWN_HANDLE_SIGNATURE);
> >> - if (KnownHandle->Handle == FvHandle) {
> >> + for (Link = mFwVolList.ForwardLink;
> >> + Link != &mFwVolList;
> >> + Link = Link->ForwardLink) {
> >> + KnownFwVol = CR (Link, KNOWN_FWVOL, Link, KNOWN_FWVOL_SIGNATURE);
> >> + if (KnownFwVol->FwVolHeader == FwVolHeader) {
> >> return TRUE;
> >> }
> >> }
> >> @@ -796,28 +801,29 @@ FvHasBeenProcessed (
> >> }
> >>
> >> /**
> >> - Remember that Fv protocol on FvHandle has had it's drivers placed on the
> >> - mDiscoveredList. This fucntion adds entries on the mFvHandleList. Items are
> >> - never removed/freed from the mFvHandleList.
> >> + Remember that the firmware volume denoted by FwVolHeader has had its drivers
> >> + placed on mDiscoveredList. This function adds entries to mFwVolList. Items
> >> + are never removed/freed from mFwVolList.
> >>
> >> - @param FvHandle The handle of a FV that has been processed
> >> + @param FwVolHeader The header of the firmware volume that's being
> >> + processed.
> >>
> >> **/
> >> VOID
> >> FvIsBeingProcesssed (
> >> - IN EFI_HANDLE FvHandle
> >> + IN EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader
> >> )
> >> {
> >> - KNOWN_HANDLE *KnownHandle;
> >> + KNOWN_FWVOL *KnownFwVol;
> >>
> >> - DEBUG ((DEBUG_INFO, "FvIsBeingProcesssed - 0x%08x\n", FvHandle));
> >> + DEBUG ((DEBUG_INFO, "FvIsBeingProcesssed - 0x%08x\n", KnownFwVol));
> >>
> >> - KnownHandle = AllocatePool (sizeof (KNOWN_HANDLE));
> >> - ASSERT (KnownHandle != NULL);
> >> + KnownFwVol = AllocatePool (sizeof (KNOWN_FWVOL));
> >> + ASSERT (KnownFwVol != NULL);
> >>
> >> - KnownHandle->Signature = KNOWN_HANDLE_SIGNATURE;
> >> - KnownHandle->Handle = FvHandle;
> >> - InsertTailList (&mFvHandleList, &KnownHandle->Link);
> >> + KnownFwVol->Signature = KNOWN_FWVOL_SIGNATURE;
> >> + KnownFwVol->FwVolHeader = FwVolHeader;
> >> + InsertTailList (&mFwVolList, &KnownFwVol->Link);
> >> }
> >>
> >> /**
> >> @@ -842,12 +848,12 @@ FvIsBeingProcesssed (
> >> **/
> >> EFI_STATUS
> >> MmAddToDriverList (
> >> - IN EFI_HANDLE FvHandle,
> >> - IN VOID *Pe32Data,
> >> - IN UINTN Pe32DataSize,
> >> - IN VOID *Depex,
> >> - IN UINTN DepexSize,
> >> - IN EFI_GUID *DriverName
> >> + IN EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader,
> >> + IN VOID *Pe32Data,
> >> + IN UINTN Pe32DataSize,
> >> + IN VOID *Depex,
> >> + IN UINTN DepexSize,
> >> + IN EFI_GUID *DriverName
> >> )
> >> {
> >> EFI_MM_DRIVER_ENTRY *DriverEntry;
> >> @@ -863,7 +869,7 @@ MmAddToDriverList (
> >>
> >> DriverEntry->Signature = EFI_MM_DRIVER_ENTRY_SIGNATURE;
> >> CopyGuid (&DriverEntry->FileName, DriverName);
> >> - DriverEntry->FvHandle = FvHandle;
> >> + DriverEntry->FwVolHeader = FwVolHeader;
> >> DriverEntry->Pe32Data = Pe32Data;
> >> DriverEntry->Pe32DataSize = Pe32DataSize;
> >> DriverEntry->Depex = Depex;
> >> diff --git a/StandaloneMmPkg/Core/FwVol.c b/StandaloneMmPkg/Core/FwVol.c
> >> index 9fe0c257a43a..99ecf4af4714 100644
> >> --- a/StandaloneMmPkg/Core/FwVol.c
> >> +++ b/StandaloneMmPkg/Core/FwVol.c
> >> @@ -24,22 +24,22 @@ EFI_FV_FILETYPE mMmFileTypes[] = {
> >>
> >> EFI_STATUS
> >> MmAddToDriverList (
> >> - IN EFI_HANDLE FvHandle,
> >> - IN VOID *Pe32Data,
> >> - IN UINTN Pe32DataSize,
> >> - IN VOID *Depex,
> >> - IN UINTN DepexSize,
> >> - IN EFI_GUID *DriverName
> >> + IN EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader,
> >> + IN VOID *Pe32Data,
> >> + IN UINTN Pe32DataSize,
> >> + IN VOID *Depex,
> >> + IN UINTN DepexSize,
> >> + IN EFI_GUID *DriverName
> >> );
> >>
> >> BOOLEAN
> >> FvHasBeenProcessed (
> >> - IN EFI_HANDLE FvHandle
> >> + IN EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader
> >> );
> >>
> >> VOID
> >> FvIsBeingProcesssed (
> >> - IN EFI_HANDLE FvHandle
> >> + IN EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader
> >> );
> >>
> >> EFI_STATUS
> >>
> >
> >
> >
> >
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 26/35] SecurityPkg: fix UninstallMultipleProtocolInterfaces() calls
2019-10-04 13:14 ` Zhang, Chao B
@ 2019-10-04 18:15 ` Laszlo Ersek
0 siblings, 0 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-10-04 18:15 UTC (permalink / raw)
To: Zhang, Chao B, devel@edk2.groups.io, Wang, Jian J, Yao, Jiewen
On 10/04/19 15:14, Zhang, Chao B wrote:
> Hi Laszlo:
> Sorry for late response. The fix is good to me.
Thanks!
Can you give Reviewed-by or Acked-by?
> I am also interested in how you find this issue, can you share it?
Sure, please see the explanation in patches #00 and #01 (I CC'd you on
them originally):
* http://mid.mail-archive.com/20190917194935.24322-1-lersek@redhat.com
https://edk2.groups.io/g/devel/message/47387
* http://mid.mail-archive.com/20190917194935.24322-2-lersek@redhat.com
https://edk2.groups.io/g/devel/message/47388
Thanks,
Laszlo
>
> -----Original Message-----
> From: Laszlo Ersek [mailto:lersek@redhat.com]
> Sent: 2019年10月3日 19:07
> To: Zhang, Chao B <chao.b.zhang@intel.com>; Wang, Jian J <jian.j.wang@intel.com>; Yao, Jiewen <jiewen.yao@intel.com>
> Cc: edk2-devel-groups-io <devel@edk2.groups.io>
> Subject: Re: [edk2-devel] [PATCH 26/35] SecurityPkg: fix UninstallMultipleProtocolInterfaces() calls
>
> Pinging SecurityPkg maintainers again, for reviewing this patch.
>
> Thanks
> Laszlo
>
> On 09/26/19 14:45, Laszlo Ersek wrote:
>> Chao, Jian, Jiewen,
>>
>> can you please review this patch?
>>
>> Thanks,
>> Laszlo
>>
>> On 09/17/19 21:49, Laszlo Ersek wrote:
>>> Unlike the InstallMultipleProtocolInterfaces() boot service, which
>>> takes an (EFI_HANDLE*) as first parameter, the
>>> UninstallMultipleProtocolInterfaces() boot service takes an
>>> EFI_HANDLE as first parameter.
>>>
>>> These are actual bugs. They must have remained hidden until now
>>> because they are all in Unload() functions, which are probably
>>> exercised infrequently. Fix the UninstallMultipleProtocolInterfaces() calls.
>>>
>>> Cc: Chao Zhang <chao.b.zhang@intel.com>
>>> Cc: Jian Wang <jian.j.wang@intel.com>
>>> Cc: Jiewen Yao <jiewen.yao@intel.com>
>>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>>> ---
>>>
>>> Notes:
>>> build-tested only
>>>
>>> SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c | 2 +-
>>> SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c | 2 +-
>>>
>>> SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfi
>>> gDriver.c | 2 +-
>>> 3 files changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c
>>> b/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c
>>> index 54155a338100..9052eced757d 100644
>>> --- a/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c
>>> +++ b/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c
>>> @@ -443,7 +443,7 @@ Tcg2ConfigDriverUnload (
>>> ASSERT (PrivateData->Signature ==
>>> TCG2_CONFIG_PRIVATE_DATA_SIGNATURE);
>>>
>>> gBS->UninstallMultipleProtocolInterfaces (
>>> - &ImageHandle,
>>> + ImageHandle,
>>> &gEfiCallerIdGuid,
>>> PrivateData,
>>> NULL
>>> diff --git a/SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c
>>> b/SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c
>>> index 341879e4c4ba..fb06624fdb8f 100644
>>> --- a/SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c
>>> +++ b/SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c
>>> @@ -138,7 +138,7 @@ TcgConfigDriverUnload (
>>> ASSERT (PrivateData->Signature ==
>>> TCG_CONFIG_PRIVATE_DATA_SIGNATURE);
>>>
>>> gBS->UninstallMultipleProtocolInterfaces (
>>> - &ImageHandle,
>>> + ImageHandle,
>>> &gEfiCallerIdGuid,
>>> PrivateData,
>>> NULL
>>> diff --git
>>> a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootCon
>>> figDriver.c
>>> b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootCon
>>> figDriver.c index 798ef9cfbc01..6c0294151e6c 100644
>>> ---
>>> a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootCon
>>> figDriver.c
>>> +++ b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBoo
>>> +++ tConfigDriver.c
>>> @@ -115,7 +115,7 @@ SecureBootConfigDriverUnload (
>>> ASSERT (PrivateData->Signature ==
>>> SECUREBOOT_CONFIG_PRIVATE_DATA_SIGNATURE);
>>>
>>> gBS->UninstallMultipleProtocolInterfaces (
>>> - &ImageHandle,
>>> + ImageHandle,
>>> &gEfiCallerIdGuid,
>>> PrivateData,
>>> NULL
>>>
>>
>>
>>
>>
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 18/35] NetworkPkg/DxeNetLib: fix type typo in NetLibGetMacAddress()
2019-10-03 11:05 ` Laszlo Ersek
@ 2019-10-04 19:18 ` Laszlo Ersek
0 siblings, 0 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-10-04 19:18 UTC (permalink / raw)
To: Jiaxin Wu, Siyuan Fu; +Cc: edk2-devel-groups-io
Ping
On 10/03/19 13:05, Laszlo Ersek wrote:
> Pinging NetworkPkg maintainers again. Please?
>
> Thanks
> Laszlo
>
> On 09/26/19 14:14, Laszlo Ersek wrote:
>> Jiaxin, Siyuan,
>>
>> can you please review this patch?
>>
>> Thanks
>> Laszlo
>>
>> On 09/17/19 21:49, Laszlo Ersek wrote:
>>> NetLibGetSnpHandle() returns an EFI_HANDLE, not an (EFI_HANDLE*).
>>> NetLibGetMacAddress() only uses the return value ("SnpHandle") for a
>>> NULL-check. Fix the type of "SnpHandle".
>>>
>>> This patch is a no-op.
>>>
>>> Cc: Jiaxin Wu <jiaxin.wu@intel.com>
>>> Cc: Siyuan Fu <siyuan.fu@intel.com>
>>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>>> ---
>>>
>>> Notes:
>>> lightly tested: MAC strings are displayed in UiApp
>>>
>>> NetworkPkg/Library/DxeNetLib/DxeNetLib.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/NetworkPkg/Library/DxeNetLib/DxeNetLib.c b/NetworkPkg/Library/DxeNetLib/DxeNetLib.c
>>> index 8e2f720666ea..a39c20be3d34 100644
>>> --- a/NetworkPkg/Library/DxeNetLib/DxeNetLib.c
>>> +++ b/NetworkPkg/Library/DxeNetLib/DxeNetLib.c
>>> @@ -2182,7 +2182,7 @@ NetLibGetMacAddress (
>>> EFI_SIMPLE_NETWORK_MODE SnpModeData;
>>> EFI_MANAGED_NETWORK_PROTOCOL *Mnp;
>>> EFI_SERVICE_BINDING_PROTOCOL *MnpSb;
>>> - EFI_HANDLE *SnpHandle;
>>> + EFI_HANDLE SnpHandle;
>>> EFI_HANDLE MnpChildHandle;
>>>
>>> ASSERT (MacAddress != NULL);
>>>
>>
>>
>>
>>
>
>
>
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 25/35] OvmfPkg/VideoDxe: document EFI_EDID_OVERRIDE_PROTOCOL.GetEdid() call
2019-09-26 12:43 ` Laszlo Ersek
@ 2019-10-04 20:01 ` Laszlo Ersek
0 siblings, 0 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-10-04 20:01 UTC (permalink / raw)
To: devel, philmd; +Cc: Ard Biesheuvel, David Woodhouse, Jordan Justen
On 09/26/19 14:43, Laszlo Ersek wrote:
> On 09/23/19 17:59, Philippe Mathieu-Daudé wrote:
>> Hi Laszlo,
>>
>> On 9/17/19 9:49 PM, Laszlo Ersek wrote:
>>> According to the UEFI spec -- and to the edk2 header
>>> "MdePkg/Include/Protocol/EdidOverride.h" too --,
>>> EFI_EDID_OVERRIDE_PROTOCOL_GET_EDID takes an (EFI_HANDLE*), and not an
>>> EFI_HANDLE, as second parameter ("ChildHandle").
>>>
>>> This is probably [*] a bug in the UEFI spec. Given that this CSM module
>>> (VideoDxe) had been used for a long time on physical platforms before it
>>> was moved to OvmfPkg, keep the current "ChildHandle" argument, just cast
>>> it explicitly.
>>>
>>> [*] The edk2 tree contains no other GetEdid() call, and also no GetEdid()
>>> implementation.
>>>
>>> The edk2-platforms tree contains two GetEdid() calls, at commit
>>> 022c212167e0, in files
>>> - "Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/Edid.c",
>>> - "Drivers/OptionRomPkg/CirrusLogic5430Dxe/Edid.c".
>>>
>>> From these, the first passes an (EFI_HANDLE*) as "ChildHandle", the
>>> second passes an EFI_HANDLE. It's difficult to draw a conclusion. :/
>>>
>>> No functional changes.
>>>
>>> (I've also requested a non-normative (informative) clarification for the
>>> UEFI spec: <https://mantis.uefi.org/mantis/view.php?id=2018>, in the
>>> direction that matches this patch.)
>>
>> (EFI_HANDLE*) makes sense to me, but I'd rather wait for the spec
>> clarification before Acking this patch, I don't want we silent a bug
>> with this cast.
>
> Right, there's been some movement in Mantis#2018.
>
> It looks like the spec is wrong, but all [*] consumers and producers of
> GetEdid(), investigated thus far, have simply ignored the mistake in the
> spec, and done the right thing in practice.
>
> So there seems to be a chance for the spec to be fixed. That would be
> followed by fixing the GetEdid() prototype in edk2. And then this patch
> would be dropped.
>
> [*] the only exception found thus far is the call site in
> edk2-platform's "DisplayLinkPkg", mentioned above in the commit message.
> However, that is a very recent code addition (commit 9df63499ea01,
> 2019-09-09), and it might not reflect "historical" usage, but an attempt
> to write brand new code, conforming to the *letter* of the spec. So in
> case the spec gets fixed, the DisplayLinkPkg code could be fixed in
> tandem, perhaps.
See new thread started here:
http://mid.mail-archive.com/985de369-7880-b6cc-46e7-5a2edca6582b@redhat.com
https://edk2.groups.io/g/devel/message/48487
Thanks!
Laszlo
>>> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>>> Cc: David Woodhouse <dwmw2@infradead.org>
>>> Cc: Jordan Justen <jordan.l.justen@intel.com>
>>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>>> ---
>>>
>>> Notes:
>>> build-tested only
>>>
>>> OvmfPkg/Csm/BiosThunk/VideoDxe/BiosVideo.c | 6 +++++-
>>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/OvmfPkg/Csm/BiosThunk/VideoDxe/BiosVideo.c b/OvmfPkg/Csm/BiosThunk/VideoDxe/BiosVideo.c
>>> index 0640656dba14..995136adee27 100644
>>> --- a/OvmfPkg/Csm/BiosThunk/VideoDxe/BiosVideo.c
>>> +++ b/OvmfPkg/Csm/BiosThunk/VideoDxe/BiosVideo.c
>>> @@ -1402,9 +1402,13 @@ BiosVideoCheckForVbe (
>>> goto Done;
>>> }
>>>
>>> + //
>>> + // Cast "ChildHandle" to (EFI_HANDLE*) in order to work around the spec bug
>>> + // in UEFI v2.8, reported as Mantis#2018.
>>> + //
>>> Status = EdidOverride->GetEdid (
>>> EdidOverride,
>>> - BiosVideoPrivate->Handle,
>>> + (EFI_HANDLE *) BiosVideoPrivate->Handle,
>>> &EdidAttributes,
>>> &EdidOverrideDataSize,
>>> (UINT8 **) &EdidOverrideDataBlock
>>>
>>
>>
>>
>
>
>
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 27/35] SecurityPkg: stop abusing EFI_EVENT for protocol notify registration
2019-10-03 11:06 ` Laszlo Ersek
2019-10-04 0:05 ` Yao, Jiewen
2019-10-04 13:16 ` Zhang, Chao B
@ 2019-10-05 14:28 ` Zhang, Chao B
2 siblings, 0 replies; 155+ messages in thread
From: Zhang, Chao B @ 2019-10-05 14:28 UTC (permalink / raw)
To: devel@edk2.groups.io, lersek@redhat.com, Wang, Jian J,
Yao, Jiewen
Reviewed-by : Chao Zhang <chao.b.zhang@intel.com>
-----Original Message-----
From: Zhang, Chao B
Sent: 2019年10月4日 21:16
To: edk2-devel-groups-io <devel@edk2.groups.io>; 'lersek@redhat.com' <lersek@redhat.com>; Wang, Jian J <jian.j.wang@intel.com>; Yao, Jiewen <jiewen.yao@intel.com>
Subject: RE: [edk2-devel] [PATCH 27/35] SecurityPkg: stop abusing EFI_EVENT for protocol notify registration
Reviewed-by : Chao Zhang <chao.b.zhang@intel.com>
-----Original Message-----
From: Laszlo Ersek [mailto:lersek@redhat.com]
Sent: 2019年10月3日 19:07
To: Zhang, Chao B <chao.b.zhang@intel.com>; Wang, Jian J <jian.j.wang@intel.com>; Yao, Jiewen <jiewen.yao@intel.com>
Cc: edk2-devel-groups-io <devel@edk2.groups.io>
Subject: Re: [edk2-devel] [PATCH 27/35] SecurityPkg: stop abusing EFI_EVENT for protocol notify registration
Pinging SecurityPkg maintainers again, for reviewing this patch.
Thanks
Laszlo
On 09/26/19 14:46, Laszlo Ersek wrote:
> Chao, Jian, Jiewen,
>
> can you please review this patch?
>
> Thanks,
> Laszlo
>
>
> On 09/17/19 21:49, Laszlo Ersek wrote:
>> EfiCreateProtocolNotifyEvent() takes a (VOID**) for "Registration",
>> similarly to gBS->RegisterProtocolNotify(). We should pass the
>> address of an actual pointer-to-VOID, and not the address of an
>> EFI_EVENT. EFI_EVENT just happens to be specified as (VOID*), and has
>> nothing to do with the registration.
>>
>> This change is a no-op in practice; it's a semantic improvement.
>>
>> Cc: Chao Zhang <chao.b.zhang@intel.com>
>> Cc: Jian Wang <jian.j.wang@intel.com>
>> Cc: Jiewen Yao <jiewen.yao@intel.com>
>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>> ---
>>
>> Notes:
>> build-tested only
>>
>> SecurityPkg/HddPassword/HddPasswordDxe.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/SecurityPkg/HddPassword/HddPasswordDxe.c
>> b/SecurityPkg/HddPassword/HddPasswordDxe.c
>> index b0d795b6597f..051e64091d7f 100644
>> --- a/SecurityPkg/HddPassword/HddPasswordDxe.c
>> +++ b/SecurityPkg/HddPassword/HddPasswordDxe.c
>> @@ -2770,7 +2770,7 @@ HddPasswordDxeInit ( {
>> EFI_STATUS Status;
>> HDD_PASSWORD_DXE_PRIVATE_DATA *Private;
>> - EFI_EVENT Registration;
>> + VOID *Registration;
>> EFI_EVENT EndOfDxeEvent;
>> EDKII_VARIABLE_LOCK_PROTOCOL *VariableLock;
>>
>>
>
>
>
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 26/35] SecurityPkg: fix UninstallMultipleProtocolInterfaces() calls
2019-10-03 11:06 ` Laszlo Ersek
2019-10-04 0:05 ` Yao, Jiewen
2019-10-04 13:14 ` Zhang, Chao B
@ 2019-10-05 14:28 ` Zhang, Chao B
2019-10-07 18:14 ` Laszlo Ersek
2 siblings, 1 reply; 155+ messages in thread
From: Zhang, Chao B @ 2019-10-05 14:28 UTC (permalink / raw)
To: devel@edk2.groups.io, lersek@redhat.com, Wang, Jian J,
Yao, Jiewen
Reviewed-by : Chao Zhang <chao.b.zhang@intel.com>
-----Original Message-----
From: Zhang, Chao B
Sent: 2019年10月4日 21:14
To: edk2-devel-groups-io <devel@edk2.groups.io>; 'lersek@redhat.com' <lersek@redhat.com>; Wang, Jian J <jian.j.wang@intel.com>; Yao, Jiewen <jiewen.yao@intel.com>
Subject: RE: [edk2-devel] [PATCH 26/35] SecurityPkg: fix UninstallMultipleProtocolInterfaces() calls
Hi Laszlo:
Sorry for late response. The fix is good to me. I am also interested in how you find this issue, can you share it?
-----Original Message-----
From: Laszlo Ersek [mailto:lersek@redhat.com]
Sent: 2019年10月3日 19:07
To: Zhang, Chao B <chao.b.zhang@intel.com>; Wang, Jian J <jian.j.wang@intel.com>; Yao, Jiewen <jiewen.yao@intel.com>
Cc: edk2-devel-groups-io <devel@edk2.groups.io>
Subject: Re: [edk2-devel] [PATCH 26/35] SecurityPkg: fix UninstallMultipleProtocolInterfaces() calls
Pinging SecurityPkg maintainers again, for reviewing this patch.
Thanks
Laszlo
On 09/26/19 14:45, Laszlo Ersek wrote:
> Chao, Jian, Jiewen,
>
> can you please review this patch?
>
> Thanks,
> Laszlo
>
> On 09/17/19 21:49, Laszlo Ersek wrote:
>> Unlike the InstallMultipleProtocolInterfaces() boot service, which
>> takes an (EFI_HANDLE*) as first parameter, the
>> UninstallMultipleProtocolInterfaces() boot service takes an
>> EFI_HANDLE as first parameter.
>>
>> These are actual bugs. They must have remained hidden until now
>> because they are all in Unload() functions, which are probably
>> exercised infrequently. Fix the UninstallMultipleProtocolInterfaces() calls.
>>
>> Cc: Chao Zhang <chao.b.zhang@intel.com>
>> Cc: Jian Wang <jian.j.wang@intel.com>
>> Cc: Jiewen Yao <jiewen.yao@intel.com>
>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>> ---
>>
>> Notes:
>> build-tested only
>>
>> SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c | 2 +-
>> SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c | 2 +-
>>
>> SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfi
>> gDriver.c | 2 +-
>> 3 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c
>> b/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c
>> index 54155a338100..9052eced757d 100644
>> --- a/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c
>> +++ b/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c
>> @@ -443,7 +443,7 @@ Tcg2ConfigDriverUnload (
>> ASSERT (PrivateData->Signature ==
>> TCG2_CONFIG_PRIVATE_DATA_SIGNATURE);
>>
>> gBS->UninstallMultipleProtocolInterfaces (
>> - &ImageHandle,
>> + ImageHandle,
>> &gEfiCallerIdGuid,
>> PrivateData,
>> NULL
>> diff --git a/SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c
>> b/SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c
>> index 341879e4c4ba..fb06624fdb8f 100644
>> --- a/SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c
>> +++ b/SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c
>> @@ -138,7 +138,7 @@ TcgConfigDriverUnload (
>> ASSERT (PrivateData->Signature ==
>> TCG_CONFIG_PRIVATE_DATA_SIGNATURE);
>>
>> gBS->UninstallMultipleProtocolInterfaces (
>> - &ImageHandle,
>> + ImageHandle,
>> &gEfiCallerIdGuid,
>> PrivateData,
>> NULL
>> diff --git
>> a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootCon
>> figDriver.c
>> b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootCon
>> figDriver.c index 798ef9cfbc01..6c0294151e6c 100644
>> ---
>> a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootCon
>> figDriver.c
>> +++ b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBoo
>> +++ tConfigDriver.c
>> @@ -115,7 +115,7 @@ SecureBootConfigDriverUnload (
>> ASSERT (PrivateData->Signature ==
>> SECUREBOOT_CONFIG_PRIVATE_DATA_SIGNATURE);
>>
>> gBS->UninstallMultipleProtocolInterfaces (
>> - &ImageHandle,
>> + ImageHandle,
>> &gEfiCallerIdGuid,
>> PrivateData,
>> NULL
>>
>
>
>
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 26/35] SecurityPkg: fix UninstallMultipleProtocolInterfaces() calls
2019-10-05 14:28 ` Zhang, Chao B
@ 2019-10-07 18:14 ` Laszlo Ersek
0 siblings, 0 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-10-07 18:14 UTC (permalink / raw)
To: devel, chao.b.zhang, Wang, Jian J, Yao, Jiewen
On 10/05/19 16:28, Zhang, Chao B wrote:
> Reviewed-by : Chao Zhang <chao.b.zhang@intel.com>
Thanks!
Laszlo
>
> -----Original Message-----
> From: Zhang, Chao B
> Sent: 2019年10月4日 21:14
> To: edk2-devel-groups-io <devel@edk2.groups.io>; 'lersek@redhat.com' <lersek@redhat.com>; Wang, Jian J <jian.j.wang@intel.com>; Yao, Jiewen <jiewen.yao@intel.com>
> Subject: RE: [edk2-devel] [PATCH 26/35] SecurityPkg: fix UninstallMultipleProtocolInterfaces() calls
>
> Hi Laszlo:
> Sorry for late response. The fix is good to me. I am also interested in how you find this issue, can you share it?
>
> -----Original Message-----
> From: Laszlo Ersek [mailto:lersek@redhat.com]
> Sent: 2019年10月3日 19:07
> To: Zhang, Chao B <chao.b.zhang@intel.com>; Wang, Jian J <jian.j.wang@intel.com>; Yao, Jiewen <jiewen.yao@intel.com>
> Cc: edk2-devel-groups-io <devel@edk2.groups.io>
> Subject: Re: [edk2-devel] [PATCH 26/35] SecurityPkg: fix UninstallMultipleProtocolInterfaces() calls
>
> Pinging SecurityPkg maintainers again, for reviewing this patch.
>
> Thanks
> Laszlo
>
> On 09/26/19 14:45, Laszlo Ersek wrote:
>> Chao, Jian, Jiewen,
>>
>> can you please review this patch?
>>
>> Thanks,
>> Laszlo
>>
>> On 09/17/19 21:49, Laszlo Ersek wrote:
>>> Unlike the InstallMultipleProtocolInterfaces() boot service, which
>>> takes an (EFI_HANDLE*) as first parameter, the
>>> UninstallMultipleProtocolInterfaces() boot service takes an
>>> EFI_HANDLE as first parameter.
>>>
>>> These are actual bugs. They must have remained hidden until now
>>> because they are all in Unload() functions, which are probably
>>> exercised infrequently. Fix the UninstallMultipleProtocolInterfaces() calls.
>>>
>>> Cc: Chao Zhang <chao.b.zhang@intel.com>
>>> Cc: Jian Wang <jian.j.wang@intel.com>
>>> Cc: Jiewen Yao <jiewen.yao@intel.com>
>>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>>> ---
>>>
>>> Notes:
>>> build-tested only
>>>
>>> SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c | 2 +-
>>> SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c | 2 +-
>>>
>>> SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfi
>>> gDriver.c | 2 +-
>>> 3 files changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c
>>> b/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c
>>> index 54155a338100..9052eced757d 100644
>>> --- a/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c
>>> +++ b/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c
>>> @@ -443,7 +443,7 @@ Tcg2ConfigDriverUnload (
>>> ASSERT (PrivateData->Signature ==
>>> TCG2_CONFIG_PRIVATE_DATA_SIGNATURE);
>>>
>>> gBS->UninstallMultipleProtocolInterfaces (
>>> - &ImageHandle,
>>> + ImageHandle,
>>> &gEfiCallerIdGuid,
>>> PrivateData,
>>> NULL
>>> diff --git a/SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c
>>> b/SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c
>>> index 341879e4c4ba..fb06624fdb8f 100644
>>> --- a/SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c
>>> +++ b/SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c
>>> @@ -138,7 +138,7 @@ TcgConfigDriverUnload (
>>> ASSERT (PrivateData->Signature ==
>>> TCG_CONFIG_PRIVATE_DATA_SIGNATURE);
>>>
>>> gBS->UninstallMultipleProtocolInterfaces (
>>> - &ImageHandle,
>>> + ImageHandle,
>>> &gEfiCallerIdGuid,
>>> PrivateData,
>>> NULL
>>> diff --git
>>> a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootCon
>>> figDriver.c
>>> b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootCon
>>> figDriver.c index 798ef9cfbc01..6c0294151e6c 100644
>>> ---
>>> a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootCon
>>> figDriver.c
>>> +++ b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBoo
>>> +++ tConfigDriver.c
>>> @@ -115,7 +115,7 @@ SecureBootConfigDriverUnload (
>>> ASSERT (PrivateData->Signature ==
>>> SECUREBOOT_CONFIG_PRIVATE_DATA_SIGNATURE);
>>>
>>> gBS->UninstallMultipleProtocolInterfaces (
>>> - &ImageHandle,
>>> + ImageHandle,
>>> &gEfiCallerIdGuid,
>>> PrivateData,
>>> NULL
>>>
>>
>>
>>
>>
>
>
>
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 18/35] NetworkPkg/DxeNetLib: fix type typo in NetLibGetMacAddress()
2019-09-17 19:49 ` [PATCH 18/35] NetworkPkg/DxeNetLib: fix type typo in NetLibGetMacAddress() Laszlo Ersek
2019-09-24 11:00 ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-26 12:14 ` Laszlo Ersek
@ 2019-10-07 18:15 ` Michael D Kinney
2 siblings, 0 replies; 155+ messages in thread
From: Michael D Kinney @ 2019-10-07 18:15 UTC (permalink / raw)
To: devel@edk2.groups.io, lersek@redhat.com, Kinney, Michael D
Cc: Wu, Jiaxin, Fu, Siyuan
Laszlo,
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Mike
> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On
> Behalf Of Laszlo Ersek
> Sent: Tuesday, September 17, 2019 12:49 PM
> To: edk2-devel-groups-io <devel@edk2.groups.io>
> Cc: Wu, Jiaxin <jiaxin.wu@intel.com>; Fu, Siyuan
> <siyuan.fu@intel.com>
> Subject: [edk2-devel] [PATCH 18/35]
> NetworkPkg/DxeNetLib: fix type typo in
> NetLibGetMacAddress()
>
> NetLibGetSnpHandle() returns an EFI_HANDLE, not an
> (EFI_HANDLE*).
> NetLibGetMacAddress() only uses the return value
> ("SnpHandle") for a NULL-check. Fix the type of
> "SnpHandle".
>
> This patch is a no-op.
>
> Cc: Jiaxin Wu <jiaxin.wu@intel.com>
> Cc: Siyuan Fu <siyuan.fu@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> lightly tested: MAC strings are displayed in UiApp
>
> NetworkPkg/Library/DxeNetLib/DxeNetLib.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/NetworkPkg/Library/DxeNetLib/DxeNetLib.c
> b/NetworkPkg/Library/DxeNetLib/DxeNetLib.c
> index 8e2f720666ea..a39c20be3d34 100644
> --- a/NetworkPkg/Library/DxeNetLib/DxeNetLib.c
> +++ b/NetworkPkg/Library/DxeNetLib/DxeNetLib.c
> @@ -2182,7 +2182,7 @@ NetLibGetMacAddress (
> EFI_SIMPLE_NETWORK_MODE SnpModeData;
> EFI_MANAGED_NETWORK_PROTOCOL *Mnp;
> EFI_SERVICE_BINDING_PROTOCOL *MnpSb;
> - EFI_HANDLE *SnpHandle;
> + EFI_HANDLE SnpHandle;
> EFI_HANDLE MnpChildHandle;
>
> ASSERT (MacAddress != NULL);
> --
> 2.19.1.3.g30247aa5d201
>
>
>
> -=-=-=-=-=-=
> Groups.io Links: You receive all messages sent to this
> group.
>
> View/Reply Online (#47405):
> https://edk2.groups.io/g/devel/message/47405
> Mute This Topic: https://groups.io/mt/34180219/1643496
> Group Owner: devel+owner@edk2.groups.io
> Unsubscribe: https://edk2.groups.io/g/devel/unsub
> [michael.d.kinney@intel.com]
> -=-=-=-=-=-=
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 18/35] NetworkPkg/DxeNetLib: fix type typo in NetLibGetMacAddress()
2019-09-24 11:00 ` [edk2-devel] " Philippe Mathieu-Daudé
@ 2019-10-08 0:32 ` Siyuan, Fu
2019-10-08 23:36 ` Laszlo Ersek
0 siblings, 1 reply; 155+ messages in thread
From: Siyuan, Fu @ 2019-10-08 0:32 UTC (permalink / raw)
To: devel@edk2.groups.io, philmd@redhat.com, lersek@redhat.com; +Cc: Wu, Jiaxin
Just return from vacation. Sorry for late response.
Reviewed-by: Siyuan Fu <siyuan.fu@intel.com>
> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Philippe
> Mathieu-Daudé
> Sent: 2019年9月24日 19:00
> To: devel@edk2.groups.io; lersek@redhat.com
> Cc: Wu, Jiaxin <jiaxin.wu@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>
> Subject: Re: [edk2-devel] [PATCH 18/35] NetworkPkg/DxeNetLib: fix type
> typo in NetLibGetMacAddress()
>
> On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> > NetLibGetSnpHandle() returns an EFI_HANDLE, not an (EFI_HANDLE*).
> > NetLibGetMacAddress() only uses the return value ("SnpHandle") for a
> > NULL-check. Fix the type of "SnpHandle".
> >
> > This patch is a no-op.
> >
> > Cc: Jiaxin Wu <jiaxin.wu@intel.com>
> > Cc: Siyuan Fu <siyuan.fu@intel.com>
> > Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> > ---
> >
> > Notes:
> > lightly tested: MAC strings are displayed in UiApp
> >
> > NetworkPkg/Library/DxeNetLib/DxeNetLib.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/NetworkPkg/Library/DxeNetLib/DxeNetLib.c
> b/NetworkPkg/Library/DxeNetLib/DxeNetLib.c
> > index 8e2f720666ea..a39c20be3d34 100644
> > --- a/NetworkPkg/Library/DxeNetLib/DxeNetLib.c
> > +++ b/NetworkPkg/Library/DxeNetLib/DxeNetLib.c
> > @@ -2182,7 +2182,7 @@ NetLibGetMacAddress (
> > EFI_SIMPLE_NETWORK_MODE SnpModeData;
> > EFI_MANAGED_NETWORK_PROTOCOL *Mnp;
> > EFI_SERVICE_BINDING_PROTOCOL *MnpSb;
> > - EFI_HANDLE *SnpHandle;
> > + EFI_HANDLE SnpHandle;
> > EFI_HANDLE MnpChildHandle;
> >
> > ASSERT (MacAddress != NULL);
> >
>
> Since SnpHandle is only checked for being non-null, this change is
> indeed a no-op, else it would probably fixed some bug.
>
> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
>
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 18/35] NetworkPkg/DxeNetLib: fix type typo in NetLibGetMacAddress()
2019-10-08 0:32 ` Siyuan, Fu
@ 2019-10-08 23:36 ` Laszlo Ersek
0 siblings, 0 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-10-08 23:36 UTC (permalink / raw)
To: Fu, Siyuan, devel@edk2.groups.io, philmd@redhat.com
Cc: Wu, Jiaxin, Michael Kinney
On 10/08/19 02:32, Fu, Siyuan wrote:
> Just return from vacation. Sorry for late response.
>
> Reviewed-by: Siyuan Fu <siyuan.fu@intel.com>
Thank you and Mike both!
Laszlo
>> -----Original Message-----
>> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Philippe
>> Mathieu-Daudé
>> Sent: 2019年9月24日 19:00
>> To: devel@edk2.groups.io; lersek@redhat.com
>> Cc: Wu, Jiaxin <jiaxin.wu@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>
>> Subject: Re: [edk2-devel] [PATCH 18/35] NetworkPkg/DxeNetLib: fix type
>> typo in NetLibGetMacAddress()
>>
>> On 9/17/19 9:49 PM, Laszlo Ersek wrote:
>>> NetLibGetSnpHandle() returns an EFI_HANDLE, not an (EFI_HANDLE*).
>>> NetLibGetMacAddress() only uses the return value ("SnpHandle") for a
>>> NULL-check. Fix the type of "SnpHandle".
>>>
>>> This patch is a no-op.
>>>
>>> Cc: Jiaxin Wu <jiaxin.wu@intel.com>
>>> Cc: Siyuan Fu <siyuan.fu@intel.com>
>>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>>> ---
>>>
>>> Notes:
>>> lightly tested: MAC strings are displayed in UiApp
>>>
>>> NetworkPkg/Library/DxeNetLib/DxeNetLib.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/NetworkPkg/Library/DxeNetLib/DxeNetLib.c
>> b/NetworkPkg/Library/DxeNetLib/DxeNetLib.c
>>> index 8e2f720666ea..a39c20be3d34 100644
>>> --- a/NetworkPkg/Library/DxeNetLib/DxeNetLib.c
>>> +++ b/NetworkPkg/Library/DxeNetLib/DxeNetLib.c
>>> @@ -2182,7 +2182,7 @@ NetLibGetMacAddress (
>>> EFI_SIMPLE_NETWORK_MODE SnpModeData;
>>> EFI_MANAGED_NETWORK_PROTOCOL *Mnp;
>>> EFI_SERVICE_BINDING_PROTOCOL *MnpSb;
>>> - EFI_HANDLE *SnpHandle;
>>> + EFI_HANDLE SnpHandle;
>>> EFI_HANDLE MnpChildHandle;
>>>
>>> ASSERT (MacAddress != NULL);
>>>
>>
>> Since SnpHandle is only checked for being non-null, this change is
>> indeed a no-op, else it would probably fixed some bug.
>>
>> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
>>
>>
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs
2019-09-17 19:49 [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs Laszlo Ersek
` (36 preceding siblings ...)
2019-09-23 16:27 ` Marvin Häuser
@ 2019-10-08 23:49 ` Laszlo Ersek
2019-10-09 9:50 ` Laszlo Ersek
37 siblings, 1 reply; 155+ messages in thread
From: Laszlo Ersek @ 2019-10-08 23:49 UTC (permalink / raw)
To: edk2-devel-groups-io
Cc: Achin Gupta, Andrew Fish, Anthony Perard, Ard Biesheuvel,
Benjamin You, Chao Zhang, Dandan Bi, David Woodhouse, Eric Dong,
Guo Dong, Hao A Wu, Jaben Carsey, Jian J Wang, Jiaxin Wu,
Jiewen Yao, Jordan Justen, Julien Grall, Leif Lindholm,
Liming Gao, Maurice Ma, Michael D Kinney, Ray Ni, Siyuan Fu,
Supreeth Venkatesh, Zhichao Gao
On 09/17/19 21:49, Laszlo Ersek wrote:
> Repository: https://github.com/lersek/edk2.git
> Branch: voidptr
>
> The UEFI / PI / Shell specifications define a number of standard types
> as pointers to VOID. This is arguably a design mistake; those types
> should have been pointers to distinct incomplete union or structure
> types. Here's why:
>
> Roughly paraphrasing the constraints from ISO C99 "6.5.16.1 Simple
> assignment" and "6.5.4 Cast operators", any pointer-to-object type
> converts implicitly to, and from, pointer-to-void, provided const /
> volatile qualifications are not relaxed. Such implicit conversions
> prevent compilers from catching at least the following two kinds of
> coding mistakes:
>
> - mixing up one type with another (for example, EFI_HANDLE with
> EFI_EVENT),
>
> - getting the depth of indirection wrong (for example, mixing up
> (EFI_HANDLE*) with EFI_HANDLE).
>
> This series first separates these standard types from each other, in the
> first patch, which is *not* being proposed for merging. This unmasks a
> number of warts (semantic issues, or actual bugs) in the source code, in
> the form of build breakages. The rest of the series works through those
> breakages, cleaning and fixing the code.
>
> Every DSC file in the edk2 tree was built for at least one of the NOOPT,
> DEBUG, RELEASE targets (NOOPT being preferred), with the GCC48 toolchain
> (for IA32 / X64) and the GCC5 toolchain (for ARM / AARCH64). Of course,
> the build arches were restricted to the SUPPORTED_ARCHITECTURES stated
> in the individual DSC files.
>
> There were two exceptions to the above rule: DynamicTablesPkg was only
> build-tested with AARCH64 (despite its SUPPORTED_ARCHITECTURES), given
> that 32-bit ARM has no ACPI bindings. StandaloneMmPkg too was only
> build-tested with AARCH64; it doesn't actually support IA32/X64 yet.
>
> Regarding boot & runtime tests, ArmVirtQemu on AARCH64 was tested with
> booting to the OS (RHEL7). Furthermore, I exercised OVMF with my usual
> boot and S3 tests, covering IA32, IA32X64, and X64. Finally, some other
> individual tests (noted per patch) were done with OVMF.
This patch series is now ready to be pushed (it's fully reviewed),
except for the following two patches:
* [edk2-devel] [PATCH 01/35]
DO NOT APPLY: edk2: turn standard handle types into pointers to
non-VOID
* [edk2-devel] [PATCH 25/35]
OvmfPkg/VideoDxe: document EFI_EDID_OVERRIDE_PROTOCOL.GetEdid() call
Regarding 01/35, it was never meant to be pushed (certainly not in this
form); plus it would likely be too early for a number of out-of-tree
platforms.
We have discussed enabling "strict UEFI types" (even by default,
possibly). That's a great goal. And I don't have any time for pursuing
it. :( So yes, I'm aware the problems will likely reproduce over time;
I'm sorry about that.
Regarding 25/35, the original (unpatched) code might actually prove
correct there (needing a fix in the EFI_EDID_OVERRIDE_PROTOCOL_GET_EDID
definition instead). That depends on
<https://mantis.uefi.org/mantis/view.php?id=2018>, however.
I've reached out to Andy Hayes here:
http://mid.mail-archive.com/985de369-7880-b6cc-46e7-5a2edca6582b@redhat.com
https://edk2.groups.io/g/devel/message/48487
but I've not received any feedback yet.
So tomorrow I plan to re-run some sanity builds, with all patches except
#01 and #25 applied. If the builds still complete, I'm going to push the
other 33 patches.
Thanks,
Laszlo
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [edk2-devel] [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs
2019-10-08 23:49 ` Laszlo Ersek
@ 2019-10-09 9:50 ` Laszlo Ersek
0 siblings, 0 replies; 155+ messages in thread
From: Laszlo Ersek @ 2019-10-09 9:50 UTC (permalink / raw)
To: edk2-devel-groups-io
Cc: Achin Gupta, Andrew Fish, Anthony Perard, Ard Biesheuvel,
Benjamin You, Chao Zhang, Dandan Bi, David Woodhouse, Eric Dong,
Guo Dong, Hao A Wu, Jaben Carsey, Jian J Wang, Jiaxin Wu,
Jiewen Yao, Jordan Justen, Julien Grall, Leif Lindholm,
Liming Gao, Maurice Ma, Michael D Kinney, Ray Ni, Siyuan Fu,
Supreeth Venkatesh, Zhichao Gao
On 10/09/19 01:49, Laszlo Ersek wrote:
> On 09/17/19 21:49, Laszlo Ersek wrote:
>> Repository: https://github.com/lersek/edk2.git
>> Branch: voidptr
>>
>> The UEFI / PI / Shell specifications define a number of standard types
>> as pointers to VOID. This is arguably a design mistake; those types
>> should have been pointers to distinct incomplete union or structure
>> types. Here's why:
>>
>> Roughly paraphrasing the constraints from ISO C99 "6.5.16.1 Simple
>> assignment" and "6.5.4 Cast operators", any pointer-to-object type
>> converts implicitly to, and from, pointer-to-void, provided const /
>> volatile qualifications are not relaxed. Such implicit conversions
>> prevent compilers from catching at least the following two kinds of
>> coding mistakes:
>>
>> - mixing up one type with another (for example, EFI_HANDLE with
>> EFI_EVENT),
>>
>> - getting the depth of indirection wrong (for example, mixing up
>> (EFI_HANDLE*) with EFI_HANDLE).
>>
>> This series first separates these standard types from each other, in the
>> first patch, which is *not* being proposed for merging. This unmasks a
>> number of warts (semantic issues, or actual bugs) in the source code, in
>> the form of build breakages. The rest of the series works through those
>> breakages, cleaning and fixing the code.
>>
>> Every DSC file in the edk2 tree was built for at least one of the NOOPT,
>> DEBUG, RELEASE targets (NOOPT being preferred), with the GCC48 toolchain
>> (for IA32 / X64) and the GCC5 toolchain (for ARM / AARCH64). Of course,
>> the build arches were restricted to the SUPPORTED_ARCHITECTURES stated
>> in the individual DSC files.
>>
>> There were two exceptions to the above rule: DynamicTablesPkg was only
>> build-tested with AARCH64 (despite its SUPPORTED_ARCHITECTURES), given
>> that 32-bit ARM has no ACPI bindings. StandaloneMmPkg too was only
>> build-tested with AARCH64; it doesn't actually support IA32/X64 yet.
>>
>> Regarding boot & runtime tests, ArmVirtQemu on AARCH64 was tested with
>> booting to the OS (RHEL7). Furthermore, I exercised OVMF with my usual
>> boot and S3 tests, covering IA32, IA32X64, and X64. Finally, some other
>> individual tests (noted per patch) were done with OVMF.
>
> This patch series is now ready to be pushed (it's fully reviewed),
> except for the following two patches:
>
> * [edk2-devel] [PATCH 01/35]
> DO NOT APPLY: edk2: turn standard handle types into pointers to
> non-VOID
>
> * [edk2-devel] [PATCH 25/35]
> OvmfPkg/VideoDxe: document EFI_EDID_OVERRIDE_PROTOCOL.GetEdid() call
>
> Regarding 01/35, it was never meant to be pushed (certainly not in this
> form); plus it would likely be too early for a number of out-of-tree
> platforms.
>
> We have discussed enabling "strict UEFI types" (even by default,
> possibly). That's a great goal. And I don't have any time for pursuing
> it. :( So yes, I'm aware the problems will likely reproduce over time;
> I'm sorry about that.
>
> Regarding 25/35, the original (unpatched) code might actually prove
> correct there (needing a fix in the EFI_EDID_OVERRIDE_PROTOCOL_GET_EDID
> definition instead). That depends on
> <https://mantis.uefi.org/mantis/view.php?id=2018>, however.
>
> I've reached out to Andy Hayes here:
>
> http://mid.mail-archive.com/985de369-7880-b6cc-46e7-5a2edca6582b@redhat.com
> https://edk2.groups.io/g/devel/message/48487
>
> but I've not received any feedback yet.
>
> So tomorrow I plan to re-run some sanity builds, with all patches except
> #01 and #25 applied. If the builds still complete, I'm going to push the
> other 33 patches.
Commit range 2de1f611be06..976d0353a6ce.
Thanks,
Laszlo
^ permalink raw reply [flat|nested] 155+ messages in thread
end of thread, other threads:[~2019-10-09 9:50 UTC | newest]
Thread overview: 155+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-09-17 19:49 [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs Laszlo Ersek
2019-09-17 19:49 ` [PATCH 01/35] DO NOT APPLY: edk2: turn standard handle types into pointers to non-VOID Laszlo Ersek
2019-09-17 20:06 ` [edk2-devel] " Ni, Ray
2019-09-17 20:22 ` Andrew Fish
2019-09-17 20:28 ` Ni, Ray
2019-09-17 21:07 ` Andrew Fish
2019-09-17 21:11 ` Michael D Kinney
2019-09-18 8:41 ` Laszlo Ersek
2019-09-18 15:16 ` Michael D Kinney
2019-09-18 17:41 ` Laszlo Ersek
2019-09-18 15:55 ` Andrew Fish
2019-09-18 16:16 ` Leif Lindholm
2019-09-18 17:45 ` Laszlo Ersek
2019-09-18 8:36 ` Laszlo Ersek
2019-09-17 19:49 ` [PATCH 02/35] EmbeddedPkg: add missing EFIAPI calling convention specifiers Laszlo Ersek
2019-09-18 17:41 ` Leif Lindholm
2019-09-17 19:49 ` [PATCH 03/35] EmbeddedPkg/AndroidFastbootTransportTcpDxe: fix DestroyChild() call Laszlo Ersek
2019-09-24 10:47 ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-26 12:12 ` Laszlo Ersek
2019-09-26 12:16 ` Ard Biesheuvel
2019-09-17 19:49 ` [PATCH 04/35] EmbeddedPkg/Universal/MmcDxe: "fix" CloseProtocol() call in BindingStop() Laszlo Ersek
2019-09-25 15:52 ` Ard Biesheuvel
2019-09-17 19:49 ` [PATCH 05/35] EmulatorPkg/DxeTimerLib: drop superfluous cast Laszlo Ersek
2019-09-17 20:02 ` Ni, Ray
2019-09-20 15:00 ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-17 19:49 ` [PATCH 06/35] EmulatorPkg: stop abusing EFI_HANDLE for keystroke notify registration Laszlo Ersek
2019-09-17 20:01 ` Ni, Ray
2019-09-24 10:44 ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-17 19:49 ` [PATCH 07/35] MdeModulePkg: fix cast in GetModuleInfoFromHandle() calls Laszlo Ersek
2019-09-19 1:46 ` Dandan Bi
2019-09-24 10:43 ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-17 19:49 ` [PATCH 08/35] MdeModulePkg/UefiHiiLib: stop using EFI_HANDLE in place of EFI_HII_HANDLE Laszlo Ersek
2019-09-19 1:46 ` Dandan Bi
2019-09-24 10:49 ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-17 19:49 ` [PATCH 09/35] MdeModulePkg: stop abusing EFI_EVENT for protocol notify registration Laszlo Ersek
2019-09-17 20:17 ` Ni, Ray
2019-09-25 16:02 ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-26 12:10 ` Laszlo Ersek
2019-09-17 19:49 ` [PATCH 10/35] MdeModulePkg/PlatformVarCleanupLib: fix HiiConstructConfigHdr() call Laszlo Ersek
2019-09-23 11:45 ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-24 17:28 ` Laszlo Ersek
2019-09-17 19:49 ` [PATCH 11/35] MdeModulePkg: document workaround for EFI_RUNTIME_EVENT_ENTRY PI spec bug Laszlo Ersek
2019-09-19 1:47 ` Dandan Bi
2019-09-17 19:49 ` [PATCH 12/35] MdeModulePkg: stop abusing EFI_HANDLE for keystroke notify registration Laszlo Ersek
2019-09-17 20:16 ` [edk2-devel] " Ni, Ray
2019-09-19 1:47 ` Dandan Bi
2019-09-24 10:54 ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-17 19:49 ` [PATCH 13/35] MdeModulePkg: PEI Core: clean up "AprioriFile" handling in FindFileEx() Laszlo Ersek
2019-09-19 1:46 ` Dandan Bi
2019-09-24 15:40 ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-17 19:49 ` [PATCH 14/35] MdeModulePkg: fix UninstallMultipleProtocolInterfaces() calls Laszlo Ersek
2019-09-17 20:16 ` Ni, Ray
2019-09-17 19:49 ` [PATCH 15/35] MdeModulePkg/PiSmmCore: make type punning consistent Laszlo Ersek
2019-09-18 2:38 ` Dong, Eric
2019-09-17 19:49 ` [PATCH 16/35] MdeModulePkg/S3SaveState: cast Position for S3BootScriptLib explicitly Laszlo Ersek
2019-09-19 1:47 ` [edk2-devel] " Dandan Bi
2019-09-17 19:49 ` [PATCH 17/35] MdePkg/DxeServicesLib: remove bogus cast Laszlo Ersek
2019-09-18 4:47 ` [edk2-devel] " Liming Gao
2019-09-24 15:38 ` Philippe Mathieu-Daudé
2019-09-17 19:49 ` [PATCH 18/35] NetworkPkg/DxeNetLib: fix type typo in NetLibGetMacAddress() Laszlo Ersek
2019-09-24 11:00 ` [edk2-devel] " Philippe Mathieu-Daudé
2019-10-08 0:32 ` Siyuan, Fu
2019-10-08 23:36 ` Laszlo Ersek
2019-09-26 12:14 ` Laszlo Ersek
2019-10-03 11:05 ` Laszlo Ersek
2019-10-04 19:18 ` Laszlo Ersek
2019-10-07 18:15 ` Michael D Kinney
2019-09-17 19:49 ` [PATCH 19/35] NetworkPkg: fix CloseProtocol & UninstallMultipleProtocolInterfaces calls Laszlo Ersek
2019-09-26 12:14 ` [edk2-devel] " Laszlo Ersek
2019-09-26 12:42 ` Philippe Mathieu-Daudé
2019-09-30 20:16 ` Laszlo Ersek
2019-10-01 7:18 ` Philippe Mathieu-Daudé
2019-09-27 0:03 ` Siyuan, Fu
2019-09-17 19:49 ` [PATCH 20/35] NetworkPkg/Ip4Dxe: fix NetLibDestroyServiceChild() call Laszlo Ersek
2019-09-23 16:03 ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-27 0:04 ` Siyuan, Fu
2019-09-26 12:14 ` Laszlo Ersek
2019-09-17 19:49 ` [PATCH 21/35] NetworkPkg/TcpDxe: fix SockFreeFoo() parameter list Laszlo Ersek
2019-09-23 15:09 ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-26 12:14 ` Laszlo Ersek
2019-09-27 0:06 ` Siyuan, Fu
2019-09-17 19:49 ` [PATCH 22/35] OvmfPkg/XenBusDxe: fix UninstallMultipleProtocolInterfaces() call Laszlo Ersek
2019-09-18 9:32 ` Anthony PERARD
2019-09-18 10:30 ` Julien Grall
2019-09-23 15:03 ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-17 19:49 ` [PATCH 23/35] OvmfPkg/VirtioNetDxe: fix SignalEvent() call Laszlo Ersek
2019-09-20 14:59 ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-26 12:16 ` Laszlo Ersek
2019-09-26 12:17 ` Ard Biesheuvel
2019-09-17 19:49 ` [PATCH 24/35] OvmfPkg/PlatformDxe: fix EFI_HII_HANDLE parameters of internal functions Laszlo Ersek
2019-09-20 14:56 ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-25 15:57 ` Ard Biesheuvel
2019-09-17 19:49 ` [PATCH 25/35] OvmfPkg/VideoDxe: document EFI_EDID_OVERRIDE_PROTOCOL.GetEdid() call Laszlo Ersek
2019-09-23 15:59 ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-26 12:43 ` Laszlo Ersek
2019-10-04 20:01 ` Laszlo Ersek
2019-09-17 19:49 ` [PATCH 26/35] SecurityPkg: fix UninstallMultipleProtocolInterfaces() calls Laszlo Ersek
2019-09-23 9:55 ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-26 12:45 ` Laszlo Ersek
2019-10-03 11:06 ` Laszlo Ersek
2019-10-04 0:05 ` Yao, Jiewen
2019-10-04 13:14 ` Zhang, Chao B
2019-10-04 18:15 ` Laszlo Ersek
2019-10-05 14:28 ` Zhang, Chao B
2019-10-07 18:14 ` Laszlo Ersek
2019-09-17 19:49 ` [PATCH 27/35] SecurityPkg: stop abusing EFI_EVENT for protocol notify registration Laszlo Ersek
2019-09-23 9:56 ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-26 12:46 ` Laszlo Ersek
2019-10-03 11:06 ` Laszlo Ersek
2019-10-04 0:05 ` Yao, Jiewen
2019-10-04 13:16 ` Zhang, Chao B
2019-10-05 14:28 ` Zhang, Chao B
2019-09-17 19:49 ` [PATCH 28/35] ShellPkg/UefiShellDriver1CommandsLib: fix parameter list typo Laszlo Ersek
2019-09-24 15:44 ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-26 2:46 ` Gao, Zhichao
2019-09-17 19:49 ` [PATCH 29/35] ShellPkg: stop using EFI_HANDLE in place of EFI_HII_HANDLE Laszlo Ersek
2019-09-25 18:04 ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-26 11:48 ` Laszlo Ersek
2019-09-26 2:43 ` Gao, Zhichao
2019-09-17 19:49 ` [PATCH 30/35] ShellPkg: stop taking EFI_HANDLE in place of SHELL_FILE_HANDLE Laszlo Ersek
2019-09-23 9:58 ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-26 2:53 ` Gao, Zhichao
2019-09-26 12:08 ` Laszlo Ersek
2019-09-26 14:43 ` Gao, Zhichao
2019-09-30 19:52 ` Laszlo Ersek
2019-09-17 19:49 ` [PATCH 31/35] ShellPkg/UefiShellDebug1CommandsLib: fix ShellCloseFile() call Laszlo Ersek
2019-09-23 10:01 ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-23 14:28 ` Carsey, Jaben
2019-09-24 1:18 ` Gao, Zhichao
2019-09-17 19:49 ` [PATCH 32/35] ShellPkg/UefiShellLib: clarify workaround for unfixable EdkShell bug Laszlo Ersek
2019-09-26 12:47 ` [edk2-devel] " Laszlo Ersek
2019-09-26 14:05 ` Gao, Zhichao
2019-09-26 14:58 ` Carsey, Jaben
2019-09-17 19:49 ` [PATCH 33/35] StandaloneMmPkg/Core: stop abusing EFI_HANDLE for FwVolHeader tracking Laszlo Ersek
2019-09-26 12:48 ` [edk2-devel] " Laszlo Ersek
2019-10-03 11:10 ` Laszlo Ersek
2019-10-03 11:17 ` Achin Gupta
2019-10-04 0:10 ` Yao, Jiewen
2019-10-04 14:53 ` Achin Gupta
2019-09-17 19:49 ` [PATCH 34/35] UefiPayloadPkg/BlSupportPei: fix MMCONFIG assignment from XSDT Laszlo Ersek
2019-09-23 2:30 ` Guo Dong
2019-09-26 13:17 ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-17 19:49 ` [PATCH 35/35] UefiPayloadPkg/BlSupportDxe: fix ReserveResourceInGcd() calls Laszlo Ersek
2019-09-23 2:28 ` [edk2-devel] " Guo Dong
2019-09-23 15:08 ` Philippe Mathieu-Daudé
2019-09-23 16:02 ` Guo Dong
2019-09-23 16:04 ` Philippe Mathieu-Daudé
2019-09-24 17:29 ` Laszlo Ersek
2019-09-19 0:32 ` [edk2-devel] [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs Wu, Hao A
2019-09-23 16:27 ` Marvin Häuser
2019-09-24 20:26 ` Laszlo Ersek
2019-09-25 8:13 ` Marvin Häuser
2019-09-25 15:54 ` Laszlo Ersek
2019-10-08 23:49 ` Laszlo Ersek
2019-10-09 9:50 ` Laszlo Ersek
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox