Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 03 3月, 2020 3 次提交
    • M
      kbuild: use KBUILD_DEFCONFIG as the fallback for DEFCONFIG_LIST · 2a86f661
      由 Masahiro Yamada 提交于 
      Most of the Kconfig commands (except defconfig and all*config) read
the .config file as a base set of CONFIG options.

When it does not exist, the files in DEFCONFIG_LIST are searched in
this order and loaded if found.

I do not see much sense in the last two lines in DEFCONFIG_LIST.

[1] ARCH_DEFCONFIG

The entry for DEFCONFIG_LIST is guarded by 'depends on !UML'. So, the
ARCH_DEFCONFIG definition in arch/x86/um/Kconfig is meaningless.

arch/{sh,sparc,x86}/Kconfig define ARCH_DEFCONFIG depending on 32 or
64 bit variant symbols. This is a little bit strange; ARCH_DEFCONFIG
should be a fixed string because the base config file is loaded before
the symbol evaluation stage.

Using KBUILD_DEFCONFIG makes more sense because it is fixed before
Kconfig is invoked. Fortunately, arch/{sh,sparc,x86}/Makefile define it
in the same way, and it works as expected. Hence, replace ARCH_DEFCONFIG
with "arch/$(SRCARCH)/configs/$(KBUILD_DEFCONFIG)".

[2] arch/$(ARCH)/defconfig

This file path is no longer valid. The defconfig files are always located
in the arch configs/ directories.

  $ find arch -name defconfig | sort
  arch/alpha/configs/defconfig
  arch/arm64/configs/defconfig
  arch/csky/configs/defconfig
  arch/nds32/configs/defconfig
  arch/riscv/configs/defconfig
  arch/s390/configs/defconfig
  arch/unicore32/configs/defconfig

The path arch/*/configs/defconfig is already covered by
"arch/$(SRCARCH)/configs/$(KBUILD_DEFCONFIG)". So, this file path is
not necessary.

I moved the default KBUILD_DEFCONFIG to the top Makefile. Otherwise,
the 7 architectures listed above would end up with endless loop of
syncconfig.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      2a86f661
    • N
      Documentation/llvm: add documentation on building w/ Clang/LLVM · fcf1b6a3
      由 Nick Desaulniers 提交于 
      Added to kbuild documentation. Provides more official info on building
kernels with Clang and LLVM than our wiki.
Suggested-by: NKees Cook <keescook@chromium.org>
Reviewed-by: NKees Cook <keescook@chromium.org>
Reviewed-by: NNathan Chancellor <natechancellor@gmail.com>
Reviewed-by: NSedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: NNick Desaulniers <ndesaulniers@google.com>
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      fcf1b6a3
    • M
      kbuild: remove trailing slash from devicetree/binding/ for descending · a1af8d71
      由 Masahiro Yamada 提交于 
      obj-* needs a trailing slash for a directory, but subdir-* does not
because it already implies a directory.

Also, change subdir-y to subdir- to ensure this is effective only
for cleaning targets.

This makes the cleaning log consistent. (no trailing slash)

Before:

  $ make clean
  CLEAN   Documentation/devicetree/bindings/

After:

  $ make clean
  CLEAN   Documentation/devicetree/bindings
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      a1af8d71
  3. 02 3月, 2020 8 次提交
    • M
      fixdep: remove redundant null character check · 3f9070a6
      由 Masahiro Yamada 提交于 
      If *q is '\0', the condition (isalnum(*q) || *q == '_') is false anyway.

It is redundant to ensure non-zero *q.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      3f9070a6
    • M
      fixdep: remove unneeded code and comments about *.ver files · 87d660f0
      由 Masahiro Yamada 提交于 
      This is probably stale code. In old days (~ Linux 2.5.59), Kbuild made
genksyms generate include/linux/modules/*.ver files.

The currenct Kbuild does not generate *.ver files at all.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      87d660f0
    • M
      kbuild: remove cc-option switch from -Wframe-larger-than= · a83e4ca2
      由 Masahiro Yamada 提交于 
      This CONFIG option was added by commit 35bb5b1e ("Add option to
enable -Wframe-larger-than= on gcc 4.4"). At that time, the cc-option
check was needed.

According to Documentation/process/changes.rst, the current minimal
supported version of GCC is 4.6, so you can assume GCC supports it.
Clang supports it as well.

Remove the cc-option switch and redundant comments.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Reviewed-by: NNathan Chancellor <natechancellor@gmail.com>
Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>
      a83e4ca2
    • M
      kbuild: remove the owner check in mkcompile_h · f84fdf8d
      由 Masahiro Yamada 提交于 
      This reverts a very old commit, which dates back to the pre-git era:

|commit 5d1cfb5b12f72145d30ba0f53c9f238144b122b8
|Author: Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de>
|Date:   Sat Jul 27 02:53:19 2002 -0500
|
|    kbuild: Fix compiling/installing as different users
|
|    "make bzImage && sudo make install" had the problem that during
|    the "sudo make install" the build system would notice that the information
|    in include/linux/compile.h is not accurate (it says "compiled by <user>",
|    but we are root), thus causing compile.h to be updated and leading to
|    some recompiles.
|
|    We now only update "compile.h" if the current user is the owner of
|    include/linux/autoconf.h, i.e. the user who did the "make *config". So the
|    above sequence will correctly state "compiled by <user>".
|
|diff --git a/scripts/mkcompile_h b/scripts/mkcompile_h
|index 6313db96172..cd956380978 100755
|--- a/scripts/mkcompile_h
|+++ b/scripts/mkcompile_h
|@@ -3,6 +3,17 @@ ARCH=$2
| SMP=$3
| CC=$4
|
|+# If compile.h exists already and we don't own autoconf.h
|+# (i.e. we're not the same user who did make *config), don't
|+# modify compile.h
|+# So "sudo make install" won't change the "compiled by <user>"
|+# do "compiled by root"
|+
|+if [ -r $TARGET -a ! -O ../include/linux/autoconf.h ]; then
|+  echo ' (not modified)'
|+  exit 0
|+fi
|+
| if [ -r ../.version ]; then
|   VERSION=`cat ../.version`
| else

The 'make bzImage && sudo make install' problem no longer happens
because commit 1648e4f8 ("x86, kbuild: make "make install" not
depend on vmlinux") fixed the root cause.

Commit 19514fc6 ("arm, kbuild: make "make install" not depend on
vmlinux") fixed the similar issue on ARM, with detailed explanation.

So, the rule is that the installation targets should never trigger
the builds of any build artifact. By following it, this check is
unneeded.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      f84fdf8d
    • L
      Linux 5.6-rc4 · 98d54f81
      由 Linus Torvalds 提交于
      98d54f81
    • L
      Merge tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 · e7086982
      由 Linus Torvalds 提交于 
      Pull ext4 fixes from Ted Ts'o:
 "Two more bug fixes (including a regression) for 5.6"

* tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4:
  ext4: potential crash on allocation error in ext4_alloc_flex_bg_array()
  jbd2: fix data races at struct journal_head
      e7086982
    • L
      Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm · f853ed90
      由 Linus Torvalds 提交于 
      Pull KVM fixes from Paolo Bonzini:
 "More bugfixes, including a few remaining "make W=1" issues such as too
  large frame sizes on some configurations.

  On the ARM side, the compiler was messing up shadow stacks between EL1
  and EL2 code, which is easily fixed with __always_inline"

* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
  KVM: VMX: check descriptor table exits on instruction emulation
  kvm: x86: Limit the number of "kvm: disabled by bios" messages
  KVM: x86: avoid useless copy of cpufreq policy
  KVM: allow disabling -Werror
  KVM: x86: allow compiling as non-module with W=1
  KVM: Pre-allocate 1 cpumask variable per cpu for both pv tlb and pv ipis
  KVM: Introduce pv check helpers
  KVM: let declaration of kvm_get_running_vcpus match implementation
  KVM: SVM: allocate AVIC data structures based on kvm_amd module parameter
  arm64: Ask the compiler to __always_inline functions used by KVM at HYP
  KVM: arm64: Define our own swab32() to avoid a uapi static inline
  KVM: arm64: Ask the compiler to __always_inline functions used at HYP
  kvm: arm/arm64: Fold VHE entry/exit work into kvm_vcpu_run_vhe()
  KVM: arm/arm64: Fix up includes for trace.h
      f853ed90
    • O
      KVM: VMX: check descriptor table exits on instruction emulation · 86f7e90c
      由 Oliver Upton 提交于 
      KVM emulates UMIP on hardware that doesn't support it by setting the
'descriptor table exiting' VM-execution control and performing
instruction emulation. When running nested, this emulation is broken as
KVM refuses to emulate L2 instructions by default.

Correct this regression by allowing the emulation of descriptor table
instructions if L1 hasn't requested 'descriptor table exiting'.

Fixes: 07721fee ("KVM: nVMX: Don't emulate instructions in guest mode")
Reported-by: NJan Kiszka <jan.kiszka@web.de>
Cc: stable@vger.kernel.org
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Jim Mattson <jmattson@google.com>
Signed-off-by: NOliver Upton <oupton@google.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      86f7e90c
  5. 01 3月, 2020 4 次提交
    • L
      Merge branch 'i2c/for-current-fixed' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux · fb279f4e
      由 Linus Torvalds 提交于 
      Pull i2c fixes from Wolfram Sang:
 "I2C has three driver bugfixes for you. We agreed on the Mac regression
  to go in via I2C"

* 'i2c/for-current-fixed' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
  macintosh: therm_windtunnel: fix regression when instantiating devices
  i2c: altera: Fix potential integer overflow
  i2c: jz4780: silence log flood on txabrt
      fb279f4e
    • D
      ext4: potential crash on allocation error in ext4_alloc_flex_bg_array() · 37b0b6b8
      由 Dan Carpenter 提交于 
      If sbi->s_flex_groups_allocated is zero and the first allocation fails
then this code will crash.  The problem is that "i--" will set "i" to
-1 but when we compare "i >= sbi->s_flex_groups_allocated" then the -1
is type promoted to unsigned and becomes UINT_MAX.  Since UINT_MAX
is more than zero, the condition is true so we call kvfree(new_groups[-1]).
The loop will carry on freeing invalid memory until it crashes.

Fixes: 7c990728 ("ext4: fix potential race between s_flex_groups online resizing and access")
Reviewed-by: NSuraj Jitindar Singh <surajjs@amazon.com>
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Cc: stable@kernel.org
Link: https://lore.kernel.org/r/20200228092142.7irbc44yaz3by7nb@kili.mountainSigned-off-by: NTheodore Ts'o <tytso@mit.edu>
      37b0b6b8
    • W
      macintosh: therm_windtunnel: fix regression when instantiating devices · 38b17afb
      由 Wolfram Sang 提交于 
      Removing attach_adapter from this driver caused a regression for at
least some machines. Those machines had the sensors described in their
DT, too, so they didn't need manual creation of the sensor devices. The
old code worked, though, because manual creation came first. Creation of
DT devices then failed later and caused error logs, but the sensors
worked nonetheless because of the manually created devices.

When removing attach_adaper, manual creation now comes later and loses
the race. The sensor devices were already registered via DT, yet with
another binding, so the driver could not be bound to it.

This fix refactors the code to remove the race and only manually creates
devices if there are no DT nodes present. Also, the DT binding is updated
to match both, the DT and manually created devices. Because we don't
know which device creation will be used at runtime, the code to start
the kthread is moved to do_probe() which will be called by both methods.

Fixes: 3e7bed52 ("macintosh: therm_windtunnel: drop using attach_adapter")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=201723Reported-by: NErhard Furtner <erhard_f@mailbox.org>
Tested-by: NErhard Furtner <erhard_f@mailbox.org>
Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org # v4.19+
      38b17afb
    • Q
      jbd2: fix data races at struct journal_head · 6c5d9112
      由 Qian Cai 提交于 
      journal_head::b_transaction and journal_head::b_next_transaction could
be accessed concurrently as noticed by KCSAN,

 LTP: starting fsync04
 /dev/zero: Can't open blockdev
 EXT4-fs (loop0): mounting ext3 file system using the ext4 subsystem
 EXT4-fs (loop0): mounted filesystem with ordered data mode. Opts: (null)
 ==================================================================
 BUG: KCSAN: data-race in __jbd2_journal_refile_buffer [jbd2] / jbd2_write_access_granted [jbd2]

 write to 0xffff99f9b1bd0e30 of 8 bytes by task 25721 on cpu 70:
  __jbd2_journal_refile_buffer+0xdd/0x210 [jbd2]
  __jbd2_journal_refile_buffer at fs/jbd2/transaction.c:2569
  jbd2_journal_commit_transaction+0x2d15/0x3f20 [jbd2]
  (inlined by) jbd2_journal_commit_transaction at fs/jbd2/commit.c:1034
  kjournald2+0x13b/0x450 [jbd2]
  kthread+0x1cd/0x1f0
  ret_from_fork+0x27/0x50

 read to 0xffff99f9b1bd0e30 of 8 bytes by task 25724 on cpu 68:
  jbd2_write_access_granted+0x1b2/0x250 [jbd2]
  jbd2_write_access_granted at fs/jbd2/transaction.c:1155
  jbd2_journal_get_write_access+0x2c/0x60 [jbd2]
  __ext4_journal_get_write_access+0x50/0x90 [ext4]
  ext4_mb_mark_diskspace_used+0x158/0x620 [ext4]
  ext4_mb_new_blocks+0x54f/0xca0 [ext4]
  ext4_ind_map_blocks+0xc79/0x1b40 [ext4]
  ext4_map_blocks+0x3b4/0x950 [ext4]
  _ext4_get_block+0xfc/0x270 [ext4]
  ext4_get_block+0x3b/0x50 [ext4]
  __block_write_begin_int+0x22e/0xae0
  __block_write_begin+0x39/0x50
  ext4_write_begin+0x388/0xb50 [ext4]
  generic_perform_write+0x15d/0x290
  ext4_buffered_write_iter+0x11f/0x210 [ext4]
  ext4_file_write_iter+0xce/0x9e0 [ext4]
  new_sync_write+0x29c/0x3b0
  __vfs_write+0x92/0xa0
  vfs_write+0x103/0x260
  ksys_write+0x9d/0x130
  __x64_sys_write+0x4c/0x60
  do_syscall_64+0x91/0xb05
  entry_SYSCALL_64_after_hwframe+0x49/0xbe

 5 locks held by fsync04/25724:
  #0: ffff99f9911093f8 (sb_writers#13){.+.+}, at: vfs_write+0x21c/0x260
  #1: ffff99f9db4c0348 (&sb->s_type->i_mutex_key#15){+.+.}, at: ext4_buffered_write_iter+0x65/0x210 [ext4]
  #2: ffff99f5e7dfcf58 (jbd2_handle){++++}, at: start_this_handle+0x1c1/0x9d0 [jbd2]
  #3: ffff99f9db4c0168 (&ei->i_data_sem){++++}, at: ext4_map_blocks+0x176/0x950 [ext4]
  #4: ffffffff99086b40 (rcu_read_lock){....}, at: jbd2_write_access_granted+0x4e/0x250 [jbd2]
 irq event stamp: 1407125
 hardirqs last  enabled at (1407125): [<ffffffff980da9b7>] __find_get_block+0x107/0x790
 hardirqs last disabled at (1407124): [<ffffffff980da8f9>] __find_get_block+0x49/0x790
 softirqs last  enabled at (1405528): [<ffffffff98a0034c>] __do_softirq+0x34c/0x57c
 softirqs last disabled at (1405521): [<ffffffff97cc67a2>] irq_exit+0xa2/0xc0

 Reported by Kernel Concurrency Sanitizer on:
 CPU: 68 PID: 25724 Comm: fsync04 Tainted: G L 5.6.0-rc2-next-20200221+ #7
 Hardware name: HPE ProLiant DL385 Gen10/ProLiant DL385 Gen10, BIOS A40 07/10/2019

The plain reads are outside of jh->b_state_lock critical section which result
in data races. Fix them by adding pairs of READ|WRITE_ONCE().
Reviewed-by: NJan Kara <jack@suse.cz>
Signed-off-by: NQian Cai <cai@lca.pw>
Link: https://lore.kernel.org/r/20200222043111.2227-1-cai@lca.pwSigned-off-by: NTheodore Ts'o <tytso@mit.edu>
      6c5d9112
  7. 29 2月, 2020 8 次提交
  9. 28 2月, 2020 17 次提交