All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: Mateusz Guzik <mjguzik@gmail.com>,
	linux-kernel@vger.kernel.org, torvalds@linux-foundation.org,
	brauner@kernel.org, ebiederm@xmission.com,
	akpm@linux-foundation.org, linux-mm@kvack.org, koct9i@gmail.com,
	dave@stgolabs.net
Subject: Re: [PATCH] kernel/fork: stop playing lockless games for exe_file replacement
Date: Mon, 14 Aug 2023 17:58:17 +0200	[thread overview]
Message-ID: <20230814155817.GC17738@redhat.com> (raw)
In-Reply-To: <52192c2f-c7b1-9c07-7ca2-10fc6bd347b0@redhat.com>

On 08/14, David Hildenbrand wrote:
>
> >OK, I seem to understand... without mmap_read_lock() it is possible that
> >
> >	- dup_mm_exe_file() sees mm->exe_file = old_exe_file
> >
> >	- replace_mm_exe_file() does allow_write_access(old_exe_file)
> >
> >	- another process does get_write_access(old_exe_file)
> >
> >	- dup_mm_exe_file()->deny_write_access() fails
> >
> >Right?
>
> From what I recall, yes.

Thanks! but then... David, this all is subjective, feel free to ignore, but
the current code doesn't look good to me, I mean the purpose of mmap_read_lock()
is very unclear. To me something like

	if (old_exe_file) {
		/*
		 * Ensure that if we race with dup_mm_exe_file() and it sees
		 * mm->exe_file == old_exe_file deny_write_access(old_exe_file)
		 * can't fail after we do allow_write_access() and another task
		 * does get_write_access(old_exe_file).
		 */
		mmap_read_lock(mm);
		mmap_read_unlock(mm);

		allow_write_access(old_exe_file);
		fput(old_exe_file);
	}

looks more understandable...



But this patch from Mateusz looks even better to me. So, FWIW,

Acked-by: Oleg Nesterov <oleg@redhat.com>



  reply	other threads:[~2023-08-14 15:59 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-13 12:33 [PATCH] kernel/fork: stop playing lockless games for exe_file replacement Mateusz Guzik
2023-08-14  7:55 ` David Hildenbrand
2023-08-14  8:21   ` Mateusz Guzik
2023-08-14  8:29     ` David Hildenbrand
2023-08-14  8:54       ` Mateusz Guzik
2023-08-14 15:38         ` David Hildenbrand
2023-08-14 15:05 ` Oleg Nesterov
2023-08-14 15:20   ` Oleg Nesterov
2023-08-14 15:37     ` David Hildenbrand
2023-08-14 15:58       ` Oleg Nesterov [this message]
2023-08-14 16:09         ` David Hildenbrand

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=20230814155817.GC17738@redhat.com \
    --to=oleg@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=brauner@kernel.org \
    --cc=dave@stgolabs.net \
    --cc=david@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=koct9i@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mjguzik@gmail.com \
    --cc=torvalds@linux-foundation.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.