There are cases that the operands of an expression are all with rank less
than UINT64/INT64 and the result of the expression is explicitly cast to
UINT64/INT64 to fit the target size.
An example will be:
UINT32 a,b;
// a and b can be any unsigned int type with rank less than UINT64, like
// UINT8, UINT16, etc.
UINT64 c;
c = (UINT64) (a + b);
Some static code checkers may warn that the expression result might
overflow within the rank of "int" (integer promotions) and the result is
then cast to a bigger size.
The commit refines codes by the following rules:
1). When the expression is possible to overflow the range of unsigned int/
int:
c = (UINT64)a + b;
2). When the expression will not overflow within the rank of "int", remove
the explicit type casts:
c = a + b;
3). When the expression will be cast to pointer of possible greater size:
UINT32 a,b;
VOID *c;
c = (VOID *)(UINTN)(a + b); --> c = (VOID *)((UINTN)a + b);
4). When one side of a comparison expression contains only operands with
rank less than UINT32:
UINT8 a;
UINT16 b;
UINTN c;
if ((UINTN)(a + b) > c) {...} --> if (((UINT32)a + b) > c) {...}
For rule 4), if we remove the 'UINTN' type cast like:
if (a + b > c) {...}
The VS compiler will complain with warning C4018 (signed/unsigned
mismatch, level 3 warning) due to promoting 'a + b' to type 'int'.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
The IsValidWorkSpace() function checks if the working block header of the
workspace is valid. A mismatch detected by this function is not
necessarily an error; it can happen with an as-yet unwritten flash chip,
which is e.g. common and normal when a new ArmVirtQemu virtual machine is
booted. Therefore downgrade the message emitted by IsValidWorkSpace() from
EFI_D_ERROR to EFI_D_INFO, and change the wording from "error" to
"mismatch".
The only caller of IsValidWorkSpace(), InitFtwProtocol(), handles all of
the following cases:
(1) IsValidWorkSpace() succeeds for the working block -- this is normal
operation,
(2) IsValidWorkSpace() fails for the working block, but succeeds for the
spare block -- InitFtwProtocol() then restores the working block from
the spare block,
(3) IsValidWorkSpace() fails for both the working and spare blocks --
InitFtwProtocol() reinitializes the full workspace.
In cases (2) and (3), InitFtwProtocol() logs additional messages about the
branch taken. Their current level is EFI_D_ERROR, but the messages are
arguably informative, not necessarily error reports.
Downgrade these messages from EFI_D_ERROR to EFI_D_INFO, so that they
don't clutter the debug output when the PcdDebugPrintErrorLevel mask only
enables EFI_D_ERROR (i.e., in a "silent" build).
These messages have annoyed / confused users; see for example:
- https://bugzilla.redhat.com/show_bug.cgi?id=1270279
Cc: Star Zeng <star.zeng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Drew Jones <drjones@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18619 6f19259b-4bc3-4df7-8a09-765794883524
There may be anti-flash wear out feature to forbid erase operation after end of dxe.
The code is missing some error handling for erase operation failure,
it should return directly after the erase operation failed.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18320 6f19259b-4bc3-4df7-8a09-765794883524
1. Work space and spare block must be in a FVB with FV header.
Updated to work space and spare block could be in independent FVBs that are without FV header.
2. NV region, work space and spare block must have same BlockSize.
Updated to NV region, work space and spare block could have different BlockSize.
3. Works space size must be <= one block size.
Update to work space size could be <= one block size (not span blocks) or > one block size (block size aligned).
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16201 6f19259b-4bc3-4df7-8a09-765794883524
PEI variable implementation checks only the variable header signature for validity. This does not seem robust if system crash occurred during previous Reclaim() operation. If the crash occurred while FTW was rewriting the variable FV, the signature could be valid even though the rest of the FV isn't valid.
Solution: Add a FaultTolerantWritePei driver to check and provide the FTW last write status, then PEI variable and early phase(before FTW protocol ready) of DXE variable can check the status and determine if all or partial variable data has been backed up in spare block, and then use the backed up data.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14454 6f19259b-4bc3-4df7-8a09-765794883524
Hao Wu
Laszlo Ersek
Star Zeng
Samer El-Haj-Mahmoud
lzeng14
erictian
hhtian
lgao4