All of lore.kernel.org
 help / color / mirror / Atom feed
From: Karl Mehltretter <kmehltretter@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@armlinux.org.uk>,
	 Nicolas Pitre <npitre@baylibre.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	 Robin Murphy <robin.murphy@arm.com>,
	iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
	 linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ARM: dma-mapping: split cache maintenance at highmem boundary
Date: Thu, 10 Sep 2026 08:24:45 +0200	[thread overview]
Message-ID: <aqJJ5fQ60Nm6xf5G@gmail.com> (raw)
In-Reply-To: <ff220a24-edae-4b75-9873-1a58f5948a01@app.fastmail.com>

On Wed, Sep 09, 2026 at 09:24:23AM +0100, Arnd Bergmann wrote:
> I can see how the fix addresses the problem, but I don't yet see
> how you can arrive in this situation. What type of memory allocation
> can produce a physically contiguous page range from multiple
> zones?
> 

Hi Arnd,

You're right that a buddy allocation cannot span zones. I found this issue
during code review while investigating another ARM DMA issue. I plan to
post a patch for that soon.

My Pi test deliberately reserved the last lowmem and first highmem pages
in DT. It confirms the crash with a crossing SG entry, but I have not
found an ordinary workload that creates one. I should have made that
clear in the changelog.

In a follow-up QEMU test, sg_alloc_table_from_pages() merged the reserved
pair into one 8192-byte entry. It checks that the pages are physically
adjacent but does not check page_zone().

I also searched a bit for a real-world example. Rockchip's vendor 4.4
boot-logo code looks like a possible case: it builds an SG table from
firmware-reserved pages and calls dma_map_sg() when no display IOMMU is
used. Product logs show the boot-logo feature in use, but I found no
record of its reserved memory crossing the lowmem/highmem boundary.
Such a crossing seems unlikely.

I still think the change is worthwhile. For v2, I will update the
changelog to make the test setup and its limits clear. I may also drop the
Cc: stable tag.

Thanks,
Karl

  reply	other threads:[~2026-09-10  6:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-09  6:44 [PATCH] ARM: dma-mapping: split cache maintenance at highmem boundary Karl Mehltretter
2026-09-09  7:24 ` Arnd Bergmann
2026-09-10  6:24   ` Karl Mehltretter [this message]
2026-09-10 12:53     ` Robin Murphy

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=aqJJ5fQ60Nm6xf5G@gmail.com \
    --to=kmehltretter@gmail.com \
    --cc=arnd@arndb.de \
    --cc=iommu@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=m.szyprowski@samsung.com \
    --cc=npitre@baylibre.com \
    --cc=robin.murphy@arm.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.