On Fri, Jun 11, 2021 at 07:53:26AM -0500, Tyler Hicks wrote: > On 2021-06-11 11:11:33, Jens Wiklander wrote: > > On Thu, Jun 10, 2021 at 11:09 PM Tyler Hicks > > <tyhicks@xxxxxxxxxxxxxxxxxxx> wrote: > > > > > > From: Allen Pais <apais@xxxxxxxxxxxxxxxxxxx> > > > > > > The following out of memory errors are seen on kexec reboot > > > from the optee core. > > > > > > [ 0.368428] tee_bnxt_fw optee-clnt0: tee_shm_alloc failed > > > [ 0.368461] tee_bnxt_fw: probe of optee-clnt0 failed with error -22 > > > > > > tee_shm_release() is not invoked on dma shm buffer. > > > > > > Implement .shutdown() method to handle the release of the buffers > > > correctly. > > > > > > More info: > > > https://github.com/OP-TEE/optee_os/issues/3637 > > > > > > Signed-off-by: Allen Pais <apais@xxxxxxxxxxxxxxxxxxx> > > > Reviewed-by: Tyler Hicks <tyhicks@xxxxxxxxxxxxxxxxxxx> > > > > Do we really need this considering the patch "optee: Refuse to load > > the driver under the kdump kernel"? > > Yes. That patch fixes boot hangs when all of the OP-TEE threads were in > the suspended state at the time of a kernel panic. The kexec into the > kdump kernel after a panic is an "emergency" kexec that doesn't even > call .shutdown hooks. There's no way for the OP-TEE driver to clean up > after itself. > > This patch disables the shm cache (and unregisters the shm buffers) > during a normal kexec from one perfectly working kernel into a new > kernel. This is required because the new kernel will not be able to > handle the virtual addresses that were cached under the old kernel. The > new kernel has an entirely different memory layout and the old addresses > point to unmapped memory or memory that's mapped but probably not a TEE > shm. Got it, thanks. Jens
