From: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
To: Jeffrey Hugo <quic_jhugo@quicinc.com>
Cc: Oded Gabbay <ogabbay@kernel.org>,
Krystian Pradzynski <krystian.pradzynski@linux.intel.com>,
Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 2/2] accel/ivpu: Do not use mutex_lock_interruptible
Date: Tue, 6 Jun 2023 15:44:43 +0200 [thread overview]
Message-ID: <20230606134443.GC324119@linux.intel.com> (raw)
In-Reply-To: <66ccf028-48df-0493-6510-19bd635210a5@quicinc.com>
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.
Regards
Stanislaw
next prev parent reply other threads:[~2023-06-06 13:44 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-25 10:38 [PATCH 1/2] accel/ivpu: Do not trigger extra VPU reset if the VPU is idle Stanislaw Gruszka
2023-05-25 10:38 ` [PATCH 2/2] accel/ivpu: Do not use mutex_lock_interruptible Stanislaw Gruszka
2023-06-02 17:30 ` Jeffrey Hugo
2023-06-06 13:44 ` Stanislaw Gruszka [this message]
2023-06-06 14:50 ` Jeffrey Hugo
2023-06-08 6:43 ` Stanislaw Gruszka
2023-06-08 6:21 ` Stanislaw Gruszka
2023-06-02 17:23 ` [PATCH 1/2] accel/ivpu: Do not trigger extra VPU reset if the VPU is idle Jeffrey Hugo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230606134443.GC324119@linux.intel.com \
--to=stanislaw.gruszka@linux.intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=jacek.lawrynowicz@linux.intel.com \
--cc=krystian.pradzynski@linux.intel.com \
--cc=ogabbay@kernel.org \
--cc=quic_jhugo@quicinc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.