Skip to content
Snippets Groups Projects
  1. Dec 24, 2021
  2. Dec 12, 2021
  3. Nov 10, 2021
  4. Nov 09, 2021
  5. Nov 06, 2021
    • Kees Cook's avatar
      Compiler Attributes: add __alloc_size() for better bounds checking · 86cffecd
      Kees Cook authored
      GCC and Clang can use the "alloc_size" attribute to better inform the
      results of __builtin_object_size() (for compile-time constant values).
      Clang can additionally use alloc_size to inform the results of
      __builtin_dynamic_object_size() (for run-time values).
      
      Because GCC sees the frequent use of struct_size() as an allocator size
      argument, and notices it can return SIZE_MAX (the overflow indication),
      it complains about these call sites overflowing (since SIZE_MAX is
      greater than the default -Walloc-size-larger-than=PTRDIFF_MAX).  This
      isn't helpful since we already know a SIZE_MAX will be caught at
      run-time (this was an intentional design).  To deal with this, we must
      disable this check as it is both a false positive and redundant.  (Clang
      does not have this warning option.)
      
      Unfortunately, just checking the -Wno-alloc-size-larger-than is not
      sufficient to make the __alloc_size attribute behave correctly under
      older GCC versions.  The attribute itself must be disabled in those
      situations too, as there appears to be no way to reliably silence the
      SIZE_MAX constant expression cases for GCC versions less than 9.1:
      
         In file included from ./include/linux/resource_ext.h:11,
                          from ./include/linux/pci.h:40,
                          from drivers/net/ethernet/intel/ixgbe/ixgbe.h:9,
                          from drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c:4:
         In function 'kmalloc_node',
             inlined from 'ixgbe_alloc_q_vector' at ./include/linux/slab.h:743:9:
         ./include/linux/slab.h:618:9: error: argument 1 value '18446744073709551615' exceeds maximum object size 9223372036854775807 [-Werror=alloc-size-larger-than=]
           return __kmalloc_node(size, flags, node);
                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         ./include/linux/slab.h: In function 'ixgbe_alloc_q_vector':
         ./include/linux/slab.h:455:7: note: in a call to allocation function '__kmalloc_node' declared here
          void *__kmalloc_node(size_t size, gfp_t flags, int node) __assume_slab_alignment __malloc;
                ^~~~~~~~~~~~~~
      
      Specifically:
       '-Wno-alloc-size-larger-than' is not correctly handled by GCC < 9.1
          https://godbolt.org/z/hqsfG7q84 (doesn't disable)
          https://godbolt.org/z/P9jdrPTYh (doesn't admit to not knowing about option)
          https://godbolt.org/z/465TPMWKb (only warns when other warnings appear)
      
       '-Walloc-size-larger-than=18446744073709551615' is not handled by GCC < 8.2
          https://godbolt.org/z/73hh1EPxz (ignores numeric value)
      
      Since anything marked with __alloc_size would also qualify for marking
      with __malloc, just include __malloc along with it to avoid redundant
      markings.  (Suggested by Linus Torvalds.)
      
      Finally, make sure checkpatch.pl doesn't get confused about finding the
      __alloc_size attribute on functions.  (Thanks to Joe Perches.)
      
      Link: https://lkml.kernel.org/r/20210930222704.2631604-3-keescook@chromium.org
      
      
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Tested-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Cc: Andy Whitcroft <apw@canonical.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Daniel Micay <danielmicay@gmail.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Dennis Zhou <dennis@kernel.org>
      Cc: Dwaipayan Ray <dwaipayanray1@gmail.com>
      Cc: Joe Perches <joe@perches.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: Alexandre Bounine <alex.bou9@gmail.com>
      Cc: Gustavo A. R. Silva <gustavoars@kernel.org>
      Cc: Ira Weiny <ira.weiny@intel.com>
      Cc: Jing Xiangfeng <jingxiangfeng@huawei.com>
      Cc: John Hubbard <jhubbard@nvidia.com>
      Cc: kernel test robot <lkp@intel.com>
      Cc: Matt Porter <mporter@kernel.crashing.org>
      Cc: Miguel Ojeda <ojeda@kernel.org>
      Cc: Nathan Chancellor <nathan@kernel.org>
      Cc: Nick Desaulniers <ndesaulniers@google.com>
      Cc: Souptick Joarder <jrdr.linux@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      86cffecd
    • weidonghui's avatar
      scripts/decodecode: fix faulting instruction no print when opps.file is DOS format · 75e2f715
      weidonghui authored
      If opps.file is in DOS format, faulting instruction cannot be printed:
      
        / # ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-
        / # ./scripts/decodecode < oops.file
        [ 0.734345] Code: d0002881 912f9c21 94067e68 d2800001 (b900003f)
        aarch64-linux-gnu-strip: '/tmp/tmp.5Y9eybnnSi.o': No such file
        aarch64-linux-gnu-objdump: '/tmp/tmp.5Y9eybnnSi.o': No such file
        All code
        ========
           0:   d0002881        adrp    x1, 0x512000
           4:   912f9c21        add     x1, x1, #0xbe7
           8:   94067e68        bl      0x19f9a8
           c:   d2800001        mov     x1, #0x0                        // #0
          10:   b900003f        str     wzr, [x1]
      
        Code starting with the faulting instruction
        ===========================================
      
      Background: The compilation environment is Ubuntu, and the test
      environment is Windows.  Most logs are generated in the Windows
      environment.  In this way, CR (carriage return) will inevitably appear,
      which will affect the use of decodecode in the Ubuntu environment.
      
      The repaired effect is as follows:
      
        / # ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-
        / # ./scripts/decodecode < oops.file
        [ 0.734345] Code: d0002881 912f9c21 94067e68 d2800001 (b900003f)
        All code
        ========
           0:   d0002881        adrp    x1, 0x512000
           4:   912f9c21        add     x1, x1, #0xbe7
           8:   94067e68        bl      0x19f9a8
           c:   d2800001        mov     x1, #0x0                        // #0
          10:*  b900003f        str     wzr, [x1]               <-- trapping instruction
      
        Code starting with the faulting instruction
        ===========================================
           0:   b900003f        str     wzr, [x1]
      
      Link: https://lkml.kernel.org/r/20211008064712.926-1-weidonghui@allwinnertech.com
      
      
      Signed-off-by: default avatarweidonghui <weidonghui@allwinnertech.com>
      Acked-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: Marc Zyngier <maz@misterjones.org>
      Cc: Will Deacon <will@kernel.org>
      Cc: Rabin Vincent <rabin@rab.in>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      75e2f715
    • Sven Eckelmann's avatar
      scripts/spelling.txt: fix "mistake" version of "synchronization" · 655edc52
      Sven Eckelmann authored
      If both "mistake" version and "correction" version are the same, a
      warning message is created by checkpatch which is impossible to fix.
      But it was noticed that Colan Ian King created a commit e6c0a088
      ("ALSA: aloop: Fix spelling mistake "synchronization" ->
      "synchronization"") which suggests that this spelling mistake was fixed
      by replacing the word "synchronization" with itself.  But the actual
      diff shows that the mistake in the code was "sychronization".  It is
      rather likely that the "mistake" in spelling.txt should have been the
      latter.
      
      Link: https://lkml.kernel.org/r/20210926065529.6880-1-sven@narfation.org
      
      
      Fixes: 2e74c9433ba8 ("scripts/spelling.txt: add more spellings to spelling.txt")
      Signed-off-by: default avatarSven Eckelmann <sven@narfation.org>
      Reviewed-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      655edc52
    • Colin Ian King's avatar
      scripts/spelling.txt: add more spellings to spelling.txt · baef1147
      Colin Ian King authored
      Some of the more common spelling mistakes and typos that I've found
      while fixing up spelling mistakes in the kernel in the past few months.
      
      Link: https://lkml.kernel.org/r/20210907072941.7033-1-colin.king@canonical.com
      
      
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      baef1147
  6. Nov 02, 2021
  7. Nov 01, 2021
  8. Oct 29, 2021
    • Rob Herring's avatar
      scripts/dtc: Update to upstream version v1.6.1-19-g0a3a9d3449c8 · a77725a9
      Rob Herring authored
      
      This adds the following commits from upstream:
      
      0a3a9d3449c8 checks: Add an interrupt-map check
      8fd24744e361 checks: Ensure '#interrupt-cells' only exists in interrupt providers
      d8d1a9a77863 checks: Drop interrupt provider '#address-cells' check
      52a16fd72824 checks: Make interrupt_provider check dependent on interrupts_extended_is_cell
      37fd700685da treesource: Maintain phandle label/path on output
      e33ce1d6a8c7 flattree: Use '\n', not ';' to separate asm pseudo-ops
      d24cc189dca6 asm: Use assembler macros instead of cpp macros
      ff3a30c115ad asm: Use .asciz and .ascii instead of .string
      5eb5927d81ee fdtdump: fix -Werror=int-to-pointer-cast
      0869f8269161 libfdt: Add ALIGNMENT error string
      69595a167f06 checks: Fix bus-range check
      72d09e2682a4 Makefile: add -Wsign-compare to warning options
      b587787ef388 checks: Fix signedness comparisons warnings
      69bed6c2418f dtc: Wrap phandle validity check
      910221185560 fdtget: Fix signedness comparisons warnings
      d966f08fcd21 tests: Fix signedness comparisons warnings
      ecfb438c07fa dtc: Fix signedness comparisons warnings: pointer diff
      5bec74a6d135 dtc: Fix signedness comparisons warnings: reservednum
      24e7f511fd4a fdtdump: Fix signedness comparisons warnings
      b6910bec1161 Bump version to v1.6.1
      21d61d18f968 Fix CID 1461557
      4c2ef8f4d14c checks: Introduce is_multiple_of()
      e59ca36fb70e Make handling of cpp line information more tolerant
      0c3fd9b6aceb checks: Drop interrupt_cells_is_cell check
      6b3081abc4ac checks: Add check_is_cell() for all phandle+arg properties
      2dffc192a77f yamltree: Remove marker ordering dependency
      61e513439e40 pylibfdt: Rework "avoid unused variable warning" lines
      c8bddd106095 tests: add a positive gpio test case
      ad4abfadb687 checks: replace strstr and strrchr with strends
      09c6a6e88718 dtc.h: add strends for suffix matching
      9bb9b8d0b4a0 checks: tigthen up nr-gpios prop exception
      b07b62ee3342 libfdt: Add FDT alignment check to fdt_check_header()
      a2def5479950 libfdt: Check that the root-node name is empty
      4ca61f84dc21 libfdt: Check that there is only one root node
      34d708249a91 dtc: Remove -O dtbo support
      8e7ff260f755 libfdt: Fix a possible "unchecked return value" warning
      88875268c05c checks: Warn on node-name and property name being the same
      9d2279e7e6ee checks: Change node-name check to match devicetree spec
      f527c867a8c6 util: limit gnu_printf format attribute to gcc >= 4.4.0
      
      Reviewed-by: default avatarFrank Rowand <frank.rowand@sony.com>
      Tested-by: default avatarFrank Rowand <frank.rowand@sony.com>
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
      a77725a9
  9. Oct 26, 2021
  10. Oct 24, 2021
  11. Oct 21, 2021
  12. Oct 18, 2021
    • Kees Cook's avatar
      stddef: Introduce DECLARE_FLEX_ARRAY() helper · 3080ea55
      Kees Cook authored
      There are many places where kernel code wants to have several different
      typed trailing flexible arrays. This would normally be done with multiple
      flexible arrays in a union, but since GCC and Clang don't (on the surface)
      allow this, there have been many open-coded workarounds, usually involving
      neighboring 0-element arrays at the end of a structure. For example,
      instead of something like this:
      
      struct thing {
      	...
      	union {
      		struct type1 foo[];
      		struct type2 bar[];
      	};
      };
      
      code works around the compiler with:
      
      struct thing {
      	...
      	struct type1 foo[0];
      	struct type2 bar[];
      };
      
      Another case is when a flexible array is wanted as the single member
      within a struct (which itself is usually in a union). For example, this
      would be worked around as:
      
      union many {
      	...
      	struct {
      		struct type3 baz[0];
      	};
      };
      
      These kinds of work-arounds cause problems with size checks against such
      zero-element arrays (for example when building with -Warray-bounds and
      -Wzero-length-bounds, and with the coming FORTIFY_SOURCE improvements),
      so they must all be converted to "real" flexible arrays, avoiding warnings
      like this:
      
      fs/hpfs/anode.c: In function 'hpfs_add_sector_to_btree':
      fs/hpfs/anode.c:209:27: warning: array subscript 0 is outside the bounds of an interior zero-length array 'struct bplus_internal_node[0]' [-Wzero-length-bounds]
        209 |    anode->btree.u.internal[0].down = cpu_to_le32(a);
            |    ~~~~~~~~~~~~~~~~~~~~~~~^~~
      In file included from fs/hpfs/hpfs_fn.h:26,
                       from fs/hpfs/anode.c:10:
      fs/hpfs/hpfs.h:412:32: note: while referencing 'internal'
        412 |     struct bplus_internal_node internal[0]; /* (internal) 2-word entries giving
            |                                ^~~~~~~~
      
      drivers/net/can/usb/etas_es58x/es58x_fd.c: In function 'es58x_fd_tx_can_msg':
      drivers/net/can/usb/etas_es58x/es58x_fd.c:360:35: warning: array subscript 65535 is outside the bounds of an interior zero-length array 'u8[0]' {aka 'unsigned char[]'} [-Wzero-length-bounds]
        360 |  tx_can_msg = (typeof(tx_can_msg))&es58x_fd_urb_cmd->raw_msg[msg_len];
            |                                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      In file included from drivers/net/can/usb/etas_es58x/es58x_core.h:22,
                       from drivers/net/can/usb/etas_es58x/es58x_fd.c:17:
      drivers/net/can/usb/etas_es58x/es58x_fd.h:231:6: note: while referencing 'raw_msg'
        231 |   u8 raw_msg[0];
            |      ^~~~~~~
      
      However, it _is_ entirely possible to have one or more flexible arrays
      in a struct or union: it just has to be in another struct. And since it
      cannot be alone in a struct, such a struct must have at least 1 other
      named member -- but that member can be zero sized. Wrap all this nonsense
      into the new DECLARE_FLEX_ARRAY() in support of having flexible arrays
      in unions (or alone in a struct).
      
      As with struct_group(), since this is needed in UAPI headers as well,
      implement the core there, with a non-UAPI wrapper.
      
      Additionally update kernel-doc to understand its existence.
      
      https://github.com/KSPP/linux/issues/137
      
      
      
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      3080ea55
    • Kees Cook's avatar
      fortify: Add compile-time FORTIFY_SOURCE tests · be58f710
      Kees Cook authored
      
      While the run-time testing of FORTIFY_SOURCE is already present in
      LKDTM, there is no testing of the expected compile-time detections. In
      preparation for correctly supporting FORTIFY_SOURCE under Clang, adding
      additional FORTIFY_SOURCE defenses, and making sure FORTIFY_SOURCE
      doesn't silently regress with GCC, introduce a build-time test suite that
      checks each expected compile-time failure condition.
      
      As this is relatively backwards from standard build rules in the
      sense that a successful test is actually a compile _failure_, create
      a wrapper script to check for the correct errors, and wire it up as
      a dummy dependency to lib/string.o, collecting the results into a log
      file artifact.
      
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      be58f710
  13. Oct 16, 2021
    • Steven Rostedt's avatar
      nds32/ftrace: Fix Error: invalid operands (*UND* and *UND* sections) for `^' · be358af1
      Steven Rostedt authored
      I received a build failure for a new patch I'm working on the nds32
      architecture, and when I went to test it, I couldn't get to my build error,
      because it failed to build with a bunch of:
      
        Error: invalid operands (*UND* and *UND* sections) for `^'
      
      issues with various files. Those files were temporary asm files that looked
      like:  kernel/.tmp_mc_fork.s
      
      I decided to look deeper, and found that the "mc" portion of that name
      stood for "mcount", and was created by the recordmcount.pl script. One that
      I wrote over a decade ago. Once I knew the source of the problem, I was
      able to investigate it further.
      
      The way the recordmcount.pl script works (BTW, there's a C version that
      simply modifies the ELF object) is by doing an "objdump" on the object
      file. Looks for all the calls to "mcount", and creates an offset of those
      locations from some global variable it can use (usually a global function
      name, found with <.*>:). Creates a asm file that is a table of references
      to these locations, using the found variable/function. Compiles it and
      links it back into the original object file. This asm file is called
      ".tmp_mc_<object_base_name>.s".
      
      The problem here is that the objdump produced by the nds32 object file,
      contains things that look like:
      
       0000159a <.L3^B1>:
          159a:       c6 00           beqz38 $r6, 159a <.L3^B1>
                              159a: R_NDS32_9_PCREL_RELA      .text+0x159e
          159c:       84 d2           movi55 $r6, #-14
          159e:       80 06           mov55 $r0, $r6
          15a0:       ec 3c           addi10.sp #0x3c
      
      Where ".L3^B1 is somehow selected as the "global" variable to index off of.
      
      Then the assembly file that holds the mcount locations looks like this:
      
              .section __mcount_loc,"a",@progbits
              .align 2
              .long .L3^B1 + -5522
              .long .L3^B1 + -5384
              .long .L3^B1 + -5270
              .long .L3^B1 + -5098
              .long .L3^B1 + -4970
              .long .L3^B1 + -4758
              .long .L3^B1 + -4122
              [...]
      
      And when it is compiled back to an object to link to the original object,
      the compile fails on the "^" symbol.
      
      Simple solution for now, is to have the perl script ignore using function
      symbols that have an "^" in the name.
      
      Link: https://lkml.kernel.org/r/20211014143507.4ad2c0f7@gandalf.local.home
      
      
      
      Cc: stable@vger.kernel.org
      Acked-by: default avatarGreentime Hu <green.hu@gmail.com>
      Fixes: fbf58a52 ("nds32/ftrace: Add RECORD_MCOUNT support")
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      be358af1
  14. Oct 15, 2021
  15. Oct 12, 2021
  16. Oct 11, 2021
  17. Oct 08, 2021
  18. Oct 06, 2021
Loading