1. 11 Aug, 2020 34 commits
  2. 07 Aug, 2020 6 commits
    • Greg Kroah-Hartman's avatar
      961f830a
    • Jiang Ying's avatar
      ext4: fix direct I/O read error · aa096231
      Jiang Ying authored
      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 <b1b4705d>
      ("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: 9fe55eea ("Fix race when checking i_size on direct i/o read")
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Co-developed-by: default avatarWang Long <wanglong19@meituan.com>
      Signed-off-by: default avatarWang Long <wanglong19@meituan.com>
      Signed-off-by: default avatarJiang Ying <jiangying8582@126.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      aa096231
    • Linus Torvalds's avatar
      random32: move the pseudo-random 32-bit definitions to prandom.h · df9a9ac7
      Linus Torvalds authored
      commit c0842fbc 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: 1c9df907 ("random: fix circular include dependency on arm64 after addition of percpu.h")
      Tested-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Acked-by: default avatarWilly Tarreau <w@1wt.eu>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      df9a9ac7
    • Linus Torvalds's avatar
      random32: remove net_rand_state from the latent entropy gcc plugin · e6b7c5f7
      Linus Torvalds authored
      commit 83bdc727 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 f227e3ec ("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: default avatarStephen 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: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e6b7c5f7
    • Willy Tarreau's avatar
      random: fix circular include dependency on arm64 after addition of percpu.h · 6f697da3
      Willy Tarreau authored
      commit 1c9df907 upstream.
      
      Daniel Díaz and Kees Cook independently reported that commit
      f227e3ec ("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: default avatarDaniel Díaz <daniel.diaz@linaro.org>
      Reported-by: default avatarKees Cook <keescook@chromium.org>
      Tested-by: default avatarMarc Zyngier <maz@kernel.org>
      Fixes: f227e3ec
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6f697da3
    • Grygorii Strashko's avatar
      ARM: percpu.h: fix build error · 546271c2
      Grygorii Strashko authored
      commit aa54ea90 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: f227e3ec ("random32: update the net random state on interrupt and activity")
      Signed-off-by: default avatarGrygorii Strashko <grygorii.strashko@ti.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      546271c2