| Message ID | 20231101090024.28934-3-jgross@suse.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Mini-OS: preparations for 9pfs in xenstore-stubdom | expand |
On Wed, Nov 1, 2023 at 5:06 AM Juergen Gross <jgross@suse.com> wrote: > > It might be perfectly fine not to have a control/shutdown Xenstore > node. If this is the case, don't crash, but just terminate the > shutdown thread after issuing a message that shutdown isn't available. > > In fini_shutdown() clearing the watch can result in an error now, in > case the early exit above was taken. Just ignore this error now. > > Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Jason Andryuk <jandryuk@gmail.com>
On 01/11/2023 9:00 am, Juergen Gross wrote: > It might be perfectly fine not to have a control/shutdown Xenstore > node. If this is the case, don't crash, but just terminate the > shutdown thread after issuing a message that shutdown isn't available. > > In fini_shutdown() clearing the watch can result in an error now, in > case the early exit above was taken. Just ignore this error now. > > Signed-off-by: Juergen Gross <jgross@suse.com> Which cases might we not have a control/shutdown node? I'm all for coping better with its absence, but it's not a piece of the Xen ABI which is optional. And on that front, not crashing is good, but why remove the watch? What if it comes into existence later? Is there any problem with just leaving the watch outstanding? ~Andrew
On 01.11.23 17:38, Andrew Cooper wrote: > On 01/11/2023 9:00 am, Juergen Gross wrote: >> It might be perfectly fine not to have a control/shutdown Xenstore >> node. If this is the case, don't crash, but just terminate the >> shutdown thread after issuing a message that shutdown isn't available. >> >> In fini_shutdown() clearing the watch can result in an error now, in >> case the early exit above was taken. Just ignore this error now. >> >> Signed-off-by: Juergen Gross <jgross@suse.com> > > Which cases might we not have a control/shutdown node? Xenstore-stubdom. It should _never_ shutdown, and it isn't really under control of Xen tools (other than being created). > I'm all for coping better with its absence, but it's not a piece of the > Xen ABI which is optional. I'd like to differ here. See reasoning above. > And on that front, not crashing is good, but why remove the watch? What > if it comes into existence later? Is there any problem with just > leaving the watch outstanding? A needless waste of memory in Xenstore-stubdom. Juergen
On 01/11/2023 4:42 pm, Juergen Gross wrote: > On 01.11.23 17:38, Andrew Cooper wrote: >> On 01/11/2023 9:00 am, Juergen Gross wrote: >>> It might be perfectly fine not to have a control/shutdown Xenstore >>> node. If this is the case, don't crash, but just terminate the >>> shutdown thread after issuing a message that shutdown isn't available. >>> >>> In fini_shutdown() clearing the watch can result in an error now, in >>> case the early exit above was taken. Just ignore this error now. >>> >>> Signed-off-by: Juergen Gross <jgross@suse.com> >> >> Which cases might we not have a control/shutdown node? > > Xenstore-stubdom. It should _never_ shutdown, and it isn't really under > control of Xen tools (other than being created). > >> I'm all for coping better with its absence, but it's not a piece of the >> Xen ABI which is optional. > > I'd like to differ here. See reasoning above. If we're going to permit this configuration, then I think it needs an extension to xenstore-paths to make it officially optional. And I think it's reasonable to support, but I wouldn't go as far as saying "never". If you've cleaved the global xenstored in twain/trine/etc, then individual parts of it can shut down normally. ~Andrew
On 01.11.23 17:57, Andrew Cooper wrote: > On 01/11/2023 4:42 pm, Juergen Gross wrote: >> On 01.11.23 17:38, Andrew Cooper wrote: >>> On 01/11/2023 9:00 am, Juergen Gross wrote: >>>> It might be perfectly fine not to have a control/shutdown Xenstore >>>> node. If this is the case, don't crash, but just terminate the >>>> shutdown thread after issuing a message that shutdown isn't available. >>>> >>>> In fini_shutdown() clearing the watch can result in an error now, in >>>> case the early exit above was taken. Just ignore this error now. >>>> >>>> Signed-off-by: Juergen Gross <jgross@suse.com> >>> >>> Which cases might we not have a control/shutdown node? >> >> Xenstore-stubdom. It should _never_ shutdown, and it isn't really under >> control of Xen tools (other than being created). >> >>> I'm all for coping better with its absence, but it's not a piece of the >>> Xen ABI which is optional. >> >> I'd like to differ here. See reasoning above. > > If we're going to permit this configuration, then I think it needs an > extension to xenstore-paths to make it officially optional. > > And I think it's reasonable to support, but I wouldn't go as far as > saying "never". If you've cleaved the global xenstored in > twain/trine/etc, then individual parts of it can shut down normally. Xenstore-stubdom is a very special case. I don't think its shutdown node can be under control of the normal Xen tools, as only the stubdom can know whether it is able to react in any sensible way to it. It needs to take specific measures to ensure that even its ABI-compliant reaction to a shutdown request is visible to Xen tools (remember that this reaction is a write to the shutdown node causing a watch event in dom0, which won't work with Xenstore going down). In the end there is no way the shutdown node can be present when starting Xenstore-stubdom. There is no Xenstore at the time the node is probed in today's Mini-OS boot sequence. Juergen
diff --git a/shutdown.c b/shutdown.c index bb2c6f11..ded6b64d 100644 --- a/shutdown.c +++ b/shutdown.c @@ -75,7 +75,9 @@ static void shutdown_thread(void *p) xenbus_wait_for_watch(&events); if ((err = xenbus_read(XBT_NIL, path, &shutdown))) { free(err); - do_exit(); + free(xenbus_unwatch_path_token(XBT_NIL, path, token)); + printk("Shutdown Xenstore node not available.\n"); + return; } if (end_shutdown_thread) @@ -117,15 +119,9 @@ void init_shutdown(void) void fini_shutdown(void) { - char *err; - end_shutdown_thread = 1; xenbus_release_wait_for_watch(&events); - err = xenbus_unwatch_path_token(XBT_NIL, path, token); - if (err) { - free(err); - do_exit(); - } + free(xenbus_unwatch_path_token(XBT_NIL, path, token)); } #endif
It might be perfectly fine not to have a control/shutdown Xenstore node. If this is the case, don't crash, but just terminate the shutdown thread after issuing a message that shutdown isn't available. In fini_shutdown() clearing the watch can result in an error now, in case the early exit above was taken. Just ignore this error now. Signed-off-by: Juergen Gross <jgross@suse.com> --- shutdown.c | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-)