From: Sasha Levin Date: Sun, 10 Jan 2021 13:18:39 +0000 (-0500) Subject: Fixes for 4.9 X-Git-Tag: v4.4.251~31 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=54167913f723c233680ed7000d06cfc194fe28cb;p=thirdparty%2Fkernel%2Fstable-queue.git Fixes for 4.9 Signed-off-by: Sasha Levin --- diff --git a/queue-4.9/scripts-gdb-fix-lx-version-string-output.patch b/queue-4.9/scripts-gdb-fix-lx-version-string-output.patch new file mode 100644 index 00000000000..076bc3fa8d8 --- /dev/null +++ b/queue-4.9/scripts-gdb-fix-lx-version-string-output.patch @@ -0,0 +1,59 @@ +From 9a488ad2dfb94000839a491773a527687c96a83a Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 7 Jan 2021 14:52:29 -0800 +Subject: scripts/gdb: fix lx-version string output + +From: Du Changbin + +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 +Signed-off-by: Kieran Bingham +Acked-by: Jan Kiszka +Cc: Jan Kiszka +Cc: Jason Wessel +Cc: Daniel Thompson +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Florian Fainelli +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-4.9/scripts-gdb-lx-dmesg-cast-log_buf-to-void-for-addr-f.patch b/queue-4.9/scripts-gdb-lx-dmesg-cast-log_buf-to-void-for-addr-f.patch new file mode 100644 index 00000000000..1b5c5f783d5 --- /dev/null +++ b/queue-4.9/scripts-gdb-lx-dmesg-cast-log_buf-to-void-for-addr-f.patch @@ -0,0 +1,50 @@ +From e86c172fc0ed2097157d2e0710aa79b93b10c709 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +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 "", line 1, in + 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 +Reviewed-by: Jan Kiszka +Cc: Jason Wessel +Cc: Kieran Bingham +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Florian Fainelli +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-4.9/scripts-gdb-lx-dmesg-use-explicit-encoding-utf8-erro.patch b/queue-4.9/scripts-gdb-lx-dmesg-use-explicit-encoding-utf8-erro.patch new file mode 100644 index 00000000000..4cc0e8cda7b --- /dev/null +++ b/queue-4.9/scripts-gdb-lx-dmesg-use-explicit-encoding-utf8-erro.patch @@ -0,0 +1,75 @@ +From 2eb96ae4e63388a00383ad341b9d90b8d32ba47b Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 7 Jan 2021 14:52:28 -0800 +Subject: scripts/gdb: lx-dmesg: use explicit encoding=utf8 errors=replace + +From: Leonard Crestez + +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 +Acked-by: Jan Kiszka +Cc: Jason Wessel +Cc: Kieran Bingham +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Florian Fainelli +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-4.9/scripts-gdb-make-lx-dmesg-command-work-reliably.patch b/queue-4.9/scripts-gdb-make-lx-dmesg-command-work-reliably.patch new file mode 100644 index 00000000000..ecc7e58fbdf --- /dev/null +++ b/queue-4.9/scripts-gdb-make-lx-dmesg-command-work-reliably.patch @@ -0,0 +1,84 @@ +From a98cbcd7f43636a2dc638fc1f90f4c010be0d949 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +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 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 /kernel/bpf/verifier.c: + static char *log_buf; + + File /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 + (gdb) p &'verifier.c'::log_buf + $4 = (char **) 0x8120fe40 + (gdb) p &'printk.c'::log_buf + $5 = (char **) 0x8048b7d0 + +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 +Tested-by: Kieran Bingham +Acked-by: Jan Kiszka +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Florian Fainelli +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-4.9/series b/queue-4.9/series index 3493ad4abd3..b2b9a668e09 100644 --- a/queue-4.9/series +++ b/queue-4.9/series @@ -14,3 +14,8 @@ cdc-ncm-remove-connected-log-message.patch 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 diff --git a/queue-4.9/video-hyperv_fb-fix-the-mmap-regression-for-v5.4.y-a.patch b/queue-4.9/video-hyperv_fb-fix-the-mmap-regression-for-v5.4.y-a.patch new file mode 100644 index 00000000000..48fd76f7a75 --- /dev/null +++ b/queue-4.9/video-hyperv_fb-fix-the-mmap-regression-for-v5.4.y-a.patch @@ -0,0 +1,76 @@ +From 83a864f2a98e020e59a6de7430c1a0d6d6f7fa20 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +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 +Signed-off-by: Sasha Levin +--- + 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 +