On Thu, Apr 29, 2021 at 09:17:06AM -0700, Yu, Yu-cheng wrote:

The lock applies to both shadow stack and ibt.  So maybe just "locked"?

Sure.

vm_munmap() returns error as the following:

(1) -EINVAL: address/size/alignment is wrong.
	For shadow stack, the kernel keeps track of it, this cannot/should not
happen.

You mean nothing might corrupt

        cet->shstk_base
        cet->shstk_size

?

I can't count the ways I've heard "should not happen" before and then it
happening anyway.

So probably not but we better catch stuff like that instead of leaking.

Should it happen, it is a bug.

Ack.

The kernel can probably do WARN().

Most definitely WARN. You need to catch funsies like that. But WARN_ONCE
should be enough for now.

(2) -ENOMEM: when doing __split_vma()/__vma_adjust(), kmem_cache_alloc()
fails.
	Not much we can do.  Perhaps WARN()?

You got it.

Bottom line is: if you can check for this and it is cheap, then
definitely. Code changes, gets rewritten, reorganized, the old
assertions change significance, and so on...

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette