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@xxxxxxxxxxx>
