Re: css_clear_io_interrupt() error handling

[Markus Armbruster <armbru@redhat.com>]

Halil Pasic <pasic@linux.ibm.com> writes:

> On Thu, 11 May 2023 14:20:51 +0200
> Markus Armbruster <armbru@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.