1. 25 Mar, 2020 29 commits
  2. 21 Mar, 2020 11 commits
    • Greg Kroah-Hartman's avatar
      Linux 5.4.27 · 585e0cc0
      Greg Kroah-Hartman authored
      585e0cc0
    • Matteo Croce's avatar
      ipv4: ensure rcu_read_lock() in cipso_v4_error() · 20ba40d2
      Matteo Croce authored
      commit 3e72dfdf upstream.
      
      Similarly to commit c543cb4a ("ipv4: ensure rcu_read_lock() in
      ipv4_link_failure()"), __ip_options_compile() must be called under rcu
      protection.
      
      Fixes: 3da1ed7a
      
       ("net: avoid use IPCB in cipso_v4_error")
      Suggested-by: default avatarGuillaume Nault <gnault@redhat.com>
      Signed-off-by: default avatarMatteo Croce <mcroce@redhat.com>
      Acked-by: default avatarPaul Moore <paul@paul-moore.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      20ba40d2
    • Ard Biesheuvel's avatar
      ARM: 8961/2: Fix Kbuild issue caused by per-task stack protector GCC plugin · 81e0dac3
      Ard Biesheuvel authored
      commit 89604523 upstream.
      
      When using plugins, GCC requires that the -fplugin= options precedes
      any of its plugin arguments appearing on the command line as well.
      This is usually not a concern, but as it turns out, this requirement
      is causing some issues with ARM's per-task stack protector plugin
      and Kbuild's implementation of $(cc-option).
      
      When the per-task stack protector plugin is enabled, and we tweak
      the implementation of cc-option not to pipe the stderr output of
      GCC to /dev/null, the following output is generated when GCC is
      executed in the context of cc-option:
      
        cc1: error: plugin arm_ssp_per_task_plugin should be specified before \
               -fplugin-arg-arm_ssp_per_task_plugin-tso=1 in the command line
        cc1: error: plugin arm_ssp_per_task_plugin should be specified before \
               -fplugin-arg-arm_ssp_per_task_plugin-offset=24 in the command line
      
      These errors will cause any option passed to cc-option to be treated
      as unsupported, which is obviously incorrect.
      
      The cause of this issue is the fact that the -fplugin= argument is
      added to GCC_PLUGINS_CFLAGS, whereas the arguments above are added
      to KBUILD_CFLAGS, and the contents of the former get filtered out of
      the latter before being passed to the GCC running the cc-option test,
      and so the -fplugin= option does not appear at all on the GCC command
      line.
      
      Adding the arguments to GCC_PLUGINS_CFLAGS instead of KBUILD_CFLAGS
      would be the correct approach here, if it weren't for the fact that we
      are using $(eval) to defer the moment that they are added until after
      asm-offsets.h is generated, which is after the point where the contents
      of GCC_PLUGINS_CFLAGS are added to KBUILD_CFLAGS. So instead, we have
      to add our plugin arguments to both.
      
      For similar reasons, we cannot append DISABLE_ARM_SSP_PER_TASK_PLUGIN
      to KBUILD_CFLAGS, as it will be passed to GCC when executing in the
      context of cc-option, whereas the other plugin arguments will have
      been filtered out, resulting in a similar error and false negative
      result as above. So add it to ccflags-y instead.
      
      Fixes: 189af465
      
       ("ARM: smp: add support for per-task stack canaries")
      Reported-by: default avatarMerlijn Wajer <merlijn@wizzup.org>
      Tested-by: default avatarTony Lindgren <tony@atomide.com>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Reviewed-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarArd Biesheuvel <ardb@kernel.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      81e0dac3
    • Tony Fischetti's avatar
      HID: add ALWAYS_POLL quirk to lenovo pixart mouse · 1dc67950
      Tony Fischetti authored
      commit 819d578d
      
       upstream.
      
      A lenovo pixart mouse (17ef:608d) is afflicted common the the malfunction
      where it disconnects and reconnects every minute--each time incrementing
      the device number. This patch adds the device id of the device and
      specifies that it needs the HID_QUIRK_ALWAYS_POLL quirk in order to
      work properly.
      Signed-off-by: default avatarTony Fischetti <tony.fischetti@gmail.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1dc67950
    • Chen-Tsung Hsieh's avatar
      HID: google: add moonball USB id · 5d961582
      Chen-Tsung Hsieh authored
      commit 58322a15
      
       upstream.
      
      Add 1 additional hammer-like device.
      Signed-off-by: default avatarChen-Tsung Hsieh <chentsung@chromium.org>
      Reviewed-by: default avatarNicolas Boichat <drinkcat@chromium.org>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5d961582
    • Jann Horn's avatar
      mm: slub: add missing TID bump in kmem_cache_alloc_bulk() · ae119b7e
      Jann Horn authored
      commit fd4d9c7d upstream.
      
      When kmem_cache_alloc_bulk() attempts to allocate N objects from a percpu
      freelist of length M, and N > M > 0, it will first remove the M elements
      from the percpu freelist, then call ___slab_alloc() to allocate the next
      element and repopulate the percpu freelist. ___slab_alloc() can re-enable
      IRQs via allocate_slab(), so the TID must be bumped before ___slab_alloc()
      to properly commit the freelist head change.
      
      Fix it by unconditionally bumping c->tid when entering the slowpath.
      
      Cc: stable@vger.kernel.org
      Fixes: ebe909e0
      
       ("slub: improve bulk alloc strategy")
      Signed-off-by: default avatarJann Horn <jannh@google.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ae119b7e
    • Kees Cook's avatar
      ARM: 8958/1: rename missed uaccess .fixup section · 47b6d269
      Kees Cook authored
      commit f87b1c49 upstream.
      
      When the uaccess .fixup section was renamed to .text.fixup, one case was
      missed. Under ld.bfd, the orphaned section was moved close to .text
      (since they share the "ax" bits), so things would work normally on
      uaccess faults. Under ld.lld, the orphaned section was placed outside
      the .text section, making it unreachable.
      
      Link: https://github.com/ClangBuiltLinux/linux/issues/282
      Link: https://bugs.chromium.org/p/chromium/issues/detail?id=1020633#c44
      Link: https://lore.kernel.org/r/nycvar.YSQ.7.76.1912032147340.17114@knanqh.ubzr
      Link: https://lore.kernel.org/lkml/202002071754.F5F073F1D@keescook/
      
      Fixes: c4a84ae3
      
       ("ARM: 8322/1: keep .text and .fixup regions closer together")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Reviewed-by: default avatarArd Biesheuvel <ardb@kernel.org>
      Reviewed-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      47b6d269
    • Florian Fainelli's avatar
      ARM: 8957/1: VDSO: Match ARMv8 timer in cntvct_functional() · 1a9e7862
      Florian Fainelli authored
      commit 45939ce2 upstream.
      
      It is possible for a system with an ARMv8 timer to run a 32-bit kernel.
      When this happens we will unconditionally have the vDSO code remove the
      __vdso_gettimeofday and __vdso_clock_gettime symbols because
      cntvct_functional() returns false since it does not match that
      compatibility string.
      
      Fixes: ecf99a43
      
       ("ARM: 8331/1: VDSO initialization, mapping, and synchronization")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1a9e7862
    • Carl Huang's avatar
      net: qrtr: fix len of skb_put_padto in qrtr_node_enqueue · 881876be
      Carl Huang authored
      commit ce57785b
      
       upstream.
      
      The len used for skb_put_padto is wrong, it need to add len of hdr.
      
      In qrtr_node_enqueue, local variable size_t len is assign with
      skb->len, then skb_push(skb, sizeof(*hdr)) will add skb->len with
      sizeof(*hdr), so local variable size_t len is not same with skb->len
      after skb_push(skb, sizeof(*hdr)).
      
      Then the purpose of skb_put_padto(skb, ALIGN(len, 4)) is to add add
      pad to the end of the skb's data if skb->len is not aligned to 4, but
      unfortunately it use len instead of skb->len, at this line, skb->len
      is 32 bytes(sizeof(*hdr)) more than len, for example, len is 3 bytes,
      then skb->len is 35 bytes(3 + 32), and ALIGN(len, 4) is 4 bytes, so
      __skb_put_padto will do nothing after check size(35) < len(4), the
      correct value should be 36(sizeof(*hdr) + ALIGN(len, 4) = 32 + 4),
      then __skb_put_padto will pass check size(35) < len(36) and add 1 byte
      to the end of skb's data, then logic is correct.
      
      function of skb_push:
      void *skb_push(struct sk_buff *skb, unsigned int len)
      {
      	skb->data -= len;
      	skb->len  += len;
      	if (unlikely(skb->data < skb->head))
      		skb_under_panic(skb, len, __builtin_return_address(0));
      	return skb->data;
      }
      
      function of skb_put_padto
      static inline int skb_put_padto(struct sk_buff *skb, unsigned int len)
      {
      	return __skb_put_padto(skb, len, true);
      }
      
      function of __skb_put_padto
      static inline int __skb_put_padto(struct sk_buff *skb, unsigned int len,
      				  bool free_on_error)
      {
      	unsigned int size = skb->len;
      
      	if (unlikely(size < len)) {
      		len -= size;
      		if (__skb_pad(skb, len, free_on_error))
      			return -ENOMEM;
      		__skb_put(skb, len);
      	}
      	return 0;
      }
      Signed-off-by: default avatarCarl Huang <cjhuang@codeaurora.org>
      Signed-off-by: default avatarWen Gong <wgong@codeaurora.org>
      Cc: Doug Anderson <dianders@chromium.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      881876be
    • Ming Lei's avatar
      blk-mq: insert flush request to the front of dispatch queue · 235fb892
      Ming Lei authored
      [ Upstream commit cc3200ea ]
      
      commit 01e99aec ("blk-mq: insert passthrough request into
      hctx->dispatch directly") may change to add flush request to the tail
      of dispatch by applying the 'add_head' parameter of
      blk_mq_sched_insert_request.
      
      Turns out this way causes performance regression on NCQ controller because
      flush is non-NCQ command, which can't be queued when there is any in-flight
      NCQ command. When adding flush rq to the front of hctx->dispatch, it is
      easier to introduce extra time to flush rq's latency compared with adding
      to the tail of dispatch queue because of S_SCHED_RESTART, then chance of
      flush merge is increased, and less flush requests may be issued to
      controller.
      
      So always insert flush request to the front of dispatch queue just like
      before applying commit 01e99aec ("blk-mq: insert passthrough request
      into hctx->dispatch directly").
      
      Cc: Damien Le Moal <Damien.LeMoal@wdc.com>
      Cc: Shinichir...
      235fb892
    • Qian Cai's avatar
      jbd2: fix data races at struct journal_head · dbce8292
      Qian Cai authored
      [ Upstream commit 6c5d9112
      
       ]
      
      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>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      dbce8292