[PATCH v2] tee: shm: fix slab page refcounting
Marco Felsch
m.felsch at pengutronix.de
Fri Feb 13 14:04:48 PST 2026
Hi Sumit,
On 26-02-13, Sumit Garg wrote:
> Hi Marco,
>
> On Thu, Feb 12, 2026 at 01:58:30PM +0100, Marco Felsch wrote:
> > Hi Sumit,
> >
> > TBH: I was hoping that you will take care of this since you're marked as
> > maintainer for the tee-trusted-key and we noticed the warning with 6.14
> > and still no fix available :/
>
> Mathew did suggested a fix long back on which everybody agreed but
You agreed. I said that the current TEE API also allows non-slabed based
backed memory and therefore I don't wanted to send this patch approach
and instead asked you to do so since you're the maintainer and fine with
the change.
> didn't got enough attention from you to test and report if that fixed
Why should it get attention from us? Maybe we do have different views of
being a maintainer.
> your issue. Since you insisted further, I have created a formal fix
Why is it our issue? It's everyones issue which uses the tee trusted-key
driver.
> patch based on that here [1]. Care to test that?
A colleague of mine is going to test it and will reply on the patch.
> [1] https://lore.kernel.org/all/20260213113317.1728769-1-sumit.garg@kernel.org/
...
> > I checked the code once again and figured that we could drop/replace
> > tee_shm_register_kernel_buf() with tee_shm_alloc_kernel_buf(). I don't
> > see why a kernel driver needs to tee_shm_register_kernel_buf() in the
> > first place, maybe this is legacy. The only users of
> > tee_shm_register_kernel_buf() are trusted_tee.c and tee_stmm_efi.c.
>
> No it's not legacy but allows for efficient memory reuse within the
> kernel as to not create bounce buffers to share data with TEE.
To be hones, there are only two driver using the API. The tee_stmm_efi
driver can do the alloc during the probe(). The trusted_tee has to use a
bounce buffer, yes but how often do you assume that (un)sealing and rng
ops have to be done during runtime? This shouldn't be a overhead at all.
Therefore my suggestion would be still to drop the internal kernel API
and only use it for userspace pages, where it could really matter.
Regards,
Marco
--
#gernperDu
#CallMeByMyFirstName
Pengutronix e.K. | |
Steuerwalder Str. 21 | https://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
More information about the linux-arm-kernel
mailing list