On 14.03.25 13:58, Jason Andryuk wrote:
On 2025-03-14 08:18, Juergen Gross wrote:Use the new unique_id of a domain in order to detect that a domain has been replaced with another one reusing the doamin-id of the old domain.While changing the related code, switch from "dom_invalid" to "dom_valid" in order to avoid double negation and use "bool" as type for it. Signed-off-by: Juergen Gross <jgr...@suse.com> --- V8: - new patch V9: - adapt to different LU-record layout - "dom_invalid" -> "dom_valid" (Jason Andryuk)Thanks. Reviewed-by: Jason Andryuk <jason.andr...@amd.com> One thought below.--- tools/xenstored/domain.c | 65 ++++++++++++++++++++++++++------ tools/xenstored/xenstore_state.h | 3 +- 2 files changed, 55 insertions(+), 13 deletions(-) diff --git a/tools/xenstored/domain.c b/tools/xenstored/domain.c index a6506a5bb2..fc0992d3a5 100644 --- a/tools/xenstored/domain.c +++ b/tools/xenstored/domain.c@@ -1778,6 +1811,14 @@ void read_state_connection(const void *ctx, const void *state)conn->conn_id = sc->conn_id; read_state_buffered_data(ctx, conn, sc); + + /* Validity of unique_id will be tested by check_domains() later. */ + if ((sc->fields & XS_STATE_CONN_FIELDS_UNIQ_ID) && domain) {Is it worth adding a sanity check for the other bits in sc->fields == 0?
Definitely not. Unknown flags can be ignored, they should never result in an error. Otherwise LU to an older Xenstore might not be possible any longer.
And a check domain != NULL when XS_STATE_CONN_FIELDS_UNIQ_ID is set?
No, I don't think so. Failing a LU due to such a case would inhibit the possibility to fix such a bug using LU. Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
