Hi David, David Woodhouse <dw...@infradead.org> writes:
> [[S/MIME Signed Part:Undecided]] > On Tue, 2023-11-21 at 22:10 +0000, Volodymyr Babchuk wrote: >> >> --- a/hw/xen/xen-operations.c >> +++ b/hw/xen/xen-operations.c >> @@ -300,6 +300,18 @@ static bool libxenstore_create(struct qemu_xs_handle >> *h, xs_transaction_t t, >> return false; >> } >> >> + if (owner == XS_PRESERVE_OWNER) { >> + struct xs_permissions *tmp; >> + unsigned int num; >> + >> + tmp = xs_get_permissions(h->xsh, t, path, &num); >> + if (tmp == NULL) { >> + return false; >> + } >> + perms_list[0].id = tmp[0].id; >> + free(tmp); >> + } >> + >> return xs_set_permissions(h->xsh, t, path, perms_list, >> ARRAY_SIZE(perms_list)); >> } > > If the existing transaction is XBT_NULL I think you want to create a > new transaction for it, don't you? I must say that your comment is valid even without my changes. xenstore_mkdir() calls qemu_xen_xs_create, providing just plain "0" (not even XBT_NULL) as a transaction, but actual xenstore interface implementation, like xs_be_create(), issue multiple calls to lower layer, passing "t" downwards. For example, xs_be_create() calls xs_impl_read, xs_impl_write and xs_impl_set_perms(). If called from xesntore_mkdir(), those three operations will be non-atomic. I don't know if this can lead to a problem, because apparently it was so for a long time... -- WBR, Volodymyr