mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Bert Karwatzki <spasswolf@web.de>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "Christian König" <christian.koenig@amd.com>,
	"Balbir Singh" <balbirs@nvidia.com>,
	"Ingo Molnar" <mingo@kernel.org>, "Kees Cook" <kees@kernel.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Andy Lutomirski" <luto@kernel.org>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	linux-kernel@vger.kernel.org, amd-gfx@lists.freedesktop.org,
	spasswolf@web.de
Subject: Re: commit 7ffb791423c7 breaks steam game
Date: Thu, 27 Mar 2025 01:58:14 +0100	[thread overview]
Message-ID: <2d547eae6f031943101d7fb10b815bc128995125.camel@web.de> (raw)
In-Reply-To: <CAHk-=wh5Suzp0z7AnK0NgSKfEAWQJw7Dgv5eku=rzBuM1ugQDg@mail.gmail.com>

Am Mittwoch, dem 26.03.2025 um 15:58 -0700 schrieb Linus Torvalds:
> On Wed, 26 Mar 2025 at 15:00, Bert Karwatzki <spasswolf@web.de> wrote:
> >
> > As Balbir Singh found out this memory comes from amdkfd
> > (kgd2kfd_init_zone_device()) with CONFIG_HSA_AMD_SVM=y. The memory gets placed
> > by devm_request_free_mem_region() which places the memory at the end of the
> > physical address space (DIRECT_MAP_PHYSMEM_END). DIRECT_MAP_PHYSMEM_END changes
> > when using nokaslr and so the memory shifts.
>
> So I just want to say that having followed the thread as a spectator,
> big kudos to everybody involved in this thing. Particularly to you,
> Bart, for all your debugging and testing, and to Balbir for following
> up and figuring it out.
>
> Because this was a strange one.
>
> >  One can work around this by removing the GFR_DESCENDING flag from
> > devm_request_free_mem_region() so the memory gets placed right after the other
> > resources:
>
> I worry that there might be other machines where that completely breaks things.
>
> There are various historical reasons why we look for addresses in high
> regions, ie on machines where there are various hidden IO regions that
> aren't enumerated by e280 and aren't found by our usual PCI BAR
> discovery because they are special hidden ones.
>
> So then users of [devm_]request_free_mem_region() might end up getting
> allocated a region that has some magic system resource in it.
>
> And no, this shouldn't happen on any normal machine, but it has
> definitely been a thing in the past.
>
> So I'm very happy that you guys figured out what ended up happening,
> but I'm not convinced that the devm_request_free_mem_region()
> workaround is tenable.
>
> So I think it needs to be more targeted to the HSA_AMD_SVM case than
> touch the devm_request_free_mem_region() logic for everybody.
>
>            Linus

This patch adds another function devm_request_free_mem_region_from_end()
with an additional argument which allows to choose the end address from
which to place the resource.
The problem here is this uses dma_get_mask(adev->dev) as end address which
uses the dma mask for the discrete GPU while it should use the dma mask for
the built-in GPU (In my case both are equal (44bits), but I'm not sure if
this is always the case)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
index d05d199b5e44..e1942fef3637 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
@@ -1042,7 +1042,8 @@ int kgd2kfd_init_zone_device(struct amdgpu_device *adev)
 		pgmap->range.end = adev->gmc.aper_base + adev->gmc.aper_size -
1;
 		pgmap->type = MEMORY_DEVICE_COHERENT;
 	} else {
-		res = devm_request_free_mem_region(adev->dev, &iomem_resource,
size);
+		res = devm_request_free_mem_region_from_end(adev->dev,
+				&iomem_resource, size, dma_get_mask(adev-
>dev));
 		if (IS_ERR(res))
 			return PTR_ERR(res);
 		pgmap->range.start = res->start;
diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index 5385349f0b8a..a9a765721ab4 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -407,6 +407,9 @@ walk_iomem_res_desc(unsigned long desc, unsigned long flags,
u64 start, u64 end,

 struct resource *devm_request_free_mem_region(struct device *dev,
 		struct resource *base, unsigned long size);
+struct resource *devm_request_free_mem_region_from_end(struct device *dev,
+		struct resource *base, unsigned long size,
+		resource_size_t seek_end);
 struct resource *request_free_mem_region(struct resource *base,
 		unsigned long size, const char *name);
 struct resource *alloc_free_mem_region(struct resource *base,
diff --git a/kernel/resource.c b/kernel/resource.c
index 12004452d999..82f40407c02d 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -1875,12 +1875,14 @@ EXPORT_SYMBOL(resource_list_free);
 #endif

 static resource_size_t gfr_start(struct resource *base, resource_size_t size,
-				 resource_size_t align, unsigned long flags)
+				 resource_size_t align, resource_size_t
seek_end,
+				 unsigned long flags)
 {
 	if (flags & GFR_DESCENDING) {
 		resource_size_t end;

 		end = min_t(resource_size_t, base->end,
DIRECT_MAP_PHYSMEM_END);
+		end = min_t(resource_size_t, end, seek_end);
 		return end - size + 1;
 	}

@@ -1920,8 +1922,8 @@ static void remove_free_mem_region(void *_res)
 static struct resource *
 get_free_mem_region(struct device *dev, struct resource *base,
 		    resource_size_t size, const unsigned long align,
-		    const char *name, const unsigned long desc,
-		    const unsigned long flags)
+		    resource_size_t seek_end, const char *name,
+		    const unsigned long desc, const unsigned long flags)
 {
 	resource_size_t addr;
 	struct resource *res;
@@ -1946,7 +1948,7 @@ get_free_mem_region(struct device *dev, struct resource
*base,
 	}

 	write_lock(&resource_lock);
-	for (addr = gfr_start(base, size, align, flags);
+	for (addr = gfr_start(base, size, align, seek_end, flags);
 	     gfr_continue(base, addr, align, flags);
 	     addr = gfr_next(addr, align, flags)) {
 		if (__region_intersects(base, addr, size, 0, IORES_DESC_NONE)
!=
@@ -2021,17 +2023,30 @@ struct resource *devm_request_free_mem_region(struct
device *dev,
 	unsigned long flags = GFR_DESCENDING | GFR_REQUEST_REGION;

 	return get_free_mem_region(dev, base, size, GFR_DEFAULT_ALIGN,
-				   dev_name(dev),
+				   DIRECT_MAP_PHYSMEM_END, dev_name(dev),
 				   IORES_DESC_DEVICE_PRIVATE_MEMORY, flags);
 }
 EXPORT_SYMBOL_GPL(devm_request_free_mem_region);

+struct resource *devm_request_free_mem_region_from_end(struct device *dev,
+		struct resource *base, unsigned long size,
+		resource_size_t seek_end)
+{
+	unsigned long flags = GFR_DESCENDING | GFR_REQUEST_REGION;
+
+	return get_free_mem_region(dev, base, size, GFR_DEFAULT_ALIGN,
+				   seek_end, dev_name(dev),
+				   IORES_DESC_DEVICE_PRIVATE_MEMORY, flags);
+}
+EXPORT_SYMBOL_GPL(devm_request_free_mem_region_from_end);
+
 struct resource *request_free_mem_region(struct resource *base,
 		unsigned long size, const char *name)
 {
 	unsigned long flags = GFR_DESCENDING | GFR_REQUEST_REGION;

-	return get_free_mem_region(NULL, base, size, GFR_DEFAULT_ALIGN, name,
+	return get_free_mem_region(NULL, base, size, GFR_DEFAULT_ALIGN,
+				   DIRECT_MAP_PHYSMEM_END, name,
 				   IORES_DESC_DEVICE_PRIVATE_MEMORY, flags);
 }
 EXPORT_SYMBOL_GPL(request_free_mem_region);
@@ -2055,8 +2070,8 @@ struct resource *alloc_free_mem_region(struct resource
*base,
 	/* Default of ascending direction and insert resource */
 	unsigned long flags = 0;

-	return get_free_mem_region(NULL, base, size, align, name,
-				   IORES_DESC_NONE, flags);
+	return get_free_mem_region(NULL, base, size, align,
DIRECT_MAP_PHYSMEM_END,
+				   name, IORES_DESC_NONE, flags);
 }
 EXPORT_SYMBOL_GPL(alloc_free_mem_region);
 #endif /* CONFIG_GET_FREE_REGION */



Bert Karwatzki

  parent reply	other threads:[~2025-03-27  0:58 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-25 10:14 Bert Karwatzki
2025-03-25 12:23 ` Christian König
2025-03-26 22:00   ` Bert Karwatzki
2025-03-26 22:58     ` Linus Torvalds
2025-03-27  0:57       ` Balbir Singh
2025-03-27  0:58       ` Bert Karwatzki [this message]
2025-03-27 10:40       ` Ingo Molnar
  -- strict thread matches above, loose matches on Subject: below --
2025-03-24 23:07 Bert Karwatzki
     [not found] ` <634e77d7-4f3c-4d1a-8aa3-1978896f9bf2@amd.com>
2025-03-25 10:25   ` Balbir Singh
2025-03-22 12:23 Bert Karwatzki
2025-03-23  6:51 ` Balbir Singh
2025-03-24 11:23   ` Bert Karwatzki
2025-03-24 12:14     ` Christian König
2025-03-24 22:48       ` Balbir Singh
     [not found]         ` <938c2cbd-c47f-4925-ba82-94eef54d9ebc@amd.com>
2025-03-25 22:45           ` Balbir Singh
2025-03-25 23:21             ` Bert Karwatzki
2025-03-25 23:43               ` Balbir Singh
2025-03-26  1:50                 ` Balbir Singh
2025-03-26 10:10                   ` Bert Karwatzki
2025-03-26 10:36                     ` Balbir Singh
2025-03-26 11:14                       ` Bert Karwatzki
2025-03-27 10:53                       ` Ingo Molnar
2025-03-27 22:03                         ` Balbir Singh
2025-03-24 21:43     ` Balbir Singh
2025-03-10 11:22 Bert Karwatzki
2025-03-10 21:48 ` Balbir Singh
2025-03-11  7:19   ` Balbir Singh
2025-03-11  7:28     ` Ingo Molnar
2025-03-11 11:15     ` Bert Karwatzki
2025-03-11 18:24       ` Bert Karwatzki
2025-03-11 22:10         ` Balbir Singh
2025-03-11 23:09           ` Bert Karwatzki
2025-03-12  0:26             ` Bert Karwatzki
2025-03-12  2:23               ` Balbir Singh
2025-03-12  1:24             ` Balbir Singh
2025-03-13  9:22               ` Bert Karwatzki
2025-03-13 10:40                 ` Balbir Singh
2025-03-13 10:53                   ` Bert Karwatzki
2025-03-13 11:47                     ` Balbir Singh
2025-03-13 18:12                       ` Bert Karwatzki
2025-03-13 21:54                         ` Balbir Singh
2025-03-13 22:22                           ` Bert Karwatzki
2025-03-14  6:14                             ` Balbir Singh
2025-03-14 13:34                               ` Balbir Singh
2025-03-14 14:18                                 ` Bert Karwatzki
2025-03-15  0:16                                   ` Balbir Singh
2025-03-15 17:40                                     ` Alex Deucher
2025-03-16 13:09                                       ` Bert Karwatzki
2025-03-16 20:06                                         ` Bert Karwatzki
2025-03-17  9:13                                         ` Balbir Singh
2025-03-20  9:01                                           ` Ingo Molnar
2025-03-20 23:55                                             ` Balbir Singh
2025-03-21 10:24                                               ` Ingo Molnar
2025-03-21 11:05                                                 ` Balbir Singh
2025-03-22  8:04                                                   ` Ingo Molnar
2025-03-22  9:40                                                     ` Balbir Singh
2025-03-20 23:43                                           ` Bert Karwatzki
2025-03-21  4:55                                             ` Balbir Singh
2025-03-21 12:26                                               ` Bert Karwatzki
2025-03-22  2:06                                                 ` Balbir Singh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2d547eae6f031943101d7fb10b815bc128995125.camel@web.de \
    --to=spasswolf@web.de \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=balbirs@nvidia.com \
    --cc=bhelgaas@google.com \
    --cc=christian.koenig@amd.com \
    --cc=kees@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®