[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [BUG] kernel bug encountered at drivers/net/xen-netback/netback.c:430!

## Paul Durrant (Paul.Durrant@xxxxxxxxxx):

> How easy is it to trigger this? I'm assuming, from the original
> description, that I can probably trigger it by forcibly terminating
> a running domain and then trying to restart it.

As Alex said: in the "common cases" (like his and mine) it seems to
be enough to run a few DomUs and just wait a little (no special
load required) - with my 10 domains, the bg triggers in a few minutes
( https://lists.xenproject.org/archives/html/xen-devel/2017-12/msg01516.html
is my report of the issue - I didn't spot Alex' report).
The order of event here is:
- boot Dom0
- xl create a few DomUs (all recent Linux, all builder=hvm in my setup,
  each VM has exactly one virtual network interface, all bridged onto
  the one ethernet interface on the Dom0 which carries all traffic
  to the Dom0 and the DomUs)
- after a few minutes, the Dom0 kernel logs the BUG() in question
- shortly after (not immediately! - may take even some more minutes)
  the DomU behind the vif reported in the BUG becomes unresponsive:
  no network traffic, no reaction on the virtual console, no message
  in syslog).
- trying to xl destroy the unresponsive domain (or trying to do a
  normal shutdown on one of the other domains) results in the corrupted
  state documented in my earlier report (see link).

In my case this "cannot" be an issue with an old gcc - Debian 9 ships
with "gcc (Debian 6.3.0-18) 6.3.0 20170516" (but beware of new bugs,
who knows?).

I could try a new kernel (KPTI, yay!) with that "mildly suspicious" commit
cc8737a5fe9051b7fa052b08c57ddb9f539c389a reverted on the weekend and
report back (just to rule that out - like you, I don't really believe
that this is the cause).
For the record, I'm still running 4.13.16 on the Dom0 (that's the last
working Dom0 kernel).


Spare Space

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.