All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sumit Garg <sumit.garg@linaro.org>
To: Etienne Carriere <etienne.carriere@linaro.org>
Cc: linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	op-tee@lists.trustedfirmware.org,
	Jens Wiklander <jens.wiklander@linaro.org>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Cristian Marussi <cristian.marussi@arm.com>
Subject: Re: [PATCH v6 1/4] tee: optee: system call property
Date: Thu, 11 May 2023 13:09:28 +0530	[thread overview]
Message-ID: <CAFA6WYNf0xk0QVKyJvRKx1cisLtbjkG_FTDQ47Q_FPAAu3WFHg@mail.gmail.com> (raw)
In-Reply-To: <CAN5uoS_0pF=-9=gznYUOU9oWPKz8HkRb=6gTAumMv=Vey8qb0g@mail.gmail.com>

On Thu, 11 May 2023 at 12:50, Etienne Carriere
<etienne.carriere@linaro.org> wrote:
>
> On Thu, 11 May 2023 at 08:03, Sumit Garg <sumit.garg@linaro.org> wrote:
> > (snip)
> > > > >
> > > > >  int optee_invoke_func(struct tee_context *ctx, struct tee_ioctl_invoke_arg *arg,
> > > > > @@ -408,12 +412,15 @@ int optee_invoke_func(struct tee_context *ctx, struct tee_ioctl_invoke_arg *arg,
> > > > >         struct optee_msg_arg *msg_arg;
> > > > >         struct optee_session *sess;
> > > > >         struct tee_shm *shm;
> > > > > +       bool system_thread;
> > > > >         u_int offs;
> > > > >         int rc;
> > > > >
> > > > >         /* Check that the session is valid */
> > > > >         mutex_lock(&ctxdata->mutex);
> > > > >         sess = find_session(ctxdata, arg->session);
> > > > > +       if (sess)
> > > >
> > > > This check is redundant if we move the assignment below...
> > >
> > > Here we change the sesssion attribute while the mutex is locked, in
> > > case some equivalent call with that session is issued.
> > > Below we return to caller once mutex is unlocked.
> > > I think it is the safer behavior. What do you think?
> >
> > Aren't we only reading session attribute in order to capture value in
> > a local variable: system_thread? I don't think that it would require a
> > mutex.
>
> optee_system_session() sets session::use_sys_thread with mutex locked
> hence I think we should get the attribute with the mutex locked.
> See "[PATCH v6 3/4] tee: optee: support tracking system threads".
>

Okay I see your point. Although I don't see a practical race between
optee_invoke_func() vs optee_system_session(), you never know what
complex kernel TEE client use-case comes up. So I can live with it
being protected by a mutex.

-Sumit

> Etienne
>
> >
> > -Sumit
> >
> > >
> > > Best regards,
> > > Etienne
> > >
> > > >
> > > > > +               system_thread = sess->use_sys_thread;
> > > > >         mutex_unlock(&ctxdata->mutex);
> > > > >         if (!sess)
> > > > >                 return -EINVAL;
> > > >
> > > > ...here as:
> > > >            system_thread = sess->use_sys_thread;
> > > > (snip)

      reply	other threads:[~2023-05-11  7:39 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-05 17:30 [PATCH v6 1/4] tee: optee: system call property Etienne Carriere
2023-05-05 17:30 ` Etienne Carriere
2023-05-05 17:30 ` [PATCH v6 2/4] tee: system session Etienne Carriere
2023-05-05 17:30   ` Etienne Carriere
2023-05-10 10:14   ` Sumit Garg
2023-05-05 17:30 ` [PATCH v6 3/4] tee: optee: support tracking system threads Etienne Carriere
2023-05-05 17:30   ` Etienne Carriere
2023-05-10 10:08   ` Sumit Garg
2023-05-10 15:15     ` Etienne Carriere
2023-05-10 17:38       ` Etienne Carriere
2023-05-11  7:23         ` Etienne Carriere
2023-05-11  7:43           ` Sumit Garg
2023-05-11  7:27         ` Sumit Garg
2023-05-11  8:19           ` Etienne Carriere
2023-05-11 11:31             ` Sumit Garg
2023-05-12  4:56               ` Etienne Carriere
2023-05-15  8:47                 ` Sumit Garg
2023-05-15  8:47                   ` Sumit Garg
2023-05-16  5:58                   ` Etienne Carriere
2023-05-16  5:58                     ` Etienne Carriere
2023-05-16  6:32                     ` Sumit Garg
2023-05-16  6:32                       ` Sumit Garg
2023-05-16  7:49                       ` Etienne Carriere
2023-05-16  7:49                         ` Etienne Carriere
2023-05-05 17:30 ` [PATCH v6 4/4] firmware: arm_scmi: optee: use optee system invocation Etienne Carriere
2023-05-05 17:30   ` Etienne Carriere
2023-05-10  8:22 ` [PATCH v6 1/4] tee: optee: system call property Sumit Garg
2023-05-10 15:02   ` Etienne Carriere
2023-05-11  6:03     ` Sumit Garg
2023-05-11  7:20       ` Etienne Carriere
2023-05-11  7:39         ` Sumit Garg [this message]

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=CAFA6WYNf0xk0QVKyJvRKx1cisLtbjkG_FTDQ47Q_FPAAu3WFHg@mail.gmail.com \
    --to=sumit.garg@linaro.org \
    --cc=cristian.marussi@arm.com \
    --cc=etienne.carriere@linaro.org \
    --cc=jens.wiklander@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=op-tee@lists.trustedfirmware.org \
    --cc=sudeep.holla@arm.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.