From: Ingo Molnar <mingo@kernel.org>
To: Jacky Li <jackyli@google.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>,
Andy Lutomirski <luto@kernel.org>,
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>, Marc Orr <marcorr@google.com>,
Alper Gun <alpergun@google.com>,
x86@kernel.org, linux-kernel@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>,
Rik van Riel <riel@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Mike Rapoport <rppt@kernel.org>, Juergen Gross <jgross@suse.com>
Subject: Re: [PATCH] x86/mm/cpa: get rid of the cpa lock
Date: Fri, 6 Jan 2023 11:52:22 +0100 [thread overview]
Message-ID: <Y7f9ZuPcIMk37KnN@gmail.com> (raw)
In-Reply-To: <20221222013330.831474-1-jackyli@google.com>
* Jacky Li <jackyli@google.com> wrote:
> It’s true that with such old code, the cpa_lock might protect more
> race conditions than those that it was introduced to protect in 2008,
> or some old hardware may depend on the cpa_lock for undocumented
> behavior. So removing the lock directly might not be a good idea, but
> it probably should not mean that we need to keep the inefficient code
> forever. I would appreciate any suggestion to navigate this lock
> removal from the folks on the to and cc list.
> -/*
> - * Serialize cpa() (for !DEBUG_PAGEALLOC which uses large identity mappings)
> - * using cpa_lock. So that we don't allow any other cpu, with stale large tlb
> - * entries change the page attribute in parallel to some other cpu
> - * splitting a large page entry along with changing the attribute.
> - */
> -static DEFINE_SPINLOCK(cpa_lock);
Yeah, so I'm *really* tempted to just remove cpa_lock if there's no in-code
documented uses of it - your patch provides *exhaustive* background.
The thing is, even in the worst-case if it breaks anything, it will get
investigated, documented better and maybe reverted - which would *still* be
an improvement over today, because we turn undocumented code into
documented code.
We cannot indefinitely keep a global lock just because we fear it might
have some undocumented dependencies...
But no strong feelings either way - I've added a few more Cc:s to discuss
this more widely.
Unless there's objections I'd be inclined to give this patch a try, and
keep an eye open for regressions, it's not difficult to revert either.
Thanks,
Ingo
next prev parent reply other threads:[~2023-01-06 10:52 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-22 1:33 [PATCH] x86/mm/cpa: get rid of the cpa lock Jacky Li
2023-01-06 10:52 ` Ingo Molnar [this message]
2023-01-09 20:30 ` Thomas Gleixner
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=Y7f9ZuPcIMk37KnN@gmail.com \
--to=mingo@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=alpergun@google.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jackyli@google.com \
--cc=jgross@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=marcorr@google.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=riel@redhat.com \
--cc=rppt@kernel.org \
--cc=tglx@linutronix.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).