public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Yunseong Kim <yunseong.kim@est.tech>
Cc: Andy Whitcroft <apw@canonical.com>, Joe Perches <joe@perches.com>,
	sashal@kernel.org, Dwaipayan Ray <dwaipayanray1@gmail.com>,
	Lukas Bulwahn <lukas.bulwahn@gmail.com>,
	stable@vger.kernel.org, linux-kernel@vger.kernel.org,
	Yunseong Kim <yunseong.kim@ericsson.com>,
	Yunseong Kim <ysk@kzalloc.com>,
	42.4.sejin@gmail.com
Subject: Re: [PATCH RESEND] checkpatch: validate upstream commit tags for stable backports
Date: Tue, 5 May 2026 14:42:04 +0200	[thread overview]
Message-ID: <2026050554-afoot-bolt-9785@gregkh> (raw)
In-Reply-To: <20260505112320.362715-2-yunseong.kim@est.tech>

On Tue, May 05, 2026 at 01:23:21PM +0200, Yunseong Kim wrote:
> According to the stable kernel rules (Option 3), backported patches
> should include the upstream commit reference using the SHA1 in one of
> two specific formats:
> 
>   1. commit <40 length sha1> upstream.
>   2. [ Upstream commit <40 length sha1> ]
> 
> Currently, checkpatch.pl does not validate these stable-specific
> formats, allowing truncated SHA1 characters to pass without notice.
> 
> These tags often conflict with the standard GIT_COMMIT_ID rule, which
> expects a "12+ chars of sha1" followed by the commit subject in
> parentheses. This causes checkpatch to trigger false positive errors.
> 
>   ERROR: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")'
>   - ie: 'commit e9acda52fd2e ("bonding: fix use-after-free due to enslave fail after slave array update")
>   #9: 
>   [ Upstream commit e9acda52fd2ee0cdca332f996da7a95c5fd25294 ]
> 
> Add validation to ensure these tags use the required 40-hex-character
> SHA1 and provide a warning if the format is malformed. For example:
> 
>   WARNING: Malformed 'commit ... upstream.' line - expected 'commit <40 hex chars SHA1> upstream.'
>   #7:
>   commit e9acda5 upstream.
> 
>   WARNING: Malformed '[ Upstream commit ]' line - expected '[ Upstream commit <40 hex chars SHA1> ]'
>   #7:
>   [ Upstream commit e9acda5 ]
> 
> Link: https://docs.kernel.org/process/stable-kernel-rules.html#option-3
> Signed-off-by: Yunseong Kim <yunseong.kim@est.tech>
> ---
>  scripts/checkpatch.pl | 22 +++++++++++++++++++++-
>  1 file changed, 21 insertions(+), 1 deletion(-)

This should not be needed, you should not need to run checkpatch on a
stable backport, as you will get quickly confused by any issues that are
in the original patch.

We take many different styles of backports for stable kernels, but yours
was just wrong, with the incorrect authorship information, which
checkpatch would not have caught.  Otherwise it would have been accepted
as-is.

thanks,

greg k-h

      reply	other threads:[~2026-05-05 12:42 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-05 11:23 [PATCH RESEND] checkpatch: validate upstream commit tags for stable backports Yunseong Kim
2026-05-05 12:42 ` Greg KH [this message]

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=2026050554-afoot-bolt-9785@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=42.4.sejin@gmail.com \
    --cc=apw@canonical.com \
    --cc=dwaipayanray1@gmail.com \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lukas.bulwahn@gmail.com \
    --cc=sashal@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=ysk@kzalloc.com \
    --cc=yunseong.kim@ericsson.com \
    --cc=yunseong.kim@est.tech \
    /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