Halil Pasic <pa...@linux.ibm.com> writes: > On Thu, 11 May 2023 14:20:51 +0200 > Markus Armbruster <arm...@redhat.com> wrote: > [..] >> > >> > In my opinion the best way to deal with such situations would be to >> > abort() in test/development and log a warning in production. Of course >> >> Understand, but... >> >> > assert() wouldn't give me that, and it wouldn't be locally consistent at >> > all. >> >> ... nothing behaves like that so far. >> > > I understand. And I agree with all statements from your previous mail. > >> Let's try to come to a conclusion. We can either keep the current >> behavior, i.e. abort(). Or we change it to just print something. >> >> If we want the latter: fprintf() to stderr, warn_report(), or trace >> point? >> >> You are the maintainer, so the decision is yours. >> >> I could stick a patch into a series of error-related cleanup patches I'm >> working on. > > I would gladly take that offer. Given that we didn't see any crashes and > thus violations of assumptions up till now, and that both the kvm and the > qemu implementations are from my perspective stable, I think not forcing > a crash is a good option. From the options you offered, warn_report() > looks the most compelling to me, but I would trust your expertise to pick > the actually best one. > > Thank you very much.
You're welcome! >> [*] I'm rather fond of the trick to have oopsie() fork & crash. > > I never thought of this, but I do actually find it very compelling > to get a dump while keeping the workload alive. Especially if > it was oopsie_once() so one does not get buried in dumps. But we don't > do things like this in QEMU, or do we? No, we don't.
