[PATCH 2/2] accel/ivpu: Do not use mutex_lock_interruptible

[Jeffrey Hugo]

On 6/6/2023 7:44 AM, Stanislaw Gruszka wrote:
> Hi
> 
> On Fri, Jun 02, 2023 at 11:30:31AM -0600, Jeffrey Hugo wrote:
>> On 5/25/2023 4:38 AM, Stanislaw Gruszka wrote:
>>> If we get signal when waiting for the mmu->lock we do not invalidate
>>> current MMU configuration what might result on undefined behavior.
>>
>> "that might result in"
>>
>>> Additionally there is little or no benefit on break waiting for
>>> ipc->lock. In current code base, we keep this lock for short periods.
>>
>> What about error cases?  Nothing where say the hardware can be unresponsive
>> and a process from userspace is blocked?  Without interruptible(), ctrl+c
>> will have no effect.
> 
> I believe we do not have any infinite loops while holding the mutexe's,
> all loops will end with timeout on unresponsive hardware and sooner or
> later SIGINT will be delivered. This time can take quite long on simulated
> environment, but in such case we can just break the simulation.

Ok, then I'm not missing anything.  It does look like all the hardware 
interactions have short timeouts.  Feels odd to me to avoid 
interruptible() in user context, but I don't see anything that is wrong 
based on the code today.

With the commit text spelling fixes,
Reviewed-by: Jeffrey Hugo <quic_jhugo at quicinc.com>