5.4-stable patches

added patches:
	ext4-fix-ext4_max_logical_block-macro.patch
	x86-fpu-make-init_fpstate-correct-with-optimized-xsave.patch

diff --git a/queue-5.4/ext4-fix-ext4_max_logical_block-macro.patch b/queue-5.4/ext4-fix-ext4_max_logical_block-macro.patch
new file mode 100644 (file)
index 0000000..8ad6644
--- /dev/null
+++ b/queue-5.4/ext4-fix-ext4_max_logical_block-macro.patch
@@ -0,0 +1,45 @@
+From 175efa81feb8405676e0136d97b10380179c92e0 Mon Sep 17 00:00:00 2001
+From: Ritesh Harjani <riteshh@linux.ibm.com>
+Date: Tue, 5 May 2020 17:43:14 +0200
+Subject: ext4: fix EXT4_MAX_LOGICAL_BLOCK macro
+
+From: Ritesh Harjani <riteshh@linux.ibm.com>
+
+commit 175efa81feb8405676e0136d97b10380179c92e0 upstream.
+
+ext4 supports max number of logical blocks in a file to be 0xffffffff.
+(This is since ext4_extent's ee_block is __le32).
+This means that EXT4_MAX_LOGICAL_BLOCK should be 0xfffffffe (starting
+from 0 logical offset). This patch fixes this.
+
+The issue was seen when ext4 moved to iomap_fiemap API and when
+overlayfs was mounted on top of ext4. Since overlayfs was missing
+filemap_check_ranges(), so it could pass a arbitrary huge length which
+lead to overflow of map.m_len logic.
+
+This patch fixes that.
+
+Fixes: d3b6f23f7167 ("ext4: move ext4_fiemap to use iomap framework")
+Reported-by: syzbot+77fa5bdb65cc39711820@syzkaller.appspotmail.com
+Signed-off-by: Ritesh Harjani <riteshh@linux.ibm.com>
+Reviewed-by: Jan Kara <jack@suse.cz>
+Signed-off-by: Christoph Hellwig <hch@lst.de>
+Link: https://lore.kernel.org/r/20200505154324.3226743-2-hch@lst.de
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: George Kennedy <george.kennedy@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ext4/ext4.h |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/ext4/ext4.h
++++ b/fs/ext4/ext4.h
+@@ -718,7 +718,7 @@ enum {
+ #define EXT4_MAX_BLOCK_FILE_PHYS      0xFFFFFFFF
+ 
+ /* Max logical block we can support */
+-#define EXT4_MAX_LOGICAL_BLOCK                0xFFFFFFFF
++#define EXT4_MAX_LOGICAL_BLOCK                0xFFFFFFFE
+ 
+ /*
+  * Structure of an inode on the disk

diff --git a/queue-5.4/series b/queue-5.4/series
new file mode 100644 (file)
index 0000000..d7bf6e2
--- /dev/null
+++ b/queue-5.4/series
@@ -0,0 +1,2 @@
+ext4-fix-ext4_max_logical_block-macro.patch
+x86-fpu-make-init_fpstate-correct-with-optimized-xsave.patch

diff --git a/queue-5.4/x86-fpu-make-init_fpstate-correct-with-optimized-xsave.patch b/queue-5.4/x86-fpu-make-init_fpstate-correct-with-optimized-xsave.patch
new file mode 100644 (file)
index 0000000..9785104
--- /dev/null
+++ b/queue-5.4/x86-fpu-make-init_fpstate-correct-with-optimized-xsave.patch
@@ -0,0 +1,163 @@
+From f9dfb5e390fab2df9f7944bb91e7705aba14cd26 Mon Sep 17 00:00:00 2001
+From: Thomas Gleixner <tglx@linutronix.de>
+Date: Fri, 18 Jun 2021 16:18:25 +0200
+Subject: x86/fpu: Make init_fpstate correct with optimized XSAVE
+
+From: Thomas Gleixner <tglx@linutronix.de>
+
+commit f9dfb5e390fab2df9f7944bb91e7705aba14cd26 upstream.
+
+The XSAVE init code initializes all enabled and supported components with
+XRSTOR(S) to init state. Then it XSAVEs the state of the components back
+into init_fpstate which is used in several places to fill in the init state
+of components.
+
+This works correctly with XSAVE, but not with XSAVEOPT and XSAVES because
+those use the init optimization and skip writing state of components which
+are in init state. So init_fpstate.xsave still contains all zeroes after
+this operation.
+
+There are two ways to solve that:
+
+   1) Use XSAVE unconditionally, but that requires to reshuffle the buffer when
+      XSAVES is enabled because XSAVES uses compacted format.
+
+   2) Save the components which are known to have a non-zero init state by other
+      means.
+
+Looking deeper, #2 is the right thing to do because all components the
+kernel supports have all-zeroes init state except the legacy features (FP,
+SSE). Those cannot be hard coded because the states are not identical on all
+CPUs, but they can be saved with FXSAVE which avoids all conditionals.
+
+Use FXSAVE to save the legacy FP/SSE components in init_fpstate along with
+a BUILD_BUG_ON() which reminds developers to validate that a newly added
+component has all zeroes init state. As a bonus remove the now unused
+copy_xregs_to_kernel_booting() crutch.
+
+The XSAVE and reshuffle method can still be implemented in the unlikely
+case that components are added which have a non-zero init state and no
+other means to save them. For now, FXSAVE is just simple and good enough.
+
+  [ bp: Fix a typo or two in the text. ]
+
+Fixes: 6bad06b76892 ("x86, xsave: Use xsaveopt in context-switch path when supported")
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Reviewed-by: Borislav Petkov <bp@suse.de>
+Cc: stable@vger.kernel.org
+Link: https://lkml.kernel.org/r/20210618143444.587311343@linutronix.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/include/asm/fpu/internal.h |   30 +++++++---------------------
+ arch/x86/kernel/fpu/xstate.c        |   38 +++++++++++++++++++++++++++++++++---
+ 2 files changed, 43 insertions(+), 25 deletions(-)
+
+--- a/arch/x86/include/asm/fpu/internal.h
++++ b/arch/x86/include/asm/fpu/internal.h
+@@ -204,6 +204,14 @@ static inline void copy_fxregs_to_kernel
+               asm volatile("fxsaveq %[fx]" : [fx] "=m" (fpu->state.fxsave));
+ }
+ 
++static inline void fxsave(struct fxregs_state *fx)
++{
++      if (IS_ENABLED(CONFIG_X86_32))
++              asm volatile( "fxsave %[fx]" : [fx] "=m" (*fx));
++      else
++              asm volatile("fxsaveq %[fx]" : [fx] "=m" (*fx));
++}
++
+ /* These macros all use (%edi)/(%rdi) as the single memory argument. */
+ #define XSAVE         ".byte " REX_PREFIX "0x0f,0xae,0x27"
+ #define XSAVEOPT      ".byte " REX_PREFIX "0x0f,0xae,0x37"
+@@ -274,28 +282,6 @@ static inline void copy_fxregs_to_kernel
+ 
+ /*
+  * This function is called only during boot time when x86 caps are not set
+- * up and alternative can not be used yet.
+- */
+-static inline void copy_xregs_to_kernel_booting(struct xregs_state *xstate)
+-{
+-      u64 mask = -1;
+-      u32 lmask = mask;
+-      u32 hmask = mask >> 32;
+-      int err;
+-
+-      WARN_ON(system_state != SYSTEM_BOOTING);
+-
+-      if (boot_cpu_has(X86_FEATURE_XSAVES))
+-              XSTATE_OP(XSAVES, xstate, lmask, hmask, err);
+-      else
+-              XSTATE_OP(XSAVE, xstate, lmask, hmask, err);
+-
+-      /* We should never fault when copying to a kernel buffer: */
+-      WARN_ON_FPU(err);
+-}
+-
+-/*
+- * This function is called only during boot time when x86 caps are not set
+  * up and alternative can not be used yet.
+  */
+ static inline void copy_kernel_to_xregs_booting(struct xregs_state *xstate)
+--- a/arch/x86/kernel/fpu/xstate.c
++++ b/arch/x86/kernel/fpu/xstate.c
+@@ -399,12 +399,32 @@ static void __init print_xstate_offset_s
+ }
+ 
+ /*
++ * All supported features have either init state all zeros or are
++ * handled in setup_init_fpu() individually. This is an explicit
++ * feature list and does not use XFEATURE_MASK*SUPPORTED to catch
++ * newly added supported features at build time and make people
++ * actually look at the init state for the new feature.
++ */
++#define XFEATURES_INIT_FPSTATE_HANDLED                \
++      (XFEATURE_MASK_FP |                     \
++       XFEATURE_MASK_SSE |                    \
++       XFEATURE_MASK_YMM |                    \
++       XFEATURE_MASK_OPMASK |                 \
++       XFEATURE_MASK_ZMM_Hi256 |              \
++       XFEATURE_MASK_Hi16_ZMM  |              \
++       XFEATURE_MASK_PKRU |                   \
++       XFEATURE_MASK_BNDREGS |                \
++       XFEATURE_MASK_BNDCSR)
++
++/*
+  * setup the xstate image representing the init state
+  */
+ static void __init setup_init_fpu_buf(void)
+ {
+       static int on_boot_cpu __initdata = 1;
+ 
++      BUILD_BUG_ON(XCNTXT_MASK != XFEATURES_INIT_FPSTATE_HANDLED);
++
+       WARN_ON_FPU(!on_boot_cpu);
+       on_boot_cpu = 0;
+ 
+@@ -423,10 +443,22 @@ static void __init setup_init_fpu_buf(vo
+       copy_kernel_to_xregs_booting(&init_fpstate.xsave);
+ 
+       /*
+-       * Dump the init state again. This is to identify the init state
+-       * of any feature which is not represented by all zero's.
++       * All components are now in init state. Read the state back so
++       * that init_fpstate contains all non-zero init state. This only
++       * works with XSAVE, but not with XSAVEOPT and XSAVES because
++       * those use the init optimization which skips writing data for
++       * components in init state.
++       *
++       * XSAVE could be used, but that would require to reshuffle the
++       * data when XSAVES is available because XSAVES uses xstate
++       * compaction. But doing so is a pointless exercise because most
++       * components have an all zeros init state except for the legacy
++       * ones (FP and SSE). Those can be saved with FXSAVE into the
++       * legacy area. Adding new features requires to ensure that init
++       * state is all zeroes or if not to add the necessary handling
++       * here.
+        */
+-      copy_xregs_to_kernel_booting(&init_fpstate.xsave);
++      fxsave(&init_fpstate.fxsave);
+ }
+ 
+ static int xfeature_uncompacted_offset(int xfeature_nr)