Re: [GIT PULL] x86/shstk for 6.4

From: Dave Hansen
Date: Tue May 16 2023 - 16:42:43 EST


On 5/16/23 13:38, Linus Torvalds wrote:
> On Mon, May 15, 2023 at 3:40 PM Linus Torvalds
> <torvalds@xxxxxxxxxxxxxxxxxxxx> 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. ;)