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
