--- /dev/null
+From b230235b386589d8f0d631b1c77a95ca79bb0732 Mon Sep 17 00:00:00 2001
+From: "Ahmed S. Darwish" <darwi@linutronix.de>
+Date: Mon, 15 May 2023 19:32:17 +0200
+Subject: docs: Set minimal gtags / GNU GLOBAL version to 6.6.5
+
+From: Ahmed S. Darwish <darwi@linutronix.de>
+
+commit b230235b386589d8f0d631b1c77a95ca79bb0732 upstream.
+
+Kernel build now uses the gtags "-C (--directory)" option, available
+since GNU GLOBAL v6.6.5. Update the documentation accordingly.
+
+Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de>
+Cc: <stable@vger.kernel.org>
+Link: https://lists.gnu.org/archive/html/info-global/2020-09/msg00000.html
+Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ Documentation/process/changes.rst | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/Documentation/process/changes.rst
++++ b/Documentation/process/changes.rst
+@@ -60,6 +60,7 @@ openssl & libcrypto 1.0.0
+ bc 1.06.95 bc --version
+ Sphinx\ [#f1]_ 1.7 sphinx-build --version
+ cpio any cpio --version
++gtags (optional) 6.6.5 gtags --version
+ ====================== =============== ========================================
+
+ .. [#f1] Sphinx is needed only to build the Kernel documentation
+@@ -174,6 +175,12 @@ You will need openssl to build kernels 3
+ enabled. You will also need openssl development packages to build kernels 4.3
+ and higher.
+
++gtags / GNU GLOBAL (optional)
++-----------------------------
++
++The kernel build requires GNU GLOBAL version 6.6.5 or later to generate
++tag files through ``make gtags``. This is due to its use of the gtags
++``-C (--directory)`` flag.
+
+ System utilities
+ ****************
--- /dev/null
+From a2b308044dcaca8d3e580959a4f867a1d5c37fac Mon Sep 17 00:00:00 2001
+From: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
+Date: Sat, 13 May 2023 14:51:00 +0200
+Subject: drm/amdgpu: Validate VM ioctl flags.
+
+From: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
+
+commit a2b308044dcaca8d3e580959a4f867a1d5c37fac upstream.
+
+None have been defined yet, so reject anybody setting any. Mesa sets
+it to 0 anyway.
+
+Signed-off-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+@@ -2363,6 +2363,10 @@ int amdgpu_vm_ioctl(struct drm_device *d
+ long timeout = msecs_to_jiffies(2000);
+ int r;
+
++ /* No valid flags defined yet */
++ if (args->in.flags)
++ return -EINVAL;
++
+ switch (args->in.op) {
+ case AMDGPU_VM_OP_RESERVE_VMID:
+ /* We only have requirement to reserve vmid from gfxhub */
--- /dev/null
+From 0e96647cff9224db564a1cee6efccb13dbe11ee2 Mon Sep 17 00:00:00 2001
+From: Finn Thain <fthain@linux-m68k.org>
+Date: Tue, 14 Mar 2023 19:51:59 +1100
+Subject: nubus: Partially revert proc_create_single_data() conversion
+
+From: Finn Thain <fthain@linux-m68k.org>
+
+commit 0e96647cff9224db564a1cee6efccb13dbe11ee2 upstream.
+
+The conversion to proc_create_single_data() introduced a regression
+whereby reading a file in /proc/bus/nubus results in a seg fault:
+
+ # grep -r . /proc/bus/nubus/e/
+ Data read fault at 0x00000020 in Super Data (pc=0x1074c2)
+ BAD KERNEL BUSERR
+ Oops: 00000000
+ Modules linked in:
+ PC: [<001074c2>] PDE_DATA+0xc/0x16
+ SR: 2010 SP: 38284958 a2: 01152370
+ d0: 00000001 d1: 01013000 d2: 01002790 d3: 00000000
+ d4: 00000001 d5: 0008ce2e a0: 00000000 a1: 00222a40
+ Process grep (pid: 45, task=142f8727)
+ Frame format=B ssw=074d isc=2008 isb=4e5e daddr=00000020 dobuf=01199e70
+ baddr=001074c8 dibuf=ffffffff ver=f
+ Stack from 01199e48:
+ 01199e70 00222a58 01002790 00000000 011a3000 01199eb0 015000c0 00000000
+ 00000000 01199ec0 01199ec0 000d551a 011a3000 00000001 00000000 00018000
+ d003f000 00000003 00000001 0002800d 01052840 01199fa8 c01f8000 00000000
+ 00000029 0b532b80 00000000 00000000 00000029 0b532b80 01199ee4 00103640
+ 011198c0 d003f000 00018000 01199fa8 00000000 011198c0 00000000 01199f4c
+ 000b3344 011198c0 d003f000 00018000 01199fa8 00000000 00018000 011198c0
+ Call Trace: [<00222a58>] nubus_proc_rsrc_show+0x18/0xa0
+ [<000d551a>] seq_read+0xc4/0x510
+ [<00018000>] fp_fcos+0x2/0x82
+ [<0002800d>] __sys_setreuid+0x115/0x1c6
+ [<00103640>] proc_reg_read+0x5c/0xb0
+ [<00018000>] fp_fcos+0x2/0x82
+ [<000b3344>] __vfs_read+0x2c/0x13c
+ [<00018000>] fp_fcos+0x2/0x82
+ [<00018000>] fp_fcos+0x2/0x82
+ [<000b8aa2>] sys_statx+0x60/0x7e
+ [<000b34b6>] vfs_read+0x62/0x12a
+ [<00018000>] fp_fcos+0x2/0x82
+ [<00018000>] fp_fcos+0x2/0x82
+ [<000b39c2>] ksys_read+0x48/0xbe
+ [<00018000>] fp_fcos+0x2/0x82
+ [<000b3a4e>] sys_read+0x16/0x1a
+ [<00018000>] fp_fcos+0x2/0x82
+ [<00002b84>] syscall+0x8/0xc
+ [<00018000>] fp_fcos+0x2/0x82
+ [<0000c016>] not_ext+0xa/0x18
+ Code: 4e5e 4e75 4e56 0000 206e 0008 2068 ffe8 <2068> 0020 2008 4e5e 4e75 4e56 0000 2f0b 206e 0008 2068 0004 2668 0020 206b ffe8
+ Disabling lock debugging due to kernel taint
+
+ Segmentation fault
+
+The proc_create_single_data() conversion does not work because
+single_open(file, nubus_proc_rsrc_show, PDE_DATA(inode)) is not
+equivalent to the original code.
+
+Fixes: 3f3942aca6da ("proc: introduce proc_create_single{,_data}")
+Cc: Christoph Hellwig <hch@lst.de>
+Cc: stable@vger.kernel.org # 5.6+
+Signed-off-by: Finn Thain <fthain@linux-m68k.org>
+Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
+Link: https://lore.kernel.org/r/d4e2a586e793cc8d9442595684ab8a077c0fe726.1678783919.git.fthain@linux-m68k.org
+Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/nubus/proc.c | 22 +++++++++++++++++-----
+ 1 file changed, 17 insertions(+), 5 deletions(-)
+
+--- a/drivers/nubus/proc.c
++++ b/drivers/nubus/proc.c
+@@ -137,6 +137,18 @@ static int nubus_proc_rsrc_show(struct s
+ return 0;
+ }
+
++static int nubus_rsrc_proc_open(struct inode *inode, struct file *file)
++{
++ return single_open(file, nubus_proc_rsrc_show, inode);
++}
++
++static const struct proc_ops nubus_rsrc_proc_ops = {
++ .proc_open = nubus_rsrc_proc_open,
++ .proc_read = seq_read,
++ .proc_lseek = seq_lseek,
++ .proc_release = single_release,
++};
++
+ void nubus_proc_add_rsrc_mem(struct proc_dir_entry *procdir,
+ const struct nubus_dirent *ent,
+ unsigned int size)
+@@ -152,8 +164,8 @@ void nubus_proc_add_rsrc_mem(struct proc
+ pded = nubus_proc_alloc_pde_data(nubus_dirptr(ent), size);
+ else
+ pded = NULL;
+- proc_create_single_data(name, S_IFREG | 0444, procdir,
+- nubus_proc_rsrc_show, pded);
++ proc_create_data(name, S_IFREG | 0444, procdir,
++ &nubus_rsrc_proc_ops, pded);
+ }
+
+ void nubus_proc_add_rsrc(struct proc_dir_entry *procdir,
+@@ -166,9 +178,9 @@ void nubus_proc_add_rsrc(struct proc_dir
+ return;
+
+ snprintf(name, sizeof(name), "%x", ent->type);
+- proc_create_single_data(name, S_IFREG | 0444, procdir,
+- nubus_proc_rsrc_show,
+- nubus_proc_alloc_pde_data(data, 0));
++ proc_create_data(name, S_IFREG | 0444, procdir,
++ &nubus_rsrc_proc_ops,
++ nubus_proc_alloc_pde_data(data, 0));
+ }
+
+ /*
--- /dev/null
+From 1c249565426e3a9940102c0ba9f63914f7cda73d Mon Sep 17 00:00:00 2001
+From: Krister Johansen <kjlx@templeofstupid.com>
+Date: Wed, 25 Jan 2023 10:34:18 -0800
+Subject: perf symbols: Symbol lookup with kcore can fail if multiple segments match stext
+
+From: Krister Johansen <kjlx@templeofstupid.com>
+
+commit 1c249565426e3a9940102c0ba9f63914f7cda73d upstream.
+
+This problem was encountered on an arm64 system with a lot of memory.
+Without kernel debug symbols installed, and with both kcore and kallsyms
+available, perf managed to get confused and returned "unknown" for all
+of the kernel symbols that it tried to look up.
+
+On this system, stext fell within the vmalloc segment. The kcore symbol
+matching code tries to find the first segment that contains stext and
+uses that to replace the segment generated from just the kallsyms
+information. In this case, however, there were two: a very large
+vmalloc segment, and the text segment. This caused perf to get confused
+because multiple overlapping segments were inserted into the RB tree
+that holds the discovered segments. However, that alone wasn't
+sufficient to cause the problem. Even when we could find the segment,
+the offsets were adjusted in such a way that the newly generated symbols
+didn't line up with the instruction addresses in the trace. The most
+obvious solution would be to consult which segment type is text from
+kcore, but this information is not exposed to users.
+
+Instead, select the smallest matching segment that contains stext
+instead of the first matching segment. This allows us to match the text
+segment instead of vmalloc, if one is contained within the other.
+
+Reviewed-by: Adrian Hunter <adrian.hunter@intel.com>
+Signed-off-by: Krister Johansen <kjlx@templeofstupid.com>
+Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Cc: David Reaver <me@davidreaver.com>
+Cc: Ian Rogers <irogers@google.com>
+Cc: Jiri Olsa <jolsa@kernel.org>
+Cc: Mark Rutland <mark.rutland@arm.com>
+Cc: Michael Petlan <mpetlan@redhat.com>
+Cc: Namhyung Kim <namhyung@kernel.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Link: http://lore.kernel.org/lkml/20230125183418.GD1963@templeofstupid.com
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Krister Johansen <kjlx@templeofstupid.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ tools/perf/util/symbol.c | 17 +++++++++++++++--
+ 1 file changed, 15 insertions(+), 2 deletions(-)
+
+--- a/tools/perf/util/symbol.c
++++ b/tools/perf/util/symbol.c
+@@ -1368,10 +1368,23 @@ static int dso__load_kcore(struct dso *d
+
+ /* Find the kernel map using the '_stext' symbol */
+ if (!kallsyms__get_function_start(kallsyms_filename, "_stext", &stext)) {
++ u64 replacement_size = 0;
++
+ list_for_each_entry(new_map, &md.maps, node) {
+- if (stext >= new_map->start && stext < new_map->end) {
++ u64 new_size = new_map->end - new_map->start;
++
++ if (!(stext >= new_map->start && stext < new_map->end))
++ continue;
++
++ /*
++ * On some architectures, ARM64 for example, the kernel
++ * text can get allocated inside of the vmalloc segment.
++ * Select the smallest matching segment, in case stext
++ * falls within more than one in the list.
++ */
++ if (!replacement_map || new_size < replacement_size) {
+ replacement_map = new_map;
+- break;
++ replacement_size = new_size;
+ }
+ }
+ }
--- /dev/null
+From e1b37563caffc410bb4b55f153ccb14dede66815 Mon Sep 17 00:00:00 2001
+From: "Ahmed S. Darwish" <darwi@linutronix.de>
+Date: Mon, 15 May 2023 19:32:16 +0200
+Subject: scripts/tags.sh: Resolve gtags empty index generation
+
+From: Ahmed S. Darwish <darwi@linutronix.de>
+
+commit e1b37563caffc410bb4b55f153ccb14dede66815 upstream.
+
+gtags considers any file outside of its current working directory
+"outside the source tree" and refuses to index it. For O= kernel builds,
+or when "make" is invoked from a directory other then the kernel source
+tree, gtags ignores the entire kernel source and generates an empty
+index.
+
+Force-set gtags current working directory to the kernel source tree.
+
+Due to commit 9da0763bdd82 ("kbuild: Use relative path when building in
+a subdir of the source tree"), if the kernel build is done in a
+sub-directory of the kernel source tree, the kernel Makefile will set
+the kernel's $srctree to ".." for shorter compile-time and run-time
+warnings. Consequently, the list of files to be indexed will be in the
+"../*" form, rendering all such paths invalid once gtags switches to the
+kernel source tree as its current working directory.
+
+If gtags indexing is requested and the build directory is not the kernel
+source tree, index all files in absolute-path form.
+
+Note, indexing in absolute-path form will not affect the generated
+index, as paths in gtags indices are always relative to the gtags "root
+directory" anyway (as evidenced by "gtags --dump").
+
+Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ scripts/tags.sh | 9 ++++++++-
+ 1 file changed, 8 insertions(+), 1 deletion(-)
+
+--- a/scripts/tags.sh
++++ b/scripts/tags.sh
+@@ -25,6 +25,13 @@ else
+ tree=${srctree}/
+ fi
+
++# gtags(1) refuses to index any file outside of its current working dir.
++# If gtags indexing is requested and the build output directory is not
++# the kernel source tree, index all files in absolute-path form.
++if [[ "$1" == "gtags" && -n "${tree}" ]]; then
++ tree=$(realpath "$tree")/
++fi
++
+ # Detect if ALLSOURCE_ARCHS is set. If not, we assume SRCARCH
+ if [ "${ALLSOURCE_ARCHS}" = "" ]; then
+ ALLSOURCE_ARCHS=${SRCARCH}
+@@ -124,7 +131,7 @@ docscope()
+
+ dogtags()
+ {
+- all_target_sources | gtags -i -f -
++ all_target_sources | gtags -i -C "${tree:-.}" -f - "$PWD"
+ }
+
+ # Basic regular expressions with an optional /kind-spec/ for ctags and
pci-acpi-validate-acpi_pci_set_power_state-parameter.patch
pci-acpi-call-_reg-when-transitioning-d-states.patch
execve-always-mark-stack-as-growing-down-during-early-stack-setup.patch
+nubus-partially-revert-proc_create_single_data-conversion.patch
+perf-symbols-symbol-lookup-with-kcore-can-fail-if-multiple-segments-match-stext.patch
+scripts-tags.sh-resolve-gtags-empty-index-generation.patch
+docs-set-minimal-gtags-gnu-global-version-to-6.6.5.patch
+drm-amdgpu-validate-vm-ioctl-flags.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
