Skip to content
  1. Mar 17, 2020
    • Eugeniy Paltsev's avatar
      initramfs: restore default compression behavior · 785d74ec
      Eugeniy Paltsev authored
      Even though INITRAMFS_SOURCE kconfig option isn't set in most of
      defconfigs it is used (set) extensively by various build systems.
      Commit f26661e1 ("initramfs: make initramfs compression choice
      non-optional") has changed default compression mode. Previously we
      compress initramfs using available compression algorithm. Now
      we don't use any compression at all by default.
      It significantly increases the image size in case of build system
      chooses embedded initramfs. Initially I faced with this issue while
      using buildroot.
      
      As of today it's not possible to set preferred compression mode
      in target defconfig as this option depends on INITRAMFS_SOURCE
      being set. Modification of all build systems either doesn't look
      like good option.
      
      Let's instead rewrite initramfs compression mode choices list
      the way that "INITRAMFS_COMPRESSION_NONE" will be the last option
      in the list. In that case it will be chosen only if all other
      options (which implements any compression) a...
      785d74ec
    • Jessica Yu's avatar
      modpost: move the namespace field in Module.symvers last · 5190044c
      Jessica Yu authored
      
      
      In order to preserve backwards compatability with kmod tools, we have to
      move the namespace field in Module.symvers last, as the depmod -e -E
      option looks at the first three fields in Module.symvers to check symbol
      versions (and it's expected they stay in the original order of crc,
      symbol, module).
      
      In addition, update an ancient comment above read_dump() in modpost that
      suggested that the export type field in Module.symvers was optional. I
      suspect that there were historical reasons behind that comment that are
      no longer accurate. We have been unconditionally printing the export
      type since 2.6.18 (commit bd5cbced), which is over a decade ago now.
      
      Fix up read_dump() to treat each field as non-optional. I suspect the
      original read_dump() code treated the export field as optional in order
      to support pre <= 2.6.18 Module.symvers (which did not have the export
      type field). Note that although symbol namespaces are optional, the
      field will not be omitted from Module.symvers if a symbol does not have
      a namespace. In this case, the field will simply be empty and the next
      delimiter or end of line will follow.
      
      Cc: stable@vger.kernel.org
      Fixes: cb9b55d2 ("modpost: add support for symbol namespaces")
      Tested-by: default avatarMatthias Maennich <maennich@google.com>
      Reviewed-by: default avatarMatthias Maennich <maennich@google.com>
      Reviewed-by: default avatarLucas De Marchi <lucas.demarchi@intel.com>
      Signed-off-by: default avatarJessica Yu <jeyu@kernel.org>
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      5190044c
  2. Mar 14, 2020
  3. Mar 13, 2020
  4. Mar 12, 2020
    • Masahiro Yamada's avatar
      int128: fix __uint128_t compiler test in Kconfig · 3a7c7331
      Masahiro Yamada authored
      
      
      The support for __uint128_t is dependent on the target bit size.
      
      GCC that defaults to the 32-bit can still build the 64-bit kernel
      with -m64 flag passed.
      
      However, $(cc-option,-D__SIZEOF_INT128__=0) is evaluated against the
      default machine bit, which may not match to the kernel it is building.
      
      Theoretically, this could be evaluated separately for 64BIT/32BIT.
      
        config CC_HAS_INT128
                bool
                default !$(cc-option,$(m64-flag) -D__SIZEOF_INT128__=0) if 64BIT
                default !$(cc-option,$(m32-flag) -D__SIZEOF_INT128__=0)
      
      I simplified it more because the 32-bit compiler is unlikely to support
      __uint128_t.
      
      Fixes: c12d3362 ("int128: move __uint128_t compiler test to Kconfig")
      Reported-by: default avatarGeorge Spelvin <lkml@sdf.org>
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      Tested-by: default avatarGeorge Spelvin <lkml@sdf.org>
      3a7c7331
    • Masahiro Yamada's avatar
      kconfig: introduce m32-flag and m64-flag · 8cc4fd73
      Masahiro Yamada authored
      When a compiler supports multiple architectures, some compiler features
      can be dependent on the target architecture.
      
      This is typical for Clang, which supports multiple LLVM backends.
      Even for GCC, we need to take care of biarch compiler cases.
      
      It is not a problem when we evaluate cc-option in Makefiles because
      cc-option is tested against the flag in question + $(KBUILD_CFLAGS).
      
      The cc-option in Kconfig, on the other hand, does not accumulate
      tested flags. Due to this simplification, it could potentially test
      cc-option against a different target.
      
      At first, Kconfig always evaluated cc-option against the host
      architecture.
      
      Since commit e8de12fb ("kbuild: Check for unknown options with
      cc-option usage in Kconfig and clang"), in case of cross-compiling
      with Clang, the target triple is correctly passed to Kconfig.
      
      The case with biarch GCC (and native build with Clang) is still not
      handled properly. We need to pass some flags to specify the target
      machine bit.
      
      Due to the design, all the macros in Kconfig are expanded in the
      parse stage, where we do not know the target bit size yet.
      
      For example, arch/x86/Kconfig allows a user to toggle CONFIG_64BIT.
      If a compiler flag -foo depends on the machine bit, it must be tested
      twice, one with -m32 and the other with -m64.
      
      However, -m32/-m64 are not always recognized. So, this commits adds
      m64-flag and m32-flag macros. They expand to -m32, -m64, respectively
      if supported. Or, they expand to an empty string if unsupported.
      
      The typical usage is like this:
      
        config FOO
                bool
                default $(cc-option,$(m64-flag) -foo) if 64BIT
                default $(cc-option,$(m32-flag) -foo)
      
      This is clumsy, but there is no elegant way to handle this in the
      current static macro expansion.
      
      There was discussion for static functions vs dynamic functions.
      The consensus was to go as far as possible with the static functions.
      (https://lkml.org/lkml/2018/3/2/22
      
      )
      
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      Tested-by: default avatarGeorge Spelvin <lkml@sdf.org>
      Reviewed-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      8cc4fd73
    • SZ Lin (林上智)'s avatar
      kbuild: Fix inconsistent comment · 46b7c492
      SZ Lin (林上智) authored
      
      
      The commit 2042b548 ("kbuild: unset variables in top Makefile
      instead of setting 0") renamed the variable from "config-targets"
      to "config-build", the comment should be consistent accordingly.
      
      Signed-off-by: default avatarKaiden PK Yu (余泊鎧) <KaidenPK.Yu@moxa.com>
      Signed-off-by: default avatarSZ Lin (林上智) <sz.lin@moxa.com>
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      46b7c492
  5. Mar 02, 2020
    • Linus Torvalds's avatar
      Linux 5.6-rc4 · 98d54f81
      Linus Torvalds authored
      v5.6-rc4
      98d54f81
    • Linus Torvalds's avatar
      Merge tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 · e7086982
      Linus Torvalds authored
      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
    • Linus Torvalds's avatar
      Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm · f853ed90
      Linus Torvalds authored
      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
    • Oliver Upton's avatar
      KVM: VMX: check descriptor table exits on instruction emulation · 86f7e90c
      Oliver Upton authored
      
      
      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: default avatarJan 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: default avatarOliver Upton <oupton@google.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      86f7e90c
  6. Mar 01, 2020
    • Linus Torvalds's avatar
      Merge branch 'i2c/for-current-fixed' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux · fb279f4e
      Linus Torvalds authored
      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
    • Dan Carpenter's avatar
      ext4: potential crash on allocation error in ext4_alloc_flex_bg_array() · 37b0b6b8
      Dan Carpenter authored
      
      
      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: default avatarSuraj Jitindar Singh <surajjs@amazon.com>
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Cc: stable@kernel.org
      Link: https://lore.kernel.org/r/20200228092142.7irbc44yaz3by7nb@kili.mountain
      
      
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      37b0b6b8
    • Wolfram Sang's avatar
      macintosh: therm_windtunnel: fix regression when instantiating devices · 38b17afb
      Wolfram Sang authored
      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=201723
      
      
      Reported-by: default avatarErhard Furtner <erhard_f@mailbox.org>
      Tested-by: default avatarErhard Furtner <erhard_f@mailbox.org>
      Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Cc: stable@kernel.org # v4.19+
      38b17afb
    • Qian Cai's avatar
      jbd2: fix data races at struct journal_head · 6c5d9112
      Qian Cai authored
      
      
      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: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarQian Cai <cai@lca.pw>
      Link: https://lore.kernel.org/r/20200222043111.2227-1-cai@lca.pw
      
      
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      6c5d9112
  7. Feb 29, 2020
  8. Feb 28, 2020