1. 21 Nov, 2018 40 commits
    • Arnd Bergmann's avatar
      lib/ubsan.c: don't mark __ubsan_handle_builtin_unreachable as noreturn · e133c33e
      Arnd Bergmann authored
      commit 1c23b4108d716cc848b38532063a8aca4f86add8 upstream.
      gcc-8 complains about the prototype for this function:
        lib/ubsan.c:432:1: error: ignoring attribute 'noreturn' in declaration of a built-in function '__ubsan_handle_builtin_unreachable' because it conflicts with attribute 'const' [-Werror=attributes]
      This is actually a GCC's bug. In GCC internals
      __ubsan_handle_builtin_unreachable() declared with both 'noreturn' and
      'const' attributes instead of only 'noreturn':
      Workaround this by removing the noreturn attribute.
      [aryabinin: add information about GCC bug in changelog]
      Link: http://lkml.kernel.org/r/20181107144516.4587-1-aryabinin@virtuozzo.com
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarAndrey Ryabinin <aryabinin@virtuozzo.com>
      Acked-by: default avatarOlof Johansson <olof@lixom.net>
      Cc: <stable@vger.kernel.org>
      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>
    • Guenter Roeck's avatar
      configfs: replace strncpy with memcpy · 8f1756ad
      Guenter Roeck authored
      commit 1823342a1f2b47a4e6f5667f67cd28ab6bc4d6cd upstream.
      gcc 8.1.0 complains:
      fs/configfs/symlink.c:67:3: warning:
      	'strncpy' output truncated before terminating nul copying as many
      	bytes from a string as its length
      fs/configfs/symlink.c: In function 'configfs_get_link':
      fs/configfs/symlink.c:63:13: note: length computed here
      Using strncpy() is indeed less than perfect since the length of data to
      be copied has already been determined with strlen(). Replace strncpy()
      with memcpy() to address the warning and optimize the code a little.
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarNobuhiro Iwamatsu <nobuhiro.iwamatsu@cybertrust.co.jp>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Miklos Szeredi's avatar
      fuse: fix leaked notify reply · d180feed
      Miklos Szeredi authored
      commit 7fabaf303458fcabb694999d6fa772cc13d4e217 upstream.
      fuse_request_send_notify_reply() may fail if the connection was reset for
      some reason (e.g. fs was unmounted).  Don't leak request reference in this
      case.  Besides leaking memory, this resulted in fc->num_waiting not being
      decremented and hence fuse_wait_aborted() left in a hanging and unkillable
      Fixes: 2d45ba38
       ("fuse: add retrieve request")
      Fixes: b8f95e5d13f5 ("fuse: umount should wait for all requests")
      Reported-and-tested-by: syzbot+6339eda9cb4ebbc4c37b@syzkaller.appspotmail.com
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Cc: <stable@vger.kernel.org> #v2.6.36
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Lukas Czerner's avatar
      fuse: fix use-after-free in fuse_direct_IO() · fdd93795
      Lukas Czerner authored
      commit ebacb81273599555a7a19f7754a1451206a5fc4f upstream.
      In async IO blocking case the additional reference to the io is taken for
      it to survive fuse_aio_complete(). In non blocking case this additional
      reference is not needed, however we still reference io to figure out
      whether to wait for completion or not. This is wrong and will lead to
      use-after-free. Fix it by storing blocking information in separate
      This was spotted by KASAN when running generic/208 fstest.
      Signed-off-by: default avatarLukas Czerner <lczerner@redhat.com>
      Reported-by: default avatarZorro Lang <zlang@redhat.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Fixes: 744742d6
       ("fuse: Add reference counting for fuse_io_priv")
      Cc: <stable@vger.kernel.org> # v4.6
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Maciej W. Rozycki's avatar
      rtc: hctosys: Add missing range error reporting · c616a932
      Maciej W. Rozycki authored
      commit 7ce9a992ffde8ce93d5ae5767362a5c7389ae895 upstream.
      Fix an issue with the 32-bit range error path in `rtc_hctosys' where no
      error code is set and consequently the successful preceding call result
      from `rtc_read_time' is propagated to `rtc_hctosys_ret'.  This in turn
      makes any subsequent call to `hctosys_show' incorrectly report in sysfs
      that the system time has been set from this RTC while it has not.
      Set the error to ERANGE then if we can't express the result due to an
      Signed-off-by: default avatarMaciej W. Rozycki <macro@linux-mips.org>
      Fixes: b3a5ac42ab18 ("rtc: hctosys: Ensure system time doesn't overflow time_t")
      Cc: stable@vger.kernel.org # 4.17+
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@bootlin.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Scott Mayhew's avatar
      nfsd: COPY and CLONE operations require the saved filehandle to be set · 7291d95a
      Scott Mayhew authored
      commit 01310bb7c9c98752cc763b36532fab028e0f8f81 upstream.
      Make sure we have a saved filehandle, otherwise we'll oops with a null
      pointer dereference in nfs4_preprocess_stateid_op().
      Signed-off-by: default avatarScott Mayhew <smayhew@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Frank Sorenson's avatar
      sunrpc: correct the computation for page_ptr when truncating · 4d9d47c7
      Frank Sorenson authored
      commit 5d7a5bcb67c70cbc904057ef52d3fcfeb24420bb upstream.
      When truncating the encode buffer, the page_ptr is getting
      advanced, causing the next page to be skipped while encoding.
      The page is still included in the response, so the response
      contains a page of bogus data.
      We need to adjust the page_ptr backwards to ensure we encode
      the next page into the correct place.
      We saw this triggered when concurrent directory modifications caused
      nfsd4_encode_direct_fattr() to return nfserr_noent, and the resulting
      call to xdr_truncate_encode() corrupted the READDIR reply.
      Signed-off-by: default avatarFrank Sorenson <sorenson@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Eric W. Biederman's avatar
      mount: Prevent MNT_DETACH from disconnecting locked mounts · 03004f41
      Eric W. Biederman authored
      commit 9c8e0a1b683525464a2abe9fb4b54404a50ed2b4 upstream.
      Timothy Baldwin <timbaldwin@fastmail.co.uk> wrote:
      > As per mount_namespaces(7) unprivileged users should not be able to look under mount points:
      >   Mounts that come as a single unit from more privileged mount are locked
      >   together and may not be separated in a less privileged mount namespace.
      > However they can:
      > 1. Create a mount namespace.
      > 2. In the mount namespace open a file descriptor to the parent of a mount point.
      > 3. Destroy the mount namespace.
      > 4. Use the file descriptor to look under the mount point.
      > I have reproduced this with Linux 4.16.18 and Linux 4.18-rc8.
      > The setup:
      > $ sudo sysctl kernel.unprivileged_userns_clone=1
      > kernel.unprivileged_userns_clone = 1
      > $ mkdir -p A/B/Secret
      > $ sudo mount -t tmpfs hide A/B
      > "Secret" is indeed hidden as expected:
      > $ ls -lR A
      > A:
      > total 0
      > drwxrwxrwt 2 root root 40 Feb 12 21:08 B
      > A/B:
      > total 0
      > The attack revealing "Secret":
      > $ unshare -Umr sh -c "exec unshare -m ls -lR /proc/self/fd/4/ 4<A"
      > /proc/self/fd/4/:
      > total 0
      > drwxr-xr-x 3 root root 60 Feb 12 21:08 B
      > /proc/self/fd/4/B:
      > total 0
      > drwxr-xr-x 2 root root 40 Feb 12 21:08 Secret
      > /proc/self/fd/4/B/Secret:
      > total 0
      I tracked this down to put_mnt_ns running passing UMOUNT_SYNC and
      disconnecting all of the mounts in a mount namespace.  Fix this by
      factoring drop_mounts out of drop_collected_mounts and passing
      0 instead of UMOUNT_SYNC.
      There are two possible behavior differences that result from this.
      - No longer setting UMOUNT_SYNC will no longer set MNT_SYNC_UMOUNT on
        the vfsmounts being unmounted.  This effects the lazy rcu walk by
        kicking the walk out of rcu mode and forcing it to be a non-lazy
      - No longer disconnecting locked mounts will keep some mounts around
        longer as they stay because the are locked to other mounts.
      There are only two users of drop_collected mounts: audit_tree.c and
      In audit_tree.c the mounts are private and there are no rcu lazy walks
      only calls to iterate_mounts. So the changes should have no effect
      except for a small timing effect as the connected mounts are disconnected.
      In put_mnt_ns there may be references from process outside the mount
      namespace to the mounts.  So the mounts remaining connected will
      be the bug fix that is needed.  That rcu walks are allowed to continue
      appears not to be a problem especially as the rcu walk change was about
      an implementation detail not about semantics.
      Cc: stable@vger.kernel.org
      Fixes: 5ff9d8a6
       ("vfs: Lock in place mounts from more privileged users")
      Reported-by: default avatarTimothy Baldwin <timbaldwin@fastmail.co.uk>
      Tested-by: default avatarTimothy Baldwin <timbaldwin@fastmail.co.uk>
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Eric W. Biederman's avatar
      mount: Don't allow copying MNT_UNBINDABLE|MNT_LOCKED mounts · d7565180
      Eric W. Biederman authored
      commit df7342b240185d58d3d9665c0bbf0a0f5570ec29 upstream.
      Jonathan Calmels from NVIDIA reported that he's able to bypass the
      mount visibility security check in place in the Linux kernel by using
      a combination of the unbindable property along with the private mount
      propagation option to allow a unprivileged user to see a path which
      was purposefully hidden by the root user.
        # Hide a path to all users using a tmpfs
        root@castiana:~# mount -t tmpfs tmpfs /sys/devices/
        # As an unprivileged user, unshare user namespace and mount namespace
        stgraber@castiana:~$ unshare -U -m -r
        # Confirm the path is still not accessible
        root@castiana:~# ls /sys/devices/
        # Make /sys recursively unbindable and private
        root@castiana:~# mount --make-runbindable /sys
        root@castiana:~# mount --make-private /sys
        # Recursively bind-mount the rest of /sys over to /mnnt
        root@castiana:~# mount --rbind /sys/ /mnt
        # Access our hidden /sys/device as an unprivileged user
        root@castiana:~# ls /mnt/devices/
        breakpoint cpu cstate_core cstate_pkg i915 intel_pt isa kprobe
        LNXSYSTM:00 msr pci0000:00 platform pnp0 power software system
        tracepoint uncore_arb uncore_cbox_0 uncore_cbox_1 uprobe virtual
      Solve this by teaching copy_tree to fail if a mount turns out to be
      both unbindable and locked.
      Cc: stable@vger.kernel.org
      Fixes: 5ff9d8a6
       ("vfs: Lock in place mounts from more privileged users")
      Reported-by: default avatarJonathan Calmels <jcalmels@nvidia.com>
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Eric W. Biederman's avatar
      mount: Retest MNT_LOCKED in do_umount · fa14e9bd
      Eric W. Biederman authored
      commit 25d202ed820ee347edec0bf3bf553544556bf64b upstream.
      It was recently pointed out that the one instance of testing MNT_LOCKED
      outside of the namespace_sem is in ksys_umount.
      Fix that by adding a test inside of do_umount with namespace_sem and
      the mount_lock held.  As it helps to fail fails the existing test is
      maintained with an additional comment pointing out that it may be racy
      because the locks are not held.
      Cc: stable@vger.kernel.org
      Reported-by: default avatarAl Viro <viro@ZenIV.linux.org.uk>
      Fixes: 5ff9d8a6
       ("vfs: Lock in place mounts from more privileged users")
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Vasily Averin's avatar
      ext4: fix buffer leak in __ext4_read_dirblock() on error path · d450fcdb
      Vasily Averin authored
      commit de59fae0043f07de5d25e02ca360f7d57bfa5866 upstream.
      Fixes: dc6982ff
       ("ext4: refactor code to read directory blocks ...")
      Signed-off-by: default avatarVasily Averin <vvs@virtuozzo.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Cc: stable@kernel.org # 3.9
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Vasily Averin's avatar
      ext4: fix buffer leak in ext4_xattr_move_to_block() on error path · 82dfeb8d
      Vasily Averin authored
      commit 6bdc9977fcdedf47118d2caf7270a19f4b6d8a8f upstream.
      Fixes: 3f2571c1 ("ext4: factor out xattr moving")
      Fixes: 6dd4ee7c
       ("ext4: Expand extra_inodes space per ...")
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarVasily Averin <vvs@virtuozzo.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Cc: stable@kernel.org # 2.6.23
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Vasily Averin's avatar
      ext4: release bs.bh before re-using in ext4_xattr_block_find() · b66102a4
      Vasily Averin authored
      commit 45ae932d246f721e6584430017176cbcadfde610 upstream.
      bs.bh was taken in previous ext4_xattr_block_find() call,
      it should be released before re-using
      Fixes: 7e01c8e5
       ("ext3/4: fix uninitialized bs in ...")
      Signed-off-by: default avatarVasily Averin <vvs@virtuozzo.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Cc: stable@kernel.org # 2.6.26
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Vasily Averin's avatar
      ext4: fix possible leak of s_journal_flag_rwsem in error path · 6b436fb6
      Vasily Averin authored
      commit af18e35bfd01e6d65a5e3ef84ffe8b252d1628c5 upstream.
      Fixes: c8585c6f
       ("ext4: fix races between changing inode journal ...")
      Signed-off-by: default avatarVasily Averin <vvs@virtuozzo.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Cc: stable@kernel.org # 4.7
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Theodore Ts'o's avatar
      ext4: fix possible leak of sbi->s_group_desc_leak in error path · 8547ff5d
      Theodore Ts'o authored
      commit 9e463084cdb22e0b56b2dfbc50461020409a5fd3 upstream.
      Fixes: bfe0a5f47ada ("ext4: add more mount time checks of the superblock")
      Reported-by: default avatarVasily Averin <vvs@virtuozzo.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Cc: stable@kernel.org # 4.18
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Theodore Ts'o's avatar
      ext4: avoid possible double brelse() in add_new_gdb() on error path · 11a2eb02
      Theodore Ts'o authored
      commit 4f32c38b4662312dd3c5f113d8bdd459887fb773 upstream.
      Fixes: b4097142
       ("ext4: add error checking to calls to ...")
      Reported-by: default avatarVasily Averin <vvs@virtuozzo.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Cc: stable@kernel.org # 2.6.38
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Vasily Averin's avatar
      ext4: fix missing cleanup if ext4_alloc_flex_bg_array() fails while resizing · 142e0172
      Vasily Averin authored
      commit f348e2241fb73515d65b5d77dd9c174128a7fbf2 upstream.
      Fixes: 117fff10
       ("ext4: grow the s_flex_groups array as needed ...")
      Signed-off-by: default avatarVasily Averin <vvs@virtuozzo.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Cc: stable@kernel.org # 3.7
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Vasily Averin's avatar
      ext4: avoid buffer leak in ext4_orphan_add() after prior errors · f30a52c9
      Vasily Averin authored
      commit feaf264ce7f8d54582e2f66eb82dd9dd124c94f3 upstream.
      Fixes: d745a8c2 ("ext4: reduce contention on s_orphan_lock")
      Fixes: 6e3617e5
       ("ext4: Handle non empty on-disk orphan link")
      Cc: Dmitry Monakhov <dmonakhov@gmail.com>
      Signed-off-by: default avatarVasily Averin <vvs@virtuozzo.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Cc: stable@kernel.org # 2.6.34
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Vasily Averin's avatar
      ext4: fix possible inode leak in the retry loop of ext4_resize_fs() · 8a6a7dd7
      Vasily Averin authored
      commit db6aee62406d9fbb53315fcddd81f1dc271d49fa upstream.
      Fixes: 1c6bd717
       ("ext4: convert file system to meta_bg if needed ...")
      Signed-off-by: default avatarVasily Averin <vvs@virtuozzo.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Cc: stable@kernel.org # 3.7
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Vasily Averin's avatar
      ext4: avoid potential extra brelse in setup_new_flex_group_blocks() · 05821678
      Vasily Averin authored
      commit 9e4028935cca3f9ef9b6a90df9da6f1f94853536 upstream.
      Currently bh is set to NULL only during first iteration of for cycle,
      then this pointer is not cleared after end of using.
      Therefore rollback after errors can lead to extra brelse(bh) call,
      decrements bh counter and later trigger an unexpected warning in __brelse()
      Patch moves brelse() calls in body of cycle to exclude requirement of
      brelse() call in rollback.
      Fixes: 33afdcc5
       ("ext4: add a function which sets up group blocks ...")
      Signed-off-by: default avatarVasily Averin <vvs@virtuozzo.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Cc: stable@kernel.org # 3.3+
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Vasily Averin's avatar
      ext4: add missing brelse() add_new_gdb_meta_bg()'s error path · c484fd25
      Vasily Averin authored
      commit 61a9c11e5e7a0dab5381afa5d9d4dd5ebf18f7a0 upstream.
      Fixes: 01f795f9
       ("ext4: add online resizing support for meta_bg ...")
      Signed-off-by: default avatarVasily Averin <vvs@virtuozzo.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Cc: stable@kernel.org # 3.7
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Vasily Averin's avatar
      ext4: add missing brelse() in set_flexbg_block_bitmap()'s error path · 771e8c73
      Vasily Averin authored
      commit cea5794122125bf67559906a0762186cf417099c upstream.
      Fixes: 33afdcc5
       ("ext4: add a function which sets up group blocks ...")
      Cc: stable@kernel.org # 3.3
      Signed-off-by: default avatarVasily Averin <vvs@virtuozzo.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Vasily Averin's avatar
      ext4: add missing brelse() update_backups()'s error path · b1341999
      Vasily Averin authored
      commit ea0abbb648452cdb6e1734b702b6330a7448fcf8 upstream.
      Fixes: ac27a0ec
       ("ext4: initial copy of files from ext3")
      Signed-off-by: default avatarVasily Averin <vvs@virtuozzo.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Cc: stable@kernel.org # 2.6.19
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Michael Kelley's avatar
      clockevents/drivers/i8253: Add support for PIT shutdown quirk · f6939dbd
      Michael Kelley authored
      commit 35b69a420bfb56b7b74cb635ea903db05e357bec upstream.
      Add support for platforms where pit_shutdown() doesn't work because of a
      quirk in the PIT emulation. On these platforms setting the counter register
      to zero causes the PIT to start running again, negating the shutdown.
      Provide a global variable that controls whether the counter register is
      zero'ed, which platform specific code can override.
      Signed-off-by: default avatarMichael Kelley <mikelley@microsoft.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>
      Cc: "devel@linuxdriverproject.org" <devel@linuxdriverproject.org>
      Cc: "daniel.lezcano@linaro.org" <daniel.lezcano@linaro.org>
      Cc: "virtualization@lists.linux-foundation.org" <virtualization@lists.linux-foundation.org>
      Cc: "jgross@suse.com" <jgross@suse.com>
      Cc: "akataria@vmware.com" <akataria@vmware.com>
      Cc: "olaf@aepfle.de" <olaf@aepfle.de>
      Cc: "apw@canonical.com" <apw@canonical.com>
      Cc: vkuznets <vkuznets@redhat.com>
      Cc: "jasowang@redhat.com" <jasowang@redhat.com>
      Cc: "marcelo.cerri@canonical.com" <marcelo.cerri@canonical.com>
      Cc: KY Srinivasan <kys@microsoft.com>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/1541303219-11142-2-git-send-email-mikelley@microsoft.com
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Filipe Manana's avatar
      Btrfs: fix data corruption due to cloning of eof block · 800d8112
      Filipe Manana authored
      commit ac765f83f1397646c11092a032d4f62c3d478b81 upstream.
      We currently allow cloning a range from a file which includes the last
      block of the file even if the file's size is not aligned to the block
      size. This is fine and useful when the destination file has the same size,
      but when it does not and the range ends somewhere in the middle of the
      destination file, it leads to corruption because the bytes between the EOF
      and the end of the block have undefined data (when there is support for
      discard/trimming they have a value of 0x00).
       $ mkfs.btrfs -f /dev/sdb
       $ mount /dev/sdb /mnt
       $ export foo_size=$((256 * 1024 + 100))
       $ xfs_io -f -c "pwrite -S 0x3c 0 $foo_size" /mnt/foo
       $ xfs_io -f -c "pwrite -S 0xb5 0 1M" /mnt/bar
       $ xfs_io -c "reflink /mnt/foo 0 512K $foo_size" /mnt/bar
       $ od -A d -t x1 /mnt/bar
       0000000 b5 b5 b5 b5 b5 b5 b5 b5 b5 b5 b5 b5 b5 b5 b5 b5
       0524288 3c 3c 3c 3c 3c 3c 3c 3c 3c 3c 3c 3c 3c 3c 3c 3c
       0786528 3c 3c 3c 3c 00 00 00 00 00 00 00 00 00 00 00 00
       0786544 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
       0790528 b5 b5 b5 b5 b5 b5 b5 b5 b5 b5 b5 b5 b5 b5 b5 b5
      The bytes in the range from 786532 (512Kb + 256Kb + 100 bytes) to 790527
      (512Kb + 256Kb + 4Kb - 1) got corrupted, having now a value of 0x00 instead
      of 0xb5.
      This is similar to the problem we had for deduplication that got recently
      fixed by commit de02b9f6bb65 ("Btrfs: fix data corruption when
      deduplicating between different files").
      Fix this by not allowing such operations to be performed and return the
      errno -EINVAL to user space. This is what XFS is doing as well at the VFS
      level. This change however now makes us return -EINVAL instead of
      -EOPNOTSUPP for cases where the source range maps to an inline extent and
      the destination range's end is smaller then the destination file's size,
      since the detection of inline extents is done during the actual process of
      dropping file extent items (at __btrfs_drop_extents()). Returning the
      -EINVAL error is done early on and solely based on the input parameters
      (offsets and length) and destination file's size. This makes us consistent
      with XFS and anyone else supporting cloning since this case is now checked
      at a higher level in the VFS and is where the -EINVAL will be returned
      from starting with kernel 4.20 (the VFS changed was introduced in 4.20-rc1
      by commit 07d19dc9fbe9 ("vfs: avoid problematic remapping requests into
      partial EOF block"). So this change is more geared towards stable kernels,
      as it's unlikely the new VFS checks get removed intentionally.
      A test case for fstests follows soon, as well as an update to filter
      existing tests that expect -EOPNOTSUPP to accept -EINVAL as well.
      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>
    • Robbie Ko's avatar
      Btrfs: fix cur_offset in the error case for nocow · 3fe6b9aa
      Robbie Ko authored
      commit 506481b20e818db40b6198815904ecd2d6daee64 upstream.
      When the cow_file_range fails, the related resources are unlocked
      according to the range [start..end), so the unlock cannot be repeated in
      In some cases (e.g. cur_offset <= end && cow_start != -1), cur_offset is
      not updated correctly, so move the cur_offset update before
        kernel BUG at mm/page-writeback.c:2663!
        Internal error: Oops - BUG: 0 [#1] SMP
        CPU: 3 PID: 31525 Comm: kworker/u8:7 Tainted: P O
        Hardware name: Realtek_RTD1296 (DT)
        Workqueue: writeback wb_workfn (flush-btrfs-1)
        task: ffffffc076db3380 ti: ffffffc02e9ac000 task.ti: ffffffc02e9ac000
        PC is at clear_page_dirty_for_io+0x1bc/0x1e8
        LR is at clear_page_dirty_for_io+0x14/0x1e8
        pc : [<ffffffc00033c91c>] lr : [<ffffffc00033c774>] pstate: 40000145
        sp : ffffffc02e9af4f0
        Process kworker/u8:7 (pid: 31525, stack limit = 0xffffffc02e9ac020)
        Call trace:
        [<ffffffc00033c91c>] clear_page_dirty_for_io+0x1bc/0x1e8
        [<ffffffbffc514674>] extent_clear_unlock_delalloc+0x1e4/0x210 [btrfs]
        [<ffffffbffc4fb168>] run_delalloc_nocow+0x3b8/0x948 [btrfs]
        [<ffffffbffc4fb948>] run_delalloc_range+0x250/0x3a8 [btrfs]
        [<ffffffbffc514c0c>] writepage_delalloc.isra.21+0xbc/0x1d8 [btrfs]
        [<ffffffbffc516048>] __extent_writepage+0xe8/0x248 [btrfs]
        [<ffffffbffc51630c>] extent_write_cache_pages.isra.17+0x164/0x378 [btrfs]
        [<ffffffbffc5185a8>] extent_writepages+0x48/0x68 [btrfs]
        [<ffffffbffc4f5828>] btrfs_writepages+0x20/0x30 [btrfs]
        [<ffffffc00033d758>] do_writepages+0x30/0x88
        [<ffffffc0003ba0f4>] __writeback_single_inode+0x34/0x198
        [<ffffffc0003ba6c4>] writeback_sb_inodes+0x184/0x3c0
        [<ffffffc0003ba96c>] __writeback_inodes_wb+0x6c/0xc0
        [<ffffffc0003bac20>] wb_writeback+0x1b8/0x1c0
        [<ffffffc0003bb0f0>] wb_workfn+0x150/0x250
        [<ffffffc0002b0014>] process_one_work+0x1dc/0x388
        [<ffffffc0002b02f0>] worker_thread+0x130/0x500
        [<ffffffc0002b6344>] kthread+0x10c/0x110
        [<ffffffc000284590>] ret_from_fork+0x10/0x40
        Code: d503201f a9025bb5 a90363b7 f90023b9 (d4210000)
      CC: stable@vger.kernel.org # 4.4+
      Reviewed-by: default avatarFilipe Manana <fdmanana@suse.com>
      Signed-off-by: default avatarRobbie Ko <robbieko@synology.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • H. Peter Anvin (Intel)'s avatar
      arch/alpha, termios: implement BOTHER, IBSHIFT and termios2 · 53111ab2
      H. Peter Anvin (Intel) authored
      commit d0ffb805b729322626639336986bc83fc2e60871 upstream.
      Alpha has had c_ispeed and c_ospeed, but still set speeds in c_cflags
      using arbitrary flags. Because BOTHER is not defined, the general
      Linux code doesn't allow setting arbitrary baud rates, and because
      CBAUDEX == 0, we can have an array overrun of the baud_rate[] table in
      drivers/tty/tty_baudrate.c if (c_cflags & CBAUD) == 037.
      Resolve both problems by #defining BOTHER to 037 on Alpha.
      However, userspace still needs to know if setting BOTHER is actually
      safe given legacy kernels (does anyone actually care about that on
      Alpha anymore?), so enable the TCGETS2/TCSETS*2 ioctls on Alpha, even
      though they use the same structure. Define struct termios2 just for
      compatibility; it is the exact same structure as struct termios. In a
      future patchset, this will be cleaned up so the uapi headers are
      usable from libc.
      Signed-off-by: default avatarH. Peter Anvin (Intel) <hpa@zytor.com>
      Cc: Jiri Slaby <jslaby@suse.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Matt Turner <mattst88@gmail.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Kate Stewart <kstewart@linuxfoundation.org>
      Cc: Philippe Ombredanne <pombredanne@nexb.com>
      Cc: Eugene Syromiatnikov <esyr@redhat.com>
      Cc: <linux-alpha@vger.kernel.org>
      Cc: <linux-serial@vger.kernel.org>
      Cc: Johan Hovold <johan@kernel.org>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • H. Peter Anvin's avatar
      termios, tty/tty_baudrate.c: fix buffer overrun · 4d18bea3
      H. Peter Anvin authored
      commit 991a25194097006ec1e0d2e0814ff920e59e3465 upstream.
      On architectures with CBAUDEX == 0 (Alpha and PowerPC), the code in tty_baudrate.c does
      not do any limit checking on the tty_baudrate[] array, and in fact a
      buffer overrun is possible on both architectures. Add a limit check to
      prevent that situation.
      This will be followed by a much bigger cleanup/simplification patch.
      Signed-off-by: default avatarH. Peter Anvin (Intel) <hpa@zytor.com>
      Requested-by: default avatarCc: Johan Hovold <johan@kernel.org>
      Cc: Jiri Slaby <jslaby@suse.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Matt Turner <mattst88@gmail.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Kate Stewart <kstewart@linuxfoundation.org>
      Cc: Philippe Ombredanne <pombredanne@nexb.com>
      Cc: Eugene Syromiatnikov <esyr@redhat.com>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • John Garry's avatar
      of, numa: Validate some distance map rules · af86cb90
      John Garry authored
      commit 89c38422e072bb453e3045b8f1b962a344c3edea upstream.
      Currently the NUMA distance map parsing does not validate the distance
      table for the distance-matrix rules 1-2 in [1].
      However the arch NUMA code may enforce some of these rules, but not all.
      Such is the case for the arm64 port, which does not enforce the rule that
      the distance between separates nodes cannot equal LOCAL_DISTANCE.
      The patch adds the following rules validation:
      - distance of node to self equals LOCAL_DISTANCE
      - distance of separate nodes > LOCAL_DISTANCE
      This change avoids a yet-unresolved crash reported in [2].
      A note on dealing with symmetrical distances between nodes:
      Validating symmetrical distances between nodes is difficult. If it were
      mandated in the bindings that every distance must be recorded in the
      table, then it would be easy. However, it isn't.
      In addition to this, it is also possible to record [b, a] distance only
      (and not [a, b]). So, when processing the table for [b, a], we cannot
      assert that current distance of [a, b] != [b, a] as invalid, as [a, b]
      distance may not be present in the table and current distance would be
      default at REMOTE_DISTANCE.
      As such, we maintain the policy that we overwrite distance [a, b] = [b, a]
      for b > a. This policy is different to kernel ACPI SLIT validation, which
      allows non-symmetrical distances (ACPI spec SLIT rules allow it). However,
      the distance debug message is dropped as it may be misleading (for a distance
      which is later overwritten).
      Some final notes on semantics:
      - It is implied that it is the responsibility of the arch NUMA code to
        reset the NUMA distance map for an error in distance map parsing.
      - It is the responsibility of the FW NUMA topology parsing (whether OF or
        ACPI) to enforce NUMA distance rules, and not arch NUMA code.
      [1] Documents/devicetree/bindings/numa.txt
      [2] https://www.spinics.net/lists/arm-kernel/msg683304.html
      Cc: stable@vger.kernel.org # 4.7
      Signed-off-by: default avatarJohn Garry <john.garry@huawei.com>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Arnd Bergmann's avatar
      mtd: docg3: don't set conflicting BCH_CONST_PARAMS option · d29a7b6f
      Arnd Bergmann authored
      commit be2e1c9dcf76886a83fb1c433a316e26d4ca2550 upstream.
      I noticed during the creation of another bugfix that the BCH_CONST_PARAMS
      option that is set by DOCG3 breaks setting variable parameters for any
      other users of the BCH library code.
      The only other user we have today is the MTD_NAND software BCH
      implementation (most flash controllers use hardware BCH these days
      and are not affected). I considered removing BCH_CONST_PARAMS entirely
      because of the inherent conflict, but according to the description in
      lib/bch.c there is a significant performance benefit in keeping it.
      To avoid the immediate problem of the conflict between MTD_NAND_BCH
      and DOCG3, this only sets the constant parameters if MTD_NAND_BCH
      is disabled, which should fix the problem for all cases that
      are affected. This should also work for all stable kernels.
      Note that there is only one machine that actually seems to use the
      DOCG3 driver (arch/arm/mach-pxa/mioa701.c), so most users should have
      the driver disabled, but it almost certainly shows up if we wanted
      to test random kernels on machines that use software BCH in MTD.
      Fixes: d13d19ec
       ("mtd: docg3: add ECC correction code")
      Cc: stable@vger.kernel.org
      Cc: Robert Jarzmik <robert.jarzmik@free.fr>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@bootlin.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Vasily Khoruzhick's avatar
      netfilter: conntrack: fix calculation of next bucket number in early_drop · 7e1e1956
      Vasily Khoruzhick authored
      commit f393808dc64149ccd0e5a8427505ba2974a59854 upstream.
      If there's no entry to drop in bucket that corresponds to the hash,
      early_drop() should look for it in other buckets. But since it increments
      hash instead of bucket number, it actually looks in the same bucket 8
      times: hsize is 16k by default (14 bits) and hash is 32-bit value, so
      reciprocal_scale(hash, hsize) returns the same value for hash..hash+7 in
      most cases.
      Fix it by increasing bucket number instead of hash and rename _hash
      to bucket to avoid future confusion.
      Fixes: 3e86638e
       ("netfilter: conntrack: consider ct netns in early_drop logic")
      Cc: <stable@vger.kernel.org> # v4.7+
      Signed-off-by: default avatarVasily Khoruzhick <vasilykh@arista.com>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Andrea Arcangeli's avatar
      mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings · 818e5846
      Andrea Arcangeli authored
      commit ac5b2c18911ffe95c08d69273917f90212cf5659 upstream.
      THP allocation might be really disruptive when allocated on NUMA system
      with the local node full or hard to reclaim.  Stefan has posted an
      allocation stall report on 4.12 based SLES kernel which suggests the
      same issue:
        kvm: page allocation stalls for 194572ms, order:9, mode:0x4740ca(__GFP_HIGHMEM|__GFP_IO|__GFP_FS|__GFP_COMP|__GFP_NOMEMALLOC|__GFP_HARDWALL|__GFP_THISNODE|__GFP_MOVABLE|__GFP_DIRECT_RECLAIM), nodemask=(null)
        kvm cpuset=/ mems_allowed=0-1
        CPU: 10 PID: 84752 Comm: kvm Tainted: G        W 4.12.0+98-ph <a href="/view.php?id=1" title="[geschlossen] Integration Ramdisk" class="resolved">0000001</a> SLE15 (unreleased)
        Hardware name: Supermicro SYS-1029P-WTRT/X11DDW-NT, BIOS 2.0 12/05/2017
        Call Trace:
        active_anon:126315487 inactive_anon:1612476 isolated_anon:5
         active_file:60183 inactive_file:245285 isolated_file:0
         unevictable:15657 dirty:286 writeback:1 unstable:0
         slab_reclaimable:75543 slab_unreclaimable:2509111
         mapped:81814 shmem:31764 pagetables:370616 bounce:0
         free:32294031 free_pcp:6233 free_cma:0
        Node 0 active_anon:254680388kB inactive_anon:1112760kB active_file:240648kB inactive_file:981168kB unevictable:13368kB isolated(anon):0kB isolated(file):0kB mapped:280240kB dirty:1144kB writeback:0kB shmem:95832kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 81225728kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no
        Node 1 active_anon:250583072kB inactive_anon:5337144kB active_file:84kB inactive_file:0kB unevictable:49260kB isolated(anon):20kB isolated(file):0kB mapped:47016kB dirty:0kB writeback:4kB shmem:31224kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 31897600kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no
      The defrag mode is "madvise" and from the above report it is clear that
      the THP has been allocated for MADV_HUGEPAGA vma.
      Andrea has identified that the main source of the problem is
      __GFP_THISNODE usage:
      : The problem is that direct compaction combined with the NUMA
      : __GFP_THISNODE logic in mempolicy.c is telling reclaim to swap very
      : hard the local node, instead of failing the allocation if there's no
      : THP available in the local node.
      : Such logic was ok until __GFP_THISNODE was added to the THP allocation
      : path even with MPOL_DEFAULT.
      : The idea behind the __GFP_THISNODE addition, is that it is better to
      : provide local memory in PAGE_SIZE units than to use remote NUMA THP
      : backed memory. That largely depends on the remote latency though, on
      : threadrippers for example the overhead is relatively low in my
      : experience.
      : The combination of __GFP_THISNODE and __GFP_DIRECT_RECLAIM results in
      : extremely slow qemu startup with vfio, if the VM is larger than the
      : size of one host NUMA node. This is because it will try very hard to
      : unsuccessfully swapout get_user_pages pinned pages as result of the
      : __GFP_THISNODE being set, instead of falling back to PAGE_SIZE
      : allocations and instead of trying to allocate THP on other nodes (it
      : would be even worse without vfio type1 GUP pins of course, except it'd
      : be swapping heavily instead).
      Fix this by removing __GFP_THISNODE for THP requests which are
      requesting the direct reclaim.  This effectivelly reverts 5265047a
      on the grounds that the zone/node reclaim was known to be disruptive due
      to premature reclaim when there was memory free.  While it made sense at
      the time for HPC workloads without NUMA awareness on rare machines, it
      was ultimately harmful in the majority of cases.  The existing behaviour
      is similar, if not as widespare as it applies to a corner case but
      crucially, it cannot be tuned around like zone_reclaim_mode can.  The
      default behaviour should always be to cause the least harm for the
      common case.
      If there are specialised use cases out there that want zone_reclaim_mode
      in specific cases, then it can be built on top.  Longterm we should
      consider a memory policy which allows for the node reclaim like behavior
      for the specific memory ranges which would allow a
      [1] http://lkml.kernel.org/r/20180820032204.9591-1-aarcange@redhat.com
      Mel said:
      : Both patches look correct to me but I'm responding to this one because
      : it's the fix.  The change makes sense and moves further away from the
      : severe stalling behaviour we used to see with both THP and zone reclaim
      : mode.
      : I put together a basic experiment with usemem configured to reference a
      : buffer multiple times that is 80% the size of main memory on a 2-socket
      : box with symmetric node sizes and defrag set to "always".  The defrag
      : setting is not the default but it would be functionally similar to
      : accessing a buffer with madvise(MADV_HUGEPAGE).  Usemem is configured to
      : reference the buffer multiple times and while it's not an interesting
      : workload, it would be expected to complete reasonably quickly as it fits
      : within memory.  The results were;
      : usemem
      :                                   vanilla           noreclaim-v1
      : Amean     Elapsd-1       42.78 (   0.00%)       26.87 (  37.18%)
      : Amean     Elapsd-3       27.55 (   0.00%)        7.44 (  73.00%)
      : Amean     Elapsd-4        5.72 (   0.00%)        5.69 (   0.45%)
      : This shows the elapsed time in seconds for 1 thread, 3 threads and 4
      : threads referencing buffers 80% the size of memory.  With the patches
      : applied, it's 37.18% faster for the single thread and 73% faster with two
      : threads.  Note that 4 threads showing little difference does not indicate
      : the problem is related to thread counts.  It's simply the case that 4
      : threads gets spread so their workload mostly fits in one node.
      : The overall view from /proc/vmstats is more startling
      :                          4.19.0-rc1  4.19.0-rc1
      :                             vanillanoreclaim-v1r1
      : Minor Faults               35593425      708164
      : Major Faults                 484088          36
      : Swap Ins                    3772837           0
      : Swap Outs                   3932295           0
      : Massive amounts of swap in/out without the patch
      : Direct pages scanned        6013214           0
      : Kswapd pages scanned              0           0
      : Kswapd pages reclaimed            0           0
      : Direct pages reclaimed      4033009           0
      : Lots of reclaim activity without the patch
      : Kswapd efficiency              100%        100%
      : Kswapd velocity               0.000       0.000
      : Direct efficiency               67%        100%
      : Direct velocity           11191.956       0.000
      : Mostly from direct reclaim context as you'd expect without the patch.
      : Page writes by reclaim  3932314.000       0.000
      : Page writes file                 19           0
      : Page writes anon            3932295           0
      : Page reclaim immediate        42336           0
      : Writes from reclaim context is never good but the patch eliminates it.
      : We should never have default behaviour to thrash the system for such a
      : basic workload.  If zone reclaim mode behaviour is ever desired but on a
      : single task instead of a global basis then the sensible option is to build
      : a mempolicy that enforces that behaviour.
      This was a severe regression compared to previous kernels that made
      important workloads unusable and it starts when __GFP_THISNODE was
      added to THP allocations under MADV_HUGEPAGE.  It is not a significant
      risk to go to the previous behavior before __GFP_THISNODE was added, it
      worked like that for years.
      This was simply an optimization to some lucky workloads that can fit in
      a single node, but it ended up breaking the VM for others that can't
      possibly fit in a single node, so going back is safe.
      [mhocko@suse.com: rewrote the changelog based on the one from Andrea]
      Link: http://lkml.kernel.org/r/20180925120326.24392-2-mhocko@kernel.org
      Fixes: 5265047a
       ("mm, thp: really limit transparent hugepage allocation to local node")
      Signed-off-by: default avatarAndrea Arcangeli <aarcange@redhat.com>
      Signed-off-by: default avatarMichal Hocko <mhocko@suse.com>
      Reported-by: default avatarStefan Priebe <s.priebe@profihost.ag>
      Debugged-by: default avatarAndrea Arcangeli <aarcange@redhat.com>
      Reported-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      Reviewed-by: default avatarMel Gorman <mgorman@techsingularity.net>
      Tested-by: default avatarMel Gorman <mgorman@techsingularity.net>
      Cc: Zi Yan <zi.yan@cs.rutgers.edu>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: David Rientjes <rientjes@google.com>
      Cc: "Kirill A. Shutemov" <kirill@shutemov.name>
      Cc: <stable@vger.kernel.org>	[4.1+]
      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>
    • Changwei Ge's avatar
      ocfs2: fix a misuse a of brelse after failing ocfs2_check_dir_entry · dd4c84ba
      Changwei Ge authored
      commit 29aa30167a0a2e6045a0d6d2e89d8168132333d5 upstream.
      Somehow, file system metadata was corrupted, which causes
      ocfs2_check_dir_entry() to fail in function ocfs2_dir_foreach_blk_el().
      According to the original design intention, if above happens we should
      skip the problematic block and continue to retrieve dir entry.  But
      there is obviouse misuse of brelse around related code.
      After failure of ocfs2_check_dir_entry(), current code just moves to
      next position and uses the problematic buffer head again and again
      during which the problematic buffer head is released for multiple times.
      I suppose, this a serious issue which is long-lived in ocfs2.  This may
      cause other file systems which is also used in a the same host insane.
      So we should also consider about bakcporting this patch into linux
      Link: http://lkml.kernel.org/r/HK2PR06MB045211675B43EED794E597B6D56E0@HK2PR06MB0452.apcprd06.prod.outlook.com
      Signed-off-by: default avatarChangwei Ge <ge.changwei@h3c.com>
      Suggested-by: default avatarChangkuo Shi <shi.changkuo@h3c.com>
      Reviewed-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Cc: Mark Fasheh <mark@fasheh.com>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Junxiao Bi <junxiao.bi@oracle.com>
      Cc: Joseph Qi <jiangqi903@gmail.com>
      Cc: <stable@vger.kernel.org>
      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>
    • Greg Edwards's avatar
      vhost/scsi: truncate T10 PI iov_iter to prot_bytes · acdc6a72
      Greg Edwards authored
      commit 4542d623c7134bc1738f8a68ccb6dd546f1c264f upstream.
      Commands with protection information included were not truncating the
      protection iov_iter to the number of protection bytes in the command.
      This resulted in vhost_scsi mis-calculating the size of the protection
      SGL in vhost_scsi_calc_sgls(), and including both the protection and
      data SG entries in the protection SGL.
      Fixes: 09b13fa8
       ("vhost/scsi: Add ANY_LAYOUT support in vhost_scsi_handle_vq")
      Signed-off-by: default avatarGreg Edwards <gedwards@ddn.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Fixes: 09b13fa8
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Gustavo A. R. Silva's avatar
      reset: hisilicon: fix potential NULL pointer dereference · e200279b
      Gustavo A. R. Silva authored
      commit e9a2310fb689151166df7fd9971093362d34bd79 upstream.
      There is a potential execution path in which function
      platform_get_resource() returns NULL. If this happens,
      we will end up having a NULL pointer dereference.
      Fix this by replacing devm_ioremap with devm_ioremap_resource,
      which has the NULL check and the memory region request.
      This code was detected with the help of Coccinelle.
      Cc: stable@vger.kernel.org
      Fixes: 97b7129c
       ("reset: hisilicon: change the definition of hisi_reset_init")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: default avatarStephen Boyd <sboyd@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Mikulas Patocka's avatar
      mach64: fix image corruption due to reading accelerator registers · 7ecf2487
      Mikulas Patocka authored
      commit c09bcc91bb94ed91f1391bffcbe294963d605732 upstream.
      Reading the registers without waiting for engine idle returns
      unpredictable values. These unpredictable values result in display
      corruption - if atyfb_imageblit reads the content of DP_PIX_WIDTH with the
      bit DP_HOST_TRIPLE_EN set (from previous invocation), the driver would
      never ever clear the bit, resulting in display corruption.
      We don't want to wait for idle because it would degrade performance, so
      this patch modifies the driver so that it never reads accelerator
      HOST_CNTL doesn't have to be read, we can just write it with
      HOST_BYTE_ALIGN because no other part of the driver cares if
      HOST_BYTE_ALIGN is set.
      DP_PIX_WIDTH is written in the functions atyfb_copyarea and atyfb_fillrect
      with the default value and in atyfb_imageblit with the value set according
      to the source image data.
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Reviewed-by: default avatarVille Syrjälä <syrjala@sci.fi>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Mikulas Patocka's avatar
      mach64: fix display corruption on big endian machines · 6bd9b552
      Mikulas Patocka authored
      commit 3c6c6a7878d00a3ac997a779c5b9861ff25dfcc8 upstream.
      The code for manual bit triple is not endian-clean. It builds the variable
      "hostdword" using byte accesses, therefore we must read the variable with
      The patch also enables (hardware or software) bit triple only if the image
      is monochrome (image->depth). If we want to blit full-color image, we
      shouldn't use the triple code.
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Reviewed-by: default avatarVille Syrjälä <syrjala@sci.fi>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Yan, Zheng's avatar
      Revert "ceph: fix dentry leak in splice_dentry()" · 43e38372
      Yan, Zheng authored
      commit efe328230dc01aa0b1269aad0b5fae73eea4677a upstream.
      This reverts commit 8b8f53af1ed9df88a4c0fbfdf3db58f62060edf3.
      splice_dentry() is used by three places. For two places, req->r_dentry
      is passed to splice_dentry(). In the case of error, req->r_dentry does
      not get updated. So splice_dentry() should not drop reference.
      Cc: stable@vger.kernel.org # 4.18+
      Signed-off-by: default avatar"Yan, Zheng" <zyan@redhat.com>
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Ilya Dryomov's avatar
      libceph: bump CEPH_MSG_MAX_DATA_LEN · 9efe0447
      Ilya Dryomov authored
      commit 94e6992bb560be8bffb47f287194adf070b57695 upstream.
      If the read is large enough, we end up spinning in the messenger:
        libceph: osd0 io error
        libceph: osd0 io error
        libceph: osd0 io error
      This is a receive side limit, so only reads were affected.
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Enric Balletbo i Serra's avatar
      clk: rockchip: Fix static checker warning in rockchip_ddrclk_get_parent call · ee27421c
      Enric Balletbo i Serra authored
      commit 665636b2940d0897c4130253467f5e8c42eea392 upstream.
      Fixes the signedness bug returning '(-22)' on the return type by removing the
      sanity checker in rockchip_ddrclk_get_parent(). The function should return
      and unsigned value only and it's safe to remove the sanity checker as the
      core functions that call get_parent like clk_core_get_parent_by_index already
      ensures the validity of the clk index returned (index >= core->num_parents).
      Fixes: a4f182bf
       ("clk: rockchip: add new clock-type for the ddrclk")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarEnric Balletbo i Serra <enric.balletbo@collabora.com>
      Reviewed-by: default avatarStephen Boyd <sboyd@kernel.org>
      Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>