public inbox for stable@vger.kernel.org
 help / color / mirror / Atom feed
From: Sasha Levin <sashal@kernel.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org,
	Jianglei Nie <niejianglei2021@163.com>,
	Baoquan He <bhe@redhat.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Chen Lifu <chenlifu@huawei.com>,
	"Eric W . Biederman" <ebiederm@xmission.com>,
	Li Chen <lchen@ambarella.com>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Paul Mackerras <paulus@samba.org>, Petr Mladek <pmladek@suse.com>,
	Russell King <linux@armlinux.org.uk>,
	ye xingchen <ye.xingchen@zte.com.cn>,
	Zeal Robot <zealci@zte.com.cn>,
	kexec@lists.infradead.org, linux-fsdevel@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH AUTOSEL 6.1 13/22] proc/vmcore: fix potential memory leak in vmcore_init()
Date: Sun, 18 Dec 2022 06:28:16 -0500	[thread overview]
Message-ID: <Y575UCk+lwfJ2CoE@sashalap> (raw)
In-Reply-To: <20221217163228.9308c293458ceb680a6ffed8@linux-foundation.org>

On Sat, Dec 17, 2022 at 04:32:28PM -0800, Andrew Morton wrote:
>On Sat, 17 Dec 2022 10:27:14 -0500 Sasha Levin <sashal@kernel.org> wrote:
>
>> From: Jianglei Nie <niejianglei2021@163.com>
>>
>> [ Upstream commit 12b9d301ff73122aebd78548fa4c04ca69ed78fe ]
>>
>> Patch series "Some minor cleanup patches resent".
>>
>> The first three patches trivial clean up patches.
>>
>> And for the patch "kexec: replace crash_mem_range with range", I got a
>> ibm-p9wr ppc64le system to test, it works well.
>>
>> This patch (of 4):
>>
>> elfcorehdr_alloc() allocates a memory chunk for elfcorehdr_addr with
>> kzalloc().  If is_vmcore_usable() returns false, elfcorehdr_addr is a
>> predefined value.  If parse_crash_elf_headers() gets some error and
>> returns a negetive value, the elfcorehdr_addr should be released with
>> elfcorehdr_free().
>
>This is exceedingly minor - a single memory leak per boot, under very
>rare circumstances.
>
>
>With every patch I merge I consider -stable.  Often I'll discuss the
>desirability of a backport with the author and with reviewers.  Every
>single patch.  And then some damn script comes along and overrides that
>quite careful decision.  argh.
>
>Can we please do something like
>
>	if (akpm && !cc:stable)
>		dont_backport()

Yup, I already had it set for 'akpm && mm/ && !cc:stable', happy to
remove the 'mm/' restriction if you're doing the same for the rest of
the patches you review.

>And even go further - if your script thinks it might be something we
>should backport and if it didn't have cc:stable then contact the
>author, reviewers and committers and ask them to reconsider before we
>go and backport it.  This approach will have the advantage of training
>people to consider the backport more consistently.

This is what this mail is all about: I haven't queued up the patch yet,
it gives folks week+ to review, and all it takes is a simple "no" for me
to drop it.

>I'd (still) like to have a new patch tag like Not-For-Stable: or
>cc:not-stable or something to tell your scripts "yes, we thought about
>it and we decided no".

No objections on my part.

-- 
Thanks,
Sasha

  reply	other threads:[~2022-12-18 11:28 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-17 15:27 [PATCH AUTOSEL 6.1 01/22] fs: jfs: fix shift-out-of-bounds in dbAllocAG Sasha Levin
2022-12-17 15:27 ` [PATCH AUTOSEL 6.1 02/22] udf: Avoid double brelse() in udf_rename() Sasha Levin
2022-12-17 15:27 ` [PATCH AUTOSEL 6.1 03/22] jfs: Fix fortify moan in symlink Sasha Levin
2022-12-17 15:27 ` [PATCH AUTOSEL 6.1 04/22] fs: jfs: fix shift-out-of-bounds in dbDiscardAG Sasha Levin
2022-12-17 15:27 ` [PATCH AUTOSEL 6.1 05/22] ACPI: processor: idle: Check acpi_fetch_acpi_dev() return value Sasha Levin
2022-12-17 15:27 ` [PATCH AUTOSEL 6.1 06/22] ACPI: EC: Add quirk for the HP Pavilion Gaming 15-cx0041ur Sasha Levin
2022-12-17 15:27 ` [PATCH AUTOSEL 6.1 07/22] ACPICA: Fix error code path in acpi_ds_call_control_method() Sasha Levin
2022-12-17 15:27 ` [PATCH AUTOSEL 6.1 08/22] thermal/core: Ensure that thermal device is registered in thermal_zone_get_temp Sasha Levin
2022-12-17 15:27 ` [PATCH AUTOSEL 6.1 09/22] ACPI: video: Change GIGABYTE GB-BXBT-2807 quirk to force_none Sasha Levin
2022-12-17 15:27 ` [PATCH AUTOSEL 6.1 10/22] ACPI: video: Change Sony Vaio VPCEH3U1E quirk to force_native Sasha Levin
2022-12-17 15:27 ` [PATCH AUTOSEL 6.1 11/22] ACPI: video: Add force_vendor quirk for Sony Vaio PCG-FRV35 Sasha Levin
2022-12-17 15:27 ` [PATCH AUTOSEL 6.1 12/22] ACPI: video: Add force_native quirk for Sony Vaio VPCY11S1E Sasha Levin
2022-12-17 15:27 ` [PATCH AUTOSEL 6.1 13/22] proc/vmcore: fix potential memory leak in vmcore_init() Sasha Levin
2022-12-18  0:32   ` Andrew Morton
2022-12-18 11:28     ` Sasha Levin [this message]
2022-12-17 15:27 ` [PATCH AUTOSEL 6.1 14/22] nilfs2: fix shift-out-of-bounds/overflow in nilfs_sb2_bad_offset() Sasha Levin
2022-12-17 15:27 ` [PATCH AUTOSEL 6.1 15/22] nilfs2: fix shift-out-of-bounds due to too large exponent of block size Sasha Levin
2022-12-17 15:27 ` [PATCH AUTOSEL 6.1 16/22] ACPI / PCI: fix LPIC IRQ model default PCI IRQ polarity Sasha Levin
2022-12-17 15:27 ` [PATCH AUTOSEL 6.1 17/22] acct: fix potential integer overflow in encode_comp_t() Sasha Levin
2022-12-17 15:27 ` [PATCH AUTOSEL 6.1 18/22] x86/apic: Handle no CONFIG_X86_X2APIC on systems with x2APIC enabled by BIOS Sasha Levin
2022-12-17 15:27 ` [PATCH AUTOSEL 6.1 19/22] ACPI: x86: Add skip i2c clients quirk for Lenovo Yoga Tab 3 Pro (YT3-X90F) Sasha Levin
2022-12-17 15:27 ` [PATCH AUTOSEL 6.1 20/22] btrfs: do not panic if we can't allocate a prealloc extent state Sasha Levin
2022-12-17 15:27 ` [PATCH AUTOSEL 6.1 21/22] ACPI: x86: Add skip i2c clients quirk for Medion Lifetab S10346 Sasha Levin
2022-12-17 15:27 ` [PATCH AUTOSEL 6.1 22/22] hfs: fix OOB Read in __hfs_brec_find Sasha Levin

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=Y575UCk+lwfJ2CoE@sashalap \
    --to=sashal@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=benh@kernel.crashing.org \
    --cc=bhe@redhat.com \
    --cc=chenlifu@huawei.com \
    --cc=ebiederm@xmission.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kexec@lists.infradead.org \
    --cc=lchen@ambarella.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=mpe@ellerman.id.au \
    --cc=niejianglei2021@163.com \
    --cc=paulus@samba.org \
    --cc=pmladek@suse.com \
    --cc=stable@vger.kernel.org \
    --cc=ye.xingchen@zte.com.cn \
    --cc=zealci@zte.com.cn \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox