All of lore.kernel.org
 help / color / mirror / Atom feed
From: kirill.shutemov@linux.intel.com
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Dave Hansen <dave.hansen@linux.intel.com>,
	linux-kernel@vger.kernel.org, x86@kernel.org, jejb@linux.ibm.com,
	martin.petersen@oracle.com
Subject: Re: [GIT PULL] x86/mm for 6.2
Date: Fri, 16 Dec 2022 05:16:45 +0300	[thread overview]
Message-ID: <20221216021645.jn576zrhadocpt66@box.shutemov.name> (raw)
In-Reply-To: <CAHk-=whC_ixb3FDdMhW_wiKw7-bB700kvUyqN+_cPUNp=1hNsQ@mail.gmail.com>

On Thu, Dec 15, 2022 at 09:17:11AM -0800, Linus Torvalds wrote:
>  - make thread creation lock it (and unlock it on creating a new mm at
> execve, but not fork).
> 
> And yes, I would actually suggest that _any_ thread creation locks it,
> so that you never *EVER* have any issues with "oh, now I need to
> synchronize with other threads". A process can set its LAM state at
> startup, not in the middle of running!

By thread creation, you mean CLONE_VM, right?

Do we care to avoid locking for CLONE_VFORK case? Seems excessive.

> Note that io_uring will automatically do that locking, because it does
> that thread creation (create_io_thread()). So io_uring threads won't
> even be a special case.

I've missed that io_uring does not use kthread_use_mm() anymore. But what
about other kthread_use_mm() users?

I did not find concrete cases where missing LAM setup would breaks things,
but I cannot prove opposite too.

kthread_use_mm() usage is suspicious in amdkfd, but I donno.

io_uring was a clear before it moved away from kthread_use_mm().

-- 
  Kiryl Shutsemau / Kirill A. Shutemov

  parent reply	other threads:[~2022-12-16  2:16 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-13 17:42 [GIT PULL] x86/mm for 6.2 Dave Hansen
2022-12-14 22:36 ` Linus Torvalds
2022-12-15 12:30   ` kirill.shutemov
2022-12-15 17:17     ` Linus Torvalds
2022-12-15 17:26       ` Linus Torvalds
2022-12-15 21:53         ` Dave Hansen
2022-12-15 22:46           ` Linus Torvalds
2022-12-16  2:16       ` kirill.shutemov [this message]
2022-12-16 15:05         ` Kirill A. Shutemov
2022-12-16 15:43           ` Linus Torvalds
2022-12-17 16:43             ` Kirill A. Shutemov
2022-12-16 20:09 ` Jason A. Donenfeld

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221216021645.jn576zrhadocpt66@box.shutemov.name \
    --to=kirill.shutemov@linux.intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=jejb@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.