linux-kernel - Re: [PATCH] Grab mm lock before grabbing pt lock

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <24b8d4a0-36c3-4404-98aa-7d8e2c67ac95@intel.com>
Date: Thu, 5 Dec 2024 10:52:24 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: Maksym Planeta <maksym@...stellar.io>, Juergen Gross <jgross@...e.com>,
 Boris Ostrovsky <boris.ostrovsky@...cle.com>,
 Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
 Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>,
 x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>
Cc: xen-devel@...ts.xenproject.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Grab mm lock before grabbing pt lock

On 12/4/24 02:35, Maksym Planeta wrote:
> Function xen_pin_page calls xen_pte_lock, which in turn grab page
> table lock (ptlock). When locking, xen_pte_lock expect mm->page_table_lock
> to be held before grabbing ptlock, but this does not happen when pinning
> is caused by xen_mm_pin_all.

In changelogs, please indicate functions with parenthesis like this:
func().  It makes it easier to tell what is a function versus a variable
or other text.

The use of init_mm here in the preexisting code is a _bit_ fishy because
these pgds *HAVE* an mm and yet xen_mm_pin_all() passes in '&init_mm'
for them. That's relevant here because locking 'init_mm' obviously
doesn't do any good for other mm's.

I have the _feeling_ it's just a big hack and this code throws caution
tot the wind because of:

>  * Expected to be called in stop_machine() ("equivalent to taking
>  * every spinlock in the system"), so the locking doesn't really
>  * matter all that much.

So the patch here kinda doubles down on the hack and continues the theme
because "locking doesn't really matter all that much."

If so, it's not super satisfying, but it is consistent with the existing
code.

> This commit addresses lockdep warning below, which shows up when
> suspending a Xen VM.

If the comment I quote above is right, this is a _harmless_ warning
because nothing else can race here and the locking that gets added is
useless anyway, right? You seem to agree because there's no cc:stable@
or Fixes: tags.

Either way, I'm hesitant to add incorrect-in-any-other-context and
uncommented locking just to shut up lockdep. Is there no better way?

If not, can we comment it at least, please, so nobody else tries to
duplicate the locking?