commit 14b58326976de6ef3998eefec1dd7f8b38b97a75
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Aug 7 09:38:42 2020 +0200

    Linux 4.14.193
    
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e4efec8c28bce3be6078657f0846e59ccded593b
Author: Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Tue Oct 3 19:14:38 2017 +0100

    ARM: 8702/1: head-common.S: Clear lr before jumping to start_kernel()
    
    commit 59b6359dd92d18f5dc04b14a4c926fa08ab66f7c upstream.
    
    If CONFIG_DEBUG_LOCK_ALLOC=y, the kernel log is spammed with a few
    hundred identical messages:
    
        unwind: Unknown symbol address c0800300
        unwind: Index not found c0800300
    
    c0800300 is the return address from the last subroutine call (to
    __memzero()) in __mmap_switched().  Apparently having this address in
    the link register confuses the unwinder.
    
    To fix this, reset the link register to zero before jumping to
    start_kernel().
    
    Fixes: 9520b1a1b5f7a348 ("ARM: head-common.S: speed up startup code")
    Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Acked-by: Nicolas Pitre <nico@linaro.org>
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    
    Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>

commit baf191c492c6592430ce684fb3464120d47d11f9
Author: Jiang Ying <jiangying8582@126.com>
Date:   Wed Aug 5 15:57:21 2020 +0800

    ext4: fix direct I/O read error
    
    This patch is used to fix ext4 direct I/O read error when
    the read size is not aligned with block size.
    
    Then, I will use a test to explain the error.
    
    (1) Make a file that is not aligned with block size:
            $dd if=/dev/zero of=./test.jar bs=1000 count=3
    
    (2) I wrote a source file named "direct_io_read_file.c" as following:
    
            #include <stdio.h>
            #include <stdlib.h>
            #include <unistd.h>
            #include <sys/file.h>
            #include <sys/types.h>
            #include <sys/stat.h>
            #include <string.h>
            #define BUF_SIZE 1024
    
            int main()
            {
                    int fd;
                    int ret;
    
                    unsigned char *buf;
                    ret = posix_memalign((void **)&buf, 512, BUF_SIZE);
                    if (ret) {
                            perror("posix_memalign failed");
                            exit(1);
                    }
                    fd = open("./test.jar", O_RDONLY | O_DIRECT, 0755);
                    if (fd < 0){
                            perror("open ./test.jar failed");
                            exit(1);
                    }
    
                    do {
                            ret = read(fd, buf, BUF_SIZE);
                            printf("ret=%d\n",ret);
                            if (ret < 0) {
                                    perror("write test.jar failed");
                            }
                    } while (ret > 0);
    
                    free(buf);
                    close(fd);
            }
    
    (3) Compile the source file:
            $gcc direct_io_read_file.c -D_GNU_SOURCE
    
    (4) Run the test program:
            $./a.out
    
            The result is as following:
            ret=1024
            ret=1024
            ret=952
            ret=-1
            write test.jar failed: Invalid argument.
    
    I have tested this program on XFS filesystem, XFS does not have
    this problem, because XFS use iomap_dio_rw() to do direct I/O
    read. And the comparing between read offset and file size is done
    in iomap_dio_rw(), the code is as following:
    
            if (pos < size) {
                    retval = filemap_write_and_wait_range(mapping, pos,
                                    pos + iov_length(iov, nr_segs) - 1);
    
                    if (!retval) {
                            retval = mapping->a_ops->direct_IO(READ, iocb,
                                                    iov, pos, nr_segs);
                    }
                    ...
            }
    
    ...only when "pos < size", direct I/O can be done, or 0 will be return.
    
    I have tested the fix patch on Ext4, it is up to the mustard of
    EINVAL in man2(read) as following:
            #include <unistd.h>
            ssize_t read(int fd, void *buf, size_t count);
    
            EINVAL
                    fd is attached to an object which is unsuitable for reading;
                    or the file was opened with the O_DIRECT flag, and either the
                    address specified in buf, the value specified in count, or the
                    current file offset is not suitably aligned.
    
    So I think this patch can be applied to fix ext4 direct I/O error.
    
    However Ext4 introduces direct I/O read using iomap infrastructure
    on kernel 5.5, the patch is commit <b1b4705d54ab>
    ("ext4: introduce direct I/O read using iomap infrastructure"),
    then Ext4 will be the same as XFS, they all use iomap_dio_rw() to do direct
    I/O read. So this problem does not exist on kernel 5.5 for Ext4.
    
    >From above description, we can see this problem exists on all the kernel
    versions between kernel 3.14 and kernel 5.4. It will cause the Applications
    to fail to read. For example, when the search service downloads a new full
    index file, the search engine is loading the previous index file and is
    processing the search request, it can not use buffer io that may squeeze
    the previous index file in use from pagecache, so the serch service must
    use direct I/O read.
    
    Please apply this patch on these kernel versions, or please use the method
    on kernel 5.5 to fix this problem.
    
    Fixes: 9fe55eea7e4b ("Fix race when checking i_size on direct i/o read")
    Reviewed-by: Jan Kara <jack@suse.cz>
    Co-developed-by: Wang Long <wanglong19@meituan.com>
    Signed-off-by: Wang Long <wanglong19@meituan.com>
    Signed-off-by: Jiang Ying <jiangying8582@126.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 35cd3649ad750a1c9ff579d8ad59ad624419205f
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri Jul 31 07:51:14 2020 +0200

    random32: move the pseudo-random 32-bit definitions to prandom.h
    
    commit c0842fbc1b18c7a044e6ff3e8fa78bfa822c7d1a upstream.
    
    The addition of percpu.h to the list of includes in random.h revealed
    some circular dependencies on arm64 and possibly other platforms.  This
    include was added solely for the pseudo-random definitions, which have
    nothing to do with the rest of the definitions in this file but are
    still there for legacy reasons.
    
    This patch moves the pseudo-random parts to linux/prandom.h and the
    percpu.h include with it, which is now guarded by _LINUX_PRANDOM_H and
    protected against recursive inclusion.
    
    A further cleanup step would be to remove this from <linux/random.h>
    entirely, and make people who use the prandom infrastructure include
    just the new header file.  That's a bit of a churn patch, but grepping
    for "prandom_" and "next_pseudo_random32" "struct rnd_state" should
    catch most users.
    
    But it turns out that that nice cleanup step is fairly painful, because
    a _lot_ of code currently seems to depend on the implicit include of
    <linux/random.h>, which can currently come in a lot of ways, including
    such fairly core headfers as <linux/net.h>.
    
    So the "nice cleanup" part may or may never happen.
    
    Fixes: 1c9df907da83 ("random: fix circular include dependency on arm64 after addition of percpu.h")
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Acked-by: Willy Tarreau <w@1wt.eu>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8dacd74f7987c1e744e988cb12fd18ab1aa2d6e0
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Wed Jul 29 19:11:00 2020 -0700

    random32: remove net_rand_state from the latent entropy gcc plugin
    
    commit 83bdc7275e6206f560d247be856bceba3e1ed8f2 upstream.
    
    It turns out that the plugin right now ends up being really unhappy
    about the change from 'static' to 'extern' storage that happened in
    commit f227e3ec3b5c ("random32: update the net random state on interrupt
    and activity").
    
    This is probably a trivial fix for the latent_entropy plugin, but for
    now, just remove net_rand_state from the list of things the plugin
    worries about.
    
    Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Cc: Emese Revfy <re.emese@gmail.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Willy Tarreau <w@1wt.eu>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8de9a00bf997a62df8a2a1ba3d0d8eb73f55b463
Author: Willy Tarreau <w@1wt.eu>
Date:   Thu Jul 30 07:59:24 2020 +0200

    random: fix circular include dependency on arm64 after addition of percpu.h
    
    commit 1c9df907da83812e4f33b59d3d142c864d9da57f upstream.
    
    Daniel Díaz and Kees Cook independently reported that commit
    f227e3ec3b5c ("random32: update the net random state on interrupt and
    activity") broke arm64 due to a circular dependency on include files
    since the addition of percpu.h in random.h.
    
    The correct fix would definitely be to move all the prandom32 stuff out
    of random.h but for backporting, a smaller solution is preferred.
    
    This one replaces linux/percpu.h with asm/percpu.h, and this fixes the
    problem on x86_64, arm64, arm, and mips.  Note that moving percpu.h
    around didn't change anything and that removing it entirely broke
    differently.  When backporting, such options might still be considered
    if this patch fails to help.
    
    [ It turns out that an alternate fix seems to be to just remove the
      troublesome <asm/pointer_auth.h> remove from the arm64 <asm/smp.h>
      that causes the circular dependency.
    
      But we might as well do the whole belt-and-suspenders thing, and
      minimize inclusion in <linux/random.h> too. Either will fix the
      problem, and both are good changes.   - Linus ]
    
    Reported-by: Daniel Díaz <daniel.diaz@linaro.org>
    Reported-by: Kees Cook <keescook@chromium.org>
    Tested-by: Marc Zyngier <maz@kernel.org>
    Fixes: f227e3ec3b5c
    Cc: Stephen Rothwell <sfr@canb.auug.org.au>
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eec3b3c667ae875a3d88b7be8f659a1a076b0c3b
Author: Grygorii Strashko <grygorii.strashko@ti.com>
Date:   Thu Jul 30 22:05:01 2020 +0300

    ARM: percpu.h: fix build error
    
    commit aa54ea903abb02303bf55855fb51e3fcee135d70 upstream.
    
    Fix build error for the case:
      defined(CONFIG_SMP) && !defined(CONFIG_CPU_V6)
    
    config: keystone_defconfig
    
      CC      arch/arm/kernel/signal.o
      In file included from ../include/linux/random.h:14,
                        from ../arch/arm/kernel/signal.c:8:
      ../arch/arm/include/asm/percpu.h: In function ‘__my_cpu_offset’:
      ../arch/arm/include/asm/percpu.h:29:34: error: ‘current_stack_pointer’ undeclared (first use in this function); did you mean ‘user_stack_pointer’?
          : "Q" (*(const unsigned long *)current_stack_pointer));
                                         ^~~~~~~~~~~~~~~~~~~~~
                                         user_stack_pointer
    
    Fixes: f227e3ec3b5c ("random32: update the net random state on interrupt and activity")
    Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 583bcbc024f6bf8daa266f4f71b99e9d6e78c40b
Author: Willy Tarreau <w@1wt.eu>
Date:   Fri Jul 10 15:23:19 2020 +0200

    random32: update the net random state on interrupt and activity
    
    commit f227e3ec3b5cad859ad15666874405e8c1bbc1d4 upstream.
    
    This modifies the first 32 bits out of the 128 bits of a random CPU's
    net_rand_state on interrupt or CPU activity to complicate remote
    observations that could lead to guessing the network RNG's internal
    state.
    
    Note that depending on some network devices' interrupt rate moderation
    or binding, this re-seeding might happen on every packet or even almost
    never.
    
    In addition, with NOHZ some CPUs might not even get timer interrupts,
    leaving their local state rarely updated, while they are running
    networked processes making use of the random state.  For this reason, we
    also perform this update in update_process_times() in order to at least
    update the state when there is user or system activity, since it's the
    only case we care about.
    
    Reported-by: Amit Klein <aksecurity@gmail.com>
    Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Eric Dumazet <edumazet@google.com>
    Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2d6a7108ed74e0c857f78809d74511f52dbf9c85
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Aug 5 11:49:14 2020 +0200

    Revert "scsi: libsas: direct call probe and destruct"
    
    This reverts commit 3a156abd24346a3188eb7e88cf86386a409e0d02 which is
    commit 0558f33c06bb910e2879e355192227a8e8f0219d upstream.
    
    John writes:
            This patch was one of a series from Jason to fix this WARN issue, below:
    
            https://lore.kernel.org/linux-scsi/8f6e3763-2b04-23e8-f1ec-8ed3c58f55d3@huawei.com/
    
            I'm doubtful that it should be taken in isolation. Maybe 1 or 2 other
            patches are required.
    
            The WARN was really annoying, so we could spend a bit of time to test a
            backport of what is strictly required. Let us know.
    
    Cc: Jason Yan <yanaijie@huawei.com>
    CC: John Garry <john.garry@huawei.com>
    CC: Johannes Thumshirn <jthumshirn@suse.de>
    CC: Ewan Milne <emilne@redhat.com>
    CC: Christoph Hellwig <hch@lst.de>
    CC: Tomas Henzl <thenzl@redhat.com>
    CC: Dan Williams <dan.j.williams@intel.com>
    Cc: Hannes Reinecke <hare@suse.com>
    Cc: Martin K. Petersen <martin.petersen@oracle.com>
    Cc: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>