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

[Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>]

On Tue, Jun 06, 2023 at 08:50:52AM -0600, Jeffrey Hugo wrote:
> 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.

In this context it should not matter much, because we hold locks for
short periods But we have also wait_event_interruptible_timeout(),
which I want to get rid of as well, because we can free and reuse
memory that could still be used by FW, if we break that wait_event. 
And solving this differently will require much complication, which I
don't really want goto into. I will need to think about that ...

Anyways thanks for the insights, appreciated.

Regards
Stanislaw