checkpatch can generate a false positive when inserting a new kernel-doc
block and function above an existing kernel-doc block.
Fix it by checking that the context line is also a newly inserted line.
Signed-off-by: Joe Perches <joe@perches.com>
Reported-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Using the extern keyword on function prototypes is superfluous visual
noise so suggest removing it.
Using extern can cause unnecessary line wrapping at 80 columns and
unnecessarily long multi-line function prototypes.
Signed-off-by: Joe Perches <joe@perches.com>
Suggested-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I got a bug report from a couple of users who said checkpatch.pl was
broken for them. It was erroring out on fairly random lines most commonly
with messages like:
Nested quantifiers in regex; marked by <--HERE in m/(\((?:[^\(\)]++ <-- HERE |(?-1))*\))/ at ./checkpatch.pl line 340.
The bug reporter was running a version of perl 5.8 which was end-of-lifed
in 2008: http://www.cpan.org/src/. Versions of perl this old are at
_best_ quite untested. At worst, they are crusty and known to be
completely broken.
If folks have a system _that_ old, then we should have mercy on them and
give them a half-decent error message rather than fail with nutty error
messages.
This patch enforces that checkpatch.pl is run with perl 5.10, which was
end-of-lifed in 2009. The new --ignore-perl-version command-line switch
will let folks override this if they want.
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Joe Perches <joe@perches.com>
Cc: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
$Lval is a test for complete name (ie: foo->bar.Baz[1])
If any of this is CamelCase, then the current test uses the entire $Lval.
This isn't optimal because it can emit messages with foo->bar.Baz and
bar.Baz when Baz is a variable specified in an include file.
So instead, break the $Lval into words and check each word for CamelCase
uses.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Suggest a few more single-line corrections.
Remove DOS line endings
Simplify removing trailing whitespace
Remove global/static initializations to 0/NULL
Convert pr_warning to pr_warn
Add space after brace
Convert binary constants to hex
Remove whitespace after line continuation
Use inline not __inline or __inline__
Use __printf and __scanf
Use a single ; for statement terminations
Convert __FUNCTION__ to __func__
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When decompressing into memory, the output buffer length is set to some
arbitrarily high value (0x7fffffff) to indicate the output is, virtually,
unlimited in size.
The problem with this is that some platforms have their physical memory at
high physical addresses (0x80000000 or more), and that the output buffer
address and its "unlimited" length cannot be added without overflowing.
An example of this can be found in inflate_fast():
/* next_out is the output buffer address */
out = strm->next_out - OFF;
/* avail_out is the output buffer size. end will overflow if the output
* address is >= 0x80000104 */
end = out + (strm->avail_out - 257);
This has huge consequences on the performance of kernel decompression,
since the following exit condition of inflate_fast() will be always true:
} while (in < last && out < end);
Indeed, "end" has overflowed and is now always lower than "out". As a
result, inflate_fast() will return after processing one single byte of
input data, and will thus need to be called an unreasonably high number of
times. This probably went unnoticed because kernel decompression is fast
enough even with this issue.
Nonetheless, adjusting the output buffer length in such a way that the
above pointer arithmetic never overflows results in a kernel decompression
that is about 3 times faster on affected machines.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Tested-by: Jon Medhurst <tixy@linaro.org>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The documentation mentions a "name" parameter, which does not exist. This
commit removes such mention from the function documentation.
Signed-off-by: Emilio López <emilio@elopez.com.ar>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Joe Perches
Dave Hansen
Alexandre Courbot
Gu Zheng
Emilio López
Christian Daudt