[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Grab mm lock before grabbing pt lock
- To: Dave Hansen <dave.hansen@xxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>, Borislav Petkov <bp@xxxxxxxxx>, Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>, x86@xxxxxxxxxx, "H. Peter Anvin" <hpa@xxxxxxxxx>
- From: Maksym Planeta <maksym@xxxxxxxxxxxxx>
- Date: Mon, 9 Dec 2024 13:39:30 +0100
- Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx
- Delivery-date: Mon, 09 Dec 2024 12:39:44 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 05/12/2024 19:52, Dave Hansen wrote:
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.
I indeed could not find reasons why locking would be strictly necessary for correctness here. On the other hand a
clearly benign warning should not be triggered, especially considering that panic_on_warn may be on on some systems.
|
