From: Oleg Nesterov <oleg@redhat.com>
To: Mateusz Guzik <mjguzik@gmail.com>
Cc: linux-kernel@vger.kernel.org, torvalds@linux-foundation.org,
brauner@kernel.org, ebiederm@xmission.com, david@redhat.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:05:31 +0200 [thread overview]
Message-ID: <20230814150530.GB17738@redhat.com> (raw)
In-Reply-To: <20230813123333.1705833-1-mjguzik@gmail.com>
On 08/13, Mateusz Guzik wrote:
>
> fe69d560b5bd ("kernel/fork: always deny write access to current MM
> exe_file") added another lock trip to synchronize the state of exe_file
> against fork, further defeating the point of xchg.
>
> As such I think the atomic here only adds complexity for no benefit.
>
> Just write-lock around the replacement.
Well, I tend to agree but can't really comment because I forgot everything
about these code paths.
But I have to admit that I don't understand the code in replace_mm_exe_file()
without this patch...
old_exe_file = xchg(&mm->exe_file, new_exe_file);
if (old_exe_file) {
/*
* Don't race with dup_mmap() getting the file and disallowing
* write access while someone might open the file writable.
*/
mmap_read_lock(mm);
allow_write_access(old_exe_file);
fput(old_exe_file);
mmap_read_unlock(mm);
}
Can someone please explain me which exactly race this mmap_read_lock() tries
to avoid and how ?
Oleg.
next prev parent reply other threads:[~2023-08-14 15:07 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 [this message]
2023-08-14 15:20 ` Oleg Nesterov
2023-08-14 15:37 ` David Hildenbrand
2023-08-14 15:58 ` Oleg Nesterov
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=20230814150530.GB17738@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.