All of lore.kernel.org
 help / color / mirror / Atom feed
From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Lorenzo Stoakes <ljs@kernel.org>,
	 "Liam R. Howlett" <liam@infradead.org>,
	Vlastimil Babka <vbabka@kernel.org>,
	 Mike Rapoport <rppt@kernel.org>,
	Suren Baghdasaryan <surenb@google.com>,
	 Michal Hocko <mhocko@suse.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	 Willy Tarreau <w@1wt.eu>,
	Jani Nikula <jani.nikula@linux.intel.com>,
	 Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	 Rodrigo Vivi <rodrigo.vivi@intel.com>,
	 Tvrtko Ursulin <tursulin@ursulin.net>,
	David Airlie <airlied@gmail.com>,
	 Simona Vetter <simona@ffwll.ch>,
	Chris Wilson <chris@chris-wilson.co.uk>,
	 Matthew Auld <matthew.auld@intel.com>,
	 Madhavan Srinivasan <maddy@linux.ibm.com>,
	 Michael Ellerman <mpe@ellerman.id.au>,
	Nicholas Piggin <npiggin@gmail.com>,
	 "Christophe Leroy (CS GROUP)" <chleroy@kernel.org>,
	 "Ritesh Harjani (IBM)" <ritesh.list@gmail.com>,
	 Shrikanth Hegde <sshegde@linux.ibm.com>,
	Rik van Riel <riel@redhat.com>,
	 Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	 intel-gfx@lists.freedesktop.org,
	dri-devel@lists.freedesktop.org,  linuxppc-dev@lists.ozlabs.org,
	"David Hildenbrand (Arm)" <david@kernel.org>,
	 stable@vger.kernel.org
Subject: [PATCH 4/5] powerpc/spufs: consider vm_pgoff in spufs_mem_mmap_access()
Date: Thu, 12 Nov 2026 23:09:00 +0100	[thread overview]
Message-ID: <20261112-access_shite-v1-4-988a5c470db2@kernel.org> (raw)
In-Reply-To: <20261112-access_shite-v1-0-988a5c470db2@kernel.org>

spufs_mem_mmap_access() calculates the local store offset relative to the
start of the VMA and ignores vm_pgoff. After VMA splits, debugger reads and
writes access the wrong part of the local store. Mappings created with a
nonzero file offset have the same problem.

Properly take the vm_pgoff into account, just like spufs_mem_mmap_fault()
already does.

Fixes: a352894d0705 ("spufs: use new vm_ops->access to allow local state access from gdb")
Cc: stable@vger.kernel.org
Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
---
 arch/powerpc/platforms/cell/spufs/file.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/cell/spufs/file.c b/arch/powerpc/platforms/cell/spufs/file.c
index 98c47bafaf678..0a46d6f7178ab 100644
--- a/arch/powerpc/platforms/cell/spufs/file.c
+++ b/arch/powerpc/platforms/cell/spufs/file.c
@@ -248,7 +248,8 @@ static int spufs_mem_mmap_access(struct vm_area_struct *vma,
 				void *buf, int len, int write)
 {
 	struct spu_context *ctx = vma->vm_file->private_data;
-	unsigned long offset = address - vma->vm_start;
+	unsigned long offset = address - vma->vm_start +
+			       (vma->vm_pgoff << PAGE_SHIFT);
 	char *local_store;
 
 	if (write && !(vma->vm_flags & VM_WRITE))

-- 
2.43.0



  parent reply	other threads:[~2026-11-12 22:09 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-12 22:08 [PATCH 0/5] mm,drm/i915,powerpc/spufs: vm_ops->access related fixes David Hildenbrand (Arm)
2026-11-12 22:08 ` [PATCH 1/5] mm: do not call vm_ops->access with FOLL_ANON David Hildenbrand (Arm)
2026-11-14 18:56   ` Lorenzo Stoakes (ARM)
2026-11-12 22:08 ` [PATCH 2/5] drm/i915: consider vm_pgoff in vm_access() David Hildenbrand (Arm)
2026-11-14 18:58   ` Lorenzo Stoakes (ARM)
2026-11-12 22:08 ` [PATCH 3/5] drm/i915/selftests: request read access for mmap access tests David Hildenbrand (Arm)
2026-11-14 18:58   ` Lorenzo Stoakes (ARM)
2026-11-12 22:09 ` David Hildenbrand (Arm) [this message]
2026-11-14 18:59   ` [PATCH 4/5] powerpc/spufs: consider vm_pgoff in spufs_mem_mmap_access() Lorenzo Stoakes (ARM)
2026-11-12 22:09 ` [PATCH 5/5] mm: check permissions and bounds for vm_ops->access David Hildenbrand (Arm)
2026-11-13 20:25   ` Kuehling, Felix
2026-11-13 21:37     ` David Hildenbrand (Arm)
2026-11-14 19:08   ` Lorenzo Stoakes (ARM)
2026-11-13  1:50 ` ✓ i915.CI.BAT: success for mm,drm/i915,powerpc/spufs: vm_ops->access related fixes Patchwork
2026-11-14  3:28 ` ✗ i915.CI.Full: failure " Patchwork
2026-11-14 16:17 ` [PATCH 0/5] " David Hildenbrand (Arm)

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=20261112-access_shite-v1-4-988a5c470db2@kernel.org \
    --to=david@kernel.org \
    --cc=airlied@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=benh@kernel.crashing.org \
    --cc=chleroy@kernel.org \
    --cc=chris@chris-wilson.co.uk \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=liam@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=ljs@kernel.org \
    --cc=maddy@linux.ibm.com \
    --cc=matthew.auld@intel.com \
    --cc=mhocko@suse.com \
    --cc=mpe@ellerman.id.au \
    --cc=npiggin@gmail.com \
    --cc=riel@redhat.com \
    --cc=ritesh.list@gmail.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=rppt@kernel.org \
    --cc=simona@ffwll.ch \
    --cc=sshegde@linux.ibm.com \
    --cc=stable@vger.kernel.org \
    --cc=surenb@google.com \
    --cc=tursulin@ursulin.net \
    --cc=vbabka@kernel.org \
    --cc=w@1wt.eu \
    /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.