From 6e8f42dc9c8548c6b37566f3b8bda1873700c4a6 Mon Sep 17 00:00:00 2001 From: Joe Perches Date: Wed, 23 Mar 2022 16:05:56 -0700 Subject: checkpatch: prefer MODULE_LICENSE("GPL") over MODULE_LICENSE("GPL v2") There is no effective difference. Given the large number of uses of "GPL v2", emit this message only for patches as a trivial treeside sed could be done one day. Ref: commit bf7fbeeae6db ("module: Cure the MODULE_LICENSE "GPL" vs. "GPL v2" bogosity") Link: https://lkml.kernel.org/r/20220128185924.80137-1-joe@perches.com Signed-off-by: Joe Perches Cc: Dwaipayan Ray Cc: Lukas Bulwahn Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- scripts/checkpatch.pl | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'scripts/checkpatch.pl') diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl index b01c36a15d9d..b7c181ea0ac5 100755 --- a/scripts/checkpatch.pl +++ b/scripts/checkpatch.pl @@ -7418,6 +7418,13 @@ sub process { WARN("MODULE_LICENSE", "unknown module license " . $extracted_string . "\n" . $herecurr); } + if (!$file && $extracted_string eq '"GPL v2"') { + if (WARN("MODULE_LICENSE", + "Prefer \"GPL\" over \"GPL v2\" - see commit bf7fbeeae6db (\"module: Cure the MODULE_LICENSE \"GPL\" vs. \"GPL v2\" bogosity\")\n" . $herecurr) && + $fix) { + $fixed[$fixlinenr] =~ s/\bMODULE_LICENSE\s*\(\s*"GPL v2"\s*\)/MODULE_LICENSE("GPL")/; + } + } } # check for sysctl duplicate constants -- cgit v1.2.3 From 481efd7bd6f28febddf189e7a970bb0bc5a53de8 Mon Sep 17 00:00:00 2001 From: Joe Perches Date: Wed, 23 Mar 2022 16:05:59 -0700 Subject: checkpatch: add --fix option for some TRAILING_STATEMENTS Single line code like: if (foo) bar; should generally be written: if (foo) bar; Add a --fix test to do so. This fix is not done when an ASSIGN_IN_IF in the same line exists. Link: https://lkml.kernel.org/r/20220128185924.80137-2-joe@perches.com Signed-off-by: Joe Perches Cc: Dwaipayan Ray Cc: Lukas Bulwahn Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- scripts/checkpatch.pl | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) (limited to 'scripts/checkpatch.pl') diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl index b7c181ea0ac5..046a018093a7 100755 --- a/scripts/checkpatch.pl +++ b/scripts/checkpatch.pl @@ -5551,6 +5551,7 @@ sub process { defined($stat) && defined($cond) && $line =~ /\b(?:if|while|for)\s*\(/ && $line !~ /^.\s*#/) { my ($s, $c) = ($stat, $cond); + my $fixed_assign_in_if = 0; if ($c =~ /\bif\s*\(.*[^<>!=]=[^=].*/s) { if (ERROR("ASSIGN_IN_IF", @@ -5575,6 +5576,7 @@ sub process { $newline .= ')'; $newline .= " {" if (defined($brace)); fix_insert_line($fixlinenr + 1, $newline); + $fixed_assign_in_if = 1; } } } @@ -5598,8 +5600,20 @@ sub process { $stat_real = "[...]\n$stat_real"; } - ERROR("TRAILING_STATEMENTS", - "trailing statements should be on next line\n" . $herecurr . $stat_real); + if (ERROR("TRAILING_STATEMENTS", + "trailing statements should be on next line\n" . $herecurr . $stat_real) && + !$fixed_assign_in_if && + $cond_lines == 0 && + $fix && $perl_version_ok && + $fixed[$fixlinenr] =~ /^\+(\s*)((?:if|while|for)\s*$balanced_parens)\s*(.*)$/) { + my $indent = $1; + my $test = $2; + my $rest = rtrim($4); + if ($rest =~ /;$/) { + $fixed[$fixlinenr] = "\+$indent$test"; + fix_insert_line($fixlinenr + 1, "$indent\t$rest"); + } + } } } -- cgit v1.2.3 From 05dc40e694e0ff527011d0b09542f08da60e28cc Mon Sep 17 00:00:00 2001 From: Joe Perches Date: Wed, 23 Mar 2022 16:06:02 -0700 Subject: checkpatch: add early_param exception to blank line after struct/function test Add early_param as another exception to the blank line preferred after function/struct/union declaration or definition test. Link: https://lkml.kernel.org/r/3bd6ada59f411a7685d7e64eeb670540d4bfdcde.camel@perches.com Signed-off-by: Joe Perches Cc: Dwaipayan Ray Cc: Lukas Bulwahn Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- scripts/checkpatch.pl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'scripts/checkpatch.pl') diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl index 046a018093a7..2653177f52d9 100755 --- a/scripts/checkpatch.pl +++ b/scripts/checkpatch.pl @@ -3926,7 +3926,7 @@ sub process { if ($prevline =~ /^[\+ ]};?\s*$/ && $line =~ /^\+/ && !($line =~ /^\+\s*$/ || - $line =~ /^\+\s*EXPORT_SYMBOL/ || + $line =~ /^\+\s*(?:EXPORT_SYMBOL|early_param)/ || $line =~ /^\+\s*MODULE_/i || $line =~ /^\+\s*\#\s*(?:end|elif|else)/ || $line =~ /^\+[a-z_]*init/ || -- cgit v1.2.3 From c882c6b1cb3105d378768aa168d2283f50b6e304 Mon Sep 17 00:00:00 2001 From: Sagar Patel Date: Wed, 23 Mar 2022 16:06:05 -0700 Subject: checkpatch: use python3 to find codespell dictionary Commit 0ee3e7b8893e ("checkpatch: get default codespell dictionary path from package location") introduced the ability to search for the codespell dictionary rather than hardcoding its path. codespell requires Python 3.6 or above, but on some systems, the python executable is a Python 2.7 interpreter. In this case, searching for the dictionary fails, subsequently making codespell fail: No codespell typos will be found - file '/usr/share/codespell/dictionary.txt': No such file or directory So, use python3 to remove ambiguity. In addition, when searching for dictionary.txt, do not check if the codespell executable exists since, - checkpatch.pl only uses dictionary.txt, not the codespell executable. - codespell can be installed via a Python package manager, in which case the codespell executable may not be present in a typical $PATH, but a dictionary does exist. Link: https://lkml.kernel.org/r/20220309180048.147672-1-sagarmp@cs.unc.edu Signed-off-by: Sagar Patel Reviewed-by: Peter Ujfalusi Cc: Joe Perches Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- scripts/checkpatch.pl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'scripts/checkpatch.pl') diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl index 2653177f52d9..577e02998701 100755 --- a/scripts/checkpatch.pl +++ b/scripts/checkpatch.pl @@ -334,7 +334,7 @@ if ($user_codespellfile) { } elsif (!(-f $codespellfile)) { # If /usr/share/codespell/dictionary.txt is not present, try to find it # under codespell's install directory: /data/dictionary.txt - if (($codespell || $help) && which("codespell") ne "" && which("python") ne "") { + if (($codespell || $help) && which("python3") ne "") { my $python_codespell_dict = << "EOF"; import os.path as op @@ -344,7 +344,7 @@ codespell_file = op.join(codespell_dir, 'data', 'dictionary.txt') print(codespell_file, end='') EOF - my $codespell_dict = `python -c "$python_codespell_dict" 2> /dev/null`; + my $codespell_dict = `python3 -c "$python_codespell_dict" 2> /dev/null`; $codespellfile = $codespell_dict if (-f $codespell_dict); } } -- cgit v1.2.3 From 73f1d07e5f8a1dec989a5ec964f5f2ce5b6f8825 Mon Sep 17 00:00:00 2001 From: "Gustavo A. R. Silva" Date: Tue, 26 Apr 2022 00:32:12 -0500 Subject: checkpatch: add new alloc functions to alloc with multiplies check kvmalloc() and kvzalloc() functions have now 2-factor multiplication argument forms kvmalloc_array() and kvcalloc(), correspondingly. Add alloc-with-multiplies checks for these new functions. Link: https://github.com/KSPP/linux/issues/187 Signed-off-by: Gustavo A. R. Silva --- scripts/checkpatch.pl | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) (limited to 'scripts/checkpatch.pl') diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl index 577e02998701..503e8abbb2c1 100755 --- a/scripts/checkpatch.pl +++ b/scripts/checkpatch.pl @@ -7033,14 +7033,16 @@ sub process { "Prefer $3(sizeof(*$1)...) over $3($4...)\n" . $herecurr); } -# check for k[mz]alloc with multiplies that could be kmalloc_array/kcalloc +# check for (kv|k)[mz]alloc with multiplies that could be kmalloc_array/kvmalloc_array/kvcalloc/kcalloc if ($perl_version_ok && defined $stat && - $stat =~ /^\+\s*($Lval)\s*\=\s*(?:$balanced_parens)?\s*(k[mz]alloc)\s*\(\s*($FuncArg)\s*\*\s*($FuncArg)\s*,/) { + $stat =~ /^\+\s*($Lval)\s*\=\s*(?:$balanced_parens)?\s*((?:kv|k)[mz]alloc)\s*\(\s*($FuncArg)\s*\*\s*($FuncArg)\s*,/) { my $oldfunc = $3; my $a1 = $4; my $a2 = $10; my $newfunc = "kmalloc_array"; + $newfunc = "kvmalloc_array" if ($oldfunc eq "kvmalloc"); + $newfunc = "kvcalloc" if ($oldfunc eq "kvzalloc"); $newfunc = "kcalloc" if ($oldfunc eq "kzalloc"); my $r1 = $a1; my $r2 = $a2; @@ -7057,7 +7059,7 @@ sub process { "Prefer $newfunc over $oldfunc with multiply\n" . $herectx) && $cnt == 1 && $fix) { - $fixed[$fixlinenr] =~ s/\b($Lval)\s*\=\s*(?:$balanced_parens)?\s*(k[mz]alloc)\s*\(\s*($FuncArg)\s*\*\s*($FuncArg)/$1 . ' = ' . "$newfunc(" . trim($r1) . ', ' . trim($r2)/e; + $fixed[$fixlinenr] =~ s/\b($Lval)\s*\=\s*(?:$balanced_parens)?\s*((?:kv|k)[mz]alloc)\s*\(\s*($FuncArg)\s*\*\s*($FuncArg)/$1 . ' = ' . "$newfunc(" . trim($r1) . ', ' . trim($r2)/e; } } } -- cgit v1.2.3 From dcea7964764aad41c2994084a4c0292371b14e36 Mon Sep 17 00:00:00 2001 From: Joe Perches Date: Wed, 25 May 2022 12:03:17 -0700 Subject: checkpatch: add XA_STATE and XA_STATE_ORDER to the macro declaration list XA_STATE() and XA_STATE_ORDER macro uses are declarations. Add them to the declaration macro list to avoid suggesting a blank line after declarations when used. Link: https://lkml.kernel.org/r/144314f4bf2c58cf2336028a75a5127e848abd81.camel@perches.com Signed-off-by: Joe Perches Reported-by: David Howells Cc: Matthew Wilcox Signed-off-by: Andrew Morton --- scripts/checkpatch.pl | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'scripts/checkpatch.pl') diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl index 503e8abbb2c1..205bf5055acf 100755 --- a/scripts/checkpatch.pl +++ b/scripts/checkpatch.pl @@ -1042,7 +1042,8 @@ our $FuncArg = qr{$Typecast{0,1}($LvalOrFunc|$Constant|$String)}; our $declaration_macros = qr{(?x: (?:$Storage\s+)?(?:[A-Z_][A-Z0-9]*_){0,2}(?:DEFINE|DECLARE)(?:_[A-Z0-9]+){1,6}\s*\(| (?:$Storage\s+)?[HLP]?LIST_HEAD\s*\(| - (?:SKCIPHER_REQUEST|SHASH_DESC|AHASH_REQUEST)_ON_STACK\s*\( + (?:SKCIPHER_REQUEST|SHASH_DESC|AHASH_REQUEST)_ON_STACK\s*\(| + (?:$Storage\s+)?(?:XA_STATE|XA_STATE_ORDER)\s*\( )}; our %allow_repeated_words = ( -- cgit v1.2.3 From f858e23a29740757fe1ca602cb1f57845034b1c5 Mon Sep 17 00:00:00 2001 From: Antonio Borneo Date: Mon, 13 Jun 2022 12:00:55 +0200 Subject: checkpatch: fix incorrect camelcase detection on numeric constant The code fragment below int foo(int *array, int index) { return array[index & 0xFF]; } triggers an incorrect camelcase detection by checking a substring of the hex constant: CHECK: Avoid CamelCase: #3: FILE: test.c:3: + return array[index & 0xFF]; This is caused by passing the whole string "array[index & 0xFF]" to the inner loop that iterates over a "$Ident" match. The numeric constant is not a $Ident as it doesn't start with [A-Za-z_] and should be excluded from the match. Similar issue can be detected with other constants like "1uL", "0xffffU". Force the match to start at word boundary so the $Ident will be properly checked starting from its first char and the constants will be filtered-out. Link: https://lkml.kernel.org/r/20220613100055.77821-1-borneo.antonio@gmail.com Signed-off-by: Antonio Borneo Cc: Joe Perches Cc: Andy Whitcroft Cc: Dwaipayan Ray Cc: Lukas Bulwahn Signed-off-by: Andrew Morton --- scripts/checkpatch.pl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'scripts/checkpatch.pl') diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl index 205bf5055acf..79e759aac543 100755 --- a/scripts/checkpatch.pl +++ b/scripts/checkpatch.pl @@ -5721,7 +5721,7 @@ sub process { $var !~ /^(?:[a-z0-9_]*|[A-Z0-9_]*)?_?[a-z][A-Z](?:_[a-z0-9_]+|_[A-Z0-9_]+)?$/ && #Ignore some three character SI units explicitly, like MiB and KHz $var !~ /^(?:[a-z_]*?)_?(?:[KMGT]iB|[KMGT]?Hz)(?:_[a-z_]+)?$/) { - while ($var =~ m{($Ident)}g) { + while ($var =~ m{\b($Ident)}g) { my $word = $1; next if ($word !~ /[A-Z][a-z]|[a-z][A-Z]/); if ($check) { -- cgit v1.2.3 From defdaff15a84c68521c5f02b157fc8541e0356f3 Mon Sep 17 00:00:00 2001 From: Ira Weiny Date: Sat, 13 Aug 2022 15:00:34 -0700 Subject: checkpatch: add kmap and kmap_atomic to the deprecated list kmap() and kmap_atomic() are being deprecated in favor of kmap_local_page(). There are two main problems with kmap(): (1) It comes with an overhead as mapping space is restricted and protected by a global lock for synchronization and (2) it also requires global TLB invalidation when the kmap's pool wraps and it might block when the mapping space is fully utilized until a slot becomes available. kmap_local_page() is safe from any context and is therefore redundant with kmap_atomic() with the exception of any pagefault or preemption disable requirements. However, using kmap_atomic() for these side effects makes the code less clear. So any requirement for pagefault or preemption disable should be made explicitly. With kmap_local_page() the mappings are per thread, CPU local, can take page faults, and can be called from any context (including interrupts). It is faster than kmap() in kernels with HIGHMEM enabled. Furthermore, the tasks can be preempted and, when they are scheduled to run again, the kernel virtual addresses are restored. Link: https://lkml.kernel.org/r/20220813220034.806698-1-ira.weiny@intel.com Signed-off-by: Ira Weiny Suggested-by: Thomas Gleixner Suggested-by: Fabio M. De Francesco Reviewed-by: Chaitanya Kulkarni Cc: Joe Perches Signed-off-by: Andrew Morton --- scripts/checkpatch.pl | 2 ++ 1 file changed, 2 insertions(+) (limited to 'scripts/checkpatch.pl') diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl index 79e759aac543..9ff219e0a9d5 100755 --- a/scripts/checkpatch.pl +++ b/scripts/checkpatch.pl @@ -807,6 +807,8 @@ our %deprecated_apis = ( "rcu_barrier_sched" => "rcu_barrier", "get_state_synchronize_sched" => "get_state_synchronize_rcu", "cond_synchronize_sched" => "cond_synchronize_rcu", + "kmap" => "kmap_local_page", + "kmap_atomic" => "kmap_local_page", ); #Create a search pattern for all these strings to speed up a loop below -- cgit v1.2.3 From 8ea0114eda0c1c85f8f01922ac8fc1e489a61129 Mon Sep 17 00:00:00 2001 From: Mickaël Salaün Date: Fri, 2 Sep 2022 13:19:23 +0200 Subject: checkpatch: handle FILE pointer type MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit When using a "FILE *" type, checkpatch considers this an error: ERROR: need consistent spacing around '*' (ctx:WxV) #32: FILE: f.c:8: +static void a(FILE *const b) ^ Fix this by explicitly defining "FILE" as a common type. This is useful for user space patches. With this patch, we now get: <_>WS( ) <_>IDENT(static) <_>WS( ) <_>DECLARE(void ) <_>FUNC(a) PAREN('(') <_>DECLARE(FILE *const ) <_>IDENT(b) <_>PAREN(')') -> V <_>WS( ) 32 > . static void a(FILE *const b) 32 > EEVVVVVVVTTTTTVNTTTTTTTTTTTTVVV 32 > ______________________________ Link: https://lkml.kernel.org/r/20220902111923.1488671-1-mic@digikod.net Link: https://lore.kernel.org/r/20220902111923.1488671-1-mic@digikod.net Signed-off-by: Mickaël Salaün Acked-by: Joe Perches Cc: Andy Whitcroft Cc: Dwaipayan Ray Cc: Lukas Bulwahn Signed-off-by: Andrew Morton --- scripts/checkpatch.pl | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) (limited to 'scripts/checkpatch.pl') diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl index 9ff219e0a9d5..18effbe1fe90 100755 --- a/scripts/checkpatch.pl +++ b/scripts/checkpatch.pl @@ -576,10 +576,14 @@ our $typeKernelTypedefs = qr{(?x: (?:__)?(?:u|s|be|le)(?:8|16|32|64)| atomic_t )}; +our $typeStdioTypedefs = qr{(?x: + FILE +)}; our $typeTypedefs = qr{(?x: $typeC99Typedefs\b| $typeOtherOSTypedefs\b| - $typeKernelTypedefs\b + $typeKernelTypedefs\b| + $typeStdioTypedefs\b )}; our $zero_initializer = qr{(?:(?:0[xX])?0+$Int_type?|NULL|false)\b}; -- cgit v1.2.3 From de48fa1a01e7752135c960a20d6c3b26544a8120 Mon Sep 17 00:00:00 2001 From: Miguel Ojeda Date: Sun, 22 May 2022 03:11:08 +0200 Subject: scripts: checkpatch: diagnose uses of `%pA` in the C side as errors The `%pA` format specifier is only intended to be used from Rust. `checkpatch.pl` already gives a warning for invalid specificers: WARNING: Invalid vsprintf pointer extension '%pA' This makes it an error and introduces an explanatory message: ERROR: Invalid vsprintf pointer extension '%pA' - '%pA' is only intended to be used from Rust code Suggested-by: Kees Cook Reviewed-by: Greg Kroah-Hartman Co-developed-by: Alex Gaynor Signed-off-by: Alex Gaynor Co-developed-by: Wedson Almeida Filho Signed-off-by: Wedson Almeida Filho Co-developed-by: Joe Perches Signed-off-by: Joe Perches Signed-off-by: Miguel Ojeda --- scripts/checkpatch.pl | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) (limited to 'scripts/checkpatch.pl') diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl index 79e759aac543..74a769310adf 100755 --- a/scripts/checkpatch.pl +++ b/scripts/checkpatch.pl @@ -6783,15 +6783,19 @@ sub process { } if ($bad_specifier ne "") { my $stat_real = get_stat_real($linenr, $lc); + my $msg_level = \&WARN; my $ext_type = "Invalid"; my $use = ""; if ($bad_specifier =~ /p[Ff]/) { $use = " - use %pS instead"; $use =~ s/pS/ps/ if ($bad_specifier =~ /pf/); + } elsif ($bad_specifier =~ /pA/) { + $use = " - '%pA' is only intended to be used from Rust code"; + $msg_level = \&ERROR; } - WARN("VSPRINTF_POINTER_EXTENSION", - "$ext_type vsprintf pointer extension '$bad_specifier'$use\n" . "$here\n$stat_real\n"); + &{$msg_level}("VSPRINTF_POINTER_EXTENSION", + "$ext_type vsprintf pointer extension '$bad_specifier'$use\n" . "$here\n$stat_real\n"); } } } -- cgit v1.2.3 From d1d84b5f73888ccb9fc148dfc3cb3e15d3604d65 Mon Sep 17 00:00:00 2001 From: Miguel Ojeda Date: Sun, 22 May 2022 17:22:58 +0200 Subject: scripts: checkpatch: enable language-independent checks for Rust Include Rust in the "source code files" category, so that the language-independent tests are checked for Rust too, and teach `checkpatch` about the comment style for Rust files. This enables the malformed SPDX check, the misplaced SPDX license tag check, the long line checks, the lines without a newline check and the embedded filename check. Reviewed-by: Kees Cook Reviewed-by: Greg Kroah-Hartman Co-developed-by: Alex Gaynor Signed-off-by: Alex Gaynor Co-developed-by: Wedson Almeida Filho Signed-off-by: Wedson Almeida Filho Signed-off-by: Miguel Ojeda --- scripts/checkpatch.pl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'scripts/checkpatch.pl') diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl index 74a769310adf..b5ed31d631fa 100755 --- a/scripts/checkpatch.pl +++ b/scripts/checkpatch.pl @@ -3616,7 +3616,7 @@ sub process { my $comment = ""; if ($realfile =~ /\.(h|s|S)$/) { $comment = '/*'; - } elsif ($realfile =~ /\.(c|dts|dtsi)$/) { + } elsif ($realfile =~ /\.(c|rs|dts|dtsi)$/) { $comment = '//'; } elsif (($checklicenseline == 2) || $realfile =~ /\.(sh|pl|py|awk|tc|yaml)$/) { $comment = '#'; @@ -3664,7 +3664,7 @@ sub process { } # check we are in a valid source file if not then ignore this hunk - next if ($realfile !~ /\.(h|c|s|S|sh|dtsi|dts)$/); + next if ($realfile !~ /\.(h|c|rs|s|S|sh|dtsi|dts)$/); # check for using SPDX-License-Identifier on the wrong line number if ($realline != $checklicenseline && -- cgit v1.2.3 From f4bf1cd4ac9c8c4610b687e49a1ba691ab286235 Mon Sep 17 00:00:00 2001 From: Jonathan Corbet Date: Tue, 27 Sep 2022 10:05:57 -0600 Subject: docs: move asm-annotations.rst into core-api This one file should not really be in the top-level documentation directory. core-api/ may not be a perfect fit but seems to be best, so move it there. Adjust a couple of internal document references to make them location-independent, and point checkpatch.pl at the new location. Cc: Jiri Slaby Cc: Joe Perches Reviewed-by: David Vernet Acked-by: Jani Nikula Signed-off-by: Jonathan Corbet Acked-by: Randy Dunlap Link: https://lore.kernel.org/r/20220927160559.97154-6-corbet@lwn.net Signed-off-by: Jonathan Corbet --- Documentation/asm-annotations.rst | 221 ---------------------------- Documentation/core-api/asm-annotations.rst | 222 +++++++++++++++++++++++++++++ Documentation/core-api/index.rst | 1 + Documentation/index.rst | 8 -- scripts/checkpatch.pl | 2 +- 5 files changed, 224 insertions(+), 230 deletions(-) delete mode 100644 Documentation/asm-annotations.rst create mode 100644 Documentation/core-api/asm-annotations.rst (limited to 'scripts/checkpatch.pl') diff --git a/Documentation/asm-annotations.rst b/Documentation/asm-annotations.rst deleted file mode 100644 index a64f2ca469d4..000000000000 --- a/Documentation/asm-annotations.rst +++ /dev/null @@ -1,221 +0,0 @@ -Assembler Annotations -===================== - -Copyright (c) 2017-2019 Jiri Slaby - -This document describes the new macros for annotation of data and code in -assembly. In particular, it contains information about ``SYM_FUNC_START``, -``SYM_FUNC_END``, ``SYM_CODE_START``, and similar. - -Rationale ---------- -Some code like entries, trampolines, or boot code needs to be written in -assembly. The same as in C, such code is grouped into functions and -accompanied with data. Standard assemblers do not force users into precisely -marking these pieces as code, data, or even specifying their length. -Nevertheless, assemblers provide developers with such annotations to aid -debuggers throughout assembly. On top of that, developers also want to mark -some functions as *global* in order to be visible outside of their translation -units. - -Over time, the Linux kernel has adopted macros from various projects (like -``binutils``) to facilitate such annotations. So for historic reasons, -developers have been using ``ENTRY``, ``END``, ``ENDPROC``, and other -annotations in assembly. Due to the lack of their documentation, the macros -are used in rather wrong contexts at some locations. Clearly, ``ENTRY`` was -intended to denote the beginning of global symbols (be it data or code). -``END`` used to mark the end of data or end of special functions with -*non-standard* calling convention. In contrast, ``ENDPROC`` should annotate -only ends of *standard* functions. - -When these macros are used correctly, they help assemblers generate a nice -object with both sizes and types set correctly. For example, the result of -``arch/x86/lib/putuser.S``:: - - Num: Value Size Type Bind Vis Ndx Name - 25: 0000000000000000 33 FUNC GLOBAL DEFAULT 1 __put_user_1 - 29: 0000000000000030 37 FUNC GLOBAL DEFAULT 1 __put_user_2 - 32: 0000000000000060 36 FUNC GLOBAL DEFAULT 1 __put_user_4 - 35: 0000000000000090 37 FUNC GLOBAL DEFAULT 1 __put_user_8 - -This is not only important for debugging purposes. When there are properly -annotated objects like this, tools can be run on them to generate more useful -information. In particular, on properly annotated objects, ``objtool`` can be -run to check and fix the object if needed. Currently, ``objtool`` can report -missing frame pointer setup/destruction in functions. It can also -automatically generate annotations for :doc:`ORC unwinder ` -for most code. Both of these are especially important to support reliable -stack traces which are in turn necessary for :doc:`Kernel live patching -`. - -Caveat and Discussion ---------------------- -As one might realize, there were only three macros previously. That is indeed -insufficient to cover all the combinations of cases: - -* standard/non-standard function -* code/data -* global/local symbol - -There was a discussion_ and instead of extending the current ``ENTRY/END*`` -macros, it was decided that brand new macros should be introduced instead:: - - So how about using macro names that actually show the purpose, instead - of importing all the crappy, historic, essentially randomly chosen - debug symbol macro names from the binutils and older kernels? - -.. _discussion: https://lore.kernel.org/r/20170217104757.28588-1-jslaby@suse.cz - -Macros Description ------------------- - -The new macros are prefixed with the ``SYM_`` prefix and can be divided into -three main groups: - -1. ``SYM_FUNC_*`` -- to annotate C-like functions. This means functions with - standard C calling conventions. For example, on x86, this means that the - stack contains a return address at the predefined place and a return from - the function can happen in a standard way. When frame pointers are enabled, - save/restore of frame pointer shall happen at the start/end of a function, - respectively, too. - - Checking tools like ``objtool`` should ensure such marked functions conform - to these rules. The tools can also easily annotate these functions with - debugging information (like *ORC data*) automatically. - -2. ``SYM_CODE_*`` -- special functions called with special stack. Be it - interrupt handlers with special stack content, trampolines, or startup - functions. - - Checking tools mostly ignore checking of these functions. But some debug - information still can be generated automatically. For correct debug data, - this code needs hints like ``UNWIND_HINT_REGS`` provided by developers. - -3. ``SYM_DATA*`` -- obviously data belonging to ``.data`` sections and not to - ``.text``. Data do not contain instructions, so they have to be treated - specially by the tools: they should not treat the bytes as instructions, - nor assign any debug information to them. - -Instruction Macros -~~~~~~~~~~~~~~~~~~ -This section covers ``SYM_FUNC_*`` and ``SYM_CODE_*`` enumerated above. - -``objtool`` requires that all code must be contained in an ELF symbol. Symbol -names that have a ``.L`` prefix do not emit symbol table entries. ``.L`` -prefixed symbols can be used within a code region, but should be avoided for -denoting a range of code via ``SYM_*_START/END`` annotations. - -* ``SYM_FUNC_START`` and ``SYM_FUNC_START_LOCAL`` are supposed to be **the - most frequent markings**. They are used for functions with standard calling - conventions -- global and local. Like in C, they both align the functions to - architecture specific ``__ALIGN`` bytes. There are also ``_NOALIGN`` variants - for special cases where developers do not want this implicit alignment. - - ``SYM_FUNC_START_WEAK`` and ``SYM_FUNC_START_WEAK_NOALIGN`` markings are - also offered as an assembler counterpart to the *weak* attribute known from - C. - - All of these **shall** be coupled with ``SYM_FUNC_END``. First, it marks - the sequence of instructions as a function and computes its size to the - generated object file. Second, it also eases checking and processing such - object files as the tools can trivially find exact function boundaries. - - So in most cases, developers should write something like in the following - example, having some asm instructions in between the macros, of course:: - - SYM_FUNC_START(memset) - ... asm insns ... - SYM_FUNC_END(memset) - - In fact, this kind of annotation corresponds to the now deprecated ``ENTRY`` - and ``ENDPROC`` macros. - -* ``SYM_FUNC_ALIAS``, ``SYM_FUNC_ALIAS_LOCAL``, and ``SYM_FUNC_ALIAS_WEAK`` can - be used to define multiple names for a function. The typical use is:: - - SYM_FUNC_START(__memset) - ... asm insns ... - SYN_FUNC_END(__memset) - SYM_FUNC_ALIAS(memset, __memset) - - In this example, one can call ``__memset`` or ``memset`` with the same - result, except the debug information for the instructions is generated to - the object file only once -- for the non-``ALIAS`` case. - -* ``SYM_CODE_START`` and ``SYM_CODE_START_LOCAL`` should be used only in - special cases -- if you know what you are doing. This is used exclusively - for interrupt handlers and similar where the calling convention is not the C - one. ``_NOALIGN`` variants exist too. The use is the same as for the ``FUNC`` - category above:: - - SYM_CODE_START_LOCAL(bad_put_user) - ... asm insns ... - SYM_CODE_END(bad_put_user) - - Again, every ``SYM_CODE_START*`` **shall** be coupled by ``SYM_CODE_END``. - - To some extent, this category corresponds to deprecated ``ENTRY`` and - ``END``. Except ``END`` had several other meanings too. - -* ``SYM_INNER_LABEL*`` is used to denote a label inside some - ``SYM_{CODE,FUNC}_START`` and ``SYM_{CODE,FUNC}_END``. They are very similar - to C labels, except they can be made global. An example of use:: - - SYM_CODE_START(ftrace_caller) - /* save_mcount_regs fills in first two parameters */ - ... - - SYM_INNER_LABEL(ftrace_caller_op_ptr, SYM_L_GLOBAL) - /* Load the ftrace_ops into the 3rd parameter */ - ... - - SYM_INNER_LABEL(ftrace_call, SYM_L_GLOBAL) - call ftrace_stub - ... - retq - SYM_CODE_END(ftrace_caller) - -Data Macros -~~~~~~~~~~~ -Similar to instructions, there is a couple of macros to describe data in the -assembly. - -* ``SYM_DATA_START`` and ``SYM_DATA_START_LOCAL`` mark the start of some data - and shall be used in conjunction with either ``SYM_DATA_END``, or - ``SYM_DATA_END_LABEL``. The latter adds also a label to the end, so that - people can use ``lstack`` and (local) ``lstack_end`` in the following - example:: - - SYM_DATA_START_LOCAL(lstack) - .skip 4096 - SYM_DATA_END_LABEL(lstack, SYM_L_LOCAL, lstack_end) - -* ``SYM_DATA`` and ``SYM_DATA_LOCAL`` are variants for simple, mostly one-line - data:: - - SYM_DATA(HEAP, .long rm_heap) - SYM_DATA(heap_end, .long rm_stack) - - In the end, they expand to ``SYM_DATA_START`` with ``SYM_DATA_END`` - internally. - -Support Macros -~~~~~~~~~~~~~~ -All the above reduce themselves to some invocation of ``SYM_START``, -``SYM_END``, or ``SYM_ENTRY`` at last. Normally, developers should avoid using -these. - -Further, in the above examples, one could see ``SYM_L_LOCAL``. There are also -``SYM_L_GLOBAL`` and ``SYM_L_WEAK``. All are intended to denote linkage of a -symbol marked by them. They are used either in ``_LABEL`` variants of the -earlier macros, or in ``SYM_START``. - - -Overriding Macros -~~~~~~~~~~~~~~~~~ -Architecture can also override any of the macros in their own -``asm/linkage.h``, including macros specifying the type of a symbol -(``SYM_T_FUNC``, ``SYM_T_OBJECT``, and ``SYM_T_NONE``). As every macro -described in this file is surrounded by ``#ifdef`` + ``#endif``, it is enough -to define the macros differently in the aforementioned architecture-dependent -header. diff --git a/Documentation/core-api/asm-annotations.rst b/Documentation/core-api/asm-annotations.rst new file mode 100644 index 000000000000..bc514ed59887 --- /dev/null +++ b/Documentation/core-api/asm-annotations.rst @@ -0,0 +1,222 @@ +Assembler Annotations +===================== + +Copyright (c) 2017-2019 Jiri Slaby + +This document describes the new macros for annotation of data and code in +assembly. In particular, it contains information about ``SYM_FUNC_START``, +``SYM_FUNC_END``, ``SYM_CODE_START``, and similar. + +Rationale +--------- +Some code like entries, trampolines, or boot code needs to be written in +assembly. The same as in C, such code is grouped into functions and +accompanied with data. Standard assemblers do not force users into precisely +marking these pieces as code, data, or even specifying their length. +Nevertheless, assemblers provide developers with such annotations to aid +debuggers throughout assembly. On top of that, developers also want to mark +some functions as *global* in order to be visible outside of their translation +units. + +Over time, the Linux kernel has adopted macros from various projects (like +``binutils``) to facilitate such annotations. So for historic reasons, +developers have been using ``ENTRY``, ``END``, ``ENDPROC``, and other +annotations in assembly. Due to the lack of their documentation, the macros +are used in rather wrong contexts at some locations. Clearly, ``ENTRY`` was +intended to denote the beginning of global symbols (be it data or code). +``END`` used to mark the end of data or end of special functions with +*non-standard* calling convention. In contrast, ``ENDPROC`` should annotate +only ends of *standard* functions. + +When these macros are used correctly, they help assemblers generate a nice +object with both sizes and types set correctly. For example, the result of +``arch/x86/lib/putuser.S``:: + + Num: Value Size Type Bind Vis Ndx Name + 25: 0000000000000000 33 FUNC GLOBAL DEFAULT 1 __put_user_1 + 29: 0000000000000030 37 FUNC GLOBAL DEFAULT 1 __put_user_2 + 32: 0000000000000060 36 FUNC GLOBAL DEFAULT 1 __put_user_4 + 35: 0000000000000090 37 FUNC GLOBAL DEFAULT 1 __put_user_8 + +This is not only important for debugging purposes. When there are properly +annotated objects like this, tools can be run on them to generate more useful +information. In particular, on properly annotated objects, ``objtool`` can be +run to check and fix the object if needed. Currently, ``objtool`` can report +missing frame pointer setup/destruction in functions. It can also +automatically generate annotations for the ORC unwinder +(Documentation/x86/orc-unwinder.rst) +for most code. Both of these are especially important to support reliable +stack traces which are in turn necessary for kernel live patching +(Documentation/livepatch/livepatch.rst). + +Caveat and Discussion +--------------------- +As one might realize, there were only three macros previously. That is indeed +insufficient to cover all the combinations of cases: + +* standard/non-standard function +* code/data +* global/local symbol + +There was a discussion_ and instead of extending the current ``ENTRY/END*`` +macros, it was decided that brand new macros should be introduced instead:: + + So how about using macro names that actually show the purpose, instead + of importing all the crappy, historic, essentially randomly chosen + debug symbol macro names from the binutils and older kernels? + +.. _discussion: https://lore.kernel.org/r/20170217104757.28588-1-jslaby@suse.cz + +Macros Description +------------------ + +The new macros are prefixed with the ``SYM_`` prefix and can be divided into +three main groups: + +1. ``SYM_FUNC_*`` -- to annotate C-like functions. This means functions with + standard C calling conventions. For example, on x86, this means that the + stack contains a return address at the predefined place and a return from + the function can happen in a standard way. When frame pointers are enabled, + save/restore of frame pointer shall happen at the start/end of a function, + respectively, too. + + Checking tools like ``objtool`` should ensure such marked functions conform + to these rules. The tools can also easily annotate these functions with + debugging information (like *ORC data*) automatically. + +2. ``SYM_CODE_*`` -- special functions called with special stack. Be it + interrupt handlers with special stack content, trampolines, or startup + functions. + + Checking tools mostly ignore checking of these functions. But some debug + information still can be generated automatically. For correct debug data, + this code needs hints like ``UNWIND_HINT_REGS`` provided by developers. + +3. ``SYM_DATA*`` -- obviously data belonging to ``.data`` sections and not to + ``.text``. Data do not contain instructions, so they have to be treated + specially by the tools: they should not treat the bytes as instructions, + nor assign any debug information to them. + +Instruction Macros +~~~~~~~~~~~~~~~~~~ +This section covers ``SYM_FUNC_*`` and ``SYM_CODE_*`` enumerated above. + +``objtool`` requires that all code must be contained in an ELF symbol. Symbol +names that have a ``.L`` prefix do not emit symbol table entries. ``.L`` +prefixed symbols can be used within a code region, but should be avoided for +denoting a range of code via ``SYM_*_START/END`` annotations. + +* ``SYM_FUNC_START`` and ``SYM_FUNC_START_LOCAL`` are supposed to be **the + most frequent markings**. They are used for functions with standard calling + conventions -- global and local. Like in C, they both align the functions to + architecture specific ``__ALIGN`` bytes. There are also ``_NOALIGN`` variants + for special cases where developers do not want this implicit alignment. + + ``SYM_FUNC_START_WEAK`` and ``SYM_FUNC_START_WEAK_NOALIGN`` markings are + also offered as an assembler counterpart to the *weak* attribute known from + C. + + All of these **shall** be coupled with ``SYM_FUNC_END``. First, it marks + the sequence of instructions as a function and computes its size to the + generated object file. Second, it also eases checking and processing such + object files as the tools can trivially find exact function boundaries. + + So in most cases, developers should write something like in the following + example, having some asm instructions in between the macros, of course:: + + SYM_FUNC_START(memset) + ... asm insns ... + SYM_FUNC_END(memset) + + In fact, this kind of annotation corresponds to the now deprecated ``ENTRY`` + and ``ENDPROC`` macros. + +* ``SYM_FUNC_ALIAS``, ``SYM_FUNC_ALIAS_LOCAL``, and ``SYM_FUNC_ALIAS_WEAK`` can + be used to define multiple names for a function. The typical use is:: + + SYM_FUNC_START(__memset) + ... asm insns ... + SYN_FUNC_END(__memset) + SYM_FUNC_ALIAS(memset, __memset) + + In this example, one can call ``__memset`` or ``memset`` with the same + result, except the debug information for the instructions is generated to + the object file only once -- for the non-``ALIAS`` case. + +* ``SYM_CODE_START`` and ``SYM_CODE_START_LOCAL`` should be used only in + special cases -- if you know what you are doing. This is used exclusively + for interrupt handlers and similar where the calling convention is not the C + one. ``_NOALIGN`` variants exist too. The use is the same as for the ``FUNC`` + category above:: + + SYM_CODE_START_LOCAL(bad_put_user) + ... asm insns ... + SYM_CODE_END(bad_put_user) + + Again, every ``SYM_CODE_START*`` **shall** be coupled by ``SYM_CODE_END``. + + To some extent, this category corresponds to deprecated ``ENTRY`` and + ``END``. Except ``END`` had several other meanings too. + +* ``SYM_INNER_LABEL*`` is used to denote a label inside some + ``SYM_{CODE,FUNC}_START`` and ``SYM_{CODE,FUNC}_END``. They are very similar + to C labels, except they can be made global. An example of use:: + + SYM_CODE_START(ftrace_caller) + /* save_mcount_regs fills in first two parameters */ + ... + + SYM_INNER_LABEL(ftrace_caller_op_ptr, SYM_L_GLOBAL) + /* Load the ftrace_ops into the 3rd parameter */ + ... + + SYM_INNER_LABEL(ftrace_call, SYM_L_GLOBAL) + call ftrace_stub + ... + retq + SYM_CODE_END(ftrace_caller) + +Data Macros +~~~~~~~~~~~ +Similar to instructions, there is a couple of macros to describe data in the +assembly. + +* ``SYM_DATA_START`` and ``SYM_DATA_START_LOCAL`` mark the start of some data + and shall be used in conjunction with either ``SYM_DATA_END``, or + ``SYM_DATA_END_LABEL``. The latter adds also a label to the end, so that + people can use ``lstack`` and (local) ``lstack_end`` in the following + example:: + + SYM_DATA_START_LOCAL(lstack) + .skip 4096 + SYM_DATA_END_LABEL(lstack, SYM_L_LOCAL, lstack_end) + +* ``SYM_DATA`` and ``SYM_DATA_LOCAL`` are variants for simple, mostly one-line + data:: + + SYM_DATA(HEAP, .long rm_heap) + SYM_DATA(heap_end, .long rm_stack) + + In the end, they expand to ``SYM_DATA_START`` with ``SYM_DATA_END`` + internally. + +Support Macros +~~~~~~~~~~~~~~ +All the above reduce themselves to some invocation of ``SYM_START``, +``SYM_END``, or ``SYM_ENTRY`` at last. Normally, developers should avoid using +these. + +Further, in the above examples, one could see ``SYM_L_LOCAL``. There are also +``SYM_L_GLOBAL`` and ``SYM_L_WEAK``. All are intended to denote linkage of a +symbol marked by them. They are used either in ``_LABEL`` variants of the +earlier macros, or in ``SYM_START``. + + +Overriding Macros +~~~~~~~~~~~~~~~~~ +Architecture can also override any of the macros in their own +``asm/linkage.h``, including macros specifying the type of a symbol +(``SYM_T_FUNC``, ``SYM_T_OBJECT``, and ``SYM_T_NONE``). As every macro +described in this file is surrounded by ``#ifdef`` + ``#endif``, it is enough +to define the macros differently in the aforementioned architecture-dependent +header. diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst index dc95df462eea..f5d8e3779fe8 100644 --- a/Documentation/core-api/index.rst +++ b/Documentation/core-api/index.rst @@ -23,6 +23,7 @@ it. printk-formats printk-index symbol-namespaces + asm-annotations Data structures and low-level utilities ======================================= diff --git a/Documentation/index.rst b/Documentation/index.rst index da80c584133c..5a700548ae82 100644 --- a/Documentation/index.rst +++ b/Documentation/index.rst @@ -89,14 +89,6 @@ platform firmwares. devicetree/index -Architecture-agnostic documentation ------------------------------------ - -.. toctree:: - :maxdepth: 1 - - asm-annotations - Architecture-specific documentation ----------------------------------- diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl index 79e759aac543..812af52f97d2 100755 --- a/scripts/checkpatch.pl +++ b/scripts/checkpatch.pl @@ -3751,7 +3751,7 @@ sub process { if ($realfile =~ /\.S$/ && $line =~ /^\+\s*(?:[A-Z]+_)?SYM_[A-Z]+_(?:START|END)(?:_[A-Z_]+)?\s*\(\s*\.L/) { WARN("AVOID_L_PREFIX", - "Avoid using '.L' prefixed local symbol names for denoting a range of code via 'SYM_*_START/END' annotations; see Documentation/asm-annotations.rst\n" . $herecurr); + "Avoid using '.L' prefixed local symbol names for denoting a range of code via 'SYM_*_START/END' annotations; see Documentation/core-api/asm-annotations.rst\n" . $herecurr); } # check we are in a valid source file C or perl if not then ignore this hunk -- cgit v1.2.3 From 69d517e6e21099f81efbd39e47874649ae575804 Mon Sep 17 00:00:00 2001 From: David Hildenbrand Date: Fri, 23 Sep 2022 13:34:25 +0200 Subject: checkpatch: warn on usage of VM_BUG_ON() and other BUG variants checkpatch does not point out that VM_BUG_ON() and friends should be avoided, however, Linus notes: VM_BUG_ON() has the exact same semantics as BUG_ON. It is literally no different, the only difference is "we can make the code smaller because these are less important". [1] So let's warn on VM_BUG_ON() and other BUG variants as well. While at it, make it clearer that the kernel really shouldn't be crashed. As there are some subsystem BUG macros that actually don't end up crashing the kernel -- for example, KVM_BUG_ON() -- exclude these manually. [1] https://lore.kernel.org/r/CAHk-=wg40EAZofO16Eviaj7mfqDhZ2gVEbvfsMf6gYzspRjYvw@mail.gmail.com Signed-off-by: David Hildenbrand Link: https://lore.kernel.org/r/20220923113426.52871-3-david@redhat.com Signed-off-by: Jonathan Corbet --- scripts/checkpatch.pl | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'scripts/checkpatch.pl') diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl index 812af52f97d2..4aa09e0cb86a 100755 --- a/scripts/checkpatch.pl +++ b/scripts/checkpatch.pl @@ -4695,12 +4695,12 @@ sub process { } } -# avoid BUG() or BUG_ON() - if ($line =~ /\b(?:BUG|BUG_ON)\b/) { +# do not use BUG() or variants + if ($line =~ /\b(?!AA_|BUILD_|DCCP_|IDA_|KVM_|RWLOCK_|snd_|SPIN_)(?:[a-zA-Z_]*_)?BUG(?:_ON)?(?:_[A-Z_]+)?\s*\(/) { my $msg_level = \&WARN; $msg_level = \&CHK if ($file); &{$msg_level}("AVOID_BUG", - "Avoid crashing the kernel - try using WARN_ON & recovery code rather than BUG() or BUG_ON()\n" . $herecurr); + "Do not crash the kernel unless it is absolutely unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of BUG() or variants\n" . $herecurr); } # avoid LINUX_VERSION_CODE -- cgit v1.2.3 From bd17e036b495bebbf07a5fc814c868e30e1dc131 Mon Sep 17 00:00:00 2001 From: Niklas Söderlund Date: Wed, 14 Sep 2022 12:02:55 +0200 Subject: checkpatch: warn for non-standard fixes tag style MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add a warning for fixes tags that does not follow community conventions. Link: https://lkml.kernel.org/r/20220914100255.1048460-1-niklas.soderlund@corigine.com Signed-off-by: Niklas Söderlund Reviewed-by: Simon Horman Reviewed-by: Louis Peens Reviewed-by: Philippe Schenker Acked-by: Dwaipayan Ray Reviewed-by: Lukas Bulwahn Acked-by: Lukas Bulwahn Acked-by: Joe Perches Signed-off-by: Andrew Morton --- Documentation/dev-tools/checkpatch.rst | 7 ++++++ scripts/checkpatch.pl | 44 ++++++++++++++++++++++++++++++++++ 2 files changed, 51 insertions(+) (limited to 'scripts/checkpatch.pl') diff --git a/Documentation/dev-tools/checkpatch.rst b/Documentation/dev-tools/checkpatch.rst index b52452bc2963..c3389c6f3838 100644 --- a/Documentation/dev-tools/checkpatch.rst +++ b/Documentation/dev-tools/checkpatch.rst @@ -612,6 +612,13 @@ Commit message See: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#describe-your-changes + **BAD_FIXES_TAG** + The Fixes: tag is malformed or does not follow the community conventions. + This can occur if the tag have been split into multiple lines (e.g., when + pasted in an email program with word wrapping enabled). + + See: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#describe-your-changes + Comparison style ---------------- diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl index 18effbe1fe90..e8e0542f29f0 100755 --- a/scripts/checkpatch.pl +++ b/scripts/checkpatch.pl @@ -3146,6 +3146,50 @@ sub process { } } +# Check Fixes: styles is correct + if (!$in_header_lines && + $line =~ /^\s*fixes:?\s*(?:commit\s*)?[0-9a-f]{5,}\b/i) { + my $orig_commit = ""; + my $id = "0123456789ab"; + my $title = "commit title"; + my $tag_case = 1; + my $tag_space = 1; + my $id_length = 1; + my $id_case = 1; + my $title_has_quotes = 0; + + if ($line =~ /(\s*fixes:?)\s+([0-9a-f]{5,})\s+($balanced_parens)/i) { + my $tag = $1; + $orig_commit = $2; + $title = $3; + + $tag_case = 0 if $tag eq "Fixes:"; + $tag_space = 0 if ($line =~ /^fixes:? [0-9a-f]{5,} ($balanced_parens)/i); + + $id_length = 0 if ($orig_commit =~ /^[0-9a-f]{12}$/i); + $id_case = 0 if ($orig_commit !~ /[A-F]/); + + # Always strip leading/trailing parens then double quotes if existing + $title = substr($title, 1, -1); + if ($title =~ /^".*"$/) { + $title = substr($title, 1, -1); + $title_has_quotes = 1; + } + } + + my ($cid, $ctitle) = git_commit_info($orig_commit, $id, + $title); + + if ($ctitle ne $title || $tag_case || $tag_space || + $id_length || $id_case || !$title_has_quotes) { + if (WARN("BAD_FIXES_TAG", + "Please use correct Fixes: style 'Fixes: <12 chars of sha1> (\"\")' - ie: 'Fixes: $cid (\"$ctitle\")'\n" . $herecurr) && + $fix) { + $fixed[$fixlinenr] = "Fixes: $cid (\"$ctitle\")"; + } + } + } + # Check email subject for common tools that don't need to be mentioned if ($in_header_lines && $line =~ /^Subject:.*\b(?:checkpatch|sparse|smatch)\b[^:]/i) { -- cgit v1.2.3