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.
