Re: [PATCH v2] tee: shm: fix slab page refcounting
Marco Felsch <[email protected]>
| Newsgroups | org.trustedfirmware.lists.op-tee,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-efi,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <252s4lfnujhrl3bkqm3xwatdkcdd3tfge3e6fla6f2llq4szjm@xltjvpqjgffn> |
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/[email protected]/ ... > > 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 |