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: <5518d438-7c73-2ba0-de77-0650742895e6@st.com>
Date:   Wed, 5 Apr 2017 08:23:37 +0000
From:   Hugues FRUCHET <hugues.fruchet@...com>
To:     Joe Perches <joe@...ches.com>, Andy Whitcroft <apw@...onical.com>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1] checkpatch: test missing initial blank line in block
 comment

Hi Joe, thanks for reviewing,

I have run the command you advice on the entire kernel code, modifying 
the script to only match the newly introduced check case.
There was 14389 hits, quite huge, so I cannot 100% certify that there 
are no false positives, but I have checked the output carefully and 
found 2 limit cases:

1) space character placed just after "/*"
WARNING: Block comments starts with an empty /*
#330: FILE: arch/alpha/kernel/core_irongate.c:330:
+	/*
+	 * Check for within the AGP aperture...
=> 146 hits (grep -c -n -E "\/\* $" /tmp/check.txt)

2) // style comment followed by pointer dereference
WARNING: Block comments starts with an empty /*
#426: FILE: drivers/media/dvb-core/dvb_ca_en50221.c:426:
+	// success
+	*tupleType = _tupleType;
=> 4 hits

Anyway this reveal comment style related issues, so I would say that we 
can keep script as it is, what do you think about ?

Here is the count detail by first level of directories within kernel:

$ grep FILE /tmp/check.txt | grep -c "FILE: drivers/"
8859
$ grep FILE /tmp/check.txt | grep -c "FILE: arch/"
2306
$ grep FILE /tmp/check.txt | grep -c "FILE: fs/"
1136
$ grep FILE /tmp/check.txt | grep -c "FILE: sound/"
810
$ grep FILE /tmp/check.txt | grep -c "FILE: include/"
669
$ grep FILE /tmp/check.txt | grep -c "FILE: kernel/"
143
$ grep FILE /tmp/check.txt | grep -c "FILE: security/"
112
$ grep FILE /tmp/check.txt | grep -c "FILE: lib/"
91
$ grep FILE /tmp/check.txt | grep -c "FILE: tools/"
81
$ grep FILE /tmp/check.txt | grep -c "FILE: crypto/"
54
$ grep FILE /tmp/check.txt | grep -c "FILE: scripts/"
44
$ grep FILE /tmp/check.txt | grep -c "FILE: mm/"
35
$ grep FILE /tmp/check.txt | grep -c "FILE: block/"
27
$ grep FILE /tmp/check.txt | grep -c "FILE: virt/"
8
$ grep FILE /tmp/check.txt | grep -c "FILE: samples/"
5
$ grep FILE /tmp/check.txt | grep -c "FILE: ipc/"
5
$ grep FILE /tmp/check.txt | grep -c "FILE: certs/"
1

The complete output is there for reference: 
http://paste.ubuntu.com/24319042/


Best regards,
Hugues.

On 04/03/2017 09:06 PM, Joe Perches wrote:
> On Mon, 2017-04-03 at 10:08 +0200, Hugues Fruchet wrote:
>> Warn when block comments are not starting with blank comment:
>>
>> /* multiple lines
>>  * block comment,
>>  * => warning
>>  */
>>
>> /*
>>  * multiple lines
>>  * block comment,
>>  * => no warning
>>  */
>>
>> Exception made for networking files where rule is the
>> exact opposite.
>
> I recall there was some reason I didn't do this
> when adding the block comment code, but I don't
> recall what it was.  Perhaps it was the initial
> line of files.
>
> Maybe your $realline > 2 test fixes it.  Maybe not.
> Dunno.
>
> If you run this against the entire kernel code
> using a unique test type and not BLOCK_COMMENT_STYLE
> are there any false positives?
>
> Maybe test with something like:
>
> $ git ls-files -- "*.[ch]" | \
>   xargs --max-args 20 ./scripts/checkpatch.pl -f --types=<your_unique_test>
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ