linux-kernel - Re: [PATCH 1/2] checkpatch: Add support for Checkpatch-ignore patch footer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+i-1C23hyQJmRQXM2OgCcxRm3ci9b+fK=EkbtFoZj0WpTh7Xg@mail.gmail.com>
Date: Tue, 14 Jan 2025 12:42:38 +0100
From: Brendan Jackman <jackmanb@...gle.com>
To: Joe Perches <joe@...ches.com>
Cc: Andy Whitcroft <apw@...onical.com>, Dwaipayan Ray <dwaipayanray1@...il.com>, 
	Lukas Bulwahn <lukas.bulwahn@...il.com>, Jonathan Corbet <corbet@....net>, 
	LKML <linux-kernel@...r.kernel.org>, workflows@...r.kernel.org, 
	linux-doc@...r.kernel.org
Subject: Re: [PATCH 1/2] checkpatch: Add support for Checkpatch-ignore patch footer

On Mon, 13 Jan 2025, 20:15 Joe Perches, <joe@...ches.com> wrote:
>
> On Mon, 2025-01-13 at 16:04 +0000, Brendan Jackman wrote:
> > Checkpatch sometimes has false positives. This makes it less useful for
> > automatic usage: tools like b4 [0] can run checkpatch on all of your
> > patches and give you a quick overview. When iterating on a branch, it's
> > tiresome to manually re-check that any errors are known false positives.
>
> If you do this, and perhaps it's not particularly necessary at all,
> I suggest using something like the message-id or branch name for an
> ignored types file and have the script auto-write the found types
> into that file.

Do you mean to say the problem is better solved in b4 instead of checkpatch?

I think that's a downgrade from the Checkpatch-args approach, because
b4 is just one of many many tools that wrap checkpatch. I think it's
nice to solve the problem for everyone.

Also, having the config in the commit message means it's there for
everyone instead of just the patch author. Running checkpatch on other
people's patches is not something I have much interest in doing
deliberately, but I'm sure there are those who do it. Maybe there are
even maintainers who would like to have their -next branch entirely
checkpatch-clean if that was an option.

Plus I bet there are just cases where it's interesting to know the
difference between "this author doesn't care about checkpatch" and
"this author disagrees with checkpatch on this patch".