commit 961f830af0658ef5ef8a7708786d634a6115f16b
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Aug 7 09:36:21 2020 +0200

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

commit aa0962310814356b10a973c578cfe595d89a3e39
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 df9a9ac7a4614afa59fae8f7ad56b93fbab45d46
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 e6b7c5f7a420578b1004dad4842b1210c580724e
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 6f697da3eb85610aae888623ca2885b347e86864
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 546271c2c8d3a4f2d5fd07d43faf49d0b4423dde
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 29204c846894d73108f87e78aea4757a8ec52c74
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>