Re: [GIT PULL] x86/shstk for 6.4

[Dave Hansen <dave.hansen@intel.com>]

On 5/16/23 13:38, Linus Torvalds wrote:
> On Mon, May 15, 2023 at 3:40 PM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>> So I *think* fork() could do something like this:
>>
>>   struct fork_cookie; // dummy type purely for type checking
>>   static struct fork_cookie *is_singe_threaded(void)
>>   {
>>         struct mm_struct *mm = current->mm;
>>         mutex_lock(&mm->fork_lock);
> Actually, let's not even bother with a new fork_lock.
> 
> I for some reason thought that fork only took the mmap_lock for
> reading (because it kind of does just read the old VM data), but when
> I actually look at dup_mmap() I notice that what it does is actually
> just
> 
>         if (mmap_write_lock_killable(oldmm)) ..
> 
> and so I think we can just use that as the lock.
> 
> So then all we'd need is to use mmap_read_lock(mm) in kthread_use_mm()
> around the mmgrab.
> 
> I don't think we even need it in kthread_unuse_mm(), because
> *decrementing* the mm counters isn't even something we need to worry
> about.
> 
> How does that sound?

Sounds promising.  I was really hesitant to bring a new lock into the world.

I need to digest what you write yesterday and convince myself a little
more that doing it at kthread_unuse_mm() is sufficient, but that's my
problem. ;)