--- /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
+@@ -3274,6 +3274,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 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
+@@ -1357,10 +1357,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
+@@ -32,6 +32,13 @@ else
+ ignore="$ignore ( -path ${tree}tools ) -prune -o"
+ 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}
+@@ -131,7 +138,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
hid-wacom-use-ktime_t-rather-than-int-when-dealing-with-timestamps.patch
hid-logitech-hidpp-add-hidpp_quirk_delayed_init-for-the-t651.patch
revert-thermal-drivers-mediatek-use-devm_of_iomap-to-avoid-resource-leak-in-mtk_thermal_probe.patch
+perf-symbols-symbol-lookup-with-kcore-can-fail-if-multiple-segments-match-stext.patch
+scripts-tags.sh-resolve-gtags-empty-index-generation.patch
+drm-amdgpu-validate-vm-ioctl-flags.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
