[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <5e059a683582799f8676b77052aeab2597f97e60.camel@intel.com>
Date: Thu, 13 Jun 2024 16:13:56 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
"linux-coco@...ts.linux.dev" <linux-coco@...ts.linux.dev>, "Hansen, Dave"
<dave.hansen@...el.com>, "lirongqing@...du.com" <lirongqing@...du.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>, "x86@...nel.org"
<x86@...nel.org>
Subject: Re: [PATCH] virt: tdx-guest: Fix the decrypted failure memory free
On Thu, 2024-06-13 at 09:07 -0700, Dave Hansen wrote:
> Second, Rick was looking in this area, but I'm not sure we ever applied
> his patches. The idea was to never leak memory silently in these
> failures. Doesn't this silently leak memory?
They did get applied actually. After a fair amount of discussion the solution
was to always leak the pages, and rely on the WARN that happens in set_memory()
to make noise about it.
It looks like this instance popped up after the sweep through the code was done.
(at least in my local branch with the patches for the fixes, this code was not
merged yet)
Powered by blists - more mailing lists