1. 06 Aug, 2019 40 commits
    • Yang Shi's avatar
      mm: vmscan: check if mem cgroup is disabled or not before calling memcg slab shrinker · beb0cc78
      Yang Shi authored
      commit fa1e512f upstream.
      
      Shakeel Butt reported premature oom on kernel with
      "cgroup_disable=memory" since mem_cgroup_is_root() returns false even
      though memcg is actually NULL.  The drop_caches is also broken.
      
      It is because commit aeed1d32 ("mm/vmscan.c: generalize
      shrink_slab() calls in shrink_node()") removed the !memcg check before
      !mem_cgroup_is_root().  And, surprisingly root memcg is allocated even
      though memory cgroup is disabled by kernel boot parameter.
      
      Add mem_cgroup_disabled() check to make reclaimer work as expected.
      
      Link: http://lkml.kernel.org/r/1563385526-20805-1-git-send-email-yang.shi@linux.alibaba.com
      Fixes: aeed1d32 ("mm/vmscan.c: generalize shrink_slab() calls in shrink_node()")
      Signed-off-by: default avatarYang Shi <yang.shi@linux.alibaba.com>
      Reported-by: default avatarShakeel Butt <shakeelb@google.com>
      Reviewed-by: default avatarShakeel Butt <shakeelb@google.com>
      Reviewed-by: default avatarKirill Tkhai <ktkhai@virtuozzo.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Cc: Jan Hadrava <had@kam.mff.cuni.cz>
      Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Roman Gushchin <guro@fb.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Qian Cai <cai@lca.pw>
      Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: <stable@vger.kernel.org>	[4.19+]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      beb0cc78
    • Samuel Thibault's avatar
      ALSA: hda: Fix 1-minute detection delay when i915 module is not available · 72651bbd
      Samuel Thibault authored
      commit 74bf71ed upstream.
      
      Distribution installation images such as Debian include different sets
      of modules which can be downloaded dynamically.  Such images may notably
      include the hda sound modules but not the i915 DRM module, even if the
      latter was enabled at build time, as reported on
      https://bugs.debian.org/931507
      
      In such a case hdac_i915 would be linked in and try to load the i915
      module, fail since it is not there, but still wait for a whole minute
      before giving up binding with it.
      
      This fixes such as case by only waiting for the binding if the module
      was properly loaded (or module support is disabled, in which case i915
      is already compiled-in anyway).
      
      Fixes: f9b54e19 ("ALSA: hda/i915: Allow delayed i915 audio component binding")
      Signed-off-by: default avatarSamuel Thibault <samuel.thibault@ens-lyon.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      72651bbd
    • Ondrej Mosnacek's avatar
      selinux: fix memory leak in policydb_init() · 46650ac2
      Ondrej Mosnacek authored
      commit 45385237 upstream.
      
      Since roles_init() adds some entries to the role hash table, we need to
      destroy also its keys/values on error, otherwise we get a memory leak in
      the error path.
      
      Cc: <stable@vger.kernel.org>
      Reported-by: syzbot+fee3a14d4cdf92646287@syzkaller.appspotmail.com
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarOndrej Mosnacek <omosnace@redhat.com>
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      46650ac2
    • Marco Felsch's avatar
      mtd: rawnand: micron: handle on-die "ECC-off" devices correctly · e7bb4c81
      Marco Felsch authored
      commit 8493b2a0 upstream.
      
      Some devices are not supposed to support on-die ECC but experience
      shows that internal ECC machinery can actually be enabled through the
      "SET FEATURE (EFh)" command, even if a read of the "READ ID Parameter
      Tables" returns that it is not.
      
      Currently, the driver checks the "READ ID Parameter" field directly
      after having enabled the feature. If the check fails it returns
      immediately but leaves the ECC on. When using buggy chips like
      MT29F2G08ABAGA and MT29F2G08ABBGA, all future read/program cycles will
      go through the on-die ECC, confusing the host controller which is
      supposed to be the one handling correction.
      
      To address this in a common way we need to turn off the on-die ECC
      directly after reading the "READ ID Parameter" and before checking the
      "ECC status".
      
      Cc: stable@vger.kernel.org
      Fixes: dbc44edb ("mtd: rawnand: micron: Fix on-die ECC detection logic")
      Signed-off-by: default avatarMarco Felsch <m.felsch@pengutronix.de>
      Reviewed-by: default avatarBoris Brezillon <boris.brezillon@collabora.com>
      Signed-off-by: default avatarMiquel Raynal <miquel.raynal@bootlin.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e7bb4c81
    • Gustavo A. R. Silva's avatar
      IB/hfi1: Fix Spectre v1 vulnerability · fafaeae4
      Gustavo A. R. Silva authored
      commit 6497d0a9 upstream.
      
      sl is controlled by user-space, hence leading to a potential
      exploitation of the Spectre variant 1 vulnerability.
      
      Fix this by sanitizing sl before using it to index ibp->sl_to_sc.
      
      Notice that given that speculation windows are large, the policy is
      to kill the speculation on the first load and not worry if it can be
      completed with a dependent load/store [1].
      
      [1] https://lore.kernel.org/lkml/20180423164740.GY17484@dhcp22.suse.cz/
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Link: https://lore.kernel.org/r/20190731175428.GA16736@embeddedorSigned-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fafaeae4
    • Michael Wu's avatar
      gpiolib: fix incorrect IRQ requesting of an active-low lineevent · fdb0fb56
      Michael Wu authored
      commit 223ecaf1 upstream.
      
      When a pin is active-low, logical trigger edge should be inverted to match
      the same interrupt opportunity.
      
      For example, a button pushed triggers falling edge in ACTIVE_HIGH case; in
      ACTIVE_LOW case, the button pushed triggers rising edge. For user space the
      IRQ requesting doesn't need to do any modification except to configuring
      GPIOHANDLE_REQUEST_ACTIVE_LOW.
      
      For example, we want to catch the event when the button is pushed. The
      button on the original board drives level to be low when it is pushed, and
      drives level to be high when it is released.
      
      In user space we can do:
      
      	req.handleflags = GPIOHANDLE_REQUEST_INPUT;
      	req.eventflags = GPIOEVENT_REQUEST_FALLING_EDGE;
      
      	while (1) {
      		read(fd, &dat, sizeof(dat));
      		if (dat.id == GPIOEVENT_EVENT_FALLING_EDGE)
      			printf("button pushed\n");
      	}
      
      Run the same logic on another board which the polarity of the button is
      inverted; it drives level to be high when pushed, and level to be low when
      released. For this inversion we add flag GPIOHANDLE_REQUEST_ACTIVE_LOW:
      
      	req.handleflags = GPIOHANDLE_REQUEST_INPUT |
      		GPIOHANDLE_REQUEST_ACTIVE_LOW;
      	req.eventflags = GPIOEVENT_REQUEST_FALLING_EDGE;
      
      At the result, there are no any events caught when the button is pushed.
      By the way, button releasing will emit a "falling" event. The timing of
      "falling" catching is not expected.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMichael Wu <michael.wu@vatics.com>
      Tested-by: default avatarBartosz Golaszewski <bgolaszewski@baylibre.com>
      Signed-off-by: default avatarBartosz Golaszewski <bgolaszewski@baylibre.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fdb0fb56
    • Joe Perches's avatar
      mmc: meson-mx-sdio: Fix misuse of GENMASK macro · 7e3efb65
      Joe Perches authored
      commit 665e985c upstream.
      
      Arguments are supposed to be ordered high then low.
      Signed-off-by: default avatarJoe Perches <joe@perches.com>
      Reviewed-by: default avatarNeil Armstrong <narmstrong@baylibre.com>
      Fixes: ed80a13b ("mmc: meson-mx-sdio: Add a driver for the Amlogic
      Meson8 and Meson8b SoCs")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7e3efb65
    • Douglas Anderson's avatar
      mmc: dw_mmc: Fix occasional hang after tuning on eMMC · 29841b5c
      Douglas Anderson authored
      commit ba2d139b upstream.
      
      In commit 46d17952 ("mmc: dw_mmc: Wait for data transfer after
      response errors.") we fixed a tuning-induced hang that I saw when
      stress testing tuning on certain SD cards.  I won't re-hash that whole
      commit, but the summary is that as a normal part of tuning you need to
      deal with transfer errors and there were cases where these transfer
      errors was putting my system into a bad state causing all future
      transfers to fail.  That commit fixed handling of the transfer errors
      for me.
      
      In downstream Chrome OS my fix landed and had the same behavior for
      all SD/MMC commands.  However, it looks like when the commit landed
      upstream we limited it to only SD tuning commands.  Presumably this
      was to try to get around problems that Alim Akhtar reported on exynos
      [1].
      
      Unfortunately while stress testing reboots (and suspend/resume) on
      some rk3288-based Chromebooks I found the same problem on the eMMC on
      some of my Chromebooks (the ones with Hynix eMMC).  Since the eMMC
      tuning command is different (MMC_SEND_TUNING_BLOCK_HS200
      vs. MMC_SEND_TUNING_BLOCK) we were basically getting back into the
      same situation.
      
      I'm hoping that whatever problems exynos was having in the past are
      somehow magically fixed now and we can make the behavior the same for
      all commands.
      
      [1] https://lkml.kernel.org/r/CAGOxZ53WfNbaMe0_AM0qBqU47kAfgmPBVZC8K8Y-_J3mDMqW4A@mail.gmail.com
      
      Fixes: 46d17952 ("mmc: dw_mmc: Wait for data transfer after response errors.")
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Cc: Marek Szyprowski <m.szyprowski@samsung.com>
      Cc: Alim Akhtar <alim.akhtar@gmail.com>
      Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      29841b5c
    • Filipe Manana's avatar
      Btrfs: fix race leading to fs corruption after transaction abort · 50d70040
      Filipe Manana authored
      commit cb2d3dad upstream.
      
      When one transaction is finishing its commit, it is possible for another
      transaction to start and enter its initial commit phase as well. If the
      first ends up getting aborted, we have a small time window where the second
      transaction commit does not notice that the previous transaction aborted
      and ends up committing, writing a superblock that points to btrees that
      reference extent buffers (nodes and leafs) that were not persisted to disk.
      The consequence is that after mounting the filesystem again, we will be
      unable to load some btree nodes/leafs, either because the content on disk
      is either garbage (or just zeroes) or corresponds to the old content of a
      previouly COWed or deleted node/leaf, resulting in the well known error
      messages "parent transid verify failed on ...".
      The following sequence diagram illustrates how this can happen.
      
              CPU 1                                           CPU 2
      
       <at transaction N>
      
       btrfs_commit_transaction()
         (...)
         --> sets transaction state to
             TRANS_STATE_UNBLOCKED
         --> sets fs_info->running_transaction
             to NULL
      
                                                          (...)
                                                          btrfs_start_transaction()
                                                            start_transaction()
                                                              wait_current_trans()
                                                                --> returns immediately
                                                                    because
                                                                    fs_info->running_transaction
                                                                    is NULL
                                                              join_transaction()
                                                                --> creates transaction N + 1
                                                                --> sets
                                                                    fs_info->running_transaction
                                                                    to transaction N + 1
                                                                --> adds transaction N + 1 to
                                                                    the fs_info->trans_list list
                                                              --> returns transaction handle
                                                                  pointing to the new
                                                                  transaction N + 1
                                                          (...)
      
                                                          btrfs_sync_file()
                                                            btrfs_start_transaction()
                                                              --> returns handle to
                                                                  transaction N + 1
                                                            (...)
      
         btrfs_write_and_wait_transaction()
           --> writeback of some extent
               buffer fails, returns an
      	 error
         btrfs_handle_fs_error()
           --> sets BTRFS_FS_STATE_ERROR in
               fs_info->fs_state
         --> jumps to label "scrub_continue"
         cleanup_transaction()
           btrfs_abort_transaction(N)
             --> sets BTRFS_FS_STATE_TRANS_ABORTED
                 flag in fs_info->fs_state
             --> sets aborted field in the
                 transaction and transaction
      	   handle structures, for
                 transaction N only
           --> removes transaction from the
               list fs_info->trans_list
                                                            btrfs_commit_transaction(N + 1)
                                                              --> transaction N + 1 was not
      							    aborted, so it proceeds
                                                              (...)
                                                              --> sets the transaction's state
                                                                  to TRANS_STATE_COMMIT_START
                                                              --> does not find the previous
                                                                  transaction (N) in the
                                                                  fs_info->trans_list, so it
                                                                  doesn't know that transaction
                                                                  was aborted, and the commit
                                                                  of transaction N + 1 proceeds
                                                              (...)
                                                              --> sets transaction N + 1 state
                                                                  to TRANS_STATE_UNBLOCKED
                                                              btrfs_write_and_wait_transaction()
                                                                --> succeeds writing all extent
                                                                    buffers created in the
                                                                    transaction N + 1
                                                              write_all_supers()
                                                                 --> succeeds
                                                                 --> we now have a superblock on
                                                                     disk that points to trees
                                                                     that refer to at least one
                                                                     extent buffer that was
                                                                     never persisted
      
      So fix this by updating the transaction commit path to check if the flag
      BTRFS_FS_STATE_TRANS_ABORTED is set on fs_info->fs_state if after setting
      the transaction to the TRANS_STATE_COMMIT_START we do not find any previous
      transaction in the fs_info->trans_list. If the flag is set, just fail the
      transaction commit with -EROFS, as we do in other places. The exact error
      code for the previous transaction abort was already logged and reported.
      
      Fixes: 49b25e05 ("btrfs: enhance transaction abort infrastructure")
      CC: stable@vger.kernel.org # 4.4+
      Reviewed-by: default avatarJosef Bacik <josef@toxicpanda.com>
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      50d70040
    • Filipe Manana's avatar
      Btrfs: fix incremental send failure after deduplication · 009d7a4e
      Filipe Manana authored
      commit b4f9a1a8 upstream.
      
      When doing an incremental send operation we can fail if we previously did
      deduplication operations against a file that exists in both snapshots. In
      that case we will fail the send operation with -EIO and print a message
      to dmesg/syslog like the following:
      
        BTRFS error (device sdc): Send: inconsistent snapshot, found updated \
        extent for inode 257 without updated inode item, send root is 258, \
        parent root is 257
      
      This requires that we deduplicate to the same file in both snapshots for
      the same amount of times on each snapshot. The issue happens because a
      deduplication only updates the iversion of an inode and does not update
      any other field of the inode, therefore if we deduplicate the file on
      each snapshot for the same amount of time, the inode will have the same
      iversion value (stored as the "sequence" field on the inode item) on both
      snapshots, therefore it will be seen as unchanged between in the send
      snapshot while there are new/updated/deleted extent items when comparing
      to the parent snapshot. This makes the send operation return -EIO and
      print an error message.
      
      Example reproducer:
      
        $ mkfs.btrfs -f /dev/sdb
        $ mount /dev/sdb /mnt
      
        # Create our first file. The first half of the file has several 64Kb
        # extents while the second half as a single 512Kb extent.
        $ xfs_io -f -s -c "pwrite -S 0xb8 -b 64K 0 512K" /mnt/foo
        $ xfs_io -c "pwrite -S 0xb8 512K 512K" /mnt/foo
      
        # Create the base snapshot and the parent send stream from it.
        $ btrfs subvolume snapshot -r /mnt /mnt/mysnap1
        $ btrfs send -f /tmp/1.snap /mnt/mysnap1
      
        # Create our second file, that has exactly the same data as the first
        # file.
        $ xfs_io -f -c "pwrite -S 0xb8 0 1M" /mnt/bar
      
        # Create the second snapshot, used for the incremental send, before
        # doing the file deduplication.
        $ btrfs subvolume snapshot -r /mnt /mnt/mysnap2
      
        # Now before creating the incremental send stream:
        #
        # 1) Deduplicate into a subrange of file foo in snapshot mysnap1. This
        #    will drop several extent items and add a new one, also updating
        #    the inode's iversion (sequence field in inode item) by 1, but not
        #    any other field of the inode;
        #
        # 2) Deduplicate into a different subrange of file foo in snapshot
        #    mysnap2. This will replace an extent item with a new one, also
        #    updating the inode's iversion by 1 but not any other field of the
        #    inode.
        #
        # After these two deduplication operations, the inode items, for file
        # foo, are identical in both snapshots, but we have different extent
        # items for this inode in both snapshots. We want to check this doesn't
        # cause send to fail with an error or produce an incorrect stream.
      
        $ xfs_io -r -c "dedupe /mnt/bar 0 0 512K" /mnt/mysnap1/foo
        $ xfs_io -r -c "dedupe /mnt/bar 512K 512K 512K" /mnt/mysnap2/foo
      
        # Create the incremental send stream.
        $ btrfs send -p /mnt/mysnap1 -f /tmp/2.snap /mnt/mysnap2
        ERROR: send ioctl failed with -5: Input/output error
      
      This issue started happening back in 2015 when deduplication was updated
      to not update the inode's ctime and mtime and update only the iversion.
      Back then we would hit a BUG_ON() in send, but later in 2016 send was
      updated to return -EIO and print the error message instead of doing the
      BUG_ON().
      
      A test case for fstests follows soon.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203933
      Fixes: 1c919a5e ("btrfs: don't update mtime/ctime on deduped inodes")
      CC: stable@vger.kernel.org # 4.4+
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      009d7a4e
    • Masahiro Yamada's avatar
      kbuild: initialize CLANG_FLAGS correctly in the top Makefile · 4c5a4425
      Masahiro Yamada authored
      commit 5241ab4c upstream.
      
      CLANG_FLAGS is initialized by the following line:
      
        CLANG_FLAGS     := --target=$(notdir $(CROSS_COMPILE:%-=%))
      
      ..., which is run only when CROSS_COMPILE is set.
      
      Some build targets (bindeb-pkg etc.) recurse to the top Makefile.
      
      When you build the kernel with Clang but without CROSS_COMPILE,
      the same compiler flags such as -no-integrated-as are accumulated
      into CLANG_FLAGS.
      
      If you run 'make CC=clang' and then 'make CC=clang bindeb-pkg',
      Kbuild will recompile everything needlessly due to the build command
      change.
      
      Fix this by correctly initializing CLANG_FLAGS.
      
      Fixes: 238bcbc4 ("kbuild: consolidate Clang compiler flags")
      Cc: <stable@vger.kernel.org> # v5.0+
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Acked-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4c5a4425
    • M. Vefa Bicakci's avatar
      kconfig: Clear "written" flag to avoid data loss · 3736612d
      M. Vefa Bicakci authored
      commit 0c5b6c28 upstream.
      
      Prior to this commit, starting nconfig, xconfig or gconfig, and saving
      the .config file more than once caused data loss, where a .config file
      that contained only comments would be written to disk starting from the
      second save operation.
      
      This bug manifests itself because the SYMBOL_WRITTEN flag is never
      cleared after the first call to conf_write, and subsequent calls to
      conf_write then skip all of the configuration symbols due to the
      SYMBOL_WRITTEN flag being set.
      
      This commit resolves this issue by clearing the SYMBOL_WRITTEN flag
      from all symbols before conf_write returns.
      
      Fixes: 8e2442a5 ("kconfig: fix missing choice values in auto.conf")
      Cc: linux-stable <stable@vger.kernel.org> # 4.19+
      Signed-off-by: default avatarM. Vefa Bicakci <m.v.b@runbox.com>
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3736612d
    • Yongxin Liu's avatar
      drm/nouveau: fix memory leak in nouveau_conn_reset() · 4c6500b5
      Yongxin Liu authored
      [ Upstream commit 09b90e2f ]
      
      In nouveau_conn_reset(), if connector->state is true,
      __drm_atomic_helper_connector_destroy_state() will be called,
      but the memory pointed by asyc isn't freed. Memory leak happens
      in the following function __drm_atomic_helper_connector_reset(),
      where newly allocated asyc->state will be assigned to connector->state.
      
      So using nouveau_conn_atomic_destroy_state() instead of
      __drm_atomic_helper_connector_destroy_state to free the "old" asyc.
      
      Here the is the log showing memory leak.
      
      unreferenced object 0xffff8c5480483c80 (size 192):
        comm "kworker/0:2", pid 188, jiffies 4294695279 (age 53.179s)
        hex dump (first 32 bytes):
          00 f0 ba 7b 54 8c ff ff 00 00 00 00 00 00 00 00  ...{T...........
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        backtrace:
          [<000000005005c0d0>] kmem_cache_alloc_trace+0x195/0x2c0
          [<00000000a122baed>] nouveau_conn_reset+0x25/0xc0 [nouveau]
          [<000000004fd189a2>] nouveau_connector_create+0x3a7/0x610 [nouveau]
          [<00000000c73343a8>] nv50_display_create+0x343/0x980 [nouveau]
          [<000000002e2b03c3>] nouveau_display_create+0x51f/0x660 [nouveau]
          [<00000000c924699b>] nouveau_drm_device_init+0x182/0x7f0 [nouveau]
          [<00000000cc029436>] nouveau_drm_probe+0x20c/0x2c0 [nouveau]
          [<000000007e961c3e>] local_pci_probe+0x47/0xa0
          [<00000000da14d569>] work_for_cpu_fn+0x1a/0x30
          [<0000000028da4805>] process_one_work+0x27c/0x660
          [<000000001d415b04>] worker_thread+0x22b/0x3f0
          [<0000000003b69f1f>] kthread+0x12f/0x150
          [<00000000c94c29b7>] ret_from_fork+0x3a/0x50
      Signed-off-by: default avatarYongxin Liu <yongxin.liu@windriver.com>
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      4c6500b5
    • Zhenzhong Duan's avatar
      x86, boot: Remove multiple copy of static function sanitize_boot_params() · 84ce0452
      Zhenzhong Duan authored
      [ Upstream commit 8c5477e8 ]
      
      Kernel build warns:
       'sanitize_boot_params' defined but not used [-Wunused-function]
      
      at below files:
        arch/x86/boot/compressed/cmdline.c
        arch/x86/boot/compressed/error.c
        arch/x86/boot/compressed/early_serial_console.c
        arch/x86/boot/compressed/acpi.c
      
      That's becausethey each include misc.h which includes a definition of
      sanitize_boot_params() via bootparam_utils.h.
      
      Remove the inclusion from misc.h and have the c file including
      bootparam_utils.h directly.
      Signed-off-by: default avatarZhenzhong Duan <zhenzhong.duan@oracle.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Link: https://lkml.kernel.org/r/1563283092-1189-1-git-send-email-zhenzhong.duan@oracle.comSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      84ce0452
    • Josh Poimboeuf's avatar
      x86/paravirt: Fix callee-saved function ELF sizes · 740e0167
      Josh Poimboeuf authored
      [ Upstream commit 083db676 ]
      
      The __raw_callee_save_*() functions have an ELF symbol size of zero,
      which confuses objtool and other tools.
      
      Fixes a bunch of warnings like the following:
      
        arch/x86/xen/mmu_pv.o: warning: objtool: __raw_callee_save_xen_pte_val() is missing an ELF size annotation
        arch/x86/xen/mmu_pv.o: warning: objtool: __raw_callee_save_xen_pgd_val() is missing an ELF size annotation
        arch/x86/xen/mmu_pv.o: warning: objtool: __raw_callee_save_xen_make_pte() is missing an ELF size annotation
        arch/x86/xen/mmu_pv.o: warning: objtool: __raw_callee_save_xen_make_pgd() is missing an ELF size annotation
      Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarJuergen Gross <jgross@suse.com>
      Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Link: https://lkml.kernel.org/r/afa6d49bb07497ca62e4fc3b27a2d0cece545b4e.1563413318.git.jpoimboe@redhat.comSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      740e0167
    • Josh Poimboeuf's avatar
      x86/kvm: Don't call kvm_spurious_fault() from .fixup · ba5c072f
      Josh Poimboeuf authored
      [ Upstream commit 3901336e ]
      
      After making a change to improve objtool's sibling call detection, it
      started showing the following warning:
      
        arch/x86/kvm/vmx/nested.o: warning: objtool: .fixup+0x15: sibling call from callable instruction with modified stack frame
      
      The problem is the ____kvm_handle_fault_on_reboot() macro.  It does a
      fake call by pushing a fake RIP and doing a jump.  That tricks the
      unwinder into printing the function which triggered the exception,
      rather than the .fixup code.
      
      Instead of the hack to make it look like the original function made the
      call, just change the macro so that the original function actually does
      make the call.  This allows removal of the hack, and also makes objtool
      happy.
      
      I triggered a vmx instruction exception and verified that the stack
      trace is still sane:
      
        kernel BUG at arch/x86/kvm/x86.c:358!
        invalid opcode: 0000 [#1] SMP PTI
        CPU: 28 PID: 4096 Comm: qemu-kvm Not tainted 5.2.0+ #16
        Hardware name: Lenovo THINKSYSTEM SD530 -[7X2106Z000]-/-[7X2106Z000]-, BIOS -[TEE113Z-1.00]- 07/17/2017
        RIP: 0010:kvm_spurious_fault+0x5/0x10
        Code: 00 00 00 00 00 8b 44 24 10 89 d2 45 89 c9 48 89 44 24 10 8b 44 24 08 48 89 44 24 08 e9 d4 40 22 00 0f 1f 40 00 0f 1f 44 00 00 <0f> 0b 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 55 49 89 fd 41
        RSP: 0018:ffffbf91c683bd00 EFLAGS: 00010246
        RAX: 000061f040000000 RBX: ffff9e159c77bba0 RCX: ffff9e15a5c87000
        RDX: 0000000665c87000 RSI: ffff9e15a5c87000 RDI: ffff9e159c77bba0
        RBP: 0000000000000000 R08: 0000000000000000 R09: ffff9e15a5c87000
        R10: 0000000000000000 R11: fffff8f2d99721c0 R12: ffff9e159c77bba0
        R13: ffffbf91c671d960 R14: ffff9e159c778000 R15: 0000000000000000
        FS:  00007fa341cbe700(0000) GS:ffff9e15b7400000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: 00007fdd38356804 CR3: 00000006759de003 CR4: 00000000007606e0
        DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
        DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
        PKRU: 55555554
        Call Trace:
         loaded_vmcs_init+0x4f/0xe0
         alloc_loaded_vmcs+0x38/0xd0
         vmx_create_vcpu+0xf7/0x600
         kvm_vm_ioctl+0x5e9/0x980
         ? __switch_to_asm+0x40/0x70
         ? __switch_to_asm+0x34/0x70
         ? __switch_to_asm+0x40/0x70
         ? __switch_to_asm+0x34/0x70
         ? free_one_page+0x13f/0x4e0
         do_vfs_ioctl+0xa4/0x630
         ksys_ioctl+0x60/0x90
         __x64_sys_ioctl+0x16/0x20
         do_syscall_64+0x55/0x1c0
         entry_SYSCALL_64_after_hwframe+0x44/0xa9
        RIP: 0033:0x7fa349b1ee5b
      Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Acked-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Link: https://lkml.kernel.org/r/64a9b64d127e87b6920a97afde8e96ea76f6524e.1563413318.git.jpoimboe@redhat.comSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      ba5c072f
    • Zhenzhong Duan's avatar
      xen/pv: Fix a boot up hang revealed by int3 self test · 11cb9f87
      Zhenzhong Duan authored
      [ Upstream commit b23e5844 ]
      
      Commit 7457c0da ("x86/alternatives: Add int3_emulate_call()
      selftest") is used to ensure there is a gap setup in int3 exception stack
      which could be used for inserting call return address.
      
      This gap is missed in XEN PV int3 exception entry path, then below panic
      triggered:
      
      [    0.772876] general protection fault: 0000 [#1] SMP NOPTI
      [    0.772886] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.2.0+ #11
      [    0.772893] RIP: e030:int3_magic+0x0/0x7
      [    0.772905] RSP: 3507:ffffffff82203e98 EFLAGS: 00000246
      [    0.773334] Call Trace:
      [    0.773334]  alternative_instructions+0x3d/0x12e
      [    0.773334]  check_bugs+0x7c9/0x887
      [    0.773334]  ? __get_locked_pte+0x178/0x1f0
      [    0.773334]  start_kernel+0x4ff/0x535
      [    0.773334]  ? set_init_arg+0x55/0x55
      [    0.773334]  xen_start_kernel+0x571/0x57a
      
      For 64bit PV guests, Xen's ABI enters the kernel with using SYSRET, with
      %rcx/%r11 on the stack. To convert back to "normal" looking exceptions,
      the xen thunks do 'xen_*: pop %rcx; pop %r11; jmp *'.
      
      E.g. Extracting 'xen_pv_trap xenint3' we have:
      xen_xenint3:
       pop %rcx;
       pop %r11;
       jmp xenint3
      
      As xenint3 and int3 entry code are same except xenint3 doesn't generate
      a gap, we can fix it by using int3 and drop useless xenint3.
      Signed-off-by: default avatarZhenzhong Duan <zhenzhong.duan@oracle.com>
      Reviewed-by: default avatarJuergen Gross <jgross@suse.com>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Stefano Stabellini <sstabellini@kernel.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Andrew Cooper <andrew.cooper3@citrix.com>
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      11cb9f87
    • Petr Machata's avatar
      mlxsw: spectrum_dcb: Configure DSCP map as the last rule is removed · d3e36788
      Petr Machata authored
      [ Upstream commit dedfde2f ]
      
      Spectrum systems use DSCP rewrite map to update DSCP field in egressing
      packets to correspond to priority that the packet has. Whether rewriting
      will take place is determined at the point when the packet ingresses the
      switch: if the port is in Trust L3 mode, packet priority is determined from
      the DSCP map at the port, and DSCP rewrite will happen. If the port is in
      Trust L2 mode, 802.1p is used for packet prioritization, and no DSCP
      rewrite will happen.
      
      The driver determines the port trust mode based on whether any DSCP
      prioritization rules are in effect at given port. If there are any, trust
      level is L3, otherwise it's L2. When the last DSCP rule is removed, the
      port is switched to trust L2. Under that scenario, if DSCP of a packet
      should be rewritten, it should be rewritten to 0.
      
      However, when switching to Trust L2, the driver neglects to also update the
      DSCP rewrite map. The last DSCP rule thus remains in effect, and packets
      egressing through this port, if they have the right priority, will have
      their DSCP set according to this rule.
      
      Fix by first configuring the rewrite map, and only then switching to trust
      L2 and bailing out.
      
      Fixes: b2b1dab6 ("mlxsw: spectrum: Support ieee_setapp, ieee_delapp")
      Signed-off-by: default avatarPetr Machata <petrm@mellanox.com>
      Reported-by: default avatarAlex Veber <alexve@mellanox.com>
      Tested-by: default avatarAlex Veber <alexve@mellanox.com>
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      d3e36788
    • Kees Cook's avatar
      ipc/mqueue.c: only perform resource calculation if user valid · 48c5c4f0
      Kees Cook authored
      [ Upstream commit a318f12e ]
      
      Andreas Christoforou reported:
      
        UBSAN: Undefined behaviour in ipc/mqueue.c:414:49 signed integer overflow:
        9 * 2305843009213693951 cannot be represented in type 'long int'
        ...
        Call Trace:
          mqueue_evict_inode+0x8e7/0xa10 ipc/mqueue.c:414
          evict+0x472/0x8c0 fs/inode.c:558
          iput_final fs/inode.c:1547 [inline]
          iput+0x51d/0x8c0 fs/inode.c:1573
          mqueue_get_inode+0x8eb/0x1070 ipc/mqueue.c:320
          mqueue_create_attr+0x198/0x440 ipc/mqueue.c:459
          vfs_mkobj+0x39e/0x580 fs/namei.c:2892
          prepare_open ipc/mqueue.c:731 [inline]
          do_mq_open+0x6da/0x8e0 ipc/mqueue.c:771
      
      Which could be triggered by:
      
              struct mq_attr attr = {
                      .mq_flags = 0,
                      .mq_maxmsg = 9,
                      .mq_msgsize = 0x1fffffffffffffff,
                      .mq_curmsgs = 0,
              };
      
              if (mq_open("/testing", 0x40, 3, &attr) == (mqd_t) -1)
                      perror("mq_open");
      
      mqueue_get_inode() was correctly rejecting the giant mq_msgsize, and
      preparing to return -EINVAL.  During the cleanup, it calls
      mqueue_evict_inode() which performed resource usage tracking math for
      updating "user", before checking if there was a valid "user" at all
      (which would indicate that the calculations would be sane).  Instead,
      delay this check to after seeing a valid "user".
      
      The overflow was real, but the results went unused, so while the flaw is
      harmless, it's noisy for kernel fuzzers, so just fix it by moving the
      calculation under the non-NULL "user" where it actually gets used.
      
      Link: http://lkml.kernel.org/r/201906072207.ECB65450@keescookSigned-off-by: default avatarKees Cook <keescook@chromium.org>
      Reported-by: default avatarAndreas Christoforou <andreaschristofo@gmail.com>
      Acked-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Davidlohr Bueso <dave@stgolabs.net>
      Cc: Manfred Spraul <manfred@colorfullife.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      48c5c4f0
    • Dan Carpenter's avatar
      drivers/rapidio/devices/rio_mport_cdev.c: NUL terminate some strings · f8731422
      Dan Carpenter authored
      [ Upstream commit 156e0b1a ]
      
      The dev_info.name[] array has space for RIO_MAX_DEVNAME_SZ + 1
      characters.  But the problem here is that we don't ensure that the user
      put a NUL terminator on the end of the string.  It could lead to an out
      of bounds read.
      
      Link: http://lkml.kernel.org/r/20190529110601.GB19119@mwanda
      Fixes: e8de3701 ("rapidio: add mport char device driver")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Acked-by: default avatarAlexandre Bounine <alex.bou9@gmail.com>
      Cc: Ira Weiny <ira.weiny@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f8731422
    • Mikko Rapeli's avatar
      uapi linux/coda_psdev.h: move upc_req definition from uapi to kernel side headers · 35ee8b84
      Mikko Rapeli authored
      [ Upstream commit f90fb3c7 ]
      
      Only users of upc_req in kernel side fs/coda/psdev.c and
      fs/coda/upcall.c already include linux/coda_psdev.h.
      
      Suggested by Jan Harkes <jaharkes@cs.cmu.edu> in
        https://lore.kernel.org/lkml/20150531111913.GA23377@cs.cmu.edu/
      
      Fixes these include/uapi/linux/coda_psdev.h compilation errors in userspace:
      
        linux/coda_psdev.h:12:19: error: field `uc_chain' has incomplete type
        struct list_head    uc_chain;
                         ^
        linux/coda_psdev.h:13:2: error: unknown type name `caddr_t'
        caddr_t             uc_data;
        ^
        linux/coda_psdev.h:14:2: error: unknown type name `u_short'
        u_short             uc_flags;
        ^
        linux/coda_psdev.h:15:2: error: unknown type name `u_short'
        u_short             uc_inSize;  /* Size is at most 5000 bytes */
        ^
        linux/coda_psdev.h:16:2: error: unknown type name `u_short'
        u_short             uc_outSize;
        ^
        linux/coda_psdev.h:17:2: error: unknown type name `u_short'
        u_short             uc_opcode;  /* copied from data to save lookup */
        ^
        linux/coda_psdev.h:19:2: error: unknown type name `wait_queue_head_t'
        wait_queue_head_t   uc_sleep;   /* process' wait queue */
        ^
      
      Link: http://lkml.kernel.org/r/9f99f5ce6a0563d5266e6cf7aa9585aac2cae971.1558117389.git.jaharkes@cs.cmu.eduSigned-off-by: default avatarMikko Rapeli <mikko.rapeli@iki.fi>
      Signed-off-by: default avatarJan Harkes <jaharkes@cs.cmu.edu>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Colin Ian King <colin.king@canonical.com>
      Cc: Dan Carpenter <dan.carpenter@oracle.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Fabian Frederick <fabf@skynet.be>
      Cc: Sam Protsenko <semen.protsenko@linaro.org>
      Cc: Yann Droneaud <ydroneaud@opteya.com>
      Cc: Zhouyang Jia <jiazhouyang09@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      35ee8b84
    • Sam Protsenko's avatar
      coda: fix build using bare-metal toolchain · dea2ee49
      Sam Protsenko authored
      [ Upstream commit b2a57e33 ]
      
      The kernel is self-contained project and can be built with bare-metal
      toolchain.  But bare-metal toolchain doesn't define __linux__.  Because
      of this u_quad_t type is not defined when using bare-metal toolchain and
      codafs build fails.  This patch fixes it by defining u_quad_t type
      unconditionally.
      
      Link: http://lkml.kernel.org/r/3cbb40b0a57b6f9923a9d67b53473c0b691a3eaa.1558117389.git.jaharkes@cs.cmu.eduSigned-off-by: default avatarSam Protsenko <semen.protsenko@linaro.org>
      Signed-off-by: default avatarJan Harkes <jaharkes@cs.cmu.edu>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Colin Ian King <colin.king@canonical.com>
      Cc: Dan Carpenter <dan.carpenter@oracle.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Fabian Frederick <fabf@skynet.be>
      Cc: Mikko Rapeli <mikko.rapeli@iki.fi>
      Cc: Yann Droneaud <ydroneaud@opteya.com>
      Cc: Zhouyang Jia <jiazhouyang09@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      dea2ee49
    • Zhouyang Jia's avatar
      coda: add error handling for fget · cf3ddc00
      Zhouyang Jia authored
      [ Upstream commit 02551c23 ]
      
      When fget fails, the lack of error-handling code may cause unexpected
      results.
      
      This patch adds error-handling code after calling fget.
      
      Link: http://lkml.kernel.org/r/2514ec03df9c33b86e56748513267a80dd8004d9.1558117389.git.jaharkes@cs.cmu.eduSigned-off-by: default avatarZhouyang Jia <jiazhouyang09@gmail.com>
      Signed-off-by: default avatarJan Harkes <jaharkes@cs.cmu.edu>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Colin Ian King <colin.king@canonical.com>
      Cc: Dan Carpenter <dan.carpenter@oracle.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Fabian Frederick <fabf@skynet.be>
      Cc: Mikko Rapeli <mikko.rapeli@iki.fi>
      Cc: Sam Protsenko <semen.protsenko@linaro.org>
      Cc: Yann Droneaud <ydroneaud@opteya.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      cf3ddc00
    • Peter Rosin's avatar
      lib/test_string.c: avoid masking memset16/32/64 failures · 93b83005
      Peter Rosin authored
      [ Upstream commit 33d6e0ff ]
      
      If a memsetXX implementation is completely broken and fails in the first
      iteration, when i, j, and k are all zero, the failure is masked as zero
      is returned.  Failing in the first iteration is perhaps the most likely
      failure, so this makes the tests pretty much useless.  Avoid the
      situation by always setting a random unused bit in the result on
      failure.
      
      Link: http://lkml.kernel.org/r/20190506124634.6807-3-peda@axentia.se
      Fixes: 03270c13 ("lib/string.c: add testcases for memset16/32/64")
      Signed-off-by: default avatarPeter Rosin <peda@axentia.se>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      93b83005
    • Kees Cook's avatar
      lib/test_overflow.c: avoid tainting the kernel and fix wrap size · 8e087a2a
      Kees Cook authored
      [ Upstream commit 8e060c21 ]
      
      This adds __GFP_NOWARN to the kmalloc()-portions of the overflow test to
      avoid tainting the kernel.  Additionally fixes up the math on wrap size
      to be architecture and page size agnostic.
      
      Link: http://lkml.kernel.org/r/201905282012.0A8767E24@keescook
      Fixes: ca90800a ("test_overflow: Add memory allocation overflow tests")
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Reported-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Suggested-by: default avatarRasmus Villemoes <linux@rasmusvillemoes.dk>
      Cc: Joe Perches <joe@perches.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      8e087a2a
    • Doug Berger's avatar
      mm/cma.c: fail if fixed declaration can't be honored · 439c79ed
      Doug Berger authored
      [ Upstream commit c633324e ]
      
      The description of cma_declare_contiguous() indicates that if the
      'fixed' argument is true the reserved contiguous area must be exactly at
      the address of the 'base' argument.
      
      However, the function currently allows the 'base', 'size', and 'limit'
      arguments to be silently adjusted to meet alignment constraints.  This
      commit enforces the documented behavior through explicit checks that
      return an error if the region does not fit within a specified region.
      
      Link: http://lkml.kernel.org/r/1561422051-16142-1-git-send-email-opendmb@gmail.com
      Fixes: 5ea3b1b2 ("cma: add placement specifier for "cma=" kernel parameter")
      Signed-off-by: default avatarDoug Berger <opendmb@gmail.com>
      Acked-by: default avatarMichal Nazarewicz <mina86@mina86.com>
      Cc: Yue Hu <huyue2@yulong.com>
      Cc: Mike Rapoport <rppt@linux.ibm.com>
      Cc: Laura Abbott <labbott@redhat.com>
      Cc: Peng Fan <peng.fan@nxp.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Marek Szyprowski <m.szyprowski@samsung.com>
      Cc: Andrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      439c79ed
    • Arnd Bergmann's avatar
      x86: math-emu: Hide clang warnings for 16-bit overflow · 1b84e674
      Arnd Bergmann authored
      [ Upstream commit 29e7e966 ]
      
      clang warns about a few parts of the math-emu implementation
      where a 16-bit integer becomes negative during assignment:
      
      arch/x86/math-emu/poly_tan.c:88:35: error: implicit conversion from 'int' to 'short' changes value from 49216 to -16320 [-Werror,-Wconstant-conversion]
                                            (0x41 + EXTENDED_Ebias) | SIGN_Negative);
                                            ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~
      arch/x86/math-emu/fpu_emu.h:180:58: note: expanded from macro 'setexponent16'
       #define setexponent16(x,y)  { (*(short *)&((x)->exp)) = (y); }
                                                            ~  ^
      arch/x86/math-emu/reg_constant.c:37:32: error: implicit conversion from 'int' to 'short' changes value from 49085 to -16451 [-Werror,-Wconstant-conversion]
      FPU_REG const CONST_PI2extra = MAKE_REG(NEG, -66,
                                     ^~~~~~~~~~~~~~~~~~
      arch/x86/math-emu/reg_constant.c:21:25: note: expanded from macro 'MAKE_REG'
                      ((EXTENDED_Ebias+(e)) | ((SIGN_##s != 0)*0x8000)) }
                       ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~
      arch/x86/math-emu/reg_constant.c:48:28: error: implicit conversion from 'int' to 'short' changes value from 65535 to -1 [-Werror,-Wconstant-conversion]
      FPU_REG const CONST_QNaN = MAKE_REG(NEG, EXP_OVER, 0x00000000, 0xC0000000);
                                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      arch/x86/math-emu/reg_constant.c:21:25: note: expanded from macro 'MAKE_REG'
                      ((EXTENDED_Ebias+(e)) | ((SIGN_##s != 0)*0x8000)) }
                       ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~
      
      The code is correct as is, so add a typecast to shut up the warnings.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Link: https://lkml.kernel.org/r/20190712090816.350668-1-arnd@arndb.deSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      1b84e674
    • Qian Cai's avatar
      x86/apic: Silence -Wtype-limits compiler warnings · 242666b2
      Qian Cai authored
      [ Upstream commit ec633558 ]
      
      There are many compiler warnings like this,
      
      In file included from ./arch/x86/include/asm/smp.h:13,
                       from ./arch/x86/include/asm/mmzone_64.h:11,
                       from ./arch/x86/include/asm/mmzone.h:5,
                       from ./include/linux/mmzone.h:969,
                       from ./include/linux/gfp.h:6,
                       from ./include/linux/mm.h:10,
                       from arch/x86/kernel/apic/io_apic.c:34:
      arch/x86/kernel/apic/io_apic.c: In function 'check_timer':
      ./arch/x86/include/asm/apic.h:37:11: warning: comparison of unsigned
      expression >= 0 is always true [-Wtype-limits]
         if ((v) <= apic_verbosity) \
                 ^~
      arch/x86/kernel/apic/io_apic.c:2160:2: note: in expansion of macro
      'apic_printk'
        apic_printk(APIC_QUIET, KERN_INFO "..TIMER: vector=0x%02X "
        ^~~~~~~~~~~
      ./arch/x86/include/asm/apic.h:37:11: warning: comparison of unsigned
      expression >= 0 is always true [-Wtype-limits]
         if ((v) <= apic_verbosity) \
                 ^~
      arch/x86/kernel/apic/io_apic.c:2207:4: note: in expansion of macro
      'apic_printk'
          apic_printk(APIC_QUIET, KERN_ERR "..MP-BIOS bug: "
          ^~~~~~~~~~~
      
      APIC_QUIET is 0, so silence them by making apic_verbosity type int.
      Signed-off-by: default avatarQian Cai <cai@lca.pw>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Link: https://lkml.kernel.org/r/1562621805-24789-1-git-send-email-cai@lca.pwSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      242666b2
    • Benjamin Poirier's avatar
      be2net: Signal that the device cannot transmit during reconfiguration · ade866ad
      Benjamin Poirier authored
      [ Upstream commit 7429c6c0 ]
      
      While changing the number of interrupt channels, be2net stops adapter
      operation (including netif_tx_disable()) but it doesn't signal that it
      cannot transmit. This may lead dev_watchdog() to falsely trigger during
      that time.
      
      Add the missing call to netif_carrier_off(), following the pattern used in
      many other drivers. netif_carrier_on() is already taken care of in
      be_open().
      Signed-off-by: default avatarBenjamin Poirier <bpoirier@suse.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ade866ad
    • Arnd Bergmann's avatar
      ACPI: fix false-positive -Wuninitialized warning · c0cca0e9
      Arnd Bergmann authored
      [ Upstream commit dfd6f9ad ]
      
      clang gets confused by an uninitialized variable in what looks
      to it like a never executed code path:
      
      arch/x86/kernel/acpi/boot.c:618:13: error: variable 'polarity' is uninitialized when used here [-Werror,-Wuninitialized]
              polarity = polarity ? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH;
                         ^~~~~~~~
      arch/x86/kernel/acpi/boot.c:606:32: note: initialize the variable 'polarity' to silence this warning
              int rc, irq, trigger, polarity;
                                            ^
                                             = 0
      arch/x86/kernel/acpi/boot.c:617:12: error: variable 'trigger' is uninitialized when used here [-Werror,-Wuninitialized]
              trigger = trigger ? ACPI_LEVEL_SENSITIVE : ACPI_EDGE_SENSITIVE;
                        ^~~~~~~
      arch/x86/kernel/acpi/boot.c:606:22: note: initialize the variable 'trigger' to silence this warning
              int rc, irq, trigger, polarity;
                                  ^
                                   = 0
      
      This is unfortunately a design decision in clang and won't be fixed.
      
      Changing the acpi_get_override_irq() macro to an inline function
      reliably avoids the issue.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Reviewed-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c0cca0e9
    • Arnd Bergmann's avatar
      x86: kvm: avoid constant-conversion warning · 80f58147
      Arnd Bergmann authored
      [ Upstream commit a6a6d3b1 ]
      
      clang finds a contruct suspicious that converts an unsigned
      character to a signed integer and back, causing an overflow:
      
      arch/x86/kvm/mmu.c:4605:39: error: implicit conversion from 'int' to 'u8' (aka 'unsigned char') changes value from -205 to 51 [-Werror,-Wconstant-conversion]
                      u8 wf = (pfec & PFERR_WRITE_MASK) ? ~w : 0;
                         ~~                               ^~
      arch/x86/kvm/mmu.c:4607:38: error: implicit conversion from 'int' to 'u8' (aka 'unsigned char') changes value from -241 to 15 [-Werror,-Wconstant-conversion]
                      u8 uf = (pfec & PFERR_USER_MASK) ? ~u : 0;
                         ~~                              ^~
      arch/x86/kvm/mmu.c:4609:39: error: implicit conversion from 'int' to 'u8' (aka 'unsigned char') changes value from -171 to 85 [-Werror,-Wconstant-conversion]
                      u8 ff = (pfec & PFERR_FETCH_MASK) ? ~x : 0;
                         ~~                               ^~
      
      Add an explicit cast to tell clang that everything works as
      intended here.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Link: https://github.com/ClangBuiltLinux/linux/issues/95Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      80f58147
    • Ravi Bangoria's avatar
      perf version: Fix segfault due to missing OPT_END() · d60e8c0c
      Ravi Bangoria authored
      [ Upstream commit 916c31ff ]
      
      'perf version' on powerpc segfaults when used with non-supported
      option:
        # perf version -a
        Segmentation fault (core dumped)
      
      Fix this.
      Signed-off-by: default avatarRavi Bangoria <ravi.bangoria@linux.ibm.com>
      Reviewed-by: default avatarKamalesh Babulal <kamalesh@linux.vnet.ibm.com>
      Tested-by: default avatarMamatha Inamdar <mamatha4@linux.vnet.ibm.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
      Link: http://lkml.kernel.org/r/20190611030109.20228-1-ravi.bangoria@linux.ibm.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      d60e8c0c
    • Benjamin Block's avatar
      scsi: zfcp: fix GCC compiler warning emitted with -Wmaybe-uninitialized · abfe761a
      Benjamin Block authored
      [ Upstream commit 48464708 ]
      
      GCC v9 emits this warning:
            CC      drivers/s390/scsi/zfcp_erp.o
          drivers/s390/scsi/zfcp_erp.c: In function 'zfcp_erp_action_enqueue':
          drivers/s390/scsi/zfcp_erp.c:217:26: warning: 'erp_action' may be used uninitialized in this function [-Wmaybe-uninitialized]
            217 |  struct zfcp_erp_action *erp_action;
                |                          ^~~~~~~~~~
      
      This is a possible false positive case, as also documented in the GCC
      documentations:
          https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wmaybe-uninitialized
      
      The actual code-sequence is like this:
          Various callers can invoke the function below with the argument "want"
          being one of:
          ZFCP_ERP_ACTION_REOPEN_ADAPTER,
          ZFCP_ERP_ACTION_REOPEN_PORT_FORCED,
          ZFCP_ERP_ACTION_REOPEN_PORT, or
          ZFCP_ERP_ACTION_REOPEN_LUN.
      
          zfcp_erp_action_enqueue(want, ...)
              ...
              need = zfcp_erp_required_act(want, ...)
                  need = want
                  ...
                  maybe: need = ZFCP_ERP_ACTION_REOPEN_PORT
                  maybe: need = ZFCP_ERP_ACTION_REOPEN_ADAPTER
                  ...
                  return need
              ...
              zfcp_erp_setup_act(need, ...)
                  struct zfcp_erp_action *erp_action; // <== line 217
                  ...
                  switch(need) {
                  case ZFCP_ERP_ACTION_REOPEN_LUN:
                          ...
                          erp_action = &zfcp_sdev->erp_action;
                          WARN_ON_ONCE(erp_action->port != port); // <== access
                          ...
                          break;
                  case ZFCP_ERP_ACTION_REOPEN_PORT:
                  case ZFCP_ERP_ACTION_REOPEN_PORT_FORCED:
                          ...
                          erp_action = &port->erp_action;
                          WARN_ON_ONCE(erp_action->port != port); // <== access
                          ...
                          break;
                  case ZFCP_ERP_ACTION_REOPEN_ADAPTER:
                          ...
                          erp_action = &adapter->erp_action;
                          WARN_ON_ONCE(erp_action->port != NULL); // <== access
                          ...
                          break;
                  }
                  ...
                  WARN_ON_ONCE(erp_action->adapter != adapter); // <== access
      
      When zfcp_erp_setup_act() is called, 'need' will never be anything else
      than one of the 4 possible enumeration-names that are used in the
      switch-case, and 'erp_action' is initialized for every one of them, before
      it is used. Thus the warning is a false positive, as documented.
      
      We introduce the extra if{} in the beginning to create an extra code-flow,
      so the compiler can be convinced that the switch-case will never see any
      other value.
      
      BUG_ON()/BUG() is intentionally not used to not crash anything, should
      this ever happen anyway - right now it's impossible, as argued above; and
      it doesn't introduce a 'default:' switch-case to retain warnings should
      'enum zfcp_erp_act_type' ever be extended and no explicit case be
      introduced. See also v5.0 commit 399b6c8b ("scsi: zfcp: drop old
      default switch case which might paper over missing case").
      Signed-off-by: default avatarBenjamin Block <bblock@linux.ibm.com>
      Reviewed-by: default avatarJens Remus <jremus@linux.ibm.com>
      Reviewed-by: default avatarSteffen Maier <maier@linux.ibm.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      abfe761a
    • Arnd Bergmann's avatar
      ACPI: blacklist: fix clang warning for unused DMI table · d5568763
      Arnd Bergmann authored
      [ Upstream commit b80d6a42 ]
      
      When CONFIG_DMI is disabled, we only have a tentative declaration,
      which causes a warning from clang:
      
      drivers/acpi/blacklist.c:20:35: error: tentative array definition assumed to have one element [-Werror]
      static const struct dmi_system_id acpi_rev_dmi_table[] __initconst;
      
      As the variable is not actually used here, hide it entirely
      in an #ifdef to shut up the warning.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      d5568763
    • Jeff Layton's avatar
      ceph: return -ERANGE if virtual xattr value didn't fit in buffer · c47e2552
      Jeff Layton authored
      [ Upstream commit 3b421018 ]
      
      The getxattr manpage states that we should return ERANGE if the
      destination buffer size is too small to hold the value.
      ceph_vxattrcb_layout does this internally, but we should be doing
      this for all vxattrs.
      
      Fix the only caller of getxattr_cb to check the returned size
      against the buffer length and return -ERANGE if it doesn't fit.
      Drop the same check in ceph_vxattrcb_layout and just rely on the
      caller to handle it.
      Signed-off-by: default avatarJeff Layton <jlayton@kernel.org>
      Reviewed-by: default avatar"Yan, Zheng" <zyan@redhat.com>
      Acked-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c47e2552
    • Andrea Parri's avatar
      ceph: fix improper use of smp_mb__before_atomic() · b39c377e
      Andrea Parri authored
      [ Upstream commit 74960773 ]
      
      This barrier only applies to the read-modify-write operations; in
      particular, it does not apply to the atomic64_set() primitive.
      
      Replace the barrier with an smp_mb().
      
      Fixes: fdd4e158 ("ceph: rework dcache readdir")
      Reported-by: default avatar"Paul E. McKenney" <paulmck@linux.ibm.com>
      Reported-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Signed-off-by: default avatarAndrea Parri <andrea.parri@amarulasolutions.com>
      Reviewed-by: default avatar"Yan, Zheng" <zyan@redhat.com>
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b39c377e
    • Ronnie Sahlberg's avatar
      cifs: Fix a race condition with cifs_echo_request · d29fbf67
      Ronnie Sahlberg authored
      [ Upstream commit f2caf901 ]
      
      There is a race condition with how we send (or supress and don't send)
      smb echos that will cause the client to incorrectly think the
      server is unresponsive and thus needs to be reconnected.
      
      Summary of the race condition:
       1) Daisy chaining scheduling creates a gap.
       2) If traffic comes unfortunate shortly after
          the last echo, the planned echo is suppressed.
       3) Due to the gap, the next echo transmission is delayed
          until after the timeout, which is set hard to twice
          the echo interval.
      
      This is fixed by changing the timeouts from 2 to three times the echo interval.
      
      Detailed description of the bug: https://lutz.donnerhacke.de/eng/Blog/Groundhog-Day-with-SMB-remountSigned-off-by: default avatarRonnie Sahlberg <lsahlber@redhat.com>
      Reviewed-by: default avatarPavel Shilovsky <pshilov@microsoft.com>
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      d29fbf67
    • Qu Wenruo's avatar
      btrfs: qgroup: Don't hold qgroup_ioctl_lock in btrfs_qgroup_inherit() · f96c70fa
      Qu Wenruo authored
      [ Upstream commit e88439de ]
      
      [BUG]
      Lockdep will report the following circular locking dependency:
      
        WARNING: possible circular locking dependency detected
        5.2.0-rc2-custom #24 Tainted: G           O
        ------------------------------------------------------
        btrfs/8631 is trying to acquire lock:
        000000002536438c (&fs_info->qgroup_ioctl_lock#2){+.+.}, at: btrfs_qgroup_inherit+0x40/0x620 [btrfs]
      
        but task is already holding lock:
        000000003d52cc23 (&fs_info->tree_log_mutex){+.+.}, at: create_pending_snapshot+0x8b6/0xe60 [btrfs]
      
        which lock already depends on the new lock.
      
        the existing dependency chain (in reverse order) is:
      
        -> #2 (&fs_info->tree_log_mutex){+.+.}:
               __mutex_lock+0x76/0x940
               mutex_lock_nested+0x1b/0x20
               btrfs_commit_transaction+0x475/0xa00 [btrfs]
               btrfs_commit_super+0x71/0x80 [btrfs]
               close_ctree+0x2bd/0x320 [btrfs]
               btrfs_put_super+0x15/0x20 [btrfs]
               generic_shutdown_super+0x72/0x110
               kill_anon_super+0x18/0x30
               btrfs_kill_super+0x16/0xa0 [btrfs]
               deactivate_locked_super+0x3a/0x80
               deactivate_super+0x51/0x60
               cleanup_mnt+0x3f/0x80
               __cleanup_mnt+0x12/0x20
               task_work_run+0x94/0xb0
               exit_to_usermode_loop+0xd8/0xe0
               do_syscall_64+0x210/0x240
               entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
        -> #1 (&fs_info->reloc_mutex){+.+.}:
               __mutex_lock+0x76/0x940
               mutex_lock_nested+0x1b/0x20
               btrfs_commit_transaction+0x40d/0xa00 [btrfs]
               btrfs_quota_enable+0x2da/0x730 [btrfs]
               btrfs_ioctl+0x2691/0x2b40 [btrfs]
               do_vfs_ioctl+0xa9/0x6d0
               ksys_ioctl+0x67/0x90
               __x64_sys_ioctl+0x1a/0x20
               do_syscall_64+0x65/0x240
               entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
        -> #0 (&fs_info->qgroup_ioctl_lock#2){+.+.}:
               lock_acquire+0xa7/0x190
               __mutex_lock+0x76/0x940
               mutex_lock_nested+0x1b/0x20
               btrfs_qgroup_inherit+0x40/0x620 [btrfs]
               create_pending_snapshot+0x9d7/0xe60 [btrfs]
               create_pending_snapshots+0x94/0xb0 [btrfs]
               btrfs_commit_transaction+0x415/0xa00 [btrfs]
               btrfs_mksubvol+0x496/0x4e0 [btrfs]
               btrfs_ioctl_snap_create_transid+0x174/0x180 [btrfs]
               btrfs_ioctl_snap_create_v2+0x11c/0x180 [btrfs]
               btrfs_ioctl+0xa90/0x2b40 [btrfs]
               do_vfs_ioctl+0xa9/0x6d0
               ksys_ioctl+0x67/0x90
               __x64_sys_ioctl+0x1a/0x20
               do_syscall_64+0x65/0x240
               entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
        other info that might help us debug this:
      
        Chain exists of:
          &fs_info->qgroup_ioctl_lock#2 --> &fs_info->reloc_mutex --> &fs_info->tree_log_mutex
      
         Possible unsafe locking scenario:
      
               CPU0                    CPU1
               ----                    ----
          lock(&fs_info->tree_log_mutex);
                                       lock(&fs_info->reloc_mutex);
                                       lock(&fs_info->tree_log_mutex);
          lock(&fs_info->qgroup_ioctl_lock#2);
      
         *** DEADLOCK ***
      
        6 locks held by btrfs/8631:
         #0: 00000000ed8f23f6 (sb_writers#12){.+.+}, at: mnt_want_write_file+0x28/0x60
         #1: 000000009fb1597a (&type->i_mutex_dir_key#10/1){+.+.}, at: btrfs_mksubvol+0x70/0x4e0 [btrfs]
         #2: 0000000088c5ad88 (&fs_info->subvol_sem){++++}, at: btrfs_mksubvol+0x128/0x4e0 [btrfs]
         #3: 000000009606fc3e (sb_internal#2){.+.+}, at: start_transaction+0x37a/0x520 [btrfs]
         #4: 00000000f82bbdf5 (&fs_info->reloc_mutex){+.+.}, at: btrfs_commit_transaction+0x40d/0xa00 [btrfs]
         #5: 000000003d52cc23 (&fs_info->tree_log_mutex){+.+.}, at: create_pending_snapshot+0x8b6/0xe60 [btrfs]
      
      [CAUSE]
      Due to the delayed subvolume creation, we need to call
      btrfs_qgroup_inherit() inside commit transaction code, with a lot of
      other mutex hold.
      This hell of lock chain can lead to above problem.
      
      [FIX]
      On the other hand, we don't really need to hold qgroup_ioctl_lock if
      we're in the context of create_pending_snapshot().
      As in that context, we're the only one being able to modify qgroup.
      
      All other qgroup functions which needs qgroup_ioctl_lock are either
      holding a transaction handle, or will start a new transaction:
        Functions will start a new transaction():
        * btrfs_quota_enable()
        * btrfs_quota_disable()
        Functions hold a transaction handler:
        * btrfs_add_qgroup_relation()
        * btrfs_del_qgroup_relation()
        * btrfs_create_qgroup()
        * btrfs_remove_qgroup()
        * btrfs_limit_qgroup()
        * btrfs_qgroup_inherit() call inside create_subvol()
      
      So we have a higher level protection provided by transaction, thus we
      don't need to always hold qgroup_ioctl_lock in btrfs_qgroup_inherit().
      
      Only the btrfs_qgroup_inherit() call in create_subvol() needs to hold
      qgroup_ioctl_lock, while the btrfs_qgroup_inherit() call in
      create_pending_snapshot() is already protected by transaction.
      
      So the fix is to detect the context by checking
      trans->transaction->state.
      If we're at TRANS_STATE_COMMIT_DOING, then we're in commit transaction
      context and no need to get the mutex.
      Reported-by: default avatarNikolay Borisov <nborisov@suse.com>
      Signed-off-by: default avatarQu Wenruo <wqu@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f96c70fa
    • David Sterba's avatar
      btrfs: fix minimum number of chunk errors for DUP · d9245dab
      David Sterba authored
      [ Upstream commit 0ee5f8ae ]
      
      The list of profiles in btrfs_chunk_max_errors lists DUP as a profile
      DUP able to tolerate 1 device missing. Though this profile is special
      with 2 copies, it still needs the device, unlike the others.
      
      Looking at the history of changes, thre's no clear reason why DUP is
      there, functions were refactored and blocks of code merged to one
      helper.
      
      d20983b4 Btrfs: fix writing data into the seed filesystem
        - factor code to a helper
      
      de11cc12 Btrfs: don't pre-allocate btrfs bio
        - unrelated change, DUP still in the list with max errors 1
      
      a236aed1 Btrfs: Deal with failed writes in mirrored configurations
        - introduced the max errors, leaves DUP and RAID1 in the same group
      Reviewed-by: default avatarQu Wenruo <wqu@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      d9245dab
    • Chunyan Zhang's avatar
      clk: sprd: Add check for return value of sprd_clk_regmap_init() · e7fcc587
      Chunyan Zhang authored
      [ Upstream commit c974c48d ]
      
      sprd_clk_regmap_init() doesn't always return success, adding check
      for its return value should make the code more strong.
      Signed-off-by: default avatarChunyan Zhang <zhang.chunyan@linaro.org>
      Reviewed-by: default avatarBaolin Wang <baolin.wang@linaro.org>
      [sboyd@kernel.org: Add a missing int ret]
      Signed-off-by: default avatarStephen Boyd <sboyd@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      e7fcc587