[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <YkFsQhpGGXIFTMyp@zn.tnic>
Date: Mon, 28 Mar 2022 10:05:22 +0200
From: Borislav Petkov <bp@...en8.de>
To: Ammar Faizi <ammarfaizi2@...weeb.org>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Alviro Iskandar Setiawan <alviro.iskandar@...il.com>,
Alviro Iskandar Setiawan <alviro.iskandar@...weeb.org>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
Tony Luck <tony.luck@...el.com>,
Yazen Ghannam <yazen.ghannam@....com>,
linux-edac@...r.kernel.org, linux-kernel@...r.kernel.org,
stable@...r.kernel.org, gwml@...r.gnuweeb.org, x86@...nel.org
Subject: Re: [PATCH v5 2/2] x86/MCE/AMD: Fix memory leak when
`threshold_create_bank()` fails
On Mon, Mar 28, 2022 at 11:12:53AM +0700, Ammar Faizi wrote:
> Although, I am not sure if that 100% guarantees mce_threshold_remove_device()
> will not mess up with the interrupt (e.g. freeing the data while the interrupt
> reading it), unless we're using RCU stuff.
>
> What do you think?
I would've said it doesn't matter but that thresholding device creation
is part of hotplug and it can happen multiple times even *after* the
interrupt vector has been set during setup so a potential teardown and
concurrent thresholding interrupt firing might really hit in a not fully
initialized/cleaned up state so yeah, let's do Yazen's thing.
The alternative would be the temporarily re-assign mce_threshold_vector
to default_threshold_interrupt while setup is being done but that's not
really necessary atm.
But call that helper function __threshold_remove_device().
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists