On 26-02-16, Sumit Garg wrote:
On Fri, Feb 13, 2026 at 11:04:48PM +0100, Marco Felsch wrote:
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.
It's really the basic expectation I have put here which every reporter of a bug needs to say if a suggested fix works for them or not.
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.
I don't disagree with what you are saying here but we really need to promote efficient memory reuse for TEE clients. There will surely be more use-cases coming in future which can benefit from the flexibility to register buffer. One another kernel client being remoteproc subsystem which is already under review for this API.
I see, thanks for the pointer. I'm really curious why STM didn't reported the warning stacktrace, since they should trigger it too.
Regards, Marco
-Sumit
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 |