From: Joerg Roedel <joro@8bytes.org>
To: Andy Lutomirski <luto@kernel.org>
Cc: X86 ML <x86@kernel.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
"H. Peter Anvin" <hpa@zytor.com>, Joerg Roedel <jroedel@suse.de>,
LKML <linux-kernel@vger.kernel.org>,
Naresh Kamboju <naresh.kamboju@linaro.org>,
stable <stable@vger.kernel.org>
Subject: Re: [PATCH] x86/mm/32: Bring back vmalloc faulting on x86_32
Date: Thu, 3 Sep 2020 17:17:39 +0200 [thread overview]
Message-ID: <20200903151739.GA28508@8bytes.org> (raw)
In-Reply-To: <CALCETrWAk-zVKKjvrq+fRAX5HKhdHF36h+jY+91_tQOa67xozA@mail.gmail.com>
Hi Andy,
On Thu, Sep 03, 2020 at 07:52:35AM -0700, Andy Lutomirski wrote:
> Does this mean we can get rid of arch_sync_kernel_mappings()? Or
> should we consider adding some locking to make it non-racy again?
Well, removing arch_sync_kernel_mappings() would mean to re-introduce
vmalloc_sync_all() calls all over the place, I am not in favour for
that.
I also thought about locking, but that is not easily doable without
destroying performance/scalability of the vmalloc alloc/free path for
other architectures too. It _could_ be done, but the effort is large and
touches a lot of generic page-table allocation code just for x86-32.
This seemed not worth it while thinking about it.
Regards,
Joerg
prev parent reply other threads:[~2020-09-03 15:18 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-02 15:59 [PATCH] x86/mm/32: Bring back vmalloc faulting on x86_32 Joerg Roedel
2020-09-03 9:53 ` [tip: x86/urgent] " tip-bot2 for Joerg Roedel
2020-09-03 14:52 ` [PATCH] " Andy Lutomirski
2020-09-03 15:17 ` Joerg Roedel [this message]
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=20200903151739.GA28508@8bytes.org \
--to=joro@8bytes.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jroedel@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=naresh.kamboju@linaro.org \
--cc=peterz@infradead.org \
--cc=stable@vger.kernel.org \
--cc=tglx@linutronix.de \
--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.