--- /dev/null
+From foo@baz Fri Jan 15 10:48:37 AM CET 2021
+From: Chris Wilson <chris@chris-wilson.co.uk>
+Date: Wed, 16 Dec 2020 09:29:51 +0000
+Subject: drm/i915: Fix mismatch between misplaced vma check and vma insert
+
+From: Chris Wilson <chris@chris-wilson.co.uk>
+
+commit 0e53656ad8abc99e0a80c3de611e593ebbf55829 upstream
+
+When inserting a VMA, we restrict the placement to the low 4G unless the
+caller opts into using the full range. This was done to allow usersapce
+the opportunity to transition slowly from a 32b address space, and to
+avoid breaking inherent 32b assumptions of some commands.
+
+However, for insert we limited ourselves to 4G-4K, but on verification
+we allowed the full 4G. This causes some attempts to bind a new buffer
+to sporadically fail with -ENOSPC, but at other times be bound
+successfully.
+
+commit 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1
+page") suggests that there is a genuine problem with stateless addressing
+that cannot utilize the last page in 4G and so we purposefully excluded
+it. This means that the quick pin pass may cause us to utilize a buggy
+placement.
+
+Reported-by: CQ Tang <cq.tang@intel.com>
+Testcase: igt/gem_exec_params/larger-than-life-batch
+Fixes: 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1 page")
+Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
+Cc: CQ Tang <cq.tang@intel.com>
+Reviewed-by: CQ Tang <cq.tang@intel.com>
+Reviewed-by: Matthew Auld <matthew.auld@intel.com>
+Cc: <stable@vger.kernel.org> # v4.5+
+Link: https://patchwork.freedesktop.org/patch/msgid/20201216092951.7124-1-chris@chris-wilson.co.uk
+(cherry picked from commit 5f22cc0b134ab702d7f64b714e26018f7288ffee)
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+[sudip: use file from old path and adjust context]
+Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
++++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+@@ -882,7 +882,7 @@ eb_vma_misplaced(struct i915_vma *vma)
+ return !only_mappable_for_reloc(entry->flags);
+
+ if ((entry->flags & EXEC_OBJECT_SUPPORTS_48B_ADDRESS) == 0 &&
+- (vma->node.start + vma->node.size - 1) >> 32)
++ (vma->node.start + vma->node.size + 4095) >> 32)
+ return true;
+
+ return false;
powerpc-fix-incorrect-stw-ux-u-x-instructions-in-__s.patch
net-ip-always-refragment-ip-defragmented-packets.patch
net-fix-pmtu-check-in-nopmtudisc-mode.patch
+vmlinux.lds.h-add-pgo-and-autofdo-input-sections.patch
+drm-i915-fix-mismatch-between-misplaced-vma-check-and-vma-insert.patch
+ubifs-wbuf-don-t-leak-kernel-memory-to-flash.patch
+spi-pxa2xx-fix-use-after-free-on-unbind.patch
--- /dev/null
+From foo@baz Fri Jan 15 10:50:57 AM CET 2021
+From: Lukas Wunner <lukas@wunner.de>
+Date: Mon, 7 Dec 2020 09:17:05 +0100
+Subject: spi: pxa2xx: Fix use-after-free on unbind
+
+From: Lukas Wunner <lukas@wunner.de>
+
+commit 5626308bb94d9f930aa5f7c77327df4c6daa7759 upstream
+
+pxa2xx_spi_remove() accesses the driver's private data after calling
+spi_unregister_controller() even though that function releases the last
+reference on the spi_controller and thereby frees the private data.
+
+Fix by switching over to the new devm_spi_alloc_master/slave() helper
+which keeps the private data accessible until the driver has unbound.
+
+Fixes: 32e5b57232c0 ("spi: pxa2xx: Fix controller unregister order")
+Signed-off-by: Lukas Wunner <lukas@wunner.de>
+Cc: <stable@vger.kernel.org> # v2.6.17+: 5e844cc37a5c: spi: Introduce device-managed SPI controller allocation
+Cc: <stable@vger.kernel.org> # v2.6.17+: 32e5b57232c0: spi: pxa2xx: Fix controller unregister order
+Cc: <stable@vger.kernel.org> # v2.6.17+
+Link: https://lore.kernel.org/r/5764b04d4a6e43069ebb7808f64c2f774ac6f193.1607286887.git.lukas@wunner.de
+Signed-off-by: Mark Brown <broonie@kernel.org>
+[sudip: adjust context]
+Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/spi/spi-pxa2xx.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/drivers/spi/spi-pxa2xx.c
++++ b/drivers/spi/spi-pxa2xx.c
+@@ -1606,7 +1606,7 @@ static int pxa2xx_spi_probe(struct platf
+ return -ENODEV;
+ }
+
+- master = spi_alloc_master(dev, sizeof(struct driver_data));
++ master = devm_spi_alloc_master(dev, sizeof(*drv_data));
+ if (!master) {
+ dev_err(&pdev->dev, "cannot alloc spi_master\n");
+ pxa_ssp_free(ssp);
+@@ -1788,7 +1788,6 @@ out_error_clock_enabled:
+ free_irq(ssp->irq, drv_data);
+
+ out_error_master_alloc:
+- spi_master_put(master);
+ pxa_ssp_free(ssp);
+ return status;
+ }
--- /dev/null
+From foo@baz Fri Jan 15 10:49:41 AM CET 2021
+From: Richard Weinberger <richard@nod.at>
+Date: Mon, 16 Nov 2020 22:05:30 +0100
+Subject: ubifs: wbuf: Don't leak kernel memory to flash
+
+From: Richard Weinberger <richard@nod.at>
+
+commit 20f1431160c6b590cdc269a846fc5a448abf5b98 upstream
+
+Write buffers use a kmalloc()'ed buffer, they can leak
+up to seven bytes of kernel memory to flash if writes are not
+aligned.
+So use ubifs_pad() to fill these gaps with padding bytes.
+This was never a problem while scanning because the scanner logic
+manually aligns node lengths and skips over these gaps.
+
+Cc: <stable@vger.kernel.org>
+Fixes: 1e51764a3c2ac05a2 ("UBIFS: add new flash file system")
+Signed-off-by: Richard Weinberger <richard@nod.at>
+Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
+Signed-off-by: Richard Weinberger <richard@nod.at>
+[sudip: adjust context]
+Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ubifs/io.c | 13 +++++++++++--
+ 1 file changed, 11 insertions(+), 2 deletions(-)
+
+--- a/fs/ubifs/io.c
++++ b/fs/ubifs/io.c
+@@ -331,7 +331,7 @@ void ubifs_pad(const struct ubifs_info *
+ {
+ uint32_t crc;
+
+- ubifs_assert(pad >= 0 && !(pad & 7));
++ ubifs_assert(pad >= 0);
+
+ if (pad >= UBIFS_PAD_NODE_SZ) {
+ struct ubifs_ch *ch = buf;
+@@ -721,6 +721,10 @@ int ubifs_wbuf_write_nolock(struct ubifs
+ * write-buffer.
+ */
+ memcpy(wbuf->buf + wbuf->used, buf, len);
++ if (aligned_len > len) {
++ ubifs_assert(aligned_len - len < 8);
++ ubifs_pad(c, wbuf->buf + wbuf->used + len, aligned_len - len);
++ }
+
+ if (aligned_len == wbuf->avail) {
+ dbg_io("flush jhead %s wbuf to LEB %d:%d",
+@@ -813,13 +817,18 @@ int ubifs_wbuf_write_nolock(struct ubifs
+ }
+
+ spin_lock(&wbuf->lock);
+- if (aligned_len)
++ if (aligned_len) {
+ /*
+ * And now we have what's left and what does not take whole
+ * max. write unit, so write it to the write-buffer and we are
+ * done.
+ */
+ memcpy(wbuf->buf, buf + written, len);
++ if (aligned_len > len) {
++ ubifs_assert(aligned_len - len < 8);
++ ubifs_pad(c, wbuf->buf + len, aligned_len - len);
++ }
++ }
+
+ if (c->leb_size - wbuf->offs >= c->max_write_size)
+ wbuf->size = c->max_write_size;
--- /dev/null
+From foo@baz Fri Jan 15 10:45:50 AM CET 2021
+From: Nick Desaulniers <ndesaulniers@google.com>
+Date: Fri, 21 Aug 2020 12:42:47 -0700
+Subject: vmlinux.lds.h: Add PGO and AutoFDO input sections
+
+From: Nick Desaulniers <ndesaulniers@google.com>
+
+commit eff8728fe69880d3f7983bec3fb6cea4c306261f upstream.
+
+Basically, consider .text.{hot|unlikely|unknown}.* part of .text, too.
+
+When compiling with profiling information (collected via PGO
+instrumentations or AutoFDO sampling), Clang will separate code into
+.text.hot, .text.unlikely, or .text.unknown sections based on profiling
+information. After D79600 (clang-11), these sections will have a
+trailing `.` suffix, ie. .text.hot., .text.unlikely., .text.unknown..
+
+When using -ffunction-sections together with profiling infomation,
+either explicitly (FGKASLR) or implicitly (LTO), code may be placed in
+sections following the convention:
+.text.hot.<foo>, .text.unlikely.<bar>, .text.unknown.<baz>
+where <foo>, <bar>, and <baz> are functions. (This produces one section
+per function; we generally try to merge these all back via linker script
+so that we don't have 50k sections).
+
+For the above cases, we need to teach our linker scripts that such
+sections might exist and that we'd explicitly like them grouped
+together, otherwise we can wind up with code outside of the
+_stext/_etext boundaries that might not be mapped properly for some
+architectures, resulting in boot failures.
+
+If the linker script is not told about possible input sections, then
+where the section is placed as output is a heuristic-laiden mess that's
+non-portable between linkers (ie. BFD and LLD), and has resulted in many
+hard to debug bugs. Kees Cook is working on cleaning this up by adding
+--orphan-handling=warn linker flag used in ARCH=powerpc to additional
+architectures. In the case of linker scripts, borrowing from the Zen of
+Python: explicit is better than implicit.
+
+Also, ld.bfd's internal linker script considers .text.hot AND
+.text.hot.* to be part of .text, as well as .text.unlikely and
+.text.unlikely.*. I didn't see support for .text.unknown.*, and didn't
+see Clang producing such code in our kernel builds, but I see code in
+LLVM that can produce such section names if profiling information is
+missing. That may point to a larger issue with generating or collecting
+profiles, but I would much rather be safe and explicit than have to
+debug yet another issue related to orphan section placement.
+
+Reported-by: Jian Cai <jiancai@google.com>
+Suggested-by: Fāng-ruì Sòng <maskray@google.com>
+Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
+Signed-off-by: Kees Cook <keescook@chromium.org>
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Tested-by: Luis Lozano <llozano@google.com>
+Tested-by: Manoj Gupta <manojgupta@google.com>
+Acked-by: Kees Cook <keescook@chromium.org>
+Cc: linux-arch@vger.kernel.org
+Cc: stable@vger.kernel.org
+Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=add44f8d5c5c05e08b11e033127a744d61c26aee
+Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=1de778ed23ce7492c523d5850c6c6dbb34152655
+Link: https://reviews.llvm.org/D79600
+Link: https://bugs.chromium.org/p/chromium/issues/detail?id=1084760
+Link: https://lore.kernel.org/r/20200821194310.3089815-7-keescook@chromium.org
+
+Debugged-by: Luis Lozano <llozano@google.com>
+[nc: Fix small conflict around lack of NOINSTR_TEXT and .text..refcount]
+Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/asm-generic/vmlinux.lds.h | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/include/asm-generic/vmlinux.lds.h
++++ b/include/asm-generic/vmlinux.lds.h
+@@ -460,7 +460,10 @@
+ */
+ #define TEXT_TEXT \
+ ALIGN_FUNCTION(); \
+- *(.text.hot TEXT_MAIN .text.fixup .text.unlikely) \
++ *(.text.hot .text.hot.*) \
++ *(TEXT_MAIN .text.fixup) \
++ *(.text.unlikely .text.unlikely.*) \
++ *(.text.unknown .text.unknown.*) \
+ *(.ref.text) \
+ MEM_KEEP(init.text) \
+ MEM_KEEP(exit.text) \
projects / thirdparty / kernel / stable-queue.git / commitdiff
