On a Thursday in 2022, Peter Krempa wrote:
Glib can internally convert only unix timestamps up to
9999-12-31T23:59:59 (253402300799). Validate that the user doesn't use
more than that as otherwise we cause an assertion failure:
(process:1183396): GLib-CRITICAL **: 14:25:00.906: g_date_time_format: assertion 'datetime != NULL' failed
Additionally adjust the schema to allow bigger values as we use
'unsigned long long' to parse the value.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2128993
Signed-off-by: Peter Krempa <pkrempa@xxxxxxxxxx>
---
src/conf/schemas/domaincommon.rng | 2 +-
src/qemu/qemu_validate.c | 17 +++++++++++++++++
.../clock-absolute.x86_64-latest.args | 2 +-
tests/qemuxml2argvdata/clock-absolute.xml | 2 +-
.../clock-absolute.x86_64-latest.xml | 2 +-
5 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/src/conf/schemas/domaincommon.rng b/src/conf/schemas/domaincommon.rng
index ebb39de3ef..cefe818044 100644
--- a/src/conf/schemas/domaincommon.rng
+++ b/src/conf/schemas/domaincommon.rng
@@ -1312,7 +1312,7 @@
<value>absolute</value>
</attribute>
<attribute name="start">
- <ref name="unsignedInt"/>
+ <ref name="unsignedLong"/>
</attribute>
</group>
</choice>
diff --git a/src/qemu/qemu_validate.c b/src/qemu/qemu_validate.c
index 1456a69351..1d4081e47e 100644
--- a/src/qemu/qemu_validate.c
+++ b/src/qemu/qemu_validate.c
@@ -663,6 +663,23 @@ qemuValidateDomainDefClockTimers(const virDomainDef *def,
}
}
+ switch ((virDomainClockOffsetType) def->clock.offset) {
+ case VIR_DOMAIN_CLOCK_OFFSET_ABSOLUTE:
+ /* maximum timestamp glib can convert is 9999-12-31T23:59:59 */
Consider #defining this as a constant, e.g.
#define QEMU_MAX_GLIB_TIMESTAMP (2932896 * (24 * 60 * 60) + 23 * (60 * 60) + 59 * (60) + 59)
+ if (def->clock.data.starttime > 253402300799) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
+ _("The maximum 'start' value for <clock offset='absolute'> is 253402300799"));
+ return -1;
+ }
+
Regardless of my above suggestion:
Reviewed-by: Ján Tomko <jtomko@xxxxxxxxxx>
Jano
