On 2021/10/20 19:03, Viresh Kumar wrote:> On 20-10-21, 12:55, Vincent Whitchurch wrote:
>> If the timeout cannot be disabled, then the driver should be fixed to
>> always copy buffers and hold on to them to avoid memory corruption in
>> the case of timeout, as I mentioned in my commit message. That would
be
>> quite a substantial change to the driver so it's not something
I'm
>> personally comfortable with doing, especially not this late in the -rc
>> cycle, so I'd leave that to others.
> Or we can avoid clearing up and freeing the buffers here until the
> point where the buffers are returned by the host. Until that happens,
> we can avoid taking new requests but return to the earlier caller with
> timeout failure. That would avoid corruption, by freeing buffers
> sooner, and not hanging of the kernel.
It seems similar to use "wait_for_completion". If the other side is
hacked, the guest may never
get the buffers returned by the host, right ?
For this moment, we can solve the problem by using a hardcoded big value
or disabling the timeout.
Over the long term, I think the backend should provide that timeout
value and guarantee that its processing
time should not exceed that value.