From: Michael Ellerman <mpe@ellerman.id.au>
To: Linus Torvalds <torvalds@linux-foundation.org>,
Jeff Xu <jeffxu@google.com>, Nicholas Piggin <npiggin@gmail.com>,
Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: "Pedro Falcato" <pedro.falcato@gmail.com>,
"kernel test robot" <oliver.sang@intel.com>,
"Jeff Xu" <jeffxu@chromium.org>,
oe-lkp@lists.linux.dev, lkp@intel.com,
linux-kernel@vger.kernel.org,
"Andrew Morton" <akpm@linux-foundation.org>,
"Kees Cook" <keescook@chromium.org>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
"Dave Hansen" <dave.hansen@intel.com>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Guenter Roeck" <groeck@chromium.org>,
"Jann Horn" <jannh@google.com>,
"Jonathan Corbet" <corbet@lwn.net>,
"Jorge Lucangeli Obes" <jorgelo@chromium.org>,
"Matthew Wilcox" <willy@infradead.org>,
"Muhammad Usama Anjum" <usama.anjum@collabora.com>,
"Stephen Röttger" <sroettger@google.com>,
"Suren Baghdasaryan" <surenb@google.com>,
"Amer Al Shanawany" <amer.shanawany@gmail.com>,
"Javier Carrasco" <javier.carrasco.cruz@gmail.com>,
"Shuah Khan" <shuah@kernel.org>,
linux-api@vger.kernel.org, linux-mm@kvack.org,
ying.huang@intel.com, feng.tang@intel.com, fengwei.yin@intel.com
Subject: Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression
Date: Tue, 06 Aug 2024 12:14:49 +1000 [thread overview]
Message-ID: <87o766iehy.fsf@mail.lhotse> (raw)
In-Reply-To: <CAHk-=wgdTWpCqTMgM9SJxG2=oYwhAueU_fDHMPifjpH5eHG8qw@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Mon, 5 Aug 2024 at 11:55, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>>
>> So please consider this a "maybe something like this" patch, but that
>> 'arch_unmap()' really is pretty nasty
>
> Actually, the whole powerpc vdso code confused me. It's not the vvar
> thing that wants this close thing, it's the other ones that have the
> remap thing.
>
> .. and there were two of those error cases that needed to reset the
> vdso pointer.
>
> That all shows just how carefully I was reading this code.
>
> New version - still untested, but now I've read through it one more
> time - attached.
Needs a slight tweak to compile, vvar_close() needs to return void. And
should probably be renamed vdso_close(). Diff below if anyone else wants
to test it.
I'm testing it now, but it should do what we need.
cheers
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index 6fa041a6690a..431b46976db8 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -81,8 +81,8 @@ static int vdso64_mremap(const struct vm_special_mapping *sm, struct vm_area_str
return vdso_mremap(sm, new_vma, &vdso64_end - &vdso64_start);
}
-static int vvar_close(const struct vm_special_mapping *sm,
- struct vm_area_struct *vma)
+static void vdso_close(const struct vm_special_mapping *sm,
+ struct vm_area_struct *vma)
{
struct mm_struct *mm = vma->vm_mm;
mm->context.vdso = NULL;
@@ -99,13 +99,13 @@ static struct vm_special_mapping vvar_spec __ro_after_init = {
static struct vm_special_mapping vdso32_spec __ro_after_init = {
.name = "[vdso]",
.mremap = vdso32_mremap,
- .close = vvar_close,
+ .close = vdso_close,
};
static struct vm_special_mapping vdso64_spec __ro_after_init = {
.name = "[vdso]",
.mremap = vdso64_mremap,
- .close = vvar_close,
+ .close = vdso_close,
};
#ifdef CONFIG_TIME_NS
next prev parent reply other threads:[~2024-08-06 2:14 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-04 8:59 [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression kernel test robot
2024-08-04 20:32 ` Linus Torvalds
2024-08-05 13:33 ` Pedro Falcato
2024-08-05 18:10 ` Jeff Xu
2024-08-05 18:55 ` Linus Torvalds
2024-08-05 19:33 ` Linus Torvalds
2024-08-06 2:14 ` Michael Ellerman [this message]
2024-08-06 2:17 ` Linus Torvalds
2024-08-06 12:03 ` Michael Ellerman
2024-08-06 14:43 ` Linus Torvalds
2024-08-07 12:26 ` Michael Ellerman
2024-08-06 6:04 ` Oliver Sang
2024-08-06 14:38 ` Linus Torvalds
2024-08-06 21:37 ` Pedro Falcato
2024-08-07 5:54 ` Oliver Sang
2024-08-05 19:37 ` Jeff Xu
2024-08-05 19:48 ` Linus Torvalds
2024-08-05 19:50 ` Linus Torvalds
2024-08-05 23:24 ` Nicholas Piggin
2024-08-06 0:13 ` Linus Torvalds
2024-08-06 1:22 ` Jeff Xu
2024-08-06 2:01 ` Michael Ellerman
2024-08-06 2:15 ` Linus Torvalds
2024-09-13 5:47 ` Christophe Leroy
2024-08-05 17:54 ` Jeff Xu
2024-08-05 13:56 ` Jeff Xu
2024-08-05 16:58 ` Jeff Xu
2024-08-06 1:44 ` Oliver Sang
2024-08-06 14:54 ` Jeff Xu
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=87o766iehy.fsf@mail.lhotse \
--to=mpe@ellerman.id.au \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=amer.shanawany@gmail.com \
--cc=christophe.leroy@csgroup.eu \
--cc=corbet@lwn.net \
--cc=dave.hansen@intel.com \
--cc=feng.tang@intel.com \
--cc=fengwei.yin@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=groeck@chromium.org \
--cc=jannh@google.com \
--cc=javier.carrasco.cruz@gmail.com \
--cc=jeffxu@chromium.org \
--cc=jeffxu@google.com \
--cc=jorgelo@chromium.org \
--cc=keescook@chromium.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lkp@intel.com \
--cc=npiggin@gmail.com \
--cc=oe-lkp@lists.linux.dev \
--cc=oliver.sang@intel.com \
--cc=pedro.falcato@gmail.com \
--cc=shuah@kernel.org \
--cc=sroettger@google.com \
--cc=surenb@google.com \
--cc=torvalds@linux-foundation.org \
--cc=usama.anjum@collabora.com \
--cc=willy@infradead.org \
--cc=ying.huang@intel.com \
/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.