[Linux-kernel-mentees] checkpatch: improving comment parsing in email

Lukas Bulwahn lukas.bulwahn at gmail.com
Wed Oct 21 05:31:47 UTC 2020

On Tue, 20 Oct 2020, Dwaipayan Ray wrote:

> Hi,
> checkpatch seems to have problems parsing some types of
> email comments. Some examples I could find were of the type:
> 1) address at example.com (Comment)
> 2) "Name (Comment) " address at example.com
> 3) address at example.com #comment
> These comments aren't processed currently which causes
> false BAD_SIGN_OFF warnings.
> Examples are:
> WARNING:BAD_SIGN_OFF: email address 'David.Laight at aculab.com
> (big endian system concerns)' might be better as 'David.Laight at aculab.com
> (big endian system concerns)'
> WARNING:BAD_SIGN_OFF: email address 'stable at vger.kernel.org #4.20+'
> might be better as 'stable at vger.kernel.org#4.20+'
> The earlier warning is very frequent in the kernel.
> I did send a patch solving (1 and 3),
> https://lore.kernel.org/linux-kernel-mentees/a15a6cc0ddea068d78113f5e315eaba6f52b917a.camel@perches.com/
> Joe points out that comments and multiple comments can
> exist at any part of email. (perhaps RFC 5322 Appendix A.5). So
> that patch didn't solve the problem at the very root.
> What do you recommend be done?

I cannot say much of BIG value and insight.

As of now, I think these cases should be handled correctly and the check 
for: is it the same name or is it the same email should work properly no 
matter where and which kind of comment is used (as described by RFC 5322 
as you pointed out).

I might change my opinion when:

1. We have an evaluation on how many cases of BAD_SIGN_OFF (and related 
types) do we currently still observed among 100,000 commits and how many 
due to not handling comments properly?

2. We have a rough idea how complex this whole checking function will get. 
At the moment, I cannot say if it "just 10 lines of code addition" (even 
if they might be quite intrinsic to get right) or if we need hundreds of 
lines with thousand of special cases etc. (which I do not expect, but who 
knows which complexity might be involved, once we go into the details).

So, I suggest to evaluate and prototype and then we can better judge if it 
is worth really going forward, discussing it with Joeand adding it to mainline.

What do you think, Dwaipayan?

Other candidates for mentorship can certainly help here with those tasks. 
Anyone up to helping us here? Just reply with what you see you can do.


More information about the Linux-kernel-mentees mailing list