Cornelia Huck <coh...@redhat.com> writes:
> On Wed, 30 May 2018 14:39:55 +0800
> Peter Xu <pet...@redhat.com> wrote:
>
>> On Wed, May 30, 2018 at 07:47:32AM +0300, Michael S. Tsirkin wrote:
>> > On Thu, May 24, 2018 at 12:44:53PM +0800, Peter Xu wrote:
>> > > There are many error_report()s that can be used in frequently called
>> > > functions, especially on IO paths. That can be unideal in that
>> > > malicious guest can try to trigger the error tons of time which might
>> > > use up the log space on the host (e.g., libvirt can capture the stderr
>> > > of QEMU and put it persistently onto disk).
>> >
>> > I think the problem is real enough but I think the API
>> > isn't great as it stresses the mechanism. Which fundamentally does
>> > not matter - we can print once or 10 times, or whatever.
>> >
>> > What happens here is a guest bug as opposed to hypervisor
>> > bug. So I think a better name would be guest_error.
>>
>> For me error_report_once() is okay since after all it's only a way to
>> dump something for the hypervisor management software (or the person
>> who manages the QEMU instance), and I don't have a strong opinion to
>> introduce a new guest_error() API.
>
> If we go with that suggestion, guest_{error,warn} should also prefix
> the message with "Guest:" or so. Otherwise, it does not offer that much
> more benefit.
>
> [And I think it should be a wrapper around the report_once
> infrastructure.]
I agree. Keep error_report_once() as low-level function (okay to stress
mechanism there), then wrap whatever higher level functions we find
useful around them, in followup patches.
[...]
