1. 18 Mar, 2020 1 commit
  2. 17 Mar, 2020 1 commit
    • 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) are not available.
      Signed-off-by: default avatarEugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      785d74ec
  3. 16 Mar, 2020 1 commit
    • 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
  4. 14 Mar, 2020 1 commit
  5. 13 Mar, 2020 1 commit
  6. 11 Mar, 2020 3 commits
    • 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
  7. 01 Mar, 2020 5 commits
  8. 29 Feb, 2020 4 commits
    • 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.mountainSigned-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=201723Reported-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.pwSigned-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      6c5d9112
    • Linus Torvalds's avatar
      Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi · 7557c1b3
      Linus Torvalds authored
      Pull SCSI fixes from James Bottomley:
       "Four small fixes.
      
        Three are in drivers for fairly obvious bugs. The fourth is a set of
        regressions introduced by the compat_ioctl changes because some of the
        compat updates wrongly replaced .ioctl instead of .compat_ioctl"
      
      * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
        scsi: compat_ioctl: cdrom: Replace .ioctl with .compat_ioctl in four appropriate places
        scsi: zfcp: fix wrong data and display format of SFP+ temperature
        scsi: sd_sbc: Fix sd_zbc_report_zones()
        scsi: libfc: free response frame from GPN_ID
      7557c1b3
  9. 28 Feb, 2020 21 commits
  10. 27 Feb, 2020 2 commits