On Thu, Mar 10, 2022 at 08:53:06AM +0700, Ammar Faizi wrote:
In mce_threshold_create_device(), if threshold_create_bank() fails, the @bp will be leaked, because the call to mce_threshold_remove_device() will not free the @bp. mce_threshold_remove_device() frees @threshold_banks. At that point, the @bp has not been written to @threshold_banks, @threshold_banks is NULL, so the call is just a nop.
Fix this by extracting the cleanup part into a new static function _mce_threshold_remove_device(), then call it from create/remove device functions.
Also, eliminate the "goto out_err", just early return inside the loop if the creation fails.
Cc: Borislav Petkov bp@alien8.de Cc: Thomas Gleixner tglx@linutronix.de Cc: Greg Kroah-Hartman gregkh@linuxfoundation.org Cc: stable@vger.kernel.org # v5.8+ Fixes: 6458de97fc15 ("x86/mce/amd: Straighten CPU hotplug path")
How did you decide this is the commit that this is fixing?
Link: https://lore.kernel.org/lkml/9dfe087a-f941-1bc4-657d-7e7c198888ff@gnuweeb.or...
That Link tag is not needed.
Co-authored-by: Alviro Iskandar Setiawan alviro.iskandar@gnuweeb.org Signed-off-by: Alviro Iskandar Setiawan alviro.iskandar@gnuweeb.org Co-authored-by: Yazen Ghannam yazen.ghannam@amd.com
There's no "Co-authored-by".
The correct tag is described in
Documentation/process/submitting-patches.rst
Please make sure you've read that file before sending patches.
Signed-off-by: Yazen Ghannam yazen.ghannam@amd.com Signed-off-by: Ammar Faizi ammarfaizi2@gnuweeb.org
arch/x86/kernel/cpu/mce/amd.c | 32 +++++++++++++++++++------------- 1 file changed, 19 insertions(+), 13 deletions(-)
...
@@ -1350,15 +1357,14 @@ int mce_threshold_create_device(unsigned int cpu) if (!(this_cpu_read(bank_map) & (1 << bank))) continue; err = threshold_create_bank(bp, cpu, bank);
if (err)goto out_err;
if (err) {_mce_threshold_remove_device(bp, numbanks);return err;}
Do I see it correctly that the publishing of the @bp pointer - i.e., this line - should be moved right above the for loop?
Then mce_threshold_remove_device() would properly free it in the error case and your patch turns into a oneliner?
And then your Fixes: tag would be correct too...