--- /dev/null
+From 9a488ad2dfb94000839a491773a527687c96a83a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 7 Jan 2021 14:52:29 -0800
+Subject: scripts/gdb: fix lx-version string output
+
+From: Du Changbin <changbin.du@gmail.com>
+
+commit b058809bfc8faeb7b7cae047666e23375a060059 upstream
+
+A bug is present in GDB which causes early string termination when
+parsing variables. This has been reported [0], but we should ensure
+that we can support at least basic printing of the core kernel strings.
+
+For current gdb version (has been tested with 7.3 and 8.1), 'lx-version'
+only prints one character.
+
+ (gdb) lx-version
+ L(gdb)
+
+This can be fixed by casting 'linux_banner' as (char *).
+
+ (gdb) lx-version
+ Linux version 4.19.0-rc1+ (changbin@acer) (gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3)) #21 SMP Sat Sep 1 21:43:30 CST 2018
+
+[0] https://sourceware.org/bugzilla/show_bug.cgi?id=20077
+
+[kbingham@kernel.org: add detail to commit message]
+Link: http://lkml.kernel.org/r/20181111162035.8356-1-kieran.bingham@ideasonboard.com
+Fixes: 2d061d999424 ("scripts/gdb: add version command")
+Signed-off-by: Du Changbin <changbin.du@gmail.com>
+Signed-off-by: Kieran Bingham <kbingham@kernel.org>
+Acked-by: Jan Kiszka <jan.kiszka@siemens.com>
+Cc: Jan Kiszka <jan.kiszka@siemens.com>
+Cc: Jason Wessel <jason.wessel@windriver.com>
+Cc: Daniel Thompson <daniel.thompson@linaro.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ scripts/gdb/linux/proc.py | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/scripts/gdb/linux/proc.py b/scripts/gdb/linux/proc.py
+index 38b1f09d1cd95..822e3767bc054 100644
+--- a/scripts/gdb/linux/proc.py
++++ b/scripts/gdb/linux/proc.py
+@@ -40,7 +40,7 @@ class LxVersion(gdb.Command):
+
+ def invoke(self, arg, from_tty):
+ # linux_banner should contain a newline
+- gdb.write(gdb.parse_and_eval("linux_banner").string())
++ gdb.write(gdb.parse_and_eval("(char *)linux_banner").string())
+
+ LxVersion()
+
+--
+2.27.0
+
--- /dev/null
+From e86c172fc0ed2097157d2e0710aa79b93b10c709 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 7 Jan 2021 14:52:27 -0800
+Subject: scripts/gdb: lx-dmesg: cast log_buf to void* for addr fetch
+
+From: Leonard Crestez <leonard.crestez@nxp.com>
+
+commit c454756f47277b651ad41a5a163499294529e35d upstream
+
+In some cases it is possible for the str() conversion here to throw
+encoding errors because log_buf might not point to valid ascii. For
+example:
+
+ (gdb) python print str(gdb.parse_and_eval("log_buf"))
+ Traceback (most recent call last):
+ File "<string>", line 1, in <module>
+ UnicodeEncodeError: 'ascii' codec can't encode character u'\u0303' in
+ position 24: ordinal not in range(128)
+
+Avoid this by explicitly casting to (void *) inside the gdb expression.
+
+Link: http://lkml.kernel.org/r/ba6f85dbb02ca980ebd0e2399b0649423399b565.1498481469.git.leonard.crestez@nxp.com
+Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
+Reviewed-by: Jan Kiszka <jan.kiszka@siemens.com>
+Cc: Jason Wessel <jason.wessel@windriver.com>
+Cc: Kieran Bingham <kieran@ksquared.org.uk>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ scripts/gdb/linux/dmesg.py | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/scripts/gdb/linux/dmesg.py b/scripts/gdb/linux/dmesg.py
+index 5afd1098e33a1..f5a030333dfd8 100644
+--- a/scripts/gdb/linux/dmesg.py
++++ b/scripts/gdb/linux/dmesg.py
+@@ -24,7 +24,7 @@ class LxDmesg(gdb.Command):
+
+ def invoke(self, arg, from_tty):
+ log_buf_addr = int(str(gdb.parse_and_eval(
+- "'printk.c'::log_buf")).split()[0], 16)
++ "(void *)'printk.c'::log_buf")).split()[0], 16)
+ log_first_idx = int(gdb.parse_and_eval("'printk.c'::log_first_idx"))
+ log_next_idx = int(gdb.parse_and_eval("'printk.c'::log_next_idx"))
+ log_buf_len = int(gdb.parse_and_eval("'printk.c'::log_buf_len"))
+--
+2.27.0
+
--- /dev/null
+From 2eb96ae4e63388a00383ad341b9d90b8d32ba47b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 7 Jan 2021 14:52:28 -0800
+Subject: scripts/gdb: lx-dmesg: use explicit encoding=utf8 errors=replace
+
+From: Leonard Crestez <leonard.crestez@nxp.com>
+
+commit 46d10a094353c05144f3b0530516bdac3ce7c435 upstream
+
+Use errors=replace because it is never desirable for lx-dmesg to fail on
+string decoding errors, not even if the log buffer is corrupt and we
+show incorrect info.
+
+The kernel will sometimes print utf8, for example the copyright symbol
+from jffs2. In order to make this work specify 'utf8' everywhere
+because python2 otherwise defaults to 'ascii'.
+
+In theory the second errors='replace' is not be required because
+everything that can be decoded as utf8 should also be encodable back to
+utf8. But it's better to be extra safe here. It's worth noting that
+this is definitely not true for encoding='ascii', unknown characters are
+replaced with U+FFFD REPLACEMENT CHARACTER and they fail to encode back
+to ascii.
+
+Link: http://lkml.kernel.org/r/acee067f3345954ed41efb77b80eebdc038619c6.1498481469.git.leonard.crestez@nxp.com
+Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
+Acked-by: Jan Kiszka <jan.kiszka@siemens.com>
+Cc: Jason Wessel <jason.wessel@windriver.com>
+Cc: Kieran Bingham <kieran@ksquared.org.uk>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ scripts/gdb/linux/dmesg.py | 13 ++++++++++---
+ 1 file changed, 10 insertions(+), 3 deletions(-)
+
+diff --git a/scripts/gdb/linux/dmesg.py b/scripts/gdb/linux/dmesg.py
+index f5a030333dfd8..6d2e09a2ad2f9 100644
+--- a/scripts/gdb/linux/dmesg.py
++++ b/scripts/gdb/linux/dmesg.py
+@@ -12,6 +12,7 @@
+ #
+
+ import gdb
++import sys
+
+ from linux import utils
+
+@@ -52,13 +53,19 @@ class LxDmesg(gdb.Command):
+ continue
+
+ text_len = utils.read_u16(log_buf[pos + 10:pos + 12])
+- text = log_buf[pos + 16:pos + 16 + text_len].decode()
++ text = log_buf[pos + 16:pos + 16 + text_len].decode(
++ encoding='utf8', errors='replace')
+ time_stamp = utils.read_u64(log_buf[pos:pos + 8])
+
+ for line in text.splitlines():
+- gdb.write("[{time:12.6f}] {line}\n".format(
++ msg = u"[{time:12.6f}] {line}\n".format(
+ time=time_stamp / 1000000000.0,
+- line=line))
++ line=line)
++ # With python2 gdb.write will attempt to convert unicode to
++ # ascii and might fail so pass an utf8-encoded str instead.
++ if sys.hexversion < 0x03000000:
++ msg = msg.encode(encoding='utf8', errors='replace')
++ gdb.write(msg)
+
+ pos += length
+
+--
+2.27.0
+
--- /dev/null
+From a98cbcd7f43636a2dc638fc1f90f4c010be0d949 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 7 Jan 2021 14:52:26 -0800
+Subject: scripts/gdb: make lx-dmesg command work (reliably)
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: André Draszik <git@andred.net>
+
+commit d6c9708737c2107c38bd75f133d14d5801b8d6d5 upstream
+
+lx-dmesg needs access to the log_buf symbol from printk.c.
+Unfortunately, the symbol log_buf also exists in BPF's verifier.c and
+hence gdb can pick one or the other. If it happens to pick BPF's
+log_buf, lx-dmesg doesn't work:
+
+ (gdb) lx-dmesg
+ Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x0:
+ Error occurred in Python command: Cannot access memory at address 0x0
+ (gdb) p log_buf
+ $15 = 0x0
+
+Luckily, GDB has a way to deal with this, see
+ https://sourceware.org/gdb/onlinedocs/gdb/Symbols.html
+
+ (gdb) info variables ^log_buf$
+ All variables matching regular expression "^log_buf$":
+
+ File <linux.git>/kernel/bpf/verifier.c:
+ static char *log_buf;
+
+ File <linux.git>/kernel/printk/printk.c:
+ static char *log_buf;
+ (gdb) p 'verifier.c'::log_buf
+ $1 = 0x0
+ (gdb) p 'printk.c'::log_buf
+ $2 = 0x811a6aa0 <__log_buf> ""
+ (gdb) p &log_buf
+ $3 = (char **) 0x8120fe40 <log_buf>
+ (gdb) p &'verifier.c'::log_buf
+ $4 = (char **) 0x8120fe40 <log_buf>
+ (gdb) p &'printk.c'::log_buf
+ $5 = (char **) 0x8048b7d0 <log_buf>
+
+By being explicit about the location of the symbol, we can make lx-dmesg
+work again. While at it, do the same for the other symbols we need from
+printk.c
+
+Link: http://lkml.kernel.org/r/20170526112222.3414-1-git@andred.net
+Signed-off-by: André Draszik <git@andred.net>
+Tested-by: Kieran Bingham <kieran@bingham.xyz>
+Acked-by: Jan Kiszka <jan.kiszka@siemens.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ scripts/gdb/linux/dmesg.py | 9 +++++----
+ 1 file changed, 5 insertions(+), 4 deletions(-)
+
+diff --git a/scripts/gdb/linux/dmesg.py b/scripts/gdb/linux/dmesg.py
+index f9b92ece78343..5afd1098e33a1 100644
+--- a/scripts/gdb/linux/dmesg.py
++++ b/scripts/gdb/linux/dmesg.py
+@@ -23,10 +23,11 @@ class LxDmesg(gdb.Command):
+ super(LxDmesg, self).__init__("lx-dmesg", gdb.COMMAND_DATA)
+
+ def invoke(self, arg, from_tty):
+- log_buf_addr = int(str(gdb.parse_and_eval("log_buf")).split()[0], 16)
+- log_first_idx = int(gdb.parse_and_eval("log_first_idx"))
+- log_next_idx = int(gdb.parse_and_eval("log_next_idx"))
+- log_buf_len = int(gdb.parse_and_eval("log_buf_len"))
++ log_buf_addr = int(str(gdb.parse_and_eval(
++ "'printk.c'::log_buf")).split()[0], 16)
++ log_first_idx = int(gdb.parse_and_eval("'printk.c'::log_first_idx"))
++ log_next_idx = int(gdb.parse_and_eval("'printk.c'::log_next_idx"))
++ log_buf_len = int(gdb.parse_and_eval("'printk.c'::log_buf_len"))
+
+ inf = gdb.inferiors()[0]
+ start = log_buf_addr + log_first_idx
+--
+2.27.0
+
vhost_net-fix-ubuf-refcount-incorrectly-when-sendmsg-fails.patch
net-sched-prevent-invalid-scell_log-shift-count.patch
virtio_net-fix-recursive-call-to-cpus_read_lock.patch
+scripts-gdb-make-lx-dmesg-command-work-reliably.patch
+scripts-gdb-lx-dmesg-cast-log_buf-to-void-for-addr-f.patch
+scripts-gdb-lx-dmesg-use-explicit-encoding-utf8-erro.patch
+scripts-gdb-fix-lx-version-string-output.patch
+video-hyperv_fb-fix-the-mmap-regression-for-v5.4.y-a.patch
--- /dev/null
+From 83a864f2a98e020e59a6de7430c1a0d6d6f7fa20 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 9 Jan 2021 14:53:58 -0800
+Subject: video: hyperv_fb: Fix the mmap() regression for v5.4.y and older
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Dexuan Cui <decui@microsoft.com>
+
+db49200b1dad is backported from the mainline commit
+5f1251a48c17 ("video: hyperv_fb: Fix the cache type when mapping the VRAM"),
+to v5.4.y and older stable branches, but unluckily db49200b1dad causes
+mmap() to fail for /dev/fb0 due to EINVAL:
+
+[ 5797.049560] x86/PAT: a.out:1910 map pfn expected mapping type
+ uncached-minus for [mem 0xf8200000-0xf85cbfff], got write-back
+
+This means the v5.4.y kernel detects an incompatibility issue about the
+mapping type of the VRAM: db49200b1dad changes to use Write-Back when
+mapping the VRAM, while the mmap() syscall tries to use Uncached-minus.
+That’s to say, the kernel thinks Uncached-minus is incompatible with
+Write-Back: see drivers/video/fbdev/core/fbmem.c: fb_mmap() ->
+vm_iomap_memory() -> io_remap_pfn_range() -> ... -> track_pfn_remap() ->
+reserve_pfn_range().
+
+Note: any v5.5 and newer kernel doesn't have the issue, because they
+have commit
+d21987d709e8 ("video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver")
+, and when the hyperv_fb driver has the deferred_io support,
+fb_deferred_io_init() overrides info->fbops->fb_mmap with
+fb_deferred_io_mmap(), which doesn’t check the mapping type
+incompatibility. Note: since it's VRAM here, the checking is not really
+necessary.
+
+Fix the regression by ioremap_wc(), which uses Write-combining. The kernel
+thinks it's compatible with Uncached-minus. The VRAM mappped by
+ioremap_wc() is slightly slower than mapped by ioremap_cache(), but is
+still significantly faster than by ioremap().
+
+Change the comment accordingly. Linux VM on ARM64 Hyper-V is still not
+working in the latest mainline yet, and when it works in future, the ARM64
+support is unlikely to be backported to v5.4 and older, so using
+ioremap_wc() in v5.4 and older should be ok.
+
+Note: this fix is only targeted at the stable branches:
+v5.4.y, v4.19.y, v4.14.y, v4.9.y and v4.4.y.
+
+Fixes: db49200b1dad ("video: hyperv_fb: Fix the cache type when mapping the VRAM")
+Signed-off-by: Dexuan Cui <decui@microsoft.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/video/fbdev/hyperv_fb.c | 6 ++----
+ 1 file changed, 2 insertions(+), 4 deletions(-)
+
+diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
+index f3938c5278832..6e680007cf6b0 100644
+--- a/drivers/video/fbdev/hyperv_fb.c
++++ b/drivers/video/fbdev/hyperv_fb.c
+@@ -713,11 +713,9 @@ static int hvfb_getmem(struct hv_device *hdev, struct fb_info *info)
+ }
+
+ /*
+- * Map the VRAM cacheable for performance. This is also required for
+- * VM Connect to display properly for ARM64 Linux VM, as the host also
+- * maps the VRAM cacheable.
++ * Map the VRAM cacheable for performance.
+ */
+- fb_virt = ioremap_cache(par->mem->start, screen_fb_size);
++ fb_virt = ioremap_wc(par->mem->start, screen_fb_size);
+ if (!fb_virt)
+ goto err2;
+
+--
+2.27.0
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
