<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu/drm/vc4, branch v6.18.48</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.18.48</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.18.48'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-08-09T18:25:23+00:00</updated>
<entry>
<title>drm/vc4: Zero the tile state data array before each BIN job</title>
<updated>2026-08-09T18:25:23+00:00</updated>
<author>
<name>Maíra Canal</name>
<email>mcanal@igalia.com</email>
</author>
<published>2026-07-27T14:32:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=57667eb7548faaac396c6e39f3b4444dab5b097c'/>
<id>urn:sha1:57667eb7548faaac396c6e39f3b4444dab5b097c</id>
<content type='text'>
commit 48a570c964d8e37d353381e4195106277e17f5cb upstream.

The binner BO is a single 16MB buffer split into 512KB slots that are
handed out to jobs at submission time and recycled as jobs complete,
without ever being cleared. Each slot holds the job's Tile State Data
Array (TSDA) at its start, followed by the tile allocation pool.

While the tile allocation pool is only walked by the render thread
through branches the binner generated during the current job, the
TSDA is the PTB's own per-tile bookkeeping and is consumed by the
hardware itself. Although the kernel sets the "Auto-initialise Tile
State Data Array" flag in the tile binning mode configuration, the
PTB demonstrably still acts on stale tile state left by the slot's
previous user: the binner ends up creating invalid command streams
with invalid primitive streams and branches, which can cause GPU hangs
as observed in [1][2].

Zero the TSDA when the job's binning slot is configured. This clears
48 bytes per tile (~24KB for a 1080p frame) in the submission path, and
guarantees the PTB never sees another job's tile state.

The tile count is only checked for being non-zero today, so the 8-bit
fields it comes from can describe a tile state array almost six times
larger than the slot it has to live in. Bound it before the slot is
handed out, since such size decides how much of the slot is left for
the tile alloc pool.

Link: https://github.com/raspberrypi/linux/issues/3221 [1]
Link: https://github.com/raspberrypi/linux/issues/5780 [2]
Fixes: 553c942f8b2c ("drm/vc4: Allow using more than 256MB of CMA memory.")
Cc: stable@vger.kernel.org
Reviewed-by: Iago Toral Quiroga &lt;itoral@igalia.com&gt;
Link: https://patch.msgid.link/20260727-vc4-bin-oom-fixes-v2-2-0d8a5eddc7c9@igalia.com
Signed-off-by: Maíra Canal &lt;mcanal@igalia.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/vc4: Supply the overflow slot size in BPOS, not the whole bin BO size</title>
<updated>2026-08-09T18:25:22+00:00</updated>
<author>
<name>Jose Maria Casanova Crespo</name>
<email>jmcasanova@igalia.com</email>
</author>
<published>2026-07-27T14:32:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6cd5acf6f87c073622bd61e38fe99c47365cda9c'/>
<id>urn:sha1:6cd5acf6f87c073622bd61e38fe99c47365cda9c</id>
<content type='text'>
commit 6395789e4739aa5177bbec0fa0f07ccc38d249b0 upstream.

vc4_overflow_mem_work() points BPOA at a 512KB slot inside the 16MB
binner BO, but writes the size of the whole BO to BPOS. On every binner
out-of-memory event the PTB is therefore authorized to write tile lists
across all the other slots (which may hold the tile state, tile alloc and
overflow memory of in-flight jobs) and, for any slot but the first, past
the end of the binner BO into unrelated CMA memory.

Since CMA pages are recycled into page cache and user allocations, this
is arbitrary memory corruption by GPU DMA. In practice it shows up as GPU
hangs with corrupted control list pointers, userspace heap corruption, a
GPU that stays permanently wedged after the first hang, and occasional
full system crashes, whenever a job overflows the initial binner slot.

The bug dates back to the conversion from a dedicated overflow BO (where
writing the full BO size was correct) to the slotted binner BO.

Fixes: 553c942f8b2c ("drm/vc4: Allow using more than 256MB of CMA memory.")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-4.8
Signed-off-by: Jose Maria Casanova Crespo &lt;jmcasanova@igalia.com&gt;
Reviewed-by: Maíra Canal &lt;mcanal@igalia.com&gt;
Reviewed-by: Iago Toral Quiroga &lt;itoral@igalia.com&gt;
Link: https://patch.msgid.link/20260727-vc4-bin-oom-fixes-v2-1-0d8a5eddc7c9@igalia.com
Signed-off-by: Maíra Canal &lt;mcanal@igalia.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/vc4: Prevent shader BO mappings from becoming writable</title>
<updated>2026-08-03T09:21:53+00:00</updated>
<author>
<name>Linmao Li</name>
<email>lilinmao@kylinos.cn</email>
</author>
<published>2026-07-21T01:15:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6deaa317201851c644c431b57682e54d06b35838'/>
<id>urn:sha1:6deaa317201851c644c431b57682e54d06b35838</id>
<content type='text'>
commit 0c9e6367639548307d3f578f6943ce72c9d39087 upstream.

vc4_gem_object_mmap() rejects a writable mapping of a validated shader
BO, but leaves VM_MAYWRITE set.  Userspace can map the BO read-only and
then turn it writable with mprotect().

Validated shader BOs must stay read-only: the validator checks the
instructions once and the GPU trusts them afterwards.  A writable
mapping lets userspace rewrite the code after validation, bypassing the
validator.

Clear VM_MAYWRITE on the read-only path so the mapping cannot be
upgraded, as i915 already does for its read-only objects.

Fixes: 463873d57014 ("drm/vc4: Add an API for creating GPU shaders in GEM BOs.")
Cc: stable@vger.kernel.org
Reported-by: Sashiko &lt;sashiko-bot@kernel.org&gt;
Closes: https://lore.kernel.org/dri-devel/20260720085554.B0AF01F000E9@smtp.kernel.org/
Signed-off-by: Linmao Li &lt;lilinmao@kylinos.cn&gt;
Link: https://patch.msgid.link/20260721011558.1672477-1-lilinmao@kylinos.cn
Reviewed-by: Maíra Canal &lt;mcanal@igalia.com&gt;
Signed-off-by: Maíra Canal &lt;mcanal@igalia.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/vc4: Shut down BO cache timer before teardown</title>
<updated>2026-08-03T09:21:53+00:00</updated>
<author>
<name>Linmao Li</name>
<email>lilinmao@kylinos.cn</email>
</author>
<published>2026-07-20T08:44:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a38f2724eb93a78ba250b01e0caf3468df4d3956'/>
<id>urn:sha1:a38f2724eb93a78ba250b01e0caf3468df4d3956</id>
<content type='text'>
commit 6273dd3ffb54ec581855b82ae77331b66028249c upstream.

The BO cache timer callback schedules time_work, and time_work can rearm
the timer through vc4_bo_cache_free_old().

vc4_bo_cache_destroy() deletes the timer and then cancels the work, which
does not break that cycle: the work being cancelled can rearm the timer,
and the timer then queues work again after teardown.

Use timer_shutdown_sync() instead, so the timer cannot be rearmed and the
cycle ends with cancel_work_sync().

Fixes: c826a6e10644 ("drm/vc4: Add a BO cache.")
Cc: stable@vger.kernel.org
Signed-off-by: Linmao Li &lt;lilinmao@kylinos.cn&gt;
Link: https://patch.msgid.link/20260720084426.1632508-1-lilinmao@kylinos.cn
Reviewed-by: Maíra Canal &lt;mcanal@igalia.com&gt;
Signed-off-by: Maíra Canal &lt;mcanal@igalia.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/vc4: fix krealloc() memory leak</title>
<updated>2026-06-19T11:44:02+00:00</updated>
<author>
<name>Alexander A. Klimov</name>
<email>grandmaster@al2klimov.de</email>
</author>
<published>2026-06-06T12:38:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=02f5e4db57c0cdd7bac89d503b301a093a0fa95c'/>
<id>urn:sha1:02f5e4db57c0cdd7bac89d503b301a093a0fa95c</id>
<content type='text'>
[ Upstream commit 5d563a5da8717629ae72f9eadf1e0e340bd1658b ]

Don't just overwrite the original pointer passed to krealloc()
with its return value without checking latter:

    MEM = krealloc(MEM, SZ, GFP);

If krealloc() returns NULL, that erases the pointer
to the still allocated memory, hence leaks this memory.
Instead, use a temporary variable, check it's not NULL
and only then assign it to the original pointer:

    TMP = krealloc(MEM, SZ, GFP);
    if (!TMP) return;
    MEM = TMP;

While on it, use krealloc_array().

Fixes: 6d45c81d229d ("drm/vc4: Add support for branching in shader validation.")
Signed-off-by: Alexander A. Klimov &lt;grandmaster@al2klimov.de&gt;
Signed-off-by: Maíra Canal &lt;mcanal@igalia.com&gt;
Link: https://patch.msgid.link/20260606123817.37222-1-grandmaster@al2klimov.de
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/vc4: platform_get_irq_byname() returns an int</title>
<updated>2026-04-22T11:22:26+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2026-02-23T15:53:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0185e0494a561edfc482507f9de89c2ad798b33d'/>
<id>urn:sha1:0185e0494a561edfc482507f9de89c2ad798b33d</id>
<content type='text'>
commit e597a809a2b97e927060ba182f58eb3e6101bc70 upstream.

platform_get_irq_byname() will return a negative value if an error
happens, so it should be checked and not just passed directly into
devm_request_threaded_irq() hoping all will be ok.

Cc: Maxime Ripard &lt;mripard@kernel.org&gt;
Cc: Dave Stevenson &lt;dave.stevenson@raspberrypi.com&gt;
Cc: Maíra Canal &lt;mcanal@igalia.com&gt;
Cc: Raspberry Pi Kernel Maintenance &lt;kernel-list@raspberrypi.com&gt;
Cc: Maarten Lankhorst &lt;maarten.lankhorst@linux.intel.com&gt;
Cc: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
Cc: David Airlie &lt;airlied@gmail.com&gt;
Cc: Simona Vetter &lt;simona@ffwll.ch&gt;
Cc: stable &lt;stable@kernel.org&gt;
Assisted-by: gkh_clanker_2000
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Link: https://patch.msgid.link/2026022339-cornflake-t-shirt-2471@gregkh
Signed-off-by: Maíra Canal &lt;mcanal@igalia.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/vc4: Protect madv read in vc4_gem_object_mmap() with madv_lock</title>
<updated>2026-04-22T11:22:19+00:00</updated>
<author>
<name>Maíra Canal</name>
<email>mcanal@igalia.com</email>
</author>
<published>2026-03-30T17:51:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0cf8ea9d677b638e650014f28ed588dbabac2cc7'/>
<id>urn:sha1:0cf8ea9d677b638e650014f28ed588dbabac2cc7</id>
<content type='text'>
[ Upstream commit 338c56050d8e892604da97f67bfa8cc4015a955f ]

The mmap callback reads bo-&gt;madv without holding madv_lock, racing with
concurrent DRM_IOCTL_VC4_GEM_MADVISE calls that modify the field under
the same lock. Add the missing locking to prevent the data race.

Fixes: b9f19259b84d ("drm/vc4: Add the DRM_IOCTL_VC4_GEM_MADVISE ioctl")
Reviewed-by: Melissa Wen &lt;mwen@igalia.com&gt;
Link: https://patch.msgid.link/20260330-vc4-misc-fixes-v1-4-92defc940a29@igalia.com
Signed-off-by: Maíra Canal &lt;mcanal@igalia.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/vc4: Fix a memory leak in hang state error path</title>
<updated>2026-04-22T11:22:19+00:00</updated>
<author>
<name>Maíra Canal</name>
<email>mcanal@igalia.com</email>
</author>
<published>2026-03-30T17:51:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e352e9adc9f6df54d63150ff832f71c04e30744b'/>
<id>urn:sha1:e352e9adc9f6df54d63150ff832f71c04e30744b</id>
<content type='text'>
[ Upstream commit 9525d169e5fd481538cf8c663cc5839e54f2e481 ]

When vc4_save_hang_state() encounters an early return condition, it
returns without freeing the previously allocated `kernel_state`,
leaking memory.

Add the missing kfree() calls by consolidating the early return paths
into a single place.

Fixes: 214613656b51 ("drm/vc4: Add an interface for capturing the GPU state after a hang.")
Reviewed-by: Melissa Wen &lt;mwen@igalia.com&gt;
Link: https://patch.msgid.link/20260330-vc4-misc-fixes-v1-3-92defc940a29@igalia.com
Signed-off-by: Maíra Canal &lt;mcanal@igalia.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/vc4: Fix memory leak of BO array in hang state</title>
<updated>2026-04-22T11:22:18+00:00</updated>
<author>
<name>Maíra Canal</name>
<email>mcanal@igalia.com</email>
</author>
<published>2026-03-30T17:51:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=421cea4f71f7cf65abaae878562ee4aa2b684628'/>
<id>urn:sha1:421cea4f71f7cf65abaae878562ee4aa2b684628</id>
<content type='text'>
[ Upstream commit f4dfd6847b3e5d24e336bca6057485116d17aea4 ]

The hang state's BO array is allocated separately with kzalloc() in
vc4_save_hang_state() but never freed in vc4_free_hang_state(). Add the
missing kfree() for the BO array before freeing the hang state struct.

Fixes: 214613656b51 ("drm/vc4: Add an interface for capturing the GPU state after a hang.")
Reviewed-by: Melissa Wen &lt;mwen@igalia.com&gt;
Link: https://patch.msgid.link/20260330-vc4-misc-fixes-v1-2-92defc940a29@igalia.com
Signed-off-by: Maíra Canal &lt;mcanal@igalia.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/vc4: Release runtime PM reference after binding V3D</title>
<updated>2026-04-22T11:22:18+00:00</updated>
<author>
<name>Maíra Canal</name>
<email>mcanal@igalia.com</email>
</author>
<published>2026-03-30T17:51:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ce12a1af6779cee2f97c42631b4a15becbeea926'/>
<id>urn:sha1:ce12a1af6779cee2f97c42631b4a15becbeea926</id>
<content type='text'>
[ Upstream commit aaefbdde9abdc43699e110679c0e10972a5e1c59 ]

The vc4_v3d_bind() function acquires a runtime PM reference via
pm_runtime_resume_and_get() to access V3D registers during setup.
However, this reference is never released after a successful bind.
This prevents the device from ever runtime suspending, since the
reference count never reaches zero.

Release the runtime PM reference by adding pm_runtime_put_autosuspend()
after autosuspend is configured, allowing the device to runtime suspend
after the delay.

Fixes: 266cff37d7fc ("drm/vc4: v3d: Rework the runtime_pm setup")
Reviewed-by: Melissa Wen &lt;mwen@igalia.com&gt;
Link: https://patch.msgid.link/20260330-vc4-misc-fixes-v1-1-92defc940a29@igalia.com
Signed-off-by: Maíra Canal &lt;mcanal@igalia.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
