- 24 Nov, 2020 40 commits
-
-
Jani Nikula authored
Now that relay_open() accepts const callbacks, make relay callbacks const. Link: https://lkml.kernel.org/r/44e3d65b71025c462948d0c554061dc7b40ab488.1606153547.git.jani.nikula@intel.com Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Acked-by:
Kalle Valo <kvalo@codeaurora.org> Cc: Christoph Hellwig <hch@infradead.org> Cc: Jens Axboe <axboe@kernel.dk> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Stephen Rothwell <sfr@canb.auug.org.au>
-
Jani Nikula authored
Now that relay_open() accepts const callbacks, make relay callbacks const. Link: https://lkml.kernel.org/r/85cabc6d4b0d0ca43d4e0fb94897ccd16e3b7930.1606153547.git.jani.nikula@intel.com Signed-off-by:
-
Jani Nikula authored
Now that relay_open() accepts const callbacks, make relay callbacks const. Link: https://lkml.kernel.org/r/534d089f413db98aa0b94773fa49d5275d0d3c25.1606153547.git.jani.nikula@intel.com Signed-off-by:
-
Jani Nikula authored
None of the relay users require the use of mutable structs for callbacks, however the relay code does. Instead of assigning the default callback for subbuf_start, add a wrapper to conditionally call the client callback if available, and fall back to default behaviour otherwise. This lets all relay users make their struct rchan_callbacks const data. Link: https://lkml.kernel.org/r/cc3ff292e4eb4fdc56bee3d690c7b8e39209cd37.1606153547.git.jani.nikula@intel.com Signed-off-by:
-
Jani Nikula authored
All clients provide create_buf_file and remove_buf_file callbacks, and they're required for relay to make sense. There is no point in them being optional. Also document whether each callback is mandatory/optional. Link: https://lkml.kernel.org/r/88003c1527386b93036e286e7917f1e33aec84ac.1606153547.git.jani.nikula@intel.com Signed-off-by:
Christoph Hellwig <hch@infradead.org> Cc: Jens Axboe <axboe@kernel.dk> Cc: Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Jani Nikula authored
There are no clients passing NULL callbacks, which makes sense as it wouldn't even create a file. Require non-NULL callbacks, and throw away the handling for NULL callbacks. Link: https://lkml.kernel.org/r/e40642f3b027d2bb6bc851ddb60e0a61ea51f5f8.1606153547.git.jani.nikula@intel.com Signed-off-by:
-
Jani Nikula authored
Patch series "relay: cleanup and const callbacks", v2. None of the relay users require the use of mutable structs for callbacks, however the relay code does. Instead of assigning default callbacks when there is none, add callback wrappers to conditionally call the client callbacks if available, and fall back to default behaviour (typically no-op) otherwise. This lets all relay users make their struct rchan_callbacks const data. This series starts with a number of cleanups first based on Christoph's feedback. This patch (of 9): No relay client uses the buf_mapped or buf_unmapped callbacks. Remove them. This makes relay's vm_operations_struct close callback a dummy, remove it as well. Link: https://lkml.kernel.org/r/cover.1606153547.git.jani.nikula@intel.com Link: https://lkml.kernel.org/r/c69fff6e0cd485563604240bbfcc028434983bec.1606153547.git.jani.nikula@intel.com Signed-off-by:
-
Alex Shi authored
Fix the following kernel-doc issue in gcov: kernel/gcov/gcc_4_7.c:238: warning: Function parameter or member 'dst' not described in 'gcov_info_add' kernel/gcov/gcc_4_7.c:238: warning: Function parameter or member 'src' not described in 'gcov_info_add' kernel/gcov/gcc_4_7.c:238: warning: Excess function parameter 'dest' description in 'gcov_info_add' kernel/gcov/gcc_4_7.c:238: warning: Excess function parameter 'source' description in 'gcov_info_add' Link: https://lkml.kernel.org/r/1605252352-63983-1-git-send-email-alex.shi@linux.alibaba.com Signed-off-by:
Alex Shi <alex.shi@linux.alibaba.com> Acked-by:
Peter Oberparleiter <oberpar@linux.ibm.com> Signed-off-by:
-
Nick Desaulniers authored
Since commit 0bddd227 ("Documentation: update for gcc 4.9 requirement") the minimum supported version of GCC is gcc-4.9. It's now safe to remove this code. Similar to commit 10415533 ("gcov: Remove old GCC 3.4 support") but that was for GCC 4.8 and this is for GCC 4.9. Link: https://github.com/ClangBuiltLinux/linux/issues/427 Link: https://lkml.kernel.org/r/20201111030557.2015680-1-ndesaulniers@google.com Signed-off-by:
Nick Desaulniers <ndesaulniers@google.com> Reviewed-by:
-
Sebastian Andrzej Siewior authored
The functions rio_get_asm() and rio_get_device() are globally exported but have almost no users in tree. The only user is rio_init_mports() which invokes it via rio_init(). rio_init() iterates over every registered device and invokes rio_fixup_device(). It looks like a fixup function which should perform a "change" to the device but does nothing. It has been like this since its introduction in commit 394b701c ("[PATCH] RapidIO support: core base") which was merged into v2.6.15-rc1. Remove rio_init() because the performed fixup function (rio_fixup_device()) does nothing. Remove rio_get_asm() and rio_get_device() which have no callers now. Link: https://lkml.kernel.org/r/20201116170004.420143-1-bigeasy@linutronix.de Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Cc: Matt Porter <mporter@kernel.crashing.org> Cc: Alexandre Bounine <alex.bou9@gmail.com> Signed-off-by:
-
Alexander Egorenkov authored
The offset of the field 'init_uts_ns.name' has changed since commit 9a56493f ("uts: Use generic ns_common::count"). Make the offset of the field 'uts_namespace.name' available in VMCOREINFO because tools like 'crash-utility' and 'makedumpfile' must be able to read it from crash dumps. Link: https://lore.kernel.org/r/159644978167.604812.1773586504374412107.stgit@localhost.localdomain Link: https://lkml.kernel.org/r/20200930102328.396488-1-egorenar@linux.ibm.com Signed-off-by:
Alexander Egorenkov <egorenar@linux.ibm.com> Acked-by:
lijiang <lijiang@redhat.com> Acked-by:
Baoquan He <bhe@redhat.com> Cc: Dave Young <dyoung@redhat.com> Cc: Vivek Goyal <vgoyal@redhat.com> Cc: "Eric W . Biederman" <ebiederm@xmission.com> Cc: Kirill Tkhai <ktkhai@virtuozzo.com> Cc: Kees Cook <keescook@chromium.org> Cc: Christian Brauner <christian.brauner@ubuntu.com> Signed-off-by:
-
Rustam Kovhaev authored
When a directory item has an invalid value set for ih_entry_count it might trigger use-after-free or out-of-bounds read in bin_search_in_dir_item() ih_entry_count * IH_SIZE for directory item should not be larger than ih_item_len Link: https://syzkaller.appspot.com/bug?extid=83b6f7cf9922cae5c4d7 Link: https://lkml.kernel.org/r/20201101140958.3650143-1-rkovhaev@gmail.com Signed-off-by:
Rustam Kovhaev <rkovhaev@gmail.com> Reported-and-tested-by:
<syzbot+83b6f7cf9922cae5c4d7@syzkaller.appspotmail.com> Cc: Jan Kara <jack@suse.cz> Signed-off-by:
-
Aditya Srivastava authored
Currently, checkpatch warns us if an assignment operator is placed at the start of a line and not at the end of previous line. E.g., running checkpatch on commit 8195b139 ("hv_netvsc: fix deadlock on hotplug") reports: CHECK: Assignment operator '=' should be on the previous line + struct netvsc_device *nvdev + = container_of(w, struct netvsc_device, subchan_work); Provide a simple fix by appending assignment operator to the previous line and removing from the current line, if both the lines are additions (ie start with '+') Link: https://lkml.kernel.org/r/20201121120407.22942-1-yashsri421@gmail.com Signed-off-by:
Aditya Srivastava <yashsri421@gmail.com> Acked-by:
Joe Perches <joe@perches.com> Signed-off-by:
-
Dwaipayan Ray authored
There is an unescaped left brace in a regex in OPEN_BRACE check. This throws a runtime error when checkpatch is run with --fix flag and the OPEN_BRACE check is executed. Fix it by escaping the left brace. Link: https://lkml.kernel.org/r/20201115202928.81955-1-dwaipayanray1@gmail.com Fixes: 8d182478 ("checkpatch: add --fix option for a couple OPEN_BRACE misuses") Signed-off-by:
Dwaipayan Ray <dwaipayanray1@gmail.com> Acked-by:
-
Aditya Srivastava authored
Currently checkpatch warns us for long lines in commits even for signature tag lines. Generally these lines exceed the 75-character limit because of: 1) long names and long email address 2) some comments on scoped review and acknowledgement, i.e., for a dedicated pointer on what was reported by the identity in 'Reported-by' 3) some additional comments on CC: stable@vger.org tags Exclude signature tag lines from this class of warning. There were 1896 COMMIT_LOG_LONG_LINE warnings in v5.6..v5.8 before this patch application and 1879 afterwards. A quick manual check found all the dropped warnings related to signature tags. Link: https://lkml.kernel.org/r/20201116083754.10629-1-yashsri421@gmail.com Signed-off-by:
-
Dwaipayan Ray authored
Delete repeated word in scripts/checkpatch.pl: "are are" -> "are" Fix typos: "commments" -> "comments" "falsly" -> "falsely" Link: https://lkml.kernel.org/r/20201113152316.62975-1-dwaipayanray1@gmail.com Signed-off-by:
-
Dwaipayan Ray authored
checkpatch doesn't report warnings for many common mistakes in emails. Some of which are trailing commas and incorrect use of email comments. At the same time several false positives are reported due to incorrect handling of mail comments. The most common of which is due to the pattern: <stable@vger.kernel.org> # X.X Improve email parsing in checkpatch. Some general email rules are defined: - Multiple name comments should not be allowed. - Comments inside address should not be allowed. - In general comments should be enclosed within parentheses. Relaxation is given to comments beginning with #. - Stable addresses should not begin with a name. - Comments in stable addresses should begin only with a #. Improvements to parsing: - Detect and report unexpected content after email. - Quoted names are excluded from comment parsing. - Trailing dots, commas or quotes in email are removed during formatting. Correspondingly a BAD_SIGN_OFF warning is emitted. - Improperly quoted email like '"name <address>"' are now warned about. In addition, added fixes for all the possible rules. Link: https://lore.kernel.org/linux-kernel-mentees/6c275d95c3033422addfc256a30e6ae3dd37941d.camel@perches.com/ Link: https://lore.kernel.org/linux-kernel-mentees/20201105200857.GC1333458@kroah.com/ Link: https://lkml.kernel.org/r/20201108100632.75340-1-dwaipayanray1@gmail.com Signed-off-by:
-
Joe Perches authored
Add __alias and __weak to the suggested __attribute__((<foo>)) conversions. Link: https://lkml.kernel.org/r/7b74137743c58ce0633ec4d575b94e2210e4dbe7.camel@perches.com Signed-off-by:
-
Aditya Srivastava authored
Currently, whenever a Gerrit Change-Id is present in a commit, checkpatch.pl warns to remove the Change-Id before submitting the patch. E.g., running checkpatch on commit adc311a5 ("iwlwifi: bump FW API to 53 for 22000 series") reports this error: ERROR: Remove Gerrit Change-Id's before submitting upstream Change-Id: I5725e46394f3f53c3069723fd513cc53c7df383d Provide a simple fix option by simply deleting the indicated line. Link: https://lkml.kernel.org/r/20201030114447.24199-1-yashsri421@gmail.com Signed-off-by:
-
Joe Perches authored
This is a slightly shorter/better patch as it eliminates the separate test below the possible conversions loop. Link: https://lkml.kernel.org/r/58e9d55e933dc8fdc6af489f2ad797fa8eb13e44.camel@perches.com Cc: Dwaipayan Ray <dwaipayanray1@gmail.com> Signed-off-by:
-
Joe Perches authored
commit 33def849 ("treewide: Convert macro and uses of __section(foo) to __section("foo")") removed the stringification of the section name and now requires quotes around the named section. Update checkpatch to not remove any quotes when suggesting conversion of __attribute__((section("name"))) to __section("name") Miscellanea: o Add section to the hash with __section replacement o Remove separate test for __attribute__((section o Remove the limitation on converting attributes containing only known, possible conversions. Any unknown attribute types are now left as-is and known types are converted and moved before __attribute__ and removed from within the __attribute__((list...)). Link: https://lkml.kernel.org/r/c04dd1c810e8d6a68e6a632e3191ae91651c8edf.camel@perches.com Signed-off-by:
-
Tom Rix authored
Remove the trailing error message from the fixed lines. Link: https://lkml.kernel.org/r/20201017142546.28988-1-trix@redhat.com Signed-off-by:
Tom Rix <trix@redhat.com> Acked-by:
-
Dwaipayan Ray authored
It is generally preferred that the macros from include/linux/compiler_attributes.h are used, unless there is a reason not to. checkpatch currently checks __attribute__ for each of packed, aligned, section, printf, scanf, and weak. Other declarations in compiler_attributes.h are not handled. Add a generic test to check the presence of such attributes. Some attributes require more specific handling and are kept separate. Also add fixes to the generic attributes check to substitute the correct conversions. New attributes which are now handled are: __always_inline__ __assume_aligned__(a, ## __VA_ARGS__) __cold__ __const__ __copy__(symbol) __designated_init__ __externally_visible__ __gnu_inline__ __malloc__ __mode__(x) __no_caller_saved_registers__ __noclone__ __noinline__ __nonstring__ __noreturn__ __pure__ __unused__ __used__ Declarations which contain multiple attributes like __attribute__((__packed__, __cold__)) are also handled except when proper conversions for one or more attributes of the list cannot be determined. Link: https://lore.kernel.org/linux-kernel-mentees/3ec15b41754b01666d94b76ce51b9832c2dd577a.camel@perches.com/ Link: https://lkml.kernel.org/r/20201025193103.23223-1-dwaipayanray1@gmail.com Signed-off-by:
-
Joe Perches authored
switch/case use of break after a return, goto or break is unnecessary. There is an existing warning for the return and goto uses, so add break and a --fix option too. Link: https://lkml.kernel.org/r/d9ea654104d55f590fb97d252d64a66b23c1a096.camel@perches.com Signed-off-by:
-
Joe Perches authored
There are about 100,000 uses of 'static const <type>' but about 400 uses of 'static <type> const' in the kernel where type is not a pointer. The kernel almost always uses "static const" over "const static" as there is a compiler warning for that declaration style. But there is no compiler warning for "static <type> const". So add a checkpatch warning for the atypical declaration uses of. const static <type> <foo> and static <type> const <foo> For example: $ ./scripts/checkpatch.pl -f --emacs --quiet --nosummary -types=static_const arch/arm/crypto/aes-ce-glue.c arch/arm/crypto/aes-ce-glue.c:75: WARNING: Move const after static - use 'static const u8' #75: FILE: arch/arm/crypto/aes-ce-glue.c:75: + static u8 const rcon[] = { Link: https://lkml.kernel.org/r/4b863be68e679546b40d50b97a4a806c03056a1c.camel@perches.com Signed-off-by: -
Łukasz Stelmach authored
Ignore autogenerated CamelCase-like defines and enum values like DRM_MODE_CONNECTOR_Unknown or ETHTOOL_LINK_MODE_Asym_Pause_BIT. Link: https://lkml.kernel.org/r/20201022184916.7904-1-l.stelmach@samsung.com Signed-off-by:
Łukasz Stelmach <l.stelmach@samsung.com> Suggested-by:
-
Aditya Srivastava authored
Presence of hexadecimal address or symbol results in false warning message by checkpatch.pl. For example, running checkpatch on commit b8ad540d ("mptcp: fix memory leak in mptcp_subflow_create_socket()") results in warning: WARNING:REPEATED_WORD: Possible repeated word: 'ff' 00 00 00 00 00 00 00 00 00 2f 30 0a 81 88 ff ff ........./0..... Similarly, the presence of list command output in commit results in an unnecessary warning. For example, running checkpatch on commit 899e5ffb ("perf record: Introduce --switch-output-event") gives: WARNING:REPEATED_WORD: Possible repeated word: 'root' dr-xr-x---. 12 root root 4096 Apr 27 17:46 .. Here, it reports 'ff' and 'root' to be repeated, but it is in fact part of some address or code, where it has to be repeated. In these cases, the intent of the warning to find stylistic issues in commit messages is not met and the warning is just completely wrong in this case. To avoid these warnings, add an additional regex check for the directory permission pattern and avoid checking the line for this class of warning. Similarly, to avoid hex pattern, check if the word consists of hex symbols and skip this warning if it is not among the common english words formed using hex letters. A quick evaluation on v5.6..v5.8 showed that this fix reduces REPEATED_WORD warnings by the frequency of 1890. A quick manual check found all cases are related to hex output or list command outputs in commit messages. Link: https://lkml.kernel.org/r/20201024102253.13614-1-yashsri421@gmail.com Signed-off-by:
-
Dwaipayan Ray authored
Recently, commit 4f6ad8aa1eac ("checkpatch: move repeated word test") moved the repeated word test to check for more file types. But after this, if checkpatch.pl is run on MAINTAINERS, it generates several new warnings of the type: WARNING: Possible repeated word: 'git' For example: WARNING: Possible repeated word: 'git' +T: git git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml.git So, the pattern "git git://..." is a false positive in this case. There are several other combinations which may produce a wrong warning message, such as "@size size", ":Begin begin", etc. Extend repeated word check to compare the characters before and after the word matches. If there is a non whitespace character before the first word or a non whitespace character excluding punctuation characters after the second word, then the check is skipped and the warning is avoided. Also add case insensitive word matching to the repeated word check. Link: https://lore.kernel.org/linux-kernel-mentees/81b6a0bb2c7b9256361573f7a13201ebcd4876f1.camel@perches.com/ Link: https://lkml.kernel.org/r/20201017162732.152351-1-dwaipayanray1@gmail.com Signed-off-by:Lukas Bulwahn <lukas.bulwahn@gmail.com> Acked-by:
-
Syed Nayyar Waris authored
Reimplement the xgpio_set_multiple() function in drivers/gpio/gpio-xilinx.c to use the new generic functions: bitmap_get_value() and bitmap_set_value(). The code is now simpler to read and understand. Moreover, instead of looping for each bit in xgpio_set_multiple() function, now we can check each channel at a time and save cycles. Link: https://lkml.kernel.org/r/15a044d3ba23f00c31fd09437bdd3e5924bb91cd.1603055402.git.syednwaris@gmail.com Signed-off-by:
Syed Nayyar Waris <syednwaris@gmail.com> Signed-off-by:
William Breathitt Gray <vilhelm.gray@gmail.com> Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com> Cc: Michal Simek <michal.simek@xilinx.com> Signed-off-by:
-
Syed Nayyar Waris authored
Reimplement the thunderx_gpio_set_multiple function in drivers/gpio/gpio-thunderx.c to use the new for_each_set_clump macro. Instead of looping for each bank in thunderx_gpio_set_multiple function, now we can skip bank which is not set and save cycles. Link: https://lkml.kernel.org/r/5e94ad3c156b98d2ed28617b2ca25bacadc189d5.1603055402.git.syednwaris@gmail.com Signed-off-by:
-
Andrew Morton authored
ERROR: that open brace { should be on the previous line #151: FILE: lib/test_bitmap.c:648: +static struct clump_test_data_params clump_test_data[] __initdata = + { {{0}, 2, 0, 64, 8, clump_exp1}, ERROR: that open brace { should be on the previous line #161: FILE: lib/test_bitmap.c:658: + for(i = 0; i < clump_test_data[index].count; i++) + { ERROR: space required before the open parenthesis '(' #161: FILE: lib/test_bitmap.c:658: + for(i = 0; i < clump_test_data[index].count; i++) ERROR: that open brace { should be on the previous line #169: FILE: lib/test_bitmap.c:666: +static void __init execute_for_each_set_clump_test(unsigned int index) +{ WARNING: suspect code indent for conditional statements (8, 8) #173: FILE: lib/test_bitmap.c:670: + for_each_set_clump(start, clump, clump_test_data[index].data, [...] + expect_eq_clump(start, clump_test_data[index].limit, clump_test_data[index].exp, ERROR: that open brace { should be on the previous line #180: FILE: lib/test_bitmap.c:677: +static void __init test_for_each_set_clump(void) +{ total: 5 errors, 1 warnings, 174 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./patches/lib-test_bitmapc-add-for_each_set_clump-test-cases.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Syed Nayyar Waris <syednwaris@gmail.com> Signed-off-by: -
Syed Nayyar Waris authored
The introduction of the generic for_each_set_clump macro need test cases to verify the implementation. This patch adds test cases for scenarios in which clump sizes are 8 bits, 24 bits, 30 bits and 6 bits. The cases contain situations where clump is getting split at the word boundary and also when zeroes are present in the start and middle of bitmap. Link: https://lkml.kernel.org/r/bf4d78db5d56a6b22e68a4ecb24d4cb09d1a3124.1603055402.git.syednwaris@gmail.com Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Syed Nayyar Waris authored
Patch series "Introduce the for_each_set_clump macro", v12. This patchset introduces a new generic version of for_each_set_clump. The previous version of for_each_set_clump8 used a fixed size 8-bit clump, but the new generic version can work with clump (n-bits) having size between 1 and BITS_PER_LONG inclusive. size less than 1 or more than BITS_PER_LONG causes undefined behaviour. The patchset utilizes the new macro in some GPIO drivers. The earlier 8-bit for_each_set_clump8 facilitated a for-loop syntax that iterates over a memory region entire groups of set bits at a time. For example, suppose you would like to iterate over a 32-bit integer 8 bits at a time, skipping over 8-bit groups with no set bit, where XXXXXXXX represents the current 8-bit group: Example: 10111110 00000000 11111111 00110011 First loop: 10111110 00000000 11111111 XXXXXXXX Second loop: 10111110 00000000 XXXXXXXX 00110011 Third loop: XXXXXXXX 00000000 11111111 00110011 Each iteration of the loop returns the next 8-bit group that has at least one set bit. But with the new for_each_set_clump the clump size can be different from 8 bits. Moreover, the clump can be split at word boundary in situations where word size is not multiple of clump size. Following are examples showing the working of new macro for clump sizes of 24 bits and 6 bits. Example 1: clump size: 24 bits, Number of clumps (or ports): 10 bitmap stores the bit information from where successive clumps are retrieved. /* bitmap memory region */ 0x00aa0000ff000000; /* Most significant bits */ 0xaaaaaa0000ff0000; 0x000000aa000000aa; 0xbbbbabcdeffedcba; /* Least significant bits */ Different iterations of for_each_set_clump:- 'offset' is the bit position and 'clump' is the 24 bit clump from the above bitmap. Iteration first: offset: 0 clump: 0xfedcba Iteration second: offset: 24 clump: 0xabcdef Iteration third: offset: 48 clump: 0xaabbbb Iteration fourth: offset: 96 clump: 0xaa Iteration fifth: offset: 144 clump: 0xff Iteration sixth: offset: 168 clump: 0xaaaaaa Iteration seventh: offset: 216 clump: 0xff Loop breaks because in the end the remaining bits (0x00aa) size was less than clump size of 24 bits. In above example it can be seen that in iteration third, the 24 bit clump that was retrieved was split between bitmap[0] and bitmap[1]. This example also shows that 24 bit zeroes if present in between, were skipped (preserving the previous for_each_set_macro8 behaviour). Example 2: clump size = 6 bits, Number of clumps (or ports) = 3. /* bitmap memory region */ 0x00aa0000ff000000; /* Most significant bits */ 0xaaaaaa0000ff0000; 0x0f00000000000000; 0x0000000000000ac0; /* Least significant bits */ Different iterations of for_each_set_clump: 'offset' is the bit position and 'clump' is the 6 bit clump from the above bitmap. Iteration first: offset: 6 clump: 0x2b Loop breaks because 6 * 3 = 18 bits traversed in bitmap. Here 6 * 3 is clump size * no. of clumps. This patch (of 4): This macro iterates for each group of bits (clump) with set bits, within a bitmap memory region. For each iteration, "start" is set to the bit offset of the found clump, while the respective clump value is stored to the location pointed by "clump". Additionally, the bitmap_get_value() and bitmap_set_value() functions are introduced to respectively get and set a value of n-bits in a bitmap memory region. The n-bits can have any size from 1 to BITS_PER_LONG. size less than 1 or more than BITS_PER_LONG causes undefined behaviour. Moreover, during setting value of n-bit in bitmap, if a situation arise that the width of next n-bit is exceeding the word boundary, then it will divide itself such that some portion of it is stored in that word, while the remaining portion is stored in the next higher word. Similar situation occurs while retrieving the value from bitmap. Link: https://lkml.kernel.org/r/cover.1603055402.git.syednwaris@gmail.com Link: https://lkml.kernel.org/r/199b749c404450d1acb667e629ec4da37f44b60c.1603055402.git.syednwaris@gmail.com Signed-off-by: -
Gao Xiang authored
LZ4 final literal copy could be overlapped when doing in-place decompression, so it's unsafe to just use memcpy() on an optimized memcpy approach but memmove() instead. Upstream LZ4 has updated this years ago [1] (and the impact is non-sensible [2] plus only a few bytes remain), this commit just synchronizes LZ4 upstream code to the kernel side as well. It can be observed as EROFS in-place decompression failure on specific files when X86_FEATURE_ERMS is unsupported, memcpy() optimization of commit 59daa706 ("x86, mem: Optimize memcpy by avoiding memory false dependece") will be enabled then. Currently most modern x86-CPUs support ERMS, these CPUs just use "rep movsb" approach so no problem at all. However, it can still be verified with forcely disabling ERMS feature... arch/x86/lib/memcpy_64.S: ALTERNATIVE_2 "jmp memcpy_orig", "", X86_FEATURE_REP_GOOD, \ - "jmp memcpy_erms", X86_FEATURE_ERMS + "jmp memcpy_orig", X86_FEATURE_ERMS We didn't observe any strange on arm64/arm/x86 platform before since most memcpy() would behave in an increasing address order ("copy upwards" [3]) and it's the correct order of in-place decompression but it really needs an update to memmove() for sure considering it's an undefined behavior according to the standard and some unique optimization already exists in the kernel. [1] https://github.com/lz4/lz4/commit/33cb8518ac385835cc17be9a770b27b40cd0e15b [2] https://github.com/lz4/lz4/pull/717#issuecomment-497818921 [3] https://sourceware.org/bugzilla/show_bug.cgi?id=12518 Link: https://lkml.kernel.org/r/20201122030749.2698994-1-hsiangkao@redhat.com Signed-off-by:
Gao Xiang <hsiangkao@redhat.com> Cc: Yann Collet <yann.collet.73@gmail.com> Cc: Nick Terrell <terrelln@fb.com> Cc: Miao Xie <miaoxie@huawei.com> Cc: Chao Yu <yuchao0@huawei.com> Cc: Li Guifu <bluce.liguifu@huawei.com> Cc: Guo Xuenan <guoxuenan@huawei.com> Signed-off-by:
-
Alexey Dobriyan authored
Use proper conversion functions. kstrto*() variants exist for all standard types. Link: https://lkml.kernel.org/r/20201122123410.GB92364@localhost.localdomain Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by:
-
Francis Laniel authored
In lkdtm.h, files targeted in comments are named "lkdtm_file.c" while there are named "file.c" in directory. Link: https://lkml.kernel.org/r/20201122162451.27551-6-laniel_francis@privacyrequired.com Signed-off-by:
Francis Laniel <laniel_francis@privacyrequired.com> Acked-by:
Kees Cook <keescook@chromium.org> Cc: Daniel Axtens <dja@axtens.net> Cc: Daniel Micay <danielmicay@gmail.com> Signed-off-by:
-
Francis Laniel authored
This new test ensures that fortified strscpy has the same behavior than vanilla strscpy (e.g. returning -E2BIG when src content is truncated). Finally, it generates a crash at runtime because there is a write overflow in destination string. Link: https://lkml.kernel.org/r/20201122162451.27551-5-laniel_francis@privacyrequired.com Signed-off-by:
-
Francis Laniel authored
The fortified version of strscpy ensures the following before vanilla strscpy is called: 1. There is no read overflow because we either size is smaller than src length or we shrink size to src length by calling fortified strnlen. 2. There is no write overflow because we either failed during compilation or at runtime by checking that size is smaller than dest size. Link: https://lkml.kernel.org/r/20201122162451.27551-4-laniel_francis@privacyrequired.com Signed-off-by:
-
Daniel Axtens authored
Add code to test both: - runtime detection of the overrun of a structure. This covers the __builtin_object_size(x, 0) case. This test is called FORTIFY_OBJECT. - runtime detection of the overrun of a char array within a structure. This covers the __builtin_object_size(x, 1) case which can be used for some string functions. This test is called FORTIFY_SUBOBJECT. Link: https://lkml.kernel.org/r/20201122162451.27551-3-laniel_francis@privacyrequired.com Signed-off-by:
Daniel Axtens <dja@axtens.net> Signed-off-by:
-
Daniel Axtens authored
Patch series "Fortify strscpy()", v7. This patch implements a fortified version of strscpy() enabled by setting CONFIG_FORTIFY_SOURCE=y. The new version ensures the following before calling vanilla strscpy(): 1. There is no read overflow because either size is smaller than src length or we shrink size to src length by calling fortified strnlen(). 2. There is no write overflow because we either failed during compilation or at runtime by checking that size is smaller than dest size. Note that, if src and dst size cannot be got, the patch defaults to call vanilla strscpy(). The patches adds the following: 1. Implement the fortified version of strscpy(). 2. Add a new LKDTM test to ensures the fortified version still returns the same value as the vanilla one while panic'ing when there is a write overflow. 3. Correct some typos in LKDTM related file. I based my modifications on top of two patches from Daniel Axtens which modify calls to __builtin_object_size, in fortified string functions, to ensure the true size of char * are returned and not the surrounding structure size. About performance, I measured the slow down of fortified strscpy(), using the vanilla one as baseline. The hardware I used is an Intel i3 2130 CPU clocked at 3.4 GHz. I ran "Linux 5.10.0-rc4+ SMP PREEMPT" inside qemu 3.10 with 4 CPU cores. The following code, called through LKDTM, was used as a benchmark: #define TIMES 10000 char *src; char dst[7]; int i; ktime_t begin; src = kstrdup("foobar", GFP_KERNEL); if (src == NULL) return; begin = ktime_get(); for (i = 0; i < TIMES; i++) strscpy(dst, src, strlen(src)); pr_info("%d fortified strscpy() tooks %lld", TIMES, ktime_get() - begin); begin = ktime_get(); for (i = 0; i < TIMES; i++) __real_strscpy(dst, src, strlen(src)); pr_info("%d vanilla strscpy() tooks %lld", TIMES, ktime_get() - begin); kfree(src); I called the above code 30 times to compute stats for each version (in ns, round to int): | version | mean | std | median | 95th | | --------- | ------- | ------ | ------- | ------- | | fortified | 245_069 | 54_657 | 216_230 | 331_122 | | vanilla | 172_501 | 70_281 | 143_539 | 219_553 | On average, fortified strscpy() is approximately 1.42 times slower than vanilla strscpy(). For the 95th percentile, the fortified version is about 1.50 times slower. So, clearly the stats are not in favor of fortified strscpy(). But, the fortified version loops the string twice (one in strnlen() and another in vanilla strscpy()) while the vanilla one only loops once. This can explain why fortified strscpy() is slower than the vanilla one. This patch (of 5): When the fortify feature was first introduced in commit 6974f0c4 ("include/linux/string.h: add the option of fortified string.h functions"), Daniel Micay observed: * It should be possible to optionally use __builtin_object_size(x, 1) for some functions (C strings) to detect intra-object overflows (like glibc's _FORTIFY_SOURCE=2), but for now this takes the conservative approach to avoid likely compatibility issues. This is a case that often cannot be caught by KASAN. Consider: struct foo { char a[10]; char b[10]; } void test() { char *msg; struct foo foo; msg = kmalloc(16, GFP_KERNEL); strcpy(msg, "Hello world!!"); // this copy overwrites foo.b strcpy(foo.a, msg); } The questionable copy overflows foo.a and writes to foo.b as well. It cannot be detected by KASAN. Currently it is also not detected by fortify, because strcpy considers __builtin_object_size(x, 0), which considers the size of the surrounding object (here, struct foo). However, if we switch the string functions over to use __builtin_object_size(x, 1), the compiler will measure the size of the closest surrounding subobject (here, foo.a), rather than the size of the surrounding object as a whole. See https://gcc.gnu.org/onlinedocs/gcc/Object-Size-Checking.html for more info. Only do this for string functions: we cannot use it on things like memcpy, memmove, memcmp and memchr_inv due to code like this which purposefully operates on multiple structure members: (arch/x86/kernel/traps.c) /* * regs->sp points to the failing IRET frame on the * ESPFIX64 stack. Copy it to the entry stack. This fills * in gpregs->ss through gpregs->ip. * */ memmove(&gpregs->ip, (void *)regs->sp, 5*8); This change passes an allyesconfig on powerpc and x86, and an x86 kernel built with it survives running with syz-stress from syzkaller, so it seems safe so far. Link: https://lkml.kernel.org/r/20201122162451.27551-1-laniel_francis@privacyrequired.com Link: https://lkml.kernel.org/r/20201122162451.27551-2-laniel_francis@privacyrequired.com Signed-off-by:
-
