On Fri, May 26, 2023 at 05:36:02PM +0200, Ben Hutchings wrote: > On Wed, 2023-05-17 at 16:06 +0200, Greg Kroah-Hartman wrote: > > On Wed, May 17, 2023 at 04:02:35PM +0200, Greg Kroah-Hartman wrote: > > > On Wed, May 17, 2023 at 02:56:21PM +0200, Ben Hutchings wrote: > > > > On Fri, 2023-03-10 at 14:33 +0100, Greg Kroah-Hartman wrote: > > > > > From: Sean Christopherson <seanjc@xxxxxxxxxx> > > > > > > > > > > [ Upstream commit e4a9af799e5539b0feb99571f0aaed5a3c81dc5a ] > > > > > > > > > > For commands with small input/output buffers, use the local stack to > > > > > "allocate" the structures used to communicate with the PSP. Now that > > > > > __sev_do_cmd_locked() gracefully handles vmalloc'd buffers, there's no > > > > > reason to avoid using the stack, e.g. CONFIG_VMAP_STACK=y will just work. > > > > [...] > > > > > > > > Julien Cristau reported a regression in ccp - the > > > > WARN_ON_ONCE(!virt_addr_valid(data)) is now being triggered. I believe > > > > this was introduced by the above commit, which depends on: > > > > > > > > commit 8347b99473a313be6549a5b940bc3c56a71be81c > > > > Author: Sean Christopherson <seanjc@xxxxxxxxxx> > > > > Date: Tue Apr 6 15:49:48 2021 -0700 > > > > > > > > crypto: ccp: Play nice with vmalloc'd memory for SEV command structs > > > > > > > > Ben. > > > > > > > > > > Thanks for letting me know, now queued up. > > > > Nope, now dropped, it breaks the build :( > > I've now looked further and found that we need both: > > d5760dee127b crypto: ccp: Reject SEV commands with mismatching command buffer > 8347b99473a3 crypto: ccp: Play nice with vmalloc'd memory for SEV command structs > > (Not yet tested; I'll ask Julien if he can do that.) Looks sane to me, both now queued up, thanks. greg k-h
