From: sashiko-bot@kernel.org
To: "Amirreza Zarrabi" <amirreza.zarrabi@oss.qualcomm.com>
Cc: conor+dt@kernel.org, devicetree@vger.kernel.org, robh@kernel.org
Subject: Re: [PATCH RFC v2 7/8] tee: optee: bind RPMI services and negotiate backend capabilities
Date: Tue, 06 Oct 2026 00:53:01 +0000 [thread overview]
Message-ID: <20261006005301.ACB591F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20261005-rpmi-tee-service-grp-dev-v2-7-72f222e23ec1@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] tee: optee: mixing goto and __free() violates cleanup guidelines
- [Low] tee: optee: missing cleanup of shm_arg_cache on probe error paths
--
commit 3ef22394684ff6d8b2126c91fa4c8bb2d1960d68
Author: Amirreza Zarrabi <amirreza.zarrabi@oss.qualcomm.com>
tee: optee: bind RPMI services and negotiate backend capabilities
Register an RPMI service driver matching the OP-TEE service UUID and integrate
it with OP-TEE module initialization and removal. It checks the service API
version, queries the trusted OS revision, initializes shared-memory tracking,
and connects the RPMI backend to the common OP-TEE operations.
> diff --git a/drivers/tee/optee/rpmi_abi.c b/drivers/tee/optee/rpmi_abi.c
> index 6e76316794c18..db541f3de4250 100644
> --- a/drivers/tee/optee/rpmi_abi.c
> +++ b/drivers/tee/optee/rpmi_abi.c
[ ... ]
> +static int optee_rpmi_probe(struct rpmi_tee_device *rdev)
> +{
> + struct tee_device *teedev;
> + struct tee_context *ctx;
> + int ret;
> +
> + struct optee *optee __free(kfree) = kzalloc_obj(*optee);
[Severity: Medium]
Does this function mix goto-based error handling and scope-based cleanup?
According to the kernel cleanup subsystem guidelines, mixing goto and
scope-based cleanups like __free() in the same function creates confusing
ownership semantics and raises the risk of missed cleanups. The guidelines
suggest converting all resources to scope-based cleanup or none at all.
> + if (!optee)
> + return -ENOMEM;
> +
[ ... ]
> + optee_cq_init(&optee->call_queue, 0);
> + optee_supp_init(&optee->supp);
> + optee_shm_arg_cache_init(optee, OPTEE_SHM_ARG_SHARED);
> + mutex_init(&optee->rpmb_dev_mutex);
> + INIT_WORK(&optee->rpmb_scan_bus_work, optee_bus_scan_rpmb);
> + optee->rpmb_intf.notifier_call = optee_rpmb_intf_rdev;
> + ret = optee_notif_init(optee, optee->rpmi.notification_count);
> + if (ret)
> + goto err_common;
[ ... ]
> +err_initialized:
> + /* The remove path owns and frees the published backend state. */
> + retain_and_null_ptr(optee);
> + optee_rpmi_remove(rdev);
> +
> + return ret;
> +err_devices:
> + tee_device_unregister(optee->supp_teedev);
> + tee_device_unregister(optee->teedev);
> + optee_shm_arg_cache_uninit(optee);
> +err_notif:
> + optee_notif_uninit(optee);
> +err_common:
[Severity: Low]
Are we missing the cleanup of the argument cache on the err_common path?
If optee_notif_init() fails, the code jumps to err_common, bypassing
err_devices where optee_shm_arg_cache_uninit() is called. This skips the
mutex_destroy() for the argument cache. The actual memory for the optee
struct is freed via the scope-based cleanup, but the logical teardown
is bypassed.
> + optee_supp_uninit(&optee->supp);
> + mutex_destroy(&optee->call_queue.mutex);
> + rpmb_dev_put(optee->rpmb_dev);
> + mutex_destroy(&optee->rpmb_dev_mutex);
> + optee_rpmi_shm_rht_uninit(optee);
> +err_pool:
> + tee_shm_pool_free(optee->pool);
> +
> + return ret;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261005-rpmi-tee-service-grp-dev-v2-0-72f222e23ec1@oss.qualcomm.com?part=7
next prev parent reply other threads:[~2026-10-06 0:53 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-06 0:39 [PATCH RFC v2 0/8] tee: optee: add RPMI backend support on RISC-V Amirreza Zarrabi
2026-10-06 0:39 ` Amirreza Zarrabi
2026-10-06 0:39 ` Amirreza Zarrabi via OP-TEE
2026-10-06 0:39 ` [PATCH RFC v2 1/8] tee: optee: allow RPMI transport builds " Amirreza Zarrabi
2026-10-06 0:39 ` Amirreza Zarrabi
2026-10-06 0:39 ` Amirreza Zarrabi via OP-TEE
2026-10-06 0:52 ` sashiko-bot
2026-10-06 0:39 ` [PATCH RFC v2 2/8] tee: optee: define the RPMI control and parcel-reference ABI Amirreza Zarrabi
2026-10-06 0:39 ` Amirreza Zarrabi
2026-10-06 0:39 ` Amirreza Zarrabi via OP-TEE
2026-10-08 6:51 ` Jens Wiklander
2026-10-08 6:51 ` Jens Wiklander
2026-10-08 6:51 ` Jens Wiklander via OP-TEE
2026-10-08 22:02 ` Amirreza Zarrabi
2026-10-08 22:02 ` Amirreza Zarrabi via OP-TEE
2026-10-08 22:02 ` Amirreza Zarrabi
2026-10-09 13:54 ` Jens Wiklander
2026-10-09 13:54 ` Jens Wiklander
2026-10-09 13:54 ` Jens Wiklander via OP-TEE
2026-10-06 0:39 ` [PATCH RFC v2 3/8] tee: optee: add RPMI shared-memory and parameter support Amirreza Zarrabi
2026-10-06 0:39 ` Amirreza Zarrabi
2026-10-06 0:39 ` Amirreza Zarrabi via OP-TEE
2026-10-08 7:10 ` Jens Wiklander
2026-10-08 7:10 ` Jens Wiklander
2026-10-08 7:10 ` Jens Wiklander via OP-TEE
2026-10-08 22:27 ` Amirreza Zarrabi
2026-10-08 22:27 ` Amirreza Zarrabi via OP-TEE
2026-10-08 22:27 ` Amirreza Zarrabi
2026-10-06 0:39 ` [PATCH RFC v2 4/8] tee: optee: add RPMI dynamic shared-memory pool Amirreza Zarrabi
2026-10-06 0:39 ` Amirreza Zarrabi
2026-10-06 0:39 ` Amirreza Zarrabi via OP-TEE
2026-10-06 0:55 ` sashiko-bot
2026-10-06 0:39 ` [PATCH RFC v2 5/8] tee: optee: add RPMI RPC handling Amirreza Zarrabi
2026-10-06 0:39 ` Amirreza Zarrabi
2026-10-06 0:39 ` Amirreza Zarrabi via OP-TEE
2026-10-06 0:39 ` [PATCH RFC v2 6/8] tee: optee: execute yielding RPMI calls Amirreza Zarrabi
2026-10-06 0:39 ` Amirreza Zarrabi
2026-10-06 0:39 ` Amirreza Zarrabi via OP-TEE
2026-10-06 0:55 ` sashiko-bot
2026-10-08 8:11 ` Jens Wiklander
2026-10-08 8:11 ` Jens Wiklander
2026-10-08 8:11 ` Jens Wiklander via OP-TEE
2026-10-08 22:56 ` Amirreza Zarrabi
2026-10-08 22:56 ` Amirreza Zarrabi
2026-10-08 22:56 ` Amirreza Zarrabi via OP-TEE
2026-10-06 0:39 ` [PATCH RFC v2 7/8] tee: optee: bind RPMI services and negotiate backend capabilities Amirreza Zarrabi
2026-10-06 0:39 ` Amirreza Zarrabi
2026-10-06 0:39 ` Amirreza Zarrabi via OP-TEE
2026-10-06 0:53 ` sashiko-bot [this message]
2026-10-08 8:20 ` Jens Wiklander
2026-10-08 8:20 ` Jens Wiklander
2026-10-08 8:20 ` Jens Wiklander via OP-TEE
2026-10-08 23:10 ` Amirreza Zarrabi
2026-10-08 23:10 ` Amirreza Zarrabi via OP-TEE
2026-10-08 23:10 ` Amirreza Zarrabi
2026-10-09 14:43 ` Jens Wiklander
2026-10-09 14:43 ` Jens Wiklander
2026-10-09 14:43 ` Jens Wiklander via OP-TEE
2026-10-06 0:39 ` [PATCH RFC v2 8/8] tee: optee: support RPMI asynchronous notification doorbells Amirreza Zarrabi
2026-10-06 0:39 ` Amirreza Zarrabi
2026-10-06 0:39 ` Amirreza Zarrabi via OP-TEE
2026-10-06 0:47 ` sashiko-bot
2026-10-08 6:15 ` [PATCH RFC v2 0/8] tee: optee: add RPMI backend support on RISC-V Jens Wiklander
2026-10-08 6:15 ` Jens Wiklander
2026-10-08 6:15 ` Jens Wiklander via OP-TEE
2026-10-08 23:21 ` Amirreza Zarrabi
2026-10-08 23:21 ` Amirreza Zarrabi
2026-10-08 23:21 ` Amirreza Zarrabi via OP-TEE
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=20261006005301.ACB591F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=amirreza.zarrabi@oss.qualcomm.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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.