|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [ovmf baseline-only test] 72177: all pass
This run is configured for baseline tests only. flight 72177 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/72177/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 27daa8658e518902bf281b07993c2d60af1913c3 baseline version: ovmf 4c34a8ea191155f438901e635bd87810072b19a4 Last test of basis 72176 2017-09-29 08:47:35 Z 0 days Testing same since 72177 2017-09-29 15:19:31 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Hao Wu <hao.a.wu@xxxxxxxxx> Ruiyu Ni <ruiyu.ni@xxxxxxxxx> jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass ------------------------------------------------------------ sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. ------------------------------------------------------------ commit 27daa8658e518902bf281b07993c2d60af1913c3 Author: Hao Wu <hao.a.wu@xxxxxxxxx> Date: Tue Sep 19 16:11:29 2017 +0800 MdeModulePkg/AtaAtapiPassThru: Fix possible out of range left shift REF: https://bugzilla.tianocore.org/show_bug.cgi?id=699 Within function AhciModeInitialization(), left shift operations of 'BIT0' in the following statements: "if ((PortImplementBitMap & (BIT0 << Port)) != 0) {" will incur possible out of range left shift when Port is 31, since "1 << 31" is possible to exceed the range of type 'int' (signed). According to the C11 spec, Section 6.5.7: > 4 The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated > bits are filled with zeros. If E1 has an unsigned type, the value > of the result is E1 * 2^E2 , reduced modulo one more than the > maximum value representable in the result type. If E1 has a signed > type and nonnegative value, and E1 * 2^E2 is representable in the > result type, then that is the resulting value; otherwise, the > behavior is undefined. This commit explicitly cast 'BIT0' with UINT32 to resolve this issue. Cc: Steven Shi <steven.shi@xxxxxxxxx> Cc: Eric Dong <eric.dong@xxxxxxxxx> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@xxxxxxxxx> Reviewed-by: Star Zeng <star.zeng@xxxxxxxxx> commit bd42d976d510ab56e862b7bf764b1f9e9b19337e Author: Hao Wu <hao.a.wu@xxxxxxxxx> Date: Tue Sep 19 14:00:45 2017 +0800 MdeModulePkg/DxeNetLib: Fix negative value left shift REF: https://bugzilla.tianocore.org/show_bug.cgi?id=698 Within function NetRandomInitSeed(), left shift a negative value is used in: "~Time.Hour << 24" which involves undefined behavior. Since Time.Hour is of type UINT8 (range from 0 to 23), hence ~Time.Hour will be a negative value (of type int, signed). According to the C11 spec, Section 6.5.7: > 4 The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated > bits are filled with zeros. If E1 has an unsigned type, the value > of the result is E1 * 2^E2 , reduced modulo one more than the > maximum value representable in the result type. If E1 has a signed > type and nonnegative value, and E1 * 2^E2 is representable in the > result type, then that is the resulting value; otherwise, the > behavior is undefined. This commit will remove the '~' operator before 'Time.Hour', since it seems like an implementation choice for generating the seed. Cc: Steven Shi <steven.shi@xxxxxxxxx> Cc: Qin Long <qin.long@xxxxxxxxx> Cc: Star Zeng <star.zeng@xxxxxxxxx> Cc: Eric Dong <eric.dong@xxxxxxxxx> Cc: Paolo Bonzini <pbonzini@xxxxxxxxxx> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@xxxxxxxxx> Reviewed-by: Wu Jiaxin <jiaxin.wu@xxxxxxxxx> Reviewed-by: Fu Siyuan <siyuan.fu@xxxxxxxxx> Reviewed-by: Ye Ting <ting.ye@xxxxxxxxx> commit d9be0f66ffa9580d27fe08de09d4883ea5535f07 Author: Hao Wu <hao.a.wu@xxxxxxxxx> Date: Tue Sep 19 13:25:23 2017 +0800 MdeModulePkg/Tpl: Fix negative value left shift REF: https://bugzilla.tianocore.org/show_bug.cgi?id=695 Within function CoreRestoreTpl(), left shift a negative value -2 is used in: "while (((-2 << NewTpl) & gEventPending) != 0) {" which involves undefined behavior. According to the C11 spec, Section 6.5.7: > 4 The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated > bits are filled with zeros. If E1 has an unsigned type, the value > of the result is E1 * 2^E2 , reduced modulo one more than the > maximum value representable in the result type. If E1 has a signed > type and nonnegative value, and E1 * 2^E2 is representable in the > result type, then that is the resulting value; otherwise, the > behavior is undefined. This commit refines the code logic to avoid left shifting the negative value. Cc: Steven Shi <steven.shi@xxxxxxxxx> Cc: Eric Dong <eric.dong@xxxxxxxxx> Cc: Paolo Bonzini <pbonzini@xxxxxxxxxx> Cc: Michael Kinney <michael.d.kinney@xxxxxxxxx> Cc: Liming Gao <liming.gao@xxxxxxxxx> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@xxxxxxxxx> Reviewed-by: Star Zeng <star.zeng@xxxxxxxxx> commit 1dfb0bf20e0b41d720940b2cdf4f81ebd8a099a8 Author: Hao Wu <hao.a.wu@xxxxxxxxx> Date: Tue Sep 19 16:31:54 2017 +0800 MdeModulePkg/PrintLib: Fix possible negative value left shift REF: https://bugzilla.tianocore.org/show_bug.cgi?id=702 Within function InternalPrintLibSPrintMarker(), possible left shift of a negative value is found in: "(*(ArgumentString + 1) << 8)" which involves undefined behavior. Since '*(ArgumentString + 1)' is of type CONST CHAR8 (signed), it will be promoted to type int (signed) during the left shift operation. If '*(ArgumentString + 1)' is a negative value, the behavior will be undefined. According to the C11 spec, Section 6.5.7: > 4 The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated > bits are filled with zeros. If E1 has an unsigned type, the value > of the result is E1 * 2^E2 , reduced modulo one more than the > maximum value representable in the result type. If E1 has a signed > type and nonnegative value, and E1 * 2^E2 is representable in the > result type, then that is the resulting value; otherwise, the > behavior is undefined. This commit explicitly cast '*(ArgumentString + 1)' with UINT8 to resolve this issue. Cc: Steven Shi <steven.shi@xxxxxxxxx> Cc: Michael Kinney <michael.d.kinney@xxxxxxxxx> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@xxxxxxxxx> Reviewed-by: Liming Gao <liming.gao@xxxxxxxxx> commit ea0b15067c54e8c34321e9f094515302039be12e Author: Hao Wu <hao.a.wu@xxxxxxxxx> Date: Tue Sep 19 16:42:04 2017 +0800 MdePkg/PrintLib: Fix possible negative value left shift REF: https://bugzilla.tianocore.org/show_bug.cgi?id=702 Within function InternalPrintLibSPrintMarker(), possible left shift of a negative value is found in: "(*(ArgumentString + 1) << 8)" which involves undefined behavior. Since '*(ArgumentString + 1)' is of type CONST CHAR8 (signed), it will be promoted to type int (signed) during the left shift operation. If '*(ArgumentString + 1)' is a negative value, the behavior will be undefined. According to the C11 spec, Section 6.5.7: > 4 The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated > bits are filled with zeros. If E1 has an unsigned type, the value > of the result is E1 * 2^E2 , reduced modulo one more than the > maximum value representable in the result type. If E1 has a signed > type and nonnegative value, and E1 * 2^E2 is representable in the > result type, then that is the resulting value; otherwise, the > behavior is undefined. This commit explicitly cast '*(ArgumentString + 1)' with UINT8 to resolve this issue. Cc: Steven Shi <steven.shi@xxxxxxxxx> Cc: Michael Kinney <michael.d.kinney@xxxxxxxxx> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@xxxxxxxxx> Reviewed-by: Liming Gao <liming.gao@xxxxxxxxx> commit 0e6584e38650cef9a6b4579553679c0f12d897bc Author: Ruiyu Ni <ruiyu.ni@xxxxxxxxx> Date: Thu Sep 28 13:46:20 2017 +0800 MdeModulePkg/BdsDxe: Don't delete "BootNext" until booting it Current implementation deletes the "BootNext" before calling any PlatformBootManagerLib APIs, but if system resets in PlatformBootManagerLib APIs, "BootNext" is not consumed but lost. The patch defers the deletion of "BootNext" to before booting it. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@xxxxxxxxx> Cc: Eric Dong <eric.dong@xxxxxxxxx> Reviewed-by: Star Zeng <star.zeng@xxxxxxxxx> Reviewed-by: Sunny Wang <sunnywang@xxxxxxx> commit b23592a8fe19c46e29c5afe50984e5c6b63e7e69 Author: Ruiyu Ni <ruiyu.ni@xxxxxxxxx> Date: Fri Sep 29 01:18:50 2017 +0800 ShellPkg/disconnect: '-r' is not optional when disconnecting all Correct the help message to match that defined in Shell spec. In 'DISCONNECT -r [-nc]' case, '-r' is not optional. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@xxxxxxxxx> Reviewed-by: Jaben Carsey <jaben.carsey@xxxxxxxxx> commit 52f2b02c709c9cc5fe048284d266ad45853bb97f Author: Ruiyu Ni <ruiyu.ni@xxxxxxxxx> Date: Fri Sep 29 01:14:53 2017 +0800 ShellPkg/dh: Correct typo in help Help message of "dh" gives an example to display all handles with "Image" protocol but actually "LoadedImage" protocol should be used. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@xxxxxxxxx> Reviewed-by: Jaben Carsey <jaben.carsey@xxxxxxxxx> _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |