Skip to content

K
Kernel

openeuler / Kernel
大约 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 08 5月, 2022 3 次提交
  3. 06 4月, 2022 2 次提交
  5. 05 4月, 2022 1 次提交
  7. 03 4月, 2022 1 次提交
  9. 01 4月, 2022 2 次提交
  11. 31 3月, 2022 1 次提交
    • M
      fixdep: use fflush() and ferror() to ensure successful write to files · 69304379
      由 Masahiro Yamada 提交于 
      Currently, fixdep checks the return value from (v)printf(), but it does
not ensure the complete write to the .cmd file.

printf() just writes data to the internal buffer, which usually succeeds.
(Of course, it may fail for another reason, for example when the file
descriptor is closed, but that is another story.)

When the buffer (4k?) is full, an actual write occurs, and printf() may
really fail. One of typical cases is "No space left on device" when the
disk is full.

The data remaining in the buffer will be pushed out to the file when
the program exits, but we never know if it is successful.

One straight-forward fix would be to add the following code at the end
of the program.

   ret = fflush(stdout);
   if (ret < 0) {
          /* error handling */
   }

However, it is tedious to check the return code in all the call sites
of printf(), fflush(), fclose(), and whatever can cause actual writes
to the end device. Doing that lets the program bail out at the first
failure but is usually not worth the effort.

Instead, let's check the error status from ferror(). This is 'sticky',
so you need to check it just once. You still need to call fflush().
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Reviewed-by: NDavid Laight <david.laight@aculab.com>
Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>
      69304379
  13. 29 3月, 2022 3 次提交
  15. 24 3月, 2022 4 次提交
  17. 23 3月, 2022 2 次提交
  19. 21 3月, 2022 1 次提交
  21. 18 3月, 2022 1 次提交
  23. 15 3月, 2022 2 次提交
  25. 13 3月, 2022 2 次提交
  27. 12 3月, 2022 1 次提交
    • R
      dt-bindings: kbuild: Use DTB files for validation · ef8795f3
      由 Rob Herring 提交于 
      Switch the DT validation to use DTB files directly instead of a DTS to
YAML conversion.

The original motivation for supporting validation on DTB files was to
enable running validation on a running system (e.g. 'dt-validate
/sys/firmware/fdt') or other cases where the original source DTS is not
available.

The YAML format was not without issues. Using DTBs with the schema type
information solves some of those problems. The YAML format relies on the
DTS source level information including bracketing of properties, size
directives, and phandle tags all of which are lost in a DTB file. While
standardizing the bracketing is a good thing, it does cause a lot of
extra warnings and churn to fix them.

Another issue has been signed types are not validated correctly as sign
information is not propagated to YAML. Using the schema type information
allows for proper handling of signed types. YAML also can't represent
the full range of 64-bit integers as numbers are stored as floats by
most/all parsers.

The DTB validation works by decoding property values using the type
information in the schemas themselves. The main corner case this does
not work for is matrix types where neither dimension is fixed. For
now, checking the dimensions in these cases are skipped.
Signed-off-by: NRob Herring <robh@kernel.org>
Tested-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20220310160513.1708182-3-robh@kernel.org
      ef8795f3
  29. 11 3月, 2022 2 次提交
  31. 10 3月, 2022 1 次提交
    • V
      s390/nospec: add an option to use thunk-extern · 1d2ad084
      由 Vasily Gorbik 提交于 
      Currently with -mindirect-branch=thunk and -mfunction-return=thunk compiler
options expoline thunks are put into individual COMDAT group sections. s390
is the only architecture which has group sections and it has implications
for kpatch and objtool tools support.

Using -mindirect-branch=thunk-extern and -mfunction-return=thunk-extern
is an alternative, which comes with a need to generate all required
expoline thunks manually. Unfortunately modules area is too far away from
the kernel image, and expolines from the kernel image cannon be used.
But since all new distributions (except Debian) build kernels for machine
generations newer than z10, where "exrl" instruction is available, that
leaves only 16 expolines thunks possible.

Provide an option to build the kernel with
-mindirect-branch=thunk-extern and -mfunction-return=thunk-extern for
z10 or newer. This also requires to postlink expoline thunks into all
modules explicitly. Currently modules already contain most expolines
anyhow.

Unfortunately -mindirect-branch=thunk-extern and
-mfunction-return=thunk-extern options support is broken in gcc <= 11.2.
Additional compile test is required to verify proper gcc support.
Acked-by: NIlya Leoshkevich <iii@linux.ibm.com>
Co-developed-by: NSumanth Korikkar <sumanthk@linux.ibm.com>
Signed-off-by: NSumanth Korikkar <sumanthk@linux.ibm.com>
Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>
      1d2ad084
  33. 08 3月, 2022 1 次提交
  35. 07 3月, 2022 1 次提交
  37. 01 3月, 2022 1 次提交
    • F
      of: unittest: add program to process EXPECT messages · 8e4296c2
      由 Frank Rowand 提交于 
      If unittest detects a problem it will print a warning or error message
to the console.  Unittest also triggers warning and error messages from
other kernel code as a result of intentionally bad unittest data.  This
has led to confusion as to whether the triggered messages are an
expected result of a test or whether there is a real problem that is
independent of unittest.

EXPECT messages were added to unittest to report each triggered message
that is expected, resulting in verbose console output.

scripts/dtc/of_unittest is a new program that processes the EXPECT
messages to determine whether the triggered messages occurred and
also removes the excess verbosity of the EXPECT messages.  More
information is available from 'scripts/dtc/of_unittest_expect --help'.
Signed-off-by: NFrank Rowand <frank.rowand@sony.com>
Signed-off-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20220201181413.2719955-1-frowand.list@gmail.com
      8e4296c2
  39. 25 2月, 2022 8 次提交