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 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.